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

 вЂў Р’ жизни РІСЃС‘ РЅРµ так, Рё автор абсолютно некомпетентен.

 вЂў Бывает куча технических проблем, Р° РЅРµ только организационных. Рђ если менеджер этого РЅРµ понимает, его нужно гнать РІ шею.

 вЂў Программисты РІРѕРІСЃРµ РЅРµ такие плохие. Р’РѕС‚ наши знакомые программисты РЅРµ срывают СЃСЂРѕРєРѕРІ, живут нуждами бизнеса Рё так далее, вообще абсолютно сознательные Рё продвинутые личности. Рђ если Рё бывают неправильные программисты, то РёС… нужно просто заменить Рё нанять более правильных.

 вЂў Наоборот, это менеджеры плохие, некомпетентные, Рё РѕС‚ РёС… неумного Рё неумелого руководства страдают умные программисты. Менеджеры, описанные РІ статье, просто РЅРёРєСѓРґР° РЅРµ РіРѕРґРЅС‹ Рё РёС… нужно уволить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 вЂў РќРµ бывает проекта без руководителя.

 вЂў Руководитель должен быть РѕРґРёРЅ.

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

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

 вЂў Р’ начале проекта всегда бывает естественное торможение. Чтобы его преодолеть, нужны терпение Рё настойчивость.

 вЂў Вполнакала проекты РЅРµ делаются.

 вЂў Только коррекцией РІ контрольных точках можно удержать проект РѕС‚ срыва.

 вЂў РџРѕ окончании проекта нужно правильно переключить ответственность.

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

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

 вЂў Р РёСЃРє неудачи проекта есть всегда.

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

 вЂў РљРѕРіРґР° РІ проекте что-то идет РЅРµ так, начальство предпринимает титанические бесполезные усилия РїРѕ наведению РїРѕСЂСЏРґРєР°.

 вЂў Бессмысленно муштровать исполнителей, нужно муштровать менеджеров.

 вЂў Наведение РїРѕСЂСЏРґРєР° РІ проекте всегда должно начинаться СЃ головы.

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