Менеджмент проектов принято описывать толстыми книгами, сертификатами и аббревиатурами из трёх-четырёх букв. Всё это имеет право на жизнь, но я заметил странную вещь: многие люди, прочитавшие эти книги, всё равно проваливают проекты, а некоторые, не прочитавшие ни одной, ведут их блестяще. Значит, суть не в терминологии. Суть в нескольких простых основах, которые нужно не знать, а чувствовать кожей.
За годы в разработке я видел сотни проектов: маленьких и огромных, удачных и катастрофических. И если свести весь этот опыт к фундаменту, получится не так уж много принципов. Их я и попробую описать без академической пыли.
Проект и продукт это не одно и то же
Первое, что стоит понять: проект это временное предприятие с началом и концом. У него есть цель, ограниченные ресурсы и дата, когда он должен закончиться. Продукт же может жить годами. Проект создаёт продукт или его часть, а потом заканчивается.
Эта разница кажется формальной, но на практике она огромна. Когда люди путают проект и продукт, проект никогда не заканчивается. Он превращается в бесконечную доработку, где каждую неделю добавляется что-то новое, бюджет течёт, а слово «готово» не звучит никогда. Хороший менеджер всегда знает, что именно будет считаться окончанием проекта, и защищает эту границу.
Треугольник, который нельзя обмануть
В основе любого проекта лежат три параметра: объём работ, бюджет и время. Я называю это треугольником проекта, и он подчиняется почти физическим законам. Нельзя изменить одну сторону, не затронув другие. Хотите больше функций? Потребуется больше денег или больше времени. Хотите быстрее? Придётся урезать объём или нанять больше людей, а это снова деньги.
Представьте канатоходца, у которого шест держится на трёх канатах. Натянете один сильнее, и два других провиснут или лопнут. Большинство конфликтов в проектах возникают именно отсюда: клиент хочет, чтобы все три каната были натянуты до предела одновременно. Больше функций, меньше денег, быстрее. Так не бывает, и задача менеджера не обещать невозможное, а честно показывать, чем придётся пожертвовать.
Есть и четвёртый, скрытый параметр: качество. Когда треугольник перетянут, качество проседает первым и незаметнее всего. Сроки соблюдены, бюджет уложен, функции на месте, а через месяц начинается поток ошибок. Это не экономия, это отложенный счёт.
Фазы проекта
Каждый проект проходит через похожие фазы, как бы их ни называли в разных методологиях.
- Инициация. Зачем мы это делаем, какую проблему решаем, как поймём, что успех достигнут.
- Планирование. Что именно делаем, в каком порядке, кто, за какие деньги и сроки, какие риски.
- Исполнение. Собственно работа, самая длинная фаза.
- Контроль. Идёт параллельно с исполнением: сравниваем план с фактом, реагируем на отклонения.
- Завершение. Сдача результата, приёмка, разбор того, что получилось и что нет.
Самая недооценённая фаза первая. Люди хотят скорее начать что-то делать, а вопрос «зачем» кажется очевидным. Но я видел проекты, которые блестяще выполнили всё запланированное, а потом выяснилось, что это никому не нужно. Час, потраченный на вопрос «зачем», экономит месяцы работы над ненужным.
Вторая по недооценённости последняя. Проект сдали, все выдохнули и разошлись. А разбор полётов, где команда честно говорит, что пошло не так, и есть то, что делает следующий проект лучше. Без него компания годами наступает на одни и те же грабли и каждый раз удивляется.
Риски: зонтик, который берут до дождя
Управление рисками звучит скучно, но это одна из самых практичных вещей в менеджменте. Риск это то, что может пойти не так. Не обязательно пойдёт, но может. Ключевой поставщик задержит поставку. Программист заболеет в самый ответственный момент. Сторонний сервис изменит условия. Клиент поменяет требования посреди проекта.
Хороший менеджер составляет список таких рисков в начале проекта и для каждого серьёзного продумывает, что будет делать, если он случится. Это как брать зонтик, когда небо хмурится. Возможно, он не пригодится. Но если пойдёт дождь, Вы будете единственным сухим человеком на остановке.
И обязательно закладывайте резерв времени и бюджета. Не потому, что команда ленивая, а потому, что в любом сложном проекте будут сюрпризы. Проект без резерва это проект, который точно опоздает, просто Вы ещё не знаете насколько.
Коммуникация это половина менеджмента
Если спросить меня, на что менеджер проекта тратит больше всего времени, ответ будет неожиданным для новичков: на общение. С клиентом, с командой, с подрядчиками, с руководством. Проекты редко проваливаются из-за технических проблем. Гораздо чаще они проваливаются из-за того, что люди поняли друг друга неправильно и долго этого не замечали.
Поэтому базовые правила коммуникации важнее любой методологии. Договорённости фиксируются письменно. Все участники знают, где искать актуальную информацию о проекте. Плохие новости сообщаются сразу, а не когда их уже невозможно скрыть. Клиент получает регулярный понятный статус, а не тишину, прерываемую паникой.
С чего начать
Если Вы только начинаете управлять проектами, не пытайтесь сразу освоить все методологии. Начните с трёх вещей. Запишите цель проекта одним предложением и критерий, по которому поймёте, что он завершён. Нарисуйте треугольник: объём, бюджет, сроки, и честно определите, какой из канатов можно ослабить, если придётся. Составьте список из пяти главных рисков и для каждого придумайте план Б.
Мы в Ingello Systems начинаем каждый клиентский проект именно с этого, ещё до того, как написана первая строчка кода. А дальше многое из рутины снимает формализация: когда система описана схемами в Fractal, объём работ становится видимым и измеримым, и треугольник перестаёт быть предметом споров. Но фундамент всегда один: понимать, зачем, сколько и к какому сроку. Остальное надстройка.
