Глава 1

Проект –

1) это однократная неповторяющаяся временная активность с ясным стартом и ясным окончанием; в проекте имеются полностью или частично занятые ресурсы, ясным образом назначенные для участия в проекте; в проекте организована временная оргструктура / иерархия управления, которая имеет преимущество перед иерархией компании (предприятия); проект предназначен для поставки ИТ-системы, нового продукта или ещё чего-нибудь.

2) это способ достижения предсказанного изменения.

Характеристики:

• Ограниченное время;
• Назначенные люди;
• Ясные роли и ответственность;
• Результаты поставки.

Глава 2 Проекты и этапы

Подходы к выполнению проекта:

1) "Большой взрыв" - единый проект, предоставит продукт по истечению срока.

Плюсы:

• Более очевидный значимый результат,
• Больше внимания от руководства (крупный проект),
• Один тренинг для пользователей в конце,
• Достаточно времени, чтобы сделать «как положено»,
• Более целостный подход к разработке ИТ системы,
• Наглядное эффектное переключение со старой системы на новую,
• Никаких временных переходов со старой системы на новую,
• Всё будет сделано только один раз, без переделок, т.е. более низкие затраты,
• Если что-то пойдет не так, то достаточно времени исправить.

2) Серия релизов.

Плюсы:

• Лучше мотивация команды (замотивированность сделать что-то из-за коротких релизов);
• Меньше затрат на контроль проекта (меньше затрат на подпроекты);
• Большая гибкость для спонсора (можно скорректировать требования после релиза, сократить затраты отказавшись от ненужного);
• Обучение в процессе исполнения проекта (ранний фидбек от конечных пользователей, более эффективное управление проектом);
• Легче вносить и контролировать изменения (up-to-date);
• Меньше рисков: эволюция, а не революция (Прекращение всей деятельности компании в старой системе и полный переход на новую огромный риск, ибо та может не взлететь);
• Меньше бесполезных затрат на функционал, который никогда не будет использоваться,
• Легче управлять четырьмя небольшими проектами, чем одним большим,
• Легче получить подтверждение ресурсов на 8 месяцев, чем на 3 года (актуальная компетенция ресурсов по окончанию проекта);
• Меньший процент людей покинет проект по сравнению с проектом типа «большой взрыв» (каждый покинувший увеличивает риск незавершенности);
• Бонусы будут выплачены раньше,
• Меньшие затраты (Меньше затрат на контроль, меньше затрат на внедрение и контроль изменений, меньше затрат на неиспользуемый функционал. Преимущество ранних выплат бонусов может стать довольно значимым преимуществом).

Ведение релизного проекта

PM - заставляет все заинтересованные стороны (спонсора, членов Совета директоров, пользователей, программистов, инженеров, и т.д.) сформулировать, какой именно функционал нужен, а какой нет. Однако, в ходе сбора такой информации можно обнаружить, что, PM знает лучше, чем сами заинтересованные стороны, что же им нужно на самом деле; и тогда он, с благословения спонсора, может сам принять решения по составу работ. Для того, чтобы стать хорошим проектным менеджером, вы должны научиться говорить самое важное слово в лексиконе проектного менеджера: «Нет». Вежливо и твёрдо: «Нет».

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

Релизный подход будет, возможно, дешевле, раньше принесет выгоды и будет надёжнее в достижении результата, принесет бизнесу лучший возврат инвестиций.

Добавление небольших улучшений в существующую IT-систему

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

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

• Боевая система не изменяется между релизами для стабильной работы.
• Экспертиза в уже изученной системе для последующих изменений.
• Отсеивание не нужных изменений.
• Процесс cnановится дешевле

Схема при разработке программного обеспечения

1. Определение проекта. Определить причины возникновения проекта, объём, роли и т.д.

2. Анализ требований.
   Определить в бизнес-терминах какие процессы и какие данные должны быть
   автоматизированы

3. Разработка Пользовательского функционального дизайна.
   Разработка дизайна системы, который сообщит пользователям как будет
   выглядеть система и что она будет делать.

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

5. Разработка и тестирование.
   Разработка означает написание миллиона строчек нового или модификацию
   существующего кода. И затем тестирование, то есть проверка, что система
   действительно делает то, что написано в Пользовательском дизайне.

6. Приёмка пользователя. Пользователи говорят, что это супер и нужно этим пользоваться.

--

При старте нового проекта для избежания хаоса

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

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

Анализ требований (шаг 2 из схемы)

Работа бизнес-аналитика вытащить все необходимые требования из заказчика.

При проведение сессий по сбору информации должны принимать участие не только пользователи и
бизнес-аналитики. Команда по разработке ИТ-дизайна также должна быть вовлечена.

1. Они могут указать на то, что способ, который сейчас используется для формулирования бизнес-процесса, создаст определённые трудности для дизайна и программирования, и, возможно, предложат другой способ для оптимизации.
2. У ИТ-дизайнеров есть мощные стимулы для того, чтобы требования были описаны полно, иначе у них возникнут проблемы при разработке дизайна.
3. ИТ-специалисты поймут, чего именно хотят пользователи на самом деле – ведь просто необходимо знать, каким образом система должна работать. Они сделают множество полезных выводов, которые никогда не придут им в голову при чтении сухого документа с описанием бизнес-процессов.

Цель: «Пользователи и специалисты ИТ! На этапе анализа требований я хочу, чтобы вы определили все требования таким образом, чтобы ИТ команде не нужно было уточнять хоть что-нибудь позже в проекте».

Разработка пользовательского функционала

Результат этапа:

1. Документ «Пользовательский функциональный дизайн», который расскажет пользователям (клиентам), что конкретно будет делать система и как будет выглядеть: всё, что система будет делать (редактирование, вычисление и т.д.), будет действительно уточнено и описано. Документ о пользовательском функционале описывает ИТ-систему (системы). Каждое редактирование, каждое вычисление, каждый процесс, упомянутый в требованиях, воспроизведён здесь в контексте системного дизайна. Исключение требований из этого документа должно быть обоснованно.
2. Стратегия тестирования, план внедрения, план проекта по разработке ИТ-дизайна, обновленный анализ затрат и выгод проекта.

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

ИТ-дизайн

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

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

Хорошая практика:

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

Внедрение и тестирование

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

Пользовательская приемка

Пользователи выполняют множество собственных
тестов и находят много ошибок в системе.

Жизненный цикл

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

Аналогия

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

Ваш документ об определении проекта гласит:

• Проблема – потратить миллион.
• Решение – разработать дизайн и построить дом.
• Спонсор – вы.
• Пользователи – ваша семья.

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

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

Если это ваш дом и ваши деньги, будете ли вы читать документ до подписания? Да!

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

В «Пользовательском дизайне» только быть те вопросы, которые заказчик обязан знать, выведите все технические вопросы в отдельный документ - «ИТ технический дизайн».

В проекте с постройкой дома вы однозначно активно участвуете в определении проекта, требований и на этапе разработки дизайна. Это применимо абсолютно ко всем заказчикам в ИТ проектах.

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

Во-вторых, на этапе дизайна вы захотите сдвинуть окно на три фута левее. Сколько вам будет это стоить? Не так много, и возможно, даже ничего. Но если дом почти достроен, сколько будет стоить такое же изменение? Кучу денег! И это точно так же работает в софтверных проектах, хотя и не так очевидно.

Эта аналогия поможет большим начальникам понять важные выводы:

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

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

Управляемые части

До начала каждого этапа проектный менеджер подписывается под стоимостью и датой окончания этого этапа и делает предварительную оценку для предстоящих этапов.

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

В конце каждого этапа проектный менеджер повторно проводит оценку стоимости и выгод проекта и идет к спонсору для получения разрешения (авторизации) на запуск следующего этапа.

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

Глава 3. Роли и ответственность

До начала проекта мы должны обеспечить помимо множества других вопросов:

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

Роли

Спонсор проекта

Ответственность:

• Несёт ответственность за проект. Если проект идёт неверно, спонсор является первым в расстрельной команде.
• Выбирает, или, по крайней мере, утверждает назначение проектного менеджера
• Обеспечивает финансирование проекта со стороны Совета директоров
• Защищает проект, обеспечивает его продвижение и поддержку у высшего руководства компании
• Отвечает за обоснование проекта (владеет бизнес-кейсом, то есть знает затраты проекта и выгоды, которые получит компания после его реализации)
• Отвечает за получение выгод от использования системы, поставленной по проекту.
• Даёт проектному менеджеру команду «идем/не идем» для каждого этапа проекта
• Формулирует и отвечает за актуальность целей проекта, имеет вИдение проекта
• Делает презентации на мобилизационном мероприятии проекта, объясняет всей команде почему проект важен
• Если есть проблема, которую проектный менеджер не может разрешить сам, то спонсор пошепчется с виновной стороной и сделает предложение, от которого та не сможет отказаться.
• Решает вопросы, которые не может решить проектный менеджер
• Обеспечивает эффективность использования бюджета (только необходимые функции будут реализованы и оплачены в рамках проекта)
• Несёт ответственность за соответствие продукта/результата проекта юридическим, правовым и прочим требованиям
• Возглавляет координационный совет проекта
• Наделяет проектного менеджера полномочиями в управлении проекта
• Проводит обзор бизнес-кейса (анализ внедренной системы) после внедрения проекта.

Координационный комитет проекта

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

Вы хотите, чтобы они:

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

И, наоборот, вы хотите, чтобы они НЕ:

• Копались в ненужных деталях
• Метались после принятых решений
• Играли в политику
• Подрывали авторитет проектного менеджера.

Проектный менеджер

йуц