Работа руководителя при создании Интернет-проекта
Приводимые здесь заметки были написаны 30 июня 2000 года. Я набросал их, в основном, для себя, чтобы спокойно резюмировать опыт, полученный при запуске первых Рамблеровских проектов в период его становления как портала.
Запущенных новых проектов тогда еще было не так много (по сравнением со всей суммой 2000 года). Это был, во-первых, проект, который мы внутри называли "Новая голова Рамблера" - на самом деле включавший в себя качественную архитектурную перестройку комплекса. Параллельно и одновременно запускались "Рамблер-Новости". Несколько раньше - в феврале-марте, были "Выборы-2000" и "Политдосье", почти умершие уже летом 2000, т.е. к моменту написания этих заметок. Еще - "Рамблер-Погода" и "Победа на Рамблере".
Де-факто мне пришлось быть ответственным выпускающим руководителем этих проектов (на самом деле совместно с Олегом Бартуновым, но мы так давно работаем вместе, что и сами не всегда понимаем, кто за что отвечает :). Де-факто - потому что формально такой должности тогда в Рамблере не существовало, и шли большие дискуссии - как же вообще надо строить такую работу.
Здесь почти не будет личных оценок и размышлений - почти одни голые факты. Буду рад, если эти заметки пригодятся кому-то из менеджеров, выпускающих (или собирающихся выпускать) новые Интернет-проекты.
Искренне Ваш
Евгений Родичев.После ряда обсуждений возникла мысль предварительно, для ориентировки, описать процесс реализации и запуска проекта. Это реальный опыт, и оргструктура должна хоть как-то с этой реальностью коррелировать.
На самом деле объем работы при реализации проекта весьма велик, наблюдений и мыслей на эту тему накопилось также немало, я здесь попытаюсь тезисно набросать основные линии, которые будут, конечно, нуждаться в дальнейшем осмыслении и уточнении.
Отдельная тема - сама необходимость в ответственном выпускающем, или руководителе проекта, может быть предметом обсуждения. Не исключено, что можно поставить некоторую "фабрику, выпекающую проекты", но пока такого реального опыта нет, и, честно говоря, я лично пока таких путей особо не вижу.
Итак, круг вопросов, которые должен "пропустить через себя" руководитель проекта.
Такова у нас была реальная жизнь.
- Участие в формулировке целей и сути проекта. Хотя сам проект и инициируется, к примеру, Дирекцией, руководитель все же должен глубоко понимать цели, которые при этом ставятся.
- Организация работы по изучению состояния дела вообще - что есть на эту тему в мире, в России, у конкурентов, история вопроса, тенденции развития аналогичных проектов. Здесь, на мой взгляд, необходима не только организация такой работы, но и личное участие - т.е. руководитель лично должен иметь ясное представление о том, как аналогичные проекты выглядят, иметь немного "видение вперед".
- Грубое определение ресурсов, необходимых для реализации проекта, при этом в голове уже начинает складываться первый вариант сетевого графика, хотя и очень приблизительный. Ресурсы здесь такие: источники контента (информационного наполнения), люди, которые обеспечат поставку контента, специалисты по программированию с б.м. детальным пониманием, какие специфические навыки от них потребуются и в каком объеме (скажем, perl, или C++, html и т.п.). Технические средства, на которых будет поставлен проект (тут уже приходится задавать довольно детальные спецификации серверной и сетевой нагрузки и, на этой основе, согласовывать конкретные конфигурации аппаратуры). Далее приходится оценить объем работы дизайна, написания текстов (включая их специфику - к примеру, юридические, или общего плана, или технические типа помощи). Наконец, на этой же стадии руководитель проекта должен продумать процедуру его раскрутки, и, соответственно, уже должен контактировать с PR, рекламными службами, маркетингом.
- Лишь после того как все, перечисленное в предыдущем пункте, достаточно прояснилось, можно приступать к наброскам реального сетевого графика и наполнения его уже конкретными людьми. На этом этапе грубые наметки, выработанные на предыдущем этапе, подвергаются весьма существенным корректировкам, ибо выстраданная "идеальная" схема начинает вступать в соприкосновение с реальной жизнью. Т.е. оказыватеся, что людей, в точности обладающих нужной квалификацией - нету, а есть немного другие, конкретная техника может отсутствовать, и приходится искать заменители, и т.п. Собственно, это все выясняется уже в процессе начала реальной реализации проекта, и таких нестыковок, по моему опыту, немало (собственно, я именно из-этого скептически отношусь к тезису "составили сетевой график, выделили ресурсы, назначили ответственного - и все OK". На Западе все более упорядочено, но и там все не предусмотришь, а уж у нас - то дисков вдруг нет по всей Москве, то еще что... При столкновении с реальной неупорядоченной жизнью планы приходится ломать и корректировать на ходу довольно значительно).
- Наконец, запускается работа программистов и поставщиков контента. В идеале - параллельно. Но программисты с самого начала требуют образцы контента, а контентщики - хотя бы тестово работающие программы, и их можно понять - и тем, и другим нужно наглядное представление того, что делается. Реально руководителю проекта приходится все время поддерживать некоторый баланс в прогрессе как одной, так и другой работы.
- Пока запускается пункт 5, уже настает время продумать то, что я называю "структурой сайта", или "концепцией дизайна". Это довольно мучительный процесс, т.к. он весьма творческий, и требует некоторого времени и покоя, но обязанности координации по п.5 создают уже довольно суетную обстановку. К тому же такая концепция, естественно, обсуждается с очень многими - маргетингом, дизайнерами, программистами, контентентщиками, дирекцией. Не обсуждать - нельзя и бессмысленно, а обсуждение с таким большим количеством заинтересованных сторон дает огромную гору идей, мнений и пожеланий. В конце концов именно руководителю проекта приходится где-то поставить точку и принять окончательное решение, иначе получается бесконечный итерационный процесс, и, по моему опыту, итерации даже не всегда имеют тенденцию к сходимости. Результатом п.6. является выдача заказа дизайнерам.
- Пункты 5 и 6 надо довольно хитро увязать во времени, чтобы 3 составляющих - программы, первый контент и дизайн - поспели, по возможности, одновременно. Это очень непростая и нервная задача, т.к. контент завязан на внешних поставщиков, которым не прикажешь, дизайнеры - люди творческие, а уж про сроки программных разработок и говорить нечего. В конце концов, все три составляющих возникают, и, как тщательно не планируй заранее, выясняется, что вместе они никак не желают стыковаться. Программы, тщательно оттестированные, начинают отчаянно глючить на реальном контенте, html-код, подготовленный дизайнерами опять же на тестах, начинает чудовищно перекашиваться на реальных данных, контент начинает идти такой, что контентщики только руками разводят (самый яркий пример у меня был с погодой, когда направление ветра, имеющее 8 значений (север, северо-восток, восток и т.д) вдруг стало приходить кодированное числами от 1 до 9!). На этом этапе приходится принимать очень много чисто волевых решений, не предусмотренных никакими планами - тут подрубить, тут нарастить, там подвинтить... Цель этого этапа - подготовить проект хоть к какому-то осмысленному тестированию. Да, здесь же необходимо вытрясти почти все необходимые тексты.
- К этому же моменту надо получить окончательно установленное и протестированное железо и правильно сконфигуренное базовое программное обеспечение. Тут окончательное тестирование приходится проводить пока самим - во всяком случае, опять же только руководитель проекта представляет полный список компонент софта и оборудования, которые будут реально задействованы.
- Запустить процесс тестирования. Независимое тестирование абсолютно необходимо, т.к. к этому времени уже все мысли накатаны, и сторонний человек легко замечает грубые ошибки, которые разработчики уже не видят. С другой стороны, руководитель проекта знает слабые места "изнутри", и, в свою очередь может и должен лично проверить все эти слабые места. Я неоднократно буквально поражал своих ведущих программистов, когда в течении одной минуты - с первой же попытки! - находил грубейшие ошибки в кодах, которые они уже тестировали и гоняли по несколько дней. А суть очень простая - именно руководитель проекта лучше всех знает внутренние нестыковки разных кусков, и именно тут выявляет ошибки. Независимое тестирование такие ошибки выявляет плохо.
- Определить реальные сроки тестирования, а, главное, время, необходимое на доработку и устранение выявленных недостатков. Это отдельная песня, т.к., естественно, на то оно и тестирование, что заранее нельзя сказать - как много и сколь трудноустранимых недостатков будет выявлено. A сроки тут определять приходится, т.к. надо уже конкретно ориентировать маркетинг и PR - кампанию по раскрутке проекта. Кроме того, на этом этапе полезно снова проверить планы раскрутки совместно с этими службами, т.к. в процессе разработки что-то всегда хоть немного, да меняется, и планы, сформированные на раннем этапе, нуждаются, как правило, в той или иной корректировке. Пункты 9 и 10 руководитель проекта должен опять же тесно увязывать по времени, что непросто, учитывая уже отмеченный непредсказуемый характер процесса тестирования.
- Запуск. К этому моменту все уже должно быть подготовлено и скоординировано. Если запускается абсолютно новый проект, как в случае с Политдосье, это проще, если же новое запускается взамен старого, на лету - как с головой Рамблера - это становится просто цирковым аттракционом. Для меня это было как запуск космического корабля - счет идет на секунды, никаких дискуссий быть уже не может, все участники проекта в идеале должны быть в состоянии полной готовности, а выпускающий проекта должен по сути мгновенно принимать решения по корректировке или даже отмене процедуры. В этот момент приходится все держать в голове, не нервничать, и адекватно оценивать возникающие неполадки. А они возникают всегда - тестирование в принципе не может выявить всего, что вылезет в реальной эксплуатации.
- Контроль работы запущенного проекта и мер по его раскрутке. Реально, по моему опыту, проект выходит на более-менее стационарное состояние эксплуатации после полутора-двух недель, не раньше. В это время уже целесообразно подключать службу эксплуатации, и обеспечить передачу ей всех дел. Есть мнение (и я его тоже придерживаюсь), что служба эксплуатации должна подключаться сильно раньше, но это мнение пока абстрактное, т.к. в нашем реальном опыте такого пока не было, и я не могу определенно сказать, будет ли такая схема работать.
- Руководитель проекта должен подготовить некоторое празднование по результатам запуска проекта, подведение итогов, должен представить планы по поощрению, премированию или наоборот. Кстати, пока по опыту - как ни планируй, но запуск - это всегда более или менее тяжелый аврал, и непосредственные участники запуска должны получить некоторый отдых. Это тоже обязательно надо отслеживать.
- Не развивающиеся проекты в Интернете не живут, и еще некоторое достаточно длительное время руководитель проекта (уже "бывший") должен по крайненй мере курировать шаги по развитию проекта. Это необходимо для обеспечения его целостности - внешней и внутренней.