“Это НЕПРИЕМЛЕМО!!!”

Сегодня подготовил и отправил менеджеру заказчика календарный план первого этапа проекта. Объём работ был согласован, состав команды проекта утверждён, дело оставалось, по сути, за продолжительностью работ. Ok, составил график, согласовал и отредактировал с командой, всё отлично. Отсылаю менеджеру со стороны заказчика и через 2 минуты получаю в скайп: “Это НЕПРИЕМЛЕМО!”

Вот так вот. Никого не интересует реальность. Народ хочет пожить сказкой, а когда показываешь реальность, тебе говорят, что это неприемлемо =) Забавно, это уже не первый мой проект, который я оцениваю, и я нутром чую, что та дата, которая указана в колонке Finish – реальна процентов на 70. Т.е. даже с учётом летних отпусков разработчиков, задержек со стороны подрядчиков и наших задержек, с учётом основных рисков и того, что мы до сих пор не учли и не учтём - мы таки можем успеть к указанной в плане дате, если хорошо поработаем. Даже неумолимая статистика, которую я веду последние два года по всем своим проектам (собираю метрики до и после), говорит о том, что вероятность успеть раньше этого срока – крайне невелика.

И вот, блин-горелый, в который раз первые слова, которые приходится слышать после обнародования действительно реального плана – это “Это НЕПРИЕМЛЕМО!!!”.

Назначил на понедельник встречу по поводу обнародованного плана. Даже интересно, согласится ли заказчик с указанной датой, увеличит бюджет или урежет функциональность… Время покажет ;)

Эдвард Йордон (автор книги “Путь камикадзе” она же “Смертельных марш”) приезжает в Россию!

Эдвард Йордон, автор Смертельного марша или Пути камикадзе (в оригинале “Death march”), планирует провести в Москве и Санкт-Петербурге семинар «Управление безнадежными проектами» (“Managing Death-March Projects”).

Семинар обещает быть очень интересным! И не только для менеджеров проектов, но и для команд разработчиков.

О самом семинаре можно подробнее прочитать тут.

Стоимость: 11 350 р. Действуют скидки.

Примечательно, что посещение семинара даёт 8 PDU.

Пять основных рисков в программных проектах

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

Сейчас я составляю высокоуровневый календарный план (вернее его заготовку), который потом будет уточняться и согласовываться со всей командой. После оценки трудозатрат на первую итерацию я заложил 10% на риски и 10% на управленческий резерв. При защите плана проекта перед спонсором необходимо обосновать каждый пункт плана, т.к. заказчики деньги считают. Для обоснования времени, выделенного на риски данной фазы я взял 5 основных рисков программных проектов, описанных в книге Тома ДеМарко и Тимоти Листера “Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения” и проанализировал их с точки зрения вероятности возникновения и возможного урона при наступлении события риска. Вот список этих рисков с моими комментариями в скобках:

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


2. Изменение требований (заказчик захотел “зелёный бант” и что бы “оно пело и плясало” в середине проекта).


3. Текучесть кадров (можно его назвать ещё просто – Кадры и в качестве подпунктов включить Текучесть кадров и всякого рода Отпуски, неожиданные отгулы, болезни и т.д. – так я и сделал).


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


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

Очень рекомендую всем, кто ещё не занимается управлением рисков в своих проектах, оценивать хотя бы эти пять основных рисков. Это очень освежает =)

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

Видео уроки по подготовке к PMP

В одном из подкастов Корнелиуса услышал о коротеньких (5-10 минут) видео-уроках, основанных на PMBOK. Данные видео-уроки можно смотреть прямо с сайта, для этого достаточно зарегистрироваться. Сами уроки бесплатные. Если ты готовишься к сдаче PMP, то, на мой взгляд, после обеда, вполне можно потратить минут 10-15 на просмотр данного материала.

Итак, идём и смотрим PMP® Exam Prep Lunchtime Lecture Series

Заказчик и предварительные оценки

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

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

Эх, одна голова хорошо, а три лучше – пойду, всё же, посоветуюсь с коллегами =)

А вы в каком виде доставляете предварительные оценки до своих заказчиков, что бы в последующем эти оценки не сыграли против вас?

P.S. Кстати, полезная, на мой взгляд, книга о том, как можно оценивать малые и средние проекты: “Сколько стоит программный проект”, С. Макконнелл.

Диаграмма процессов управления проектами

На сайте Андрея Куликова, PMP (кстати, интересный сайт – советую покопаться!) нашёл картинку с диаграммной процессов управления проектами. В отличие от того, что можно найти в PMBOK, в данной диаграмме процессы сгруппированы по пяти фазам очень наглядно.

Данную диаграмму можно применять в качестве check list’а для себя и своих проектов. Я распечатал эту диаграмму и повесил на стену около рабочего места, подкрасив маркером те процессы, которые я уже интегрировал в свою практику управления проектами. Теперь, на любом из этапов моих текущих проектов (а их аж 4 штуки сейчас, о господи! =))) я буду смотреть на данную диаграмму и стараться закрасить ещё один её пунктик. Т.е. ещё на один процесс усовершенствовать свою рабочую методологию.

Конечно, применять в своих проектах всё то, что описано в PMBOK вот так сразу – сложно, да и не имеет смысла. Но об этом я напишу в другой заметке =)

А вот и сама диаграмма (кликабельно):

Источник: "Диаграмма процессов Риты".

Интересный подкаст Карнелиуса и Дины

На днях прослушал интересный подкаст известного многим Cornelius Fichtner, PMP, в котором он общается с так же многим известной Dina Henry Scott, PMP на тему управления проектами вообще, без привязки к какой-то определённой области знаний или методике. Вроде бы обычное бла-бла-бла между двумя PM’ами, но на мой взгляд очень интересное и местами смешное бла-бла =) Рекомендую для прослушивания в непринуждённой обстановке.

Итак, слушаем “Everyday, Real Life Project Management” с Cornelius Fichtner, PMP и Dina Henry Scott, PMP: прослушать.