Обсуждение

Enhanced reality ждет нас в самых неожиданных местах. В тему http://www.aleph.se/andart/archives/2007/09/nervous_about_resizing.html

Абсолютно в тему. Чудеса только-только начинаются.

> Увязали управление нормами/процессами с управлением программами/проектами. Расскажите как увязали, пожалуйста.

Уже рассказал подробно: http://ailev.livejournal.com/510186.html

Спасибо. Я уже отметился в том посте. Ремарка. Я не оригинален - разделение между операционной и проектной деятельностью описано в PMI PMBOK. А об управлении через проекты в разработке, как о неком гибриде можно прочитать в переводе SWEBOOK Сергея Орлика: «В последние годы стала активно применяться практика трансформации определенных видов операционной деятельности в программы, состоящие из однотипных проектов, выполняемых с определенной периодичностью. Такой подход получил название "управление через проекты"». (см. http://www.sorlik.ru/2-project_management.pdf)

PMI PMBoK нам тут не указ -- мы же на жизнь смотрим, а не в PMI PMBoK :) Дух нашего подхода сохраняет дух всех этих различалок "процессы-проекты": у "наших процессов" явно есть аспект повторяемости и отсутствие моментов начала-конца (у шаблона, вестимо, их нет), а у проектов -- есть уникальность (единичность) и присутствие момента начала-конца. Мы просто говорим, что "процесс" -- это не работа, а норма (описание). А проект -- это конкретный план конкретной работы. Вы мне подтверждаете: процессы -- это только не слишком привязанные ко времени описания разбиения работ (а не то, что происходит при каждом уникальном выполнении работ "по процессу"), а вот проекты -- это планы того, что будет происходить в конкретные моменты времени.

Ок-ок. Задам вопрос по-другому. Как сделать привязку к конкретным моментам времени? Нормированием времени на каждую задачу или?

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

Написано. Проблема не в том, что я учебники не читал :-) Проблема в практическом применении. Давайте кейс разберем: процесс "разработка ПО", шаблон процесса состоит из 5 стадий: (1) выявление требований, (2) проектирование, (3) конструирование, (4) тестирование, (5) дистрибуция. Инициация проекта - заключение договора на разработку, так? При заключении договора, необходимо оценить затраты, чтобы нарисовать план-график реализации процесса, так? Проблема в том, что более менее валидная оценка трудоемкости стадии (3) и (4) будет определена после стадии (2), а трудоемкость стадии (2) и (1) неизвестна.(Слово "трудоемкость" можно заменить словом "срок выполнения"). Получается, что о проекте (с mailstones и собственно план-графике) мы можем говорить, только в середине проекта, нет?

Шаблон не процесса, а проекта. Ибо процесс у нас -- это и есть шаблон, по которому далее штампуются проекты. В приведенном вами примере все легко решается путем постепенного уточнения проекта: он состоит отдельно из: -- структуры работ (которая прямо наследуется из процесса, если вы намерены следовать именно этому процессу). Как я понимаю, далее каждый этап детализируется: структура работ иерархична, в ней можно указывать и разные зависимости (типа приведенных вами -- уточнение трудоемкости кодирования и тестирования возможно только после проектирования). -- графика работ (времена выполнения работ, сроки milestones) -- росписи ресурсов. Эти "отдельности" в проекте изменяются независимо. Вполне возможно начальное состояние проекта с пустым графиком и пустыми ресурсами. Потом проект живет, более того (страшно! страшно!) структура работ в проекте может изменяться так, что она перестает соответствовать породившим ее процессам (ибо набрать структуру работ можно из целого ряда "библиотечных" процессов). Управление проектами при этом остается классическим или идет с использованием гибких методов, а управление процессами по факту является управлением знаниями о том, как выполнять работы в проектах.

ОК, это вопрос терминологии. Основная проблема в том, что "постепенное уточнение проекта" - нереалистичное условие. Большая часть проектов (например, разработка ПО на заказ), требует заранее определить бюджетное и временные рамки - они в договоре выполнения работ или купли-продажи указываются. А "страшно! страшно!" можно говорить про инвестиционный (внутренний) проект или проект с открытой датой и оплатой по факту. Но таких удобных для поставщика услуг проектов заказчики очень не любят (мы не на бюджетные организации работаем) - им нужны сроки и деньги ДО момента выполнения работ. Получается, что принципиально итерационная деятельность по разработке софта не укладывается в проектную схему (план-график). В большинстве случаев разработка под проектную схему подгоняется насильственно - делается оценка ad hoc каждой стадии, рисуется план-график с учетом текущей загрузки ресурсов и с большим запасом прочности по времени (буферизация), и задача PM сводится к тому, чтобы вовремя затыкать возникающие дыры (реальной оценки нет - постоянно реализуются риски неверной экспертной оценки трудоемкости) — это такая игра в угадайку. Не поэтому ли количество успешных проектов в разработке ПО меньше 40%? Надеюсь, проблема понятна.

А разве не эта проблема обсуждается в XP, когда там говорят про другой тип контракта? Вроде, про новые типы сделок по созданию софта довольно много написано в этих книжках.

Вы о быстрой разработке ПО?

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