Искусство управления высокотехнологичными проектами

Цели

Сначала озвучим критерии успешного проекта:

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

Чтобы проект соответствовал этим критериям, на его начальном этапе менеджер проекта должен задать себе несколько вопросов:

• Кто является заказчиком проекта?
• Очевиден ли для всех результат проекта?
• Нужно ли рассматривать промышленные или государственные ограничения?
• Имеет ли проект обоснованные ограничения по времени?
• Выделены ли средства для реализации проекта?
• Есть ли аналоги в отрасли?
• Есть ли влияние смежных систем?
• Нет ли других вариантов?

Формирование цели проекта

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

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

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

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

Конфликт проектов по целям

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

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

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

Команда

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

Менеджер проекта

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

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

Например, в проекте по построению единого интеграционного решения для компании «Миг Кредит» мы провели более 50 интервью с сотрудниками различных функциональных подразделений заказчика для выявления потребностей бизнеса. Благодаря такому скрупулезному подходу мы выстроили единый конвейер, который обеспечил работу всей организации от входящего звонка клиента до работы с ним после погашения займа.

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

Аналитики

В подавляющем большинстве случаев проект начинается со списка требований, изложенного на 1–2 страницах или озвученного во время встречи. Здесь первую скрипку играют бизнес-аналитики: именно они проводят интервью с пользователями, фиксируют функциональные требования к системе, встречаются с представителями службы эксплуатации заказчика и определяют нефункциональные требования. Совместно с архитектором и ИТ-подразделением компании определяется технологический стек проекта, разрабатывается и согласовывается с заказчиком техническое задание. Это действительно масштабная работа, поскольку заказчик не всегда до конца представляет, что именно должно стать результатом проекта, и очень редко – как система должна работать в деталях. После окончания этапа аналитики архитектор и менеджер проекта могут оценить его бюджет и сроки и начать этап проектирования системы. На этой стадии солировать начинает архитектор, однако один в поле не воин, поэтому аналитики также серьезно вовлечены в процесс проектирования.

Архитектор

Его основная задача – спроектировать архитектуру приложения в соответствии с выявленными требованиями, разбить систему на компоненты, выбрать протоколы, фреймворки. При проектировании учитываются нефункциональные требования по производительности, обеспечению надёжности и т.д. Так же, как архитектор согласовывает техническое задание на выполнимость, аналитик согласовывает архитектуру приложения, описываемую в технорабочем проекте, на соответствие требованиям. В процессе разработки архитектор декомпозирует принятые решения на задачи, назначает их разработчикам, контролирует выполнение задач. Именно он является лицом, принимающим решения в вопросах, касающихся сложных технических проблем.

Разработчики

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

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

Тестировщики

Помимо навыков программирования, тестировщику потребуются знания, которые обычно ассоциируют с архитекторами, системными аналитиками и администраторами сетей. «Сломать» систему не так трудно, гораздо сложнее понять, в чем причина проблемы и как ее можно решить. Например, чтобы правильно протестировать систему, содержащую базу данных, нужно сначала разобраться в принципах построения БД; для проверки телеком-решений нужно знать протоколы, которые в них используются, бизнес-процессы, архитектуру решений.

Тестировщики в ряде случаев работают «классическим способом» – только руками и головой – и не пользуются средствами автоматизации. Огромную роль в таком тестировании играет человеческий фактор: эксперту нужно уметь ставить себя на место пользователя, анализируя при этом поведение программы.

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

Технологии

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

Если выбранная под проект технология новая, впечатляет заявленными возможностями, но пока не имеет широкого распространения, во многих случаях лучше подождать, пока ее обкатают, а пока выбрать более известный вариант. Слишком часто технология служит оправданием всего остального, что приводит к непредвиденным проблемам на проекте. Менеджер проекта должен быть готов сказать «нет» или, по крайней мере, «мы вернёмся к этому проекту позже», грамотно и подробно обосновав свою позицию. Приведем пример: один из крупных российских банков выбрал для себя известное на рынке решение, которое уже стоит в крупнейшем западном банке. Референс-визиты, довольный заказчик – на первый взгляд, все замечательно. Однако при его внедрении становится очевидно, что система не соответствует бизнес-процессам заказчика и не обеспечивает требования российских регуляторов. Специалистам пришлось приложить массу усилий для «заточки и подгонки» решения для удовлетворения потребностей конечных пользователей.

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