Работа руководителя при создании Интернет-проекта

Приводимые здесь заметки были написаны 30 июня 2000 года. Я набросал их, в основном, для себя, чтобы спокойно резюмировать опыт, полученный при запуске первых Рамблеровских проектов в период его становления как портала.

Запущенных новых проектов тогда еще было не так много (по сравнением со всей суммой 2000 года). Это был, во-первых, проект, который мы внутри называли "Новая голова Рамблера" - на самом деле включавший в себя качественную архитектурную перестройку комплекса. Параллельно и одновременно запускались "Рамблер-Новости". Несколько раньше - в феврале-марте, были "Выборы-2000" и "Политдосье", почти умершие уже летом 2000, т.е. к моменту написания этих заметок. Еще - "Рамблер-Погода" и "Победа на Рамблере".

Де-факто мне пришлось быть ответственным выпускающим руководителем этих проектов (на самом деле совместно с Олегом Бартуновым, но мы так давно работаем вместе, что и сами не всегда понимаем, кто за что отвечает :). Де-факто - потому что формально такой должности тогда в Рамблере не существовало, и шли большие дискуссии - как же вообще надо строить такую работу.

Здесь почти не будет личных оценок и размышлений - почти одни голые факты. Буду рад, если эти заметки пригодятся кому-то из менеджеров, выпускающих (или собирающихся выпускать) новые Интернет-проекты.

Искренне Ваш
      Евгений Родичев.

После ряда обсуждений возникла мысль предварительно, для ориентировки, описать процесс реализации и запуска проекта. Это реальный опыт, и оргструктура должна хоть как-то с этой реальностью коррелировать.

На самом деле объем работы при реализации проекта весьма велик, наблюдений и мыслей на эту тему накопилось также немало, я здесь попытаюсь тезисно набросать основные линии, которые будут, конечно, нуждаться в дальнейшем осмыслении и уточнении.

Отдельная тема - сама необходимость в ответственном выпускающем, или руководителе проекта, может быть предметом обсуждения. Не исключено, что можно поставить некоторую "фабрику, выпекающую проекты", но пока такого реального опыта нет, и, честно говоря, я лично пока таких путей особо не вижу.

Итак, круг вопросов, которые должен "пропустить через себя" руководитель проекта.

1. Участие в формулировке целей и сути проекта. Хотя сам проект и инициируется, к примеру, Дирекцией, руководитель все же должен глубоко понимать цели, которые при этом ставятся.

2. Организация работы по изучению состояния дела вообще - что есть на эту тему в мире, в России, у конкурентов, история вопроса, тенденции развития аналогичных проектов. Здесь, на мой взгляд, необходима не только организация такой работы, но и личное участие - т.е. руководитель лично должен иметь ясное представление о том, как аналогичные проекты выглядят, иметь немного "видение вперед".

3. Грубое определение ресурсов, необходимых для реализации проекта, при этом в голове уже начинает складываться первый вариант сетевого графика, хотя и очень приблизительный. Ресурсы здесь такие: источники контента (информационного наполнения), люди, которые обеспечат поставку контента, специалисты по программированию с б.м. детальным пониманием, какие специфические навыки от них потребуются и в каком объеме (скажем, perl, или C++, html и т.п.). Технические средства, на которых будет поставлен проект (тут уже приходится задавать довольно детальные спецификации серверной и сетевой нагрузки и, на этой основе, согласовывать конкретные конфигурации аппаратуры). Далее приходится оценить объем работы дизайна, написания текстов (включая их специфику - к примеру, юридические, или общего плана, или технические типа помощи). Наконец, на этой же стадии руководитель проекта должен продумать процедуру его раскрутки, и, соответственно, уже должен контактировать с PR, рекламными службами, маркетингом.

4. Лишь после того как все, перечисленное в предыдущем пункте, достаточно прояснилось, можно приступать к наброскам реального сетевого графика и наполнения его уже конкретными людьми. На этом этапе грубые наметки, выработанные на предыдущем этапе, подвергаются весьма существенным корректировкам, ибо выстраданная "идеальная" схема начинает вступать в соприкосновение с реальной жизнью. Т.е. оказыватеся, что людей, в точности обладающих нужной квалификацией - нету, а есть немного другие, конкретная техника может отсутствовать, и приходится искать заменители, и т.п. Собственно, это все выясняется уже в процессе начала реальной реализации проекта, и таких нестыковок, по моему опыту, немало (собственно, я именно из-этого скептически отношусь к тезису "составили сетевой график, выделили ресурсы, назначили ответственного - и все OK". На Западе все более упорядочено, но и там все не предусмотришь, а уж у нас - то дисков вдруг нет по всей Москве, то еще что... При столкновении с реальной неупорядоченной жизнью планы приходится ломать и корректировать на ходу довольно значительно).

5. Наконец, запускается работа программистов и поставщиков контента. В идеале - параллельно. Но программисты с самого начала требуют образцы контента, а контентщики - хотя бы тестово работающие программы, и их можно понять - и тем, и другим нужно наглядное представление того, что делается. Реально руководителю проекта приходится все время поддерживать некоторый баланс в прогрессе как одной, так и другой работы.

6. Пока запускается пункт 5, уже настает время продумать то, что я называю "структурой сайта", или "концепцией дизайна". Это довольно мучительный процесс, т.к. он весьма творческий, и требует некоторого времени и покоя, но обязанности координации по п.5 создают уже довольно суетную обстановку. К тому же такая концепция, естественно, обсуждается с очень многими - маргетингом, дизайнерами, программистами, контентентщиками, дирекцией. Не обсуждать - нельзя и бессмысленно, а обсуждение с таким большим количеством заинтересованных сторон дает огромную гору идей, мнений и пожеланий. В конце концов именно руководителю проекта приходится где-то поставить точку и принять окончательное решение, иначе получается бесконечный итерационный процесс, и, по моему опыту, итерации даже не всегда имеют тенденцию к сходимости. Результатом п.6. является выдача заказа дизайнерам.

7. Пункты 5 и 6 надо довольно хитро увязать во времени, чтобы 3 составляющих - программы, первый контент и дизайн - поспели, по возможности, одновременно. Это очень непростая и нервная задача, т.к. контент завязан на внешних поставщиков, которым не прикажешь, дизайнеры - люди творческие, а уж про сроки программных разработок и говорить нечего. В конце концов, все три составляющих возникают, и, как тщательно не планируй заранее, выясняется, что вместе они никак не желают стыковаться. Программы, тщательно оттестированные, начинают отчаянно глючить на реальном контенте, html-код, подготовленный дизайнерами опять же на тестах, начинает чудовищно перекашиваться на реальных данных, контент начинает идти такой, что контентщики только руками разводят (самый яркий пример у меня был с погодой, когда направление ветра, имеющее 8 значений (север, северо-восток, восток и т.д) вдруг стало приходить кодированное числами от 1 до 9!). На этом этапе приходится принимать очень много чисто волевых решений, не предусмотренных никакими планами - тут подрубить, тут нарастить, там подвинтить... Цель этого этапа - подготовить проект хоть к какому-то осмысленному тестированию. Да, здесь же необходимо вытрясти почти все необходимые тексты.

8. К этому же моменту надо получить окончательно установленное и протестированное железо и правильно сконфигуренное базовое программное обеспечение. Тут окончательное тестирование приходится проводить пока самим - во всяком случае, опять же только руководитель проекта представляет полный список компонент софта и оборудования, которые будут реально задействованы.

9. Запустить процесс тестирования. Независимое тестирование абсолютно необходимо, т.к. к этому времени уже все мысли накатаны, и сторонний человек легко замечает грубые ошибки, которые разработчики уже не видят. С другой стороны, руководитель проекта знает слабые места "изнутри", и, в свою очередь может и должен лично проверить все эти слабые места. Я неоднократно буквально поражал своих ведущих программистов, когда в течении одной минуты - с первой же попытки! - находил грубейшие ошибки в кодах, которые они уже тестировали и гоняли по несколько дней. А суть очень простая - именно руководитель проекта лучше всех знает внутренние нестыковки разных кусков, и именно тут выявляет ошибки. Независимое тестирование такие ошибки выявляет плохо.

10. Определить реальные сроки тестирования, а, главное, время, необходимое на доработку и устранение выявленных недостатков. Это отдельная песня, т.к., естественно, на то оно и тестирование, что заранее нельзя сказать - как много и сколь трудноустранимых недостатков будет выявлено. A сроки тут определять приходится, т.к. надо уже конкретно ориентировать маркетинг и PR - кампанию по раскрутке проекта. Кроме того, на этом этапе полезно снова проверить планы раскрутки совместно с этими службами, т.к. в процессе разработки что-то всегда хоть немного, да меняется, и планы, сформированные на раннем этапе, нуждаются, как правило, в той или иной корректировке. Пункты 9 и 10 руководитель проекта должен опять же тесно увязывать по времени, что непросто, учитывая уже отмеченный непредсказуемый характер процесса тестирования.

11. Запуск. К этому моменту все уже должно быть подготовлено и скоординировано. Если запускается абсолютно новый проект, как в случае с Политдосье, это проще, если же новое запускается взамен старого, на лету - как с головой Рамблера - это становится просто цирковым аттракционом. Для меня это было как запуск космического корабля - счет идет на секунды, никаких дискуссий быть уже не может, все участники проекта в идеале должны быть в состоянии полной готовности, а выпускающий проекта должен по сути мгновенно принимать решения по корректировке или даже отмене процедуры. В этот момент приходится все держать в голове, не нервничать, и адекватно оценивать возникающие неполадки. А они возникают всегда - тестирование в принципе не может выявить всего, что вылезет в реальной эксплуатации.

12. Контроль работы запущенного проекта и мер по его раскрутке. Реально, по моему опыту, проект выходит на более-менее стационарное состояние эксплуатации после полутора-двух недель, не раньше. В это время уже целесообразно подключать службу эксплуатации, и обеспечить передачу ей всех дел. Есть мнение (и я его тоже придерживаюсь), что служба эксплуатации должна подключаться сильно раньше, но это мнение пока абстрактное, т.к. в нашем реальном опыте такого пока не было, и я не могу определенно сказать, будет ли такая схема работать.

13. Руководитель проекта должен подготовить некоторое празднование по результатам запуска проекта, подведение итогов, должен представить планы по поощрению, премированию или наоборот. Кстати, пока по опыту - как ни планируй, но запуск - это всегда более или менее тяжелый аврал, и непосредственные участники запуска должны получить некоторый отдых. Это тоже обязательно надо отслеживать.

14. Не развивающиеся проекты в Интернете не живут, и еще некоторое достаточно длительное время руководитель проекта (уже "бывший") должен по крайненй мере курировать шаги по развитию проекта. Это необходимо для обеспечения его целостности - внешней и внутренней.

Такова у нас была реальная жизнь.