, , web design, , , , web , , , , , web site development, , , , -, web-

Статьи: веб дизайн и разработка сайтов / Менеджмент веб проектов, управление программистами / Правила Ашманова
 

Правила Ашманова. Часть 2: об управлении проектами

http://www.ashmanov.com

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

 • В жизни всё не так, и автор абсолютно некомпетентен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 • Вполнакала проекты не делаются.

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

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

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

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

 • Риск неудачи проекта есть всегда.

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

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

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

 • Наведение порядка в проекте всегда должно начинаться с головы.

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