В преддверии семинара Эдварда Йордона (того самого, кто написал «Путь камикадзе») я решил вспомнить и систематизировать предыдущий семинар «It-online» по управлению проектами. Я говорю о семинаре Скотта Беркуна «Основы управления проектами» (25 апреля 2007).

О Скотте Беркуне
Скот работал в «Microsoft» руководителем проектов таких как: IE (с первой по пятую версию), сайт MSN и Windows. Сублимируя свой опыт он написал книгу «Искусство управления IT-проектами». Сейчас является независимым консультантом в области управления проектами.

Дом Скот находится в лесу в окрестности Сиетла. Естественно этот любопытный факт несколько раз был в фокусе участников семинара. К примеру звучали такие вопросы как: «Как Вам видится IT рынок России из леса» =).

Семинар «Основы управления проектами»
Часть 1. Планирование и постановка задачи
В начале публике была предложена страшилка — статистическая информация из исследований в США: 50% проектов в 2-а раза дороже чем запланированно, 30% сворачиваются и только 16% заканчиваются в срок и в рамках выделенного бюджета. Основные причины этого в том, что изначально нет четкого виденья (не описана цель), оценки излишне оптимистичны (переоценка ресурсов). Кроме того не учитываются риски: ошибки, изменения, больничные и тд.

Отдельно Скот выделяет то, что при изменении первоначальной задачи не учитывают изменение в необходимых ресурсах. Проект это взаимосвязанная система из 4 переменных — время, деньги, качество продукта и задача проекта. Если мы изменяем одну переменную изменяются и все остальные (данный факт крайне важен при общении с заказчиком продукта). Поэтому говоря о планировании, Скот обратил внимание на то, что хороший план проекта должен быть всегда гибкий, а значит актуальным для текущего положения.

Описывая процесс планирования, Скот предложил следующую модель:

• В начале создается виденье проекта или иными словами миссия. Если вспомнить лекции по стратегическому менеджменту, можно сказать, что это идеальная картина к которой мы должны стремится.
  
• На втором этапе виденье более подробно описывается целями (что конкретно необходимо достигнуть чтобы воплатить виденье в жизнь). Иными словами это декомпозиция идеальной картины. Виденье и цели в совокупности образуют документ "Vision Document". В качестве примера, Скот предложил описание стула: стул который будет обдувать сидящего на нем человака — это виденье. Система вентиляторов, кондиционер, система подачи воздуха — это цели проекта.
• Цели переходят в характеристики и спецификации. На этом этапе описываются требования, характеристики или черты которым должен соответствовать продукт, чтобы реализовать цели. Документ в который заносят характеристики и спецификации называют "Specsification". Обращаясь к проекту «стул» в качестве спецификации можно выделить следующее: подаваемый воздух должен быть с температурой 20 градусов; скорость потока 10 метров в секунду; направление воздушного потока...
• После описания спецификации описывают конкретные виды работ. Список действий образует документ "Item list". В проекте «стул» виды работ могут выглядеть следующим образом: создание каркаса стула, подготовка воздуховодов… и т.д.
  

Описанный выше процесс планирования Скот представил в виде пирамиды в основании которой находится виденье, а на вершине конкретные виды работ. Если необходимо внести изменения в какойто элемент, то изменится вся пирамида выше.

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

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

Часть 2. Ход проекта
В предыдущей части я обратился к планированию проекта и постановке задачи рассмотренной Скоттом Беркуном в семинаре «Основы управления проектами». Этом посте я систематизирую информацию по ведению проекта.

В начале обратимся к тому как описывает Скотт ход проекта. По его словам почти каждый проект с жесткими сроками развивается ступенчато. Изначально график работ (Y-объем работ, X-время) выглядит как прямой отрезок: выходящий из точки с максимальным объемом работ и временем начала проекта, заканчивающийся в точке когда вся работа выполнена и время полностью израсходовано. Но поскольку, как писалось ранее, при планировании не учитываются риски и изменения график работ начинает запаздывать, а что бы вернуться к планируемому ходу работ необходимо отказаться от части низкоприоритетных задач или иными словами сократить объем работ. Задача РП четко понимать приоритеты выполняемых задач и предупреждать такие ситуации.

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

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

Встречей обязательно руководит ответственный сотрудник, обычно РП. Наиболее эффективные встречи проходят при не большом количестве участников. Отдельно Скот обратил внимание, что при всей полезности быстрых летучек, существует очень «скучные» и не полезные встречи, которые необходимо избегать и уж точно не инициировать. Скотт описал некотрые варианты проведения таких совещаний, например: Scrum *. На такой встрече обсуждается только 4-5 вопроса, каждый участник выступает по 10-15 минут. Нельзя распыляться — обсуждаются только вопросы которые помогут реализовать проект: «Что мешает перейти к новому этапу?», «Как устранить причину?», «Что нужно чтобы закончить вовремя?»

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

Цели Высокий приоритет Средний приоритет Низкий приоритет

Характеристики Высокий приоритет Средний приоритет Низкий приоритет

Виды работ Высокий приоритет Средний приоритет Низкий приоритет

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

• Либо изменится затраченное на проект время;
• Либо изменится стоимость проекта;
• Либо изменится качество исполнения проекта;
• Либо будут сокращены другие задачи в рамках проекта.
  

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

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

Методика оценки трудозатрат
На семинаре Скотт предложил 2-а варианта оценки трудозатрат проекта.

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

Реальная оценка получается по формуле:
(Оптимистичный вар. + 4 * Реалистичный вар. + Пессимистичный вар.) / 6

Для песcимистов =) есть отдельная формула:
(Оптимистичный вар. + 4 * Реалистичный вар. + 2 * Пессимистичный вар.) / 7

Групповая методика оценки
Чтобы оценка была более корректна применяют групповой метод. Этот метод основывается на итерационном подходе. В начале все участники рабочей группы (4-5 представителя разработчиков и их руководителей) закрыто пишут пессимистичный, реалистичный и оптимистичный вариант оценки. После чего данные озвучиваются и отображаются на доске (белая доска для записей, любимый инструмент Скотта).

Иван	30 дней 50 дней 70 дней
Ольга	40 дней 60 дней 70 дней
Петр	45 дней 60 дней 80 дней

Полученные числа аргументируются участниками. После чего проводится следующий этап закрытой оценки. На последне итерации данные усредняются и РП принимает окончательное решение.

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

При планировании трудозатрат необходимо помнить о больничных, праздниках и выходных днях. Кроме того по статистике сотрудник не сможет работать все 8 часов в день ему необходимо время на обсуждение текущих вопросов с сотрудниками, время на иные задачи вне проекта. По статистике в США 30% рабочего времени сотрудники работают в одиночестве, 50% общаются по рабочим вопросам с другим сотрудником, 20% общаются по рабочим вопросам с другими сотрудниками в группах (совещание).

Метод принятия решений

1. В начале необходимо четко понять в отношении чего принимается решение;
2. Какие существуют альтернативы;
3. Анализ + и — каждой альтернативы;
4. Скептический и критический анализ альтернатив. Что случится через неделю после принятия решения.
5. Принятие решения;
6. Исполнение решения;
7. Анализ принятого решения. Если допущена ошибка, анализ того как ее можно было избежать.

Крайне важно понять как в действительности звучит вопрос по которому принимается решение. Например.
Вопрос: «Нужно ли отдать разработку на аутсорсинг?»
Может означать: «Необходимо достигнуть наивысшей эффективности» или «Необходимо разгрузить программистов» или «Необходимо разработать продукт с наивысшим качеством».

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

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

В некотрых случаях полезно протестировать альтернативы., создать прототип.

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

Вариант	За (+)	Против (-)	Рейтинг (приоритет)
A
B
Ничего не делать

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

Крушение проекта
Если крушение проекта неминуемо, возможны следующие варианты:

1. Изменение цели проекта;
2. Отмена проекта;
3. Снизить скорость и обдумать последующие действия (изменить цель, отмена проекта и анализ ошибок);
4. Ничего не делать и наслаждаться катастрофой (не хороший вариант);
5. Сделать вид что такой финал проекта и был задуман (плохой вариант, но люди склонны не признавать свои ошибки);
6. Ускорить кризис (в некотрых случаях этот вариант лучший).

Часть 3. Управление командой
В предыдущих частях «Планирование проекта и постановка задачи», «Ход проекта» Скотт уже обращался к команде участвующей в проекте. Теперь рассмотрим этом вопрос подробней.

Изначально Скотт предложил два варианта управления — 1. диктатура (менеджер указывает подчиненным что делать, управление строится на непоколебимом авторитете) 2. коммуникация (менеджер помогает наилучшим способом решить поставленную задачу, объясняет как лучше поступить, менеджер объединяет интеллектуалов вокруг идеи). Коммуникация — это не то что я говорю, а то как меня понимают.

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

Как этого можно добиться. Скотт рекомендует в начале рабочего дня заглянуть в кабинет к разработчику и уточнить: Чем занят сотрудник? Возникли какие либо сложности и угрозы для проекта? Чем РП может помочь в их решении? Хорошая идея выпить вместе кофе. Важно интересоваться мнением и работой сотрудников задействованных в проекте.

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

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

Я	Вместе	Сотрудник
Пишу спецификацию ...	... ...	Пишу код Исправляю баги ...

Хорошим решением будет вывешивание таблицы на видное место.

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

В конце семинара Скотт рассказал о любопытном исследовании. Если ввести в проект изменение начинается зона хаоса. Даже если изменение в конечном счете позитивно, возможны колебания эффективности команды. Это происходит потому что люди привыкают к новому, учатся, настраивают коммуникации. Задача РП максимально сократить период хаоса (неизвестности).

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

Вопросы РП на каждый день

1. Что может пойти не так? Какие вещи с большой вероятностью могут пойти не так?
2. Что можно сделать чтобы их предупредить?
3. Какие датчики оповещения мы можем встроить в систему?

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

Скотт особо выделяет, что для решения любой проблемы необходим ответственный за проблему сотрудник. Но в любом случае РП контролирует решение проблемы.

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

Состав команды IE 1-я версия (в 1994 году)
1 РП на 10-15 сотрудников
5-6 программистов
3-4 тестера
2 технических писателя

Состав команды IE 3-я версия
2 РП на 40 сотрудников

Состав команды IE 4-я версия
25 РП на 200 сотрудников

* Небольшое отступление по поводу Scrum совещаний
Такие встречи сихронизации работы команды называются по-разному. Daily Scrum Meeting, stand-up meeting, иногда просто Status Meeting. В Luxoft принято называть Daily Scrum или просто скрам. Основная цель скрама — синхронизация работы команды и минимизация напрасной траты времени, связанной с недостаточной осведомленностью членов команды. Каждый член команды должен осозновать, чем занимаются другие люди и понимать в чем конечная цель проекта.

Мной были найдены иные описания Scrum совещаний (например Асхат Уразбаев): ежедневное (обычно утреннее) совещание длительностью 10-15 минут. Причем, встреча не предназначена для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы скрам совещания.

Каждый участник совещания отвечает на 3 вопроса:

1. Что сделано вчера?
2. Что будет сделано сегодня?
3. С какими проблемами столкнулся?

Примеры плохого скрама:

• Два человека начинают вдаваться глубоко в детали технической проблемы и решать ее на скраме
• Менеджер проекта начинает обсуждать бюджет проекта с заказчиком
• Аналитик достает ноутбук и углубляется в чтение почты
• Во время скрама два разработчика обсуждают вчерашний футбольный матч
• На вопрос менеджера проекта все отвечают «ничего нового»
• Каждый человек докладывает менеджеру проекта статус по своей задаче глядя ему в глаза
• Разработчик опаздывает на скрам

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

Как бороться с неправильным течением скрама:

Проблема	Решение
Члены команды «докладывают» РП, а не команде	Убедиться, что все понимают зачем нужен скрам (поделиться информацией внутри команды); Скрам мастер может избегать визуального контакта с говорящим (прятать глаза или становиться сзади).
Опоздания	Ввести небольшие (символические) штрафы за опоздания: Перенести скрам на другое время:
Обсуждения затягиваются	Проводить встречи стоя; Каждому человеку выделять на его рассказ не более двух минут. По истечении этого времени передавать слово следующему; На следующем скраме полезно убедиться, что все "Item list" были отработаны; Собирать "Item list". Как только загорается нешуточная дискуссия на техническую тему, РП записывает "Item list" в формате Что/Кто/Когда: Что Кто Когда Обсудить проблему с отрисовкой контрола Петя и Вася Сразу просле скрама
Во время скрама люди отвлекаются	Опять таки, встреча должна быть короткой; Можно принять решения о том, что во время встречи все должны стоять; Уходить в переговорную комнату подальше от почты и других соблазнов; РП правильно управляет совещанием — не дает разгораться посторонним разговорам.
Проблема языкового барьера — не все хорошо понимают английский	В таком случае можно использовать т.н. Scrum Notes. Каждый член команды (включая onsite team) перед скрамом высылает ответ на три вопроса в письменной форме скрам мастеру, который их консолидирует и рассылает всей команде. Это не отменяет сам скрам, но делает его проще для всех.

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

О развитии скрама
Скрам — это чрезвычайно полезная практика. С течением времени члены команды учатся правильно проводить скрамы и участвовать в скрамах. Проблем с проведением становится меньше (при условии, что вы решаете эти проблемы!). Через некоторое время скрам превращается в рутинное мероприятие, и вам может захотеться сделать его менее формальным и более веселым. Несколько советов от Jean Tabaka из книги Collaboration Explained:

• Начинать скрам с задорной песни. Нужно угадать название и исполнителя. Победитель получает приз — конфетку;
• Каждый человек раз в неделю рассказывает анекдот;
• Придумать прозвища и обращаться к другу другу по этим прозвищам;
• Приносить конфеты или другую еду по очереди на скрам.

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