Правила Ашманова-2. Управление проектами

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

Игорь Ашманов

Правила Ашманова 2
© "Ашманов и Партнеры"

От автора

 

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

  • В жизни всё не так, и автор абсолютно некомпетентен.
  • Бывает куча технических проблем, а не только организационных. А если менеджер этого не понимает, его нужно гнать в шею.
  • Программисты вовсе не такие плохие. Вот наши знакомые программисты не срывают сроков, живут нуждами бизнеса и так далее, вообще абсолютно сознательные и продвинутые личности. А если и бывают неправильные программисты, то их нужно просто заменить и нанять более правильных.
  • Наоборот, это менеджеры плохие, некомпетентные, и от их неумного и неумелого руководства страдают умные программисты. Менеджеры, описанные в статье, просто никуда не годны и их нужно уволить.

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

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

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

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

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

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

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

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

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

Содержание

  1. Введение - правила одной строкой
  2. I. Правильный проект: запуск, ведение, завершение
  3. II. Неправильный проект и его лечение
  4. III. Приложение. Словарь ненормативной лексики руководителя

Введение - правила одной строкой

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

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

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

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

А. Кадры решают всё.

Б. Ключ к успеху проекта - передача ответственности участникам проекта.

В. Ключевой момент переключения ответственности - принятие решения.

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

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

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

Вот эти правила.

I. Как правильно запустить проект и закончить его

  • Решение о запуске проекта должны принимать ответственные лица.
  • Для начала проекта нужно исполнить процедуру запуска проектов.
  • Без энтузиаста любой проект мертв.
  • Проект нельзя обсуждать без обоснования.
  • Не бывает проекта без руководителя.
  • Руководитель должен быть один.
  • Проект нельзя запускать без плана, написанного лично руководителем проекта.
  • Проект нельзя запускать без ресурсов.
  • В начале проекта всегда бывает естественное торможение. Чтобы его преодолеть, нужны терпение и настойчивость.
  • Вполнакала проекты не делаются.
  • Только коррекцией в контрольных точках можно удержать проект от срыва.
  • По окончании проекта нужно правильно переключить ответственность.
  • После завершения проекта нужно запустить следующий "бессрочный" проект - проект поддержки.

II. Неправильный проект и его лечение

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

Разберем эти принципы и правила подробнее...

Напиши уточненный план

I. Правильный проект: запуск, ведение, завершение

Основные принципы устройства коротких проектов

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

Такой короткий проект обычно отличается от длинного и большого тем, что:

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

В условиях сильно ограниченных ресурсов нет возможности делать всё по-хорошему: тщательно планировать, использовать специальные средства планирования и управления, методично нанимать нужных специалистов, закладывать достаточные сроки тестирования и документирования.

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

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

Отсюда вытекает принцип номер один:

Принцип А. Кадры решают всё.

Автор этого принципа широко известен.

Люди вовлечены в проект настолько, насколько они чувствуют свою ответственность за него, поэтому второй основной принцип гласит:

Принцип Б. Ключ к успеху проекта - передача ответственности участникам проекта.

(Предвидя возможные возражения разработчиков, скажу, что энтузиазм и авторские творческие порывы я тоже отношу к чувству ответственности.)

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

Точками переключения ответственности служат решения. Отсюда - третий принцип:

Принцип В. Ключевой момент переключения ответственности - принятие решения.

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

Руководитель проекта в свою очередь начинает транслировать часть ответственности дальше вниз, принимая решения о подборе и расстановке разработчиков.

Если люди, структура ответственности и решения в проекте выбраны правильно, то и проект будет правильным.

Правильный проект

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

  • правильный запуск проекта;
  • правильный контроль;
  • правильное окончание или остановка проекта.

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

От идеи до запуска проекта

Для начала нового проекта нужны две вещи: начальная идея и принятие решения об инициации проекта.

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

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

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

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

Правило 1. Решение о запуске проекта должны принимать ответственные лица компании.

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

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

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

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

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

Мертворожденные проекты

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

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

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

Процедура запуска

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

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

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

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

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

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

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

Энтузиасты

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

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

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

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

Обоснование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ресурсы

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

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

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

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

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

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

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

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

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

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

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

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

Трение покоя

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

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

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

Это - нормально.

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

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

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

Правило 9. В начале проекта всегда бывает естественное торможение. Чтобы его преодолеть, нужны терпение и настойчивость.

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

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

Впрочем, какой-то период торможения всё равно будет, только покороче.

Температура горения

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

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

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

Правило 10. Вполнакала проекты не делаются.

(Точной формулировкой этого правила я обязан Илье Ставискому, владельцу компании "Информатик".)

Доверие, оно же контроль

В ходе проекта также несколько раз приходится принимать решения. Это должно происходить в контрольных точках. Контрольные точки должны быть сразу внесены в планы проекта.

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

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

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

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

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

Правило 11. Только коррекцией в контрольных точках можно удержать проект от срыва.

Корректное завершение проекта - передача ответственности

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

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

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

Правило 12. По окончании проекта нужно правильно переключить ответственность.

Принятие решения о завершении проекта

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

Передача проекта

Теперь завершенный проект должен быть официально передан от разработчиков в департамент продаж, департамент поддержки и им подобные. "Передан" означает официальную передачу ответственности за проект.

Новая рабочая группа

В этот момент может быть назначен новый руководитель (ответственный), должен быть пересмотрен состав рабочей группы - сформирована группа поддержки проекта, написан план поддержки. Фактически, снова произведена процедура запуска проекта - теперь уже проекта поддержки.

Размывание ответственности на стыке

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

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

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

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

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

Проекты никогда не заканчиваются

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

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

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

Итак, получаем последнее правило в данной части:

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

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

Проект
© "Ашманов и Партнеры&quo"

24.03.2010

Следите за нашими новостями

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

Для завершения подписки вам необходимо перейти по ссылке,
присланной по указанному адресу email.

Произошла ошибка

Пожалуйста, попробуйте еще раз