DACI framework. Правильное принятие решений.

Привет!



Коллеги подсказали отличный инструмент, который может пригодится в вашей работы как ПМа. Странно, но информации по данному инструменту в сети не очень много.


Представим ситуацию (пример - вымышленный, все совпадения - случайны )

Бизнес в лице product owner озвучил, что необходимо запилить принципиально новую фичу. После первичных обсуждений команде проекта стало понятно, что в рамках используемых технологий решить задачу нельзя, нужно использовать что-то новое. Техлид команды рассказал о новом open-source фреймворке, о котором как раз услышал на конференции. Один из ведущих разработчиков упомянул, что когда-то уже приходилось участвовать в разработке подобного функционала и использовали готовый, но достаточно дорогой, фреймворк.

Если в рамках вашей организации/проекта уже есть устоявшийся процесс принятия решений - отлично!

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

Какие альтернативы?

Применить подход DACI (Driver+Approver+Contributors+Informed)!

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

Подробно о нем можно здесь.

Как использовать? 

Рассмотрим как его можно применить к описанной  в начале ситуации.
Поехали!

1.закрепляем ответственных 

Driver(т.е. тот кто двигает вперед процесс принятия решения) должен быть один. Точно так же как и Approver(т.е. тот за кем последнее слово в принятии решения). 

2. описываем текущую ситуацию и входящие данные

3. подключаем экспертизу коллег

4. описываем все "за" и "против" альтернативных решений, проводим оценку их стоимости, идентифицируем риски, описываем планы внедрения

Вариант1

Вариант2

5. фиксируем дополнительную информацию полученную в процессе 

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

Технический аспект

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

Другой вариант - сделать/найти шаблон в google docs. Для особых случаев -  доступен печатный вариант.

Заключение

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

Применение  DACI :

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

Улучшайте процессы, принимайте правильные решения правильно! )

Измерить программиста

Привет!

Время от времени меня привлекают к разработке системы оценки качества работы девелоперов.

Потребности озвучиваются разные. Если упростить, то всем хочется решить следующую задачу: взять разработанные критерии, посчитать показатели и сказать "Петя - 7 уровня,  Коля - 9 уровня. Потому: Коля для проекта полезнее, ему дадим лычку поинтереснее и на +XYZ денежных знаков больше чем Пете".

Возможно ли разработать такие метрики?
Если да, то почему каждый раз речь идет об очередной попытке  "изобрести свой велосипед"?
Если же невозможно, то что же делать?

Вопрос сложный. И вот почему.

В чем проблема? 

Я рассматриваю ситуацию с позиции проектного менеджера. С акцентом на "проектного".

Что такое проект? С точки зрения скучной PMBOK:

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

Многое в IT software development либо организовано как проекты, либо обладает проектными признаками.  Потому имеем такой фактор как "уникальность", а это приводит к сложности построения кросспроектных унифицированных метрик для оценки разработчика.

Сегодня разработчик пишет очередной (но все-таки хотя бы немного отличающийся) интернет магазин, завтра - решение для IoT, послезавтра - занимается разработкой решения для управления роботизированными высотными складами или блокчейном...В аутсорсе, в продукте, в стартапе...

Меняются технологии, команды, заказчики, требования к софтскиллам.

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

Как мерять? 

А если не пытаться сводить все к единственной оценке, а разложить на составляющие (компетенции)?

Можем столкнуться с другой проблемой - субъективностью и ситуативностью критериев оценивания.

Как померить все эти "знать", "понимать", "применять", "уметь", "сложные задачи" и т.д. придумать можно. Но это будет ваша оценка, понятная для вас и применимая в вашей ситуации/проекте/компании. Не более. И хорошо, если сумеете внятно разработчику разъяснить формальные признаки отличающие разные уровни, в рамках одной компетенции.

Можно же, конечно, оставить только метрики, которые измеримы.
Количество коммитов в github, количество закрытых багов в jira, количество успешно пройденных ревью кода с первого раза и т.д.

Если таких метрик мало, то повысим риск фокуса усилий на росте конкретных метрик. Вызывая проблемы в направлениях, которые остались без внимания в системе оценок.

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

Посчитали и что же?

Смотришь на эти финальные цифры и видишь, у сотрудника, согласно оценкам, тот или другой уровень... а вот весь твой опыт работы с этим конкретным человеком так и пытается вставить "да, но...".

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

Заключение

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

Разрабатывать такую систему нужно опираясь на аспекты, которые важны вашему проекту/компании/специфике работы.

Если модель компетенций на уровне компании не разработана, то создайте ее самостоятельно, для себя. Ведь это отличное подспорье в проведении one-to-one (вы же их проводите, правда?! ), performance review митингов.

Базовый список,  который  использую я,  выглядит следующим образом:

• Техническая экспертиза
• Качество выполняемой работы
• Объем выполняемой работы
• Инициативность
• Коммуникация
• Самостоятельность
• Дисциплина
• Лидерство
• Лояльность

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

Но наличие даже такого списка позволяет существенно упростить и повысить качество в части people management. 

Улучшайте процессы, растите команды! :)

Исправляем ошибки документирования

Всем привет!

Сложности документирования, с которыми мне приходилось сталкиваться при работе на разных проектах, описаны в посте "7 ошибок документирования".

А что вы как project manager можете сделать для  улучшения процессов связанных с документированием?

Советы и рекомендации - ниже.

Поехали!

1. Выберите правильный инструментарий

Найдите эффективную для вашего проекта связку task tracker  + content collaboration software.

От content collaboration software вам нужно:

• легкий в использовании функционал по работе с разметкой, таблицами, форматированием текста;
• поддержка версионности документов;
• возможности просмотра изменений между двумя версиями документа; 
• Спасибо, Кэп! возможности коллективной работы.

Три варианта, с которыми приходилось работать:

• Jira + Confluence
• Jira + Ms Word
• Redmine + MediaWiki

Mediawiki. “Дешево, но сердито”. Сложный функционал редактирования (особенно табличных данных) компенсирован низкой стоимостью решения.  Устанавливали различные  плагины, но все равно оказалось не очень удобно.

MS Word. Отличные возможности для редактирования контента, но отсутствие поддержки коллективной работы. Как выход - можно использовать систему контроля версий.

Confluence. Удобно управлять контентом,  есть интеграция с Jira, поддержка коллективной работы. Но стоит денег.

Самый удобный вариант  -  Jira+Confluence. Его и буду рассматривать в качестве примера в следующих пунктах.

2. Внедрите документирование в процесс разработки

• Как начать писать документацию и не забывать ее актуализировать? Сделайте написание документации обязательной частью процесса разработки! При чем не на уровне декларации “Нужно!”, а потому что процесс будет останавливаться-замедляться.

• Документация должна стать основой общения участников процесса разработки - аналитиков, разработчиков, тестировщиков и т.д.

• Документация должна быть единственным “источником правды”. Что не написано на странице в Confluence - не может рассматриваться как договоренность.

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

• Откажитесь от использования Jira для описания требований в тексте тикета. Вместо этого - используйте ccылку на описание требования в Confluence.

• Используйте задачи в Jira как отправную точку для grooming meeting. Выстраивайте задачи в порядке приоритета - упорядочите  обсуждения user story.

• Один из критериев готовности задачи к передаче в разработку - наличие описанного требования в Confluence.

• Следите за тем, чтобы вся значимая информация о требовании была отображена  в Confluence.

• Прививайте команде культуру бережного обращения с информацией в Confluence.

3. Использовать версионирование документов

• Описывайте только финальный вариант требования. Что, где и как должно поменяться покажет Confluence c помощью функции Compare selected versions. Это и время экономит, и количество ошибок уменьшает.

• В задаче в Jira - ссылайтесь на конкретную версию страницы в Confluence. Появится возможность работать над новой редакцией документа без влияния на тот вариант, который уже отдан в разработку.

• Альтернативный вариант - в Confluence указать ссылку на задачу Jira (используя магию Jira Issues Macro). Получаем двустороннюю трассировку “требование-задача”. Но теряем преимущество связанное с возможностью работать с разными версиями страницы.

4. Разработать стандарты

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

• Разработайте шаблон структуры требований. Это ускорит написание требований и позволит избежать потери важной информации. Иногда подходит простенькая структура user story, иногда на поиск и разработку подходящих шаблонов  может уйти несколько месяцев.

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

• В Confluence есть шаблон требований “из коробки”. Используйте его на старте процесса внедрения документирования.

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

Заключение

Возвращаясь к вопросу “нужна ли документация или можно обойтись без нее?”.

Для меня ответ очевиден - да, нужна. И не только для требований.

А как же тезис Working software over comprehensive documentation из agile manifesto?
Соблюдается!  Вносите в документы только “необходимую и достаточную” информацию. Не превращайте ее в "избыточную".

Улучшайте процессы, внедряйте документирование! )