Трекер для управления проходом или управления выживанием проекта?

Пост родился из обсуждения:

Victor Erukhimovich Не уверен, что не офф-топ... если я правильно понимаю, о чем вообще тут речь, конечно. А насколько в принципе освещена тема трекинга задач с плавающей постановкой?

Like · Reply · 1 · 8 hrs

Alex Turkhanov На всяких ивентах, посвященных адаптивному кейс менеджменту вполне себе тема обсуждается несколько лет и проработана. Плюс, Эджайл. Alexey Deryushkin есть, что на эту тему?

Like · Reply · 1 · 8 hrs

Alexey Deryushkin Alex Turkhanov, где задачи не меняются, там и word сойдет. :) Я вообще плохо представляю , как в условиях неопределенности или нестабильности управлять чем бы то ни было без трекера.

Есть примеры применения оного, например, в банках НЕ в ИТ, а в ритэйле.

Like · Reply · 1 · 8 hrs

Alex Turkhanov Так а теория в виде книжек и статей есть? Или все в устной традиции только?

Like · Reply · 8 hrs

Victor Erukhimovich Alex Turkhanov Аджайл, кстати, тоже не отвечает на этот вопрос. Вернее, отвечает не идеально. Пример (из жизни) - разработка ИТ-решения на новой платформе, по которой еще нет статистики, для бизнес-процессов, по которым еще никто не работал. Соответственно, начинается все с прототипа. Изначальное допущение - что прототип будет сделан в результате последовательности задач 1 и 2, каждая размером в один тайм-бокс. Но по завершении первого таймбокса становится ясно, что задача 1 на самом деле состоит из 5 подзадач по таймбоксу каждая, то есть прогресс из 100% сползает в 20%. Или вообще случай (Андрей знает) - проект по бизнес -оптимизации, когда в стратегической фазе определили ряд инициатив, а потом на фазе внедрения заявленный эффект был достигнут, но с помощью почти непересекающегося списка альтернативных инициатив. То есть - прогресс по проекту - 100%, хотя прогресс по большинству задач - 0%. То есть, когда мы треким прогресс, мы треким задачи, про которые мы еще не знаем, что они не релевантны, про которые мы уже знаем, что они не релевантны, про которые мы еще не знаем, что оценка эффорта не соответствует действительности, и про которые мы уже знаем это. И в эту картину мира еще добавить зависимости от смежных проектов и субподрядчиков :) Мой скудный опыт пока не придумал ничего лучше, чем трекить относительно текущего снапшота плана/оценок, а снапшот обновлять по-возможности каждую неделю (что, в принципе, относительно легко встраивается в еженедельную агенду по управлению RAID). Что остается за кадром пока - оценка процента, на который можно доверять собственно текущему снапшоту, и управление ожиданиями стейкхолдеров, которые норовят каждый снапшот воспринять как истину в последней инстанции... вот если есть какие-то техники, адресуюшие этот букет проблем - было бы очень интересно послушать! Или почитать :)

Like · Reply · 6 hrs · Edited

Alexey Deryushkin Alex Turkhanov, не знаю, книжек-статей именно по применению трекеров вне ИТ не искал. JIRA в Райффайзенбанке не для ИТ ставилась, знаю. Свечку не держал.

Like · Reply · 6 hrs

Alexey Deryushkin Victor Erukhimovich, нормальная такая ситуация, жизненная. :) Звучит так, как будто по задачам definition of done был не очень корректно сформулирован, или декомпозиция неверно проведена. 

Если DoD определен хорошо, и декомпозиция задач по модели invest, то можно вполне предсказуемо работать с метриками kanban или вообще банальным burn-down chart. В ситуации "все с нуля" стартовую точку надо будет тщательно выбрать, чтобы не 5-6 итераций набирать статистику, а 3-4.Like · Reply · 6 hrs

Alex Turkhanov Наблюдаю путаницу с throughput management и project progress tracking. Это разные темы. Похоже, надо написать вечером про OMG Essence и alpha states tracking.

***

Разберем ситуацию с позиций OMG Essence kernel http://www.omg.org/spec/Essence/1.1/

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

В kernel есть всего три основных понятия:

Alphas – representations of the essential things to work with. The Alphas provide descriptions of the kind of things that a team will manage, produce, and use in the process of developing, maintaining, and supporting software and, as such, are relevant to assessing the progress and health of a software endeavor. They also act as the anchor for any additional sub-alphas and work products required by the software engineering practices.

Activity Spaces – representations of the essential things to do. The Activity Spaces provide descriptions of the challenges a team faces when developing, maintaining, and supporting software systems, and the kinds of things that the team will do to meet them.

Competencies – representations of the key capabilities required to carry out the work of software engineering.

Каждый из семи основных функциональных элементов схемы называется альфой, и у него есть поведение – он перемещается по Activity spaces.

Для продвижения альф по состояниям activity spaces в каждой области нужны определенные компетенции.

Состояние альфы определяется чек-листом.

По разному распределяя состояние альф между стадиями проекта, можно получать различные модели жизненного цикла:

***
Трекер, как технология, используется в двух практиках:
1) Управление проходом, наиболее часто используемая, это то, о чем пишут в исходном обсуждении

• "по которой еще нет статистики, для бизнес-процессов, по которым еще никто не работал. Соответственно, начинается все с прототипа. Изначальное допущение - что прототип будет сделан в результате последовательности задач 1 и 2, каждая размером в один тайм-бокс. Но по завершении первого таймбокса становится ясно, что задача 1 на самом деле состоит из 5 подзадач по таймбоксу каждая, то есть прогресс из 100% сползает в 20%. " 
• "То есть, когда мы треким прогресс, мы треким задачи, про которые мы еще не знаем, что они не релевантны, про которые мы уже знаем, что они не релевантны, про которые мы еще не знаем, что оценка эффорта не соответствует действительности, и про которые мы уже знаем это. " 
• "Если DoD определен хорошо, и декомпозиция задач по модели invest, то можно вполне предсказуемо работать с метриками kanban или вообще банальным burn-down chart. В ситуации "все с нуля" стартовую точку надо будет тщательно выбрать, чтобы не 5-6 итераций набирать статистику, а 3-4"

2) Управление выживанием проекта (это как раз очень условно и ограничено соответствие снапшота или, в традиционном ПМ БОК изложении "базового плана" реальному положению дел). Другими словами, насколько текущее состояние проекта соответствует плановому состоянию дел, с использованием заявленного на старте проекта метода.

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

Ответ на поднятую проблему "как без процентов оценить прогресс проекта?" - использовать kernel. Прогресс проекта - это продвижение альф по activity spaces, а не процентное выражение выполненных работ по сравнению с запланированным.

Конкретика будет позже, но пример чек-листа на прохождение контрольной точки могу дать прямо сейчас:
Контрольная точка КТ1 «Проект запущен»
(подальфа "Архитектура работ" Работ, состояние "Архитектура предопределена")
Подзадачи:
1) Спонсор согласовал цели по SMART, задачи и продукт проекта.
2) Заказчики проекта определены, их требования и ожидания собраны и согласованы со спонсором.
3) Проект разбиты на фазы, основные контрольные точки проекта, текущие и целевые значения проектных KPI определены и согласованы со спонсором и заказчиками.
4) Компетенции и ресурсы, необходимые для начала реализации проекта, определены, спонсор и заказчики подтвердили выделение этих ресурсов на проект.
5) Проект согласован заинтересованными сторонами.

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

6) Кик-оф организован.

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

7) Лидер проекта поставил проект на контроль.

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

8) Лидер проекта регулярно отчитывается спонсору и проектному офису о ходе работ проекта, используя трекер и чек-листы контроля проекта.
9) Лидер проекта организовал детальное планирование проекта. В результат планирования входят:

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

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

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

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

Фактически, для отслеживания здоровья проекта надо создать в трекере workflows и загнать туда альфы и граф состояний с чек-листами с выводом индикации на панель. Тогда он будет с одной стороны отслеживать проход (throughput), а с другой будет доступна оценка прогресса командой всех ключевых аспектов проекта.

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