Лидер, руководитель или наблюдатель проекта?

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

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

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

Наилучший результат будет получен в случае, если:

• Исполняется большая часть возможностей, все делается в срок, при этом как можно меньше дефектов будет обнаружено в первые 90 дней после выпуска ПО.
• Наблюдается четкое понимание статуса проекта на протяжении его выполнения всеми участниками и внутренними обозревателями.

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

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

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

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

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

Выбор своего поля боя

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

Лидеры проектов попадаются редко, поэтому вопрос также заключается в том, каким проектам нужны лидеры, а какие могут выжить даже с руководителями или наблюдателями? Подумайте о разнице между пилотажем самолета и вождением поезда. Поезд уже стоит на рельсах - вы можете контролировать только одну переменную (скорость). Самолеты имеют гораздо больше переменных - не просто в трех осях, но также множество других внешних взаимодействий. Наблюдатели могут вести поезд, руководители - управлять самолетом. А лидеры? Лидерам лучше заниматься "миссиями на истребителях".

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

Ключевые моменты для действий

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

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

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

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

Что вы ищите?

При поиске нового лидера проекта многие корпорации делают особенный акцент на навыках в управлении проектами и методах - IPMA Level B, сертификация PMI и большой опыт работы с Microsoft Project или каким-то другим пакетом ПО для корпоративного управления проектами. Неудивительно, но это привлекает руководителей, а не лидеров проектов. В следующий раз, когда вы удостоитесь чести участвовать в процессе отбора руководителя или лидера в вашей компании, подумайте о тех профессиональных навыках, которым вы не сможете их с легкостью обучить.