http://www.ashmanov.com

Отсюда следует второе правило:

Правило 2. Для начала проекта нужно исполнить процедуру запуска проектов.

Процедура запуска весьма проста и включает следующие основные этапы:

• принятие решения об инициации проекта ответственным лицом,
• написание обоснования проекта и оценки затрат на проект,
• назначение руководителя,
• принятие решения о запуске проекта,
• написание руководителем плана работ и принятие его начальством,
• выделение ресурсов.

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

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

На самом деле здесь есть и завуалированное третье решение - принятие плана.

Энтузиасты

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

Правило 3. Без энтузиаста любой проект мертв.

Энтузиаст должен быть готов преодолеть небольшие барьеры, которые ставит перед проектом процедура запуска - убеждение соратников, написание обоснования, получение одобрения руководства на запуск проекта.

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

Обоснование

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

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

Обоснование - первый из таких барьеров.

Обоснование может быть написано тем самым энтузиастом или заказано коммерческому отделу, оно может состоять не из десяти, а всего из двух страниц, но без него нельзя. Если по проекту не удается (или некому) даже написать обоснование, его не нужно начинать. Введем очередное правило:

Правило 4. Проект нельзя обсуждать без обоснования.

Замечу, что обоснование может написать и разработчик, если он является инициатором или сторонником идеи. Не страшно, что он "не понимает в коммерции". Если идея интересная, нужно придать ему коммерсанта для прояснения затрат, рыночных условий, будущей окупаемости.

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

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

Главное - нужна трезвая оценка затрат и рисков. Руководство должно принимать решение, то есть идти на расходы и риск с открытыми глазами.

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

Про виртуальные обоснования будущей рентабельности типа: "объем рынка равен полутора миллиардам долларов, если мы с нашим продуктом займем 0,5%, или даже лучше 1,5%, то это будут громадные деньги..." - даже говорить не хочется.

Руководитель

Далее нужно назначить руководителя. Это может быть то самый энтузиаст или другой менеджер, но руководитель должен быть. Если никто не несет персональную ответственность за проект, то проекта всё равно что нет. Каждый движущийся по дороге автомобиль должен быть снабжен шофером.

Итак, еще одно очень простое правило:

Правило 5. Не бывает проекта без руководителя.

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

Руководитель проекта должен быть назначен как можно раньше.

Руководитель должен быть один

Здесь нужно обязательно отметить, что много ответственных не бывает. Много бывает только безответственных.

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

- Руководитель проекта нужен. Кого назначим?
- Да вот хоть Володя с Максом - один продавец, другой технарь. Как раз разберутся. Да, и пусть Пупкин им поможет с маркетингом.

Это верный путь к провалу или созданию "виртуального" проекта-зомби, который как бы движется. А назначенные Володя, Макс и Пупкин думают, что работа как-то там ведется другими двумя товарищами. У семи нянек...

Правило 6. Руководитель должен быть один.

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

План и ответственность

Основная функция руководителя - планирование, потому что, во-первых, планирование начинается до всякого управления, а во-вторых, план есть квинтэссенция ответственности.

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

Таким образом, если план - это вопрос обязательств и ответственности, то руководитель без плана - лицо безответственное.

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

Работает менеджер много, энергично, письма шлет ежечасно, а вот планов почему-то не пишет. Казалось бы, ну напиши программу действий, утверди у начальства и действуй, что тут сложного? Но ведь на самом деле это вопрос не программы действий, а ответственности!

Следовательно, здесь требуется моральный выбор и принятие рискованного решения - взятие на себя ответственности. И менеджер, часто бессознательно, уклоняется от этой ответственности.

То есть много работать он готов, клясться в верности проекту готов, делать разные обязательные вещи - тоже, а составить план и принять на себя ответственность - нет.

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

Именно поэтому начальные планы так неточны.

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

- Дай уточненный план выпуска бета-версии, наконец! Когда вы действительно ее сделаете, а не так, как в прошлый раз!
- Да я прямо сейчас могу сказать, без писанины - там почти всё готово, скоро выпустим.
- Ну так запиши это кратко на бумаге и поставь даты! Когда точно?
- Да за выходные выпустим. В понедельник точно выпущу.
- Вот и пришли мне письмо с этой датой, и там подробно напиши, что именно будет выпущено. Функциональность и недоделки, которые потом исправите.
- Хорошо, в начале той недели во всем разберусь и пришлю план.
- Как это - план в начале недели?! В понедельник ведь уже должна быть бета, ты же только что сказал!!! План мне нужен сегодня!
- Ну, хорошо, хорошо. Только я сегодня кровь из носу должен собрать промежуточную сборку и отдать тестировщикам (исправить ошибку, съездить к заказчику, написать задание для программистов). А план завтра напишу...

Далее - по индукции. Недели проходят, а уточненного плана всё нет... И бета-версия (сайт, продукт, каталог, сборник) всё в том же положении - почти готова.

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

Правило 7. Проект нельзя запускать без плана, написанного лично руководителем проекта.

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

Конечно, есть и другой метод - спуск плана сверху. Начальством задан срок и требования к проекту, дальше - проси ресурсов (а вот дадут ли их и сколько - это уж как повезет) и работай хоть до четырех утра; по крайней мере, уходи домой позже босса.

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

Несколько раз мне приходилось наблюдать подобные ситуации в разработке ПО, и они почти всегда кончались развалом проектной команды и срывом проекта.

Метод спуска планов сверху наиболее сродни сталинской модели индустриализации, когда и жесткие планы, и суровая ответственность наступают неотвратимо, как дождь или снег. И кнут, и пряник в руках у главного босса в этой модели должны быть почти такими же весомыми, как жизнь и смерть. Да, и нужно еще одно условие: исполнитель не должен иметь возможности сбежать. К счастью, в наших условиях свободного рынка труда эта модель не работает.

Простые и эффективные советы, как именно писать планы про разработке программного обеспечения, даются в статье Джоэла Спольски "Painless Software Schedules" ("Планирование разработки малой кровью"), так что я позволю себе не углубляться здесь в технические и организационные подробности.

Ресурсы

Правило 8. Проект нельзя запускать без ресурсов.

Ну, это же вообще очевидно, скажете вы. Так, да не так. По разным причинам боссы всячески тянут с выделением ресурсов на уже утвержденный проект.

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

Возникает дурная петля выпрашивания: вроде бы менеджер проекта поставил босса в известность о том, что ресурсы нужны и какие именно, и тот согласился. Планы и заявки утверждены.

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

Менеджер снова приходит к боссу, а тот смотрит на него с надеждой - а может, так справишься? С деньгами в магазин и дурак сходит, а вот ты попробуй без денег!

Заново происходит торговля, препирательства. Менеджер снова выбивает уже однажды оговоренные ресурсы. Что-то наконец выделяют, чего-то опять не дают. И еще и еще раз, и так по кругу.

Заметим, что всё это время часы проекта тикают - ведь план утвержден и время уже пошло!

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

Я могу здесь посоветовать только одно - постараться не принимать действительность такой, как она есть, и не работать с урезанными ресурсами.

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

Такой формальный подход может не помочь с ресурсами (особенно если страшный секрет начальства состоит в том, что их на самом деле нет), но, по крайней мере, снимет с менеджера ответственность за чужие проблемы.