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 ошибок документирования".

А что вы как 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?
Соблюдается!  Вносите в документы только “необходимую и достаточную” информацию. Не превращайте ее в "избыточную".

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

Правильные инструменты или Email vs Skype vs Meeting

Привет!

Как-то я попал в команду, где все решалось через Skype. Для меня, привыкшего к связке Outlook + Communicator + корпоративный портал на SharePoint, настроившего много-много фильтров в почте и использовавшего встроенный в Outlook функционал по Task'ам для ведения to-do листа, происходящее вокруг вызывало спектр эмоций от шока до недоумения. Объявления, вопросы, споры, выяснения отношений решение конфликтов, согласования... Всё-всё-всё происходило в "тысяча и одном чате". Нужно было читать-писать-переключаться между многочисленными обсуждениями, пытаясь не упустить что-то важное и пропуская изрядную долю неважного. И ладно мне, менеджеру, для которого много коммуницировать - это часть обязанностей. А каково девелоперам, QA? Как же "вхождение в поток", "погружение в задачу" и всё такое прочее?

Позже оказалось, что в целом - никак :) Т.е. время от времени практически каждый приходил к мысли "либо общаться в чатах, либо выполнять поставленные задачи". Делать одновременно и то, и другое - неэффективно.

Хорошо, а какая же альтернатива? Что нужно делать по-другому?

Перескочу через одно звено в цепочке очевидных логических рассуждений и выдам свои best practice :)

Все просто:

Используйте разные инструменты для разных целей.

Итак, список (далеко не полный, но все равно длинный) из того что, когда и как использую я.

E-mail

Достоинства: 

- фильтры
Не понимаю, как можно использовать почту без фильтров :) Любимый инструмент для отделения и контроля важного/срочного/требующего ответа.

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

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

- письмо как источник информации для задачи
Несколько кликов и письмо превращается в задачу в твоем to-do листе. Очень экономит время.

- письмо как триггер для event
Аналогично, но уже в части организации митингов.

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

Использовать: 
- постановка задач
Особенно, если в силу каких-либо причин нет возможности/необходимости использовать корпоративный тасктреккер. Стоит поставить в копию письма-задачи и себя - появляется возможность положить куда-то такое письмо и самому не забыть о задаче :)

- фиксация договоренностей и знаний
История, структура папок для хранения, структурирование текста - все это помогает сохранить,быстро найти и понять. Если вдруг почему-то у вас не принято использовать системы подобные Confluence, Wiki.

Не использовать:
- обсуждения, особенно сложных вопросов
Многочисленные ответы на ответы, отвеченные на ответы... (ну вы понимаете, да?) только затянут согласование спорных позиций. Просто пытайтесь избегать попадания в такие ситуации, предлагая альтернативный вариант обсуждения.

- быстрое решение вопросов
Сам инструмент не предполагает скорости. Звоните-встречайтесь-говорите, это более надежно.

Особенности:
- использование информативной и лаконичной тема письма - инвестиция в уменьшение времени на поиск информации в дальнейшем.

- осмысленное использование типов адресатов (to/cc/bcc) позволит более точно обозначить желаемую степень вовлеченности участников.

- форматирование текста в теле письма легко и эффективно акцентирует внимание на ключевых моментах вашего сообщения.

Instant messengers* 

*На примере Skype. Его в силу разных причин использовал больше всего.

Достоинства:
- вовлеченность участников
Можно обсуждать активно, можно обсуждать с паузами
- коллективное обсуждение


Недостатки:
- потеря информации
Если общаешься не в личке, а в общем чате, то найти информацию часто порой либо
сложно, либо практически невозможно.

- написать!=сказать
Я отношу это к недостаткам, но для части людей - это, наоборот, дополнительные возможности. И речь вот о чем: согласно исследованиям 60-70% нашего живого общения - это невербальная часть (жесты, мимика, поза и т.д.). Т.е. то что вы говорите составляет меньшую часть. Больше информации дает то как вы говорите. И если вы хороший коммуникатор и активно используете невербалику, то, возможно, теряете часть этих 60-70% при общении "не голосом".
Другое дело, если общение в живую не вызывает особого энтузиазма. А в IT таких людей немало :) Тогда вместо того что бы обсудить голосом, вам будут строчить-писать, даже если вы сидите рядом за соседним столом.

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

- сбор информации по проблеме
Бывает, что знаниями по какой-то проблеме владеют несколько человек, и не всегда понятно кто именно. Возможность легко добавлять нужных, убирать бесполезных участников чата позволит повысить эффективность выяснения.
Не использовать:
- обсуждения, особенно сложных вопросов
Как и в случае с почтой, обсуждение темы по которой "есть что сказать" легко превратить в пустую трату времени. Пишем мы, обычно, медленнее чем говорим. А если же пишем быстро, то чаще всего непонятно. А если
еще и участников более чем 2, то понять кто-кому-что-на что ответил - проблема. Да и правило "не перебивать, дослушать до конца" как-то не особо получается соблюдать.

Особенности:

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

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

- "Маркер трех сообщений". Очень легко вовлечься в длинную переписку все вновь и вновь пытаясь объяснить собеседнику свою невероятно простую мысль. А он все не понимает и не понимает. И общаетесь же на одном языке, а диалог все не идет! Я использую подход, который называю "маркер трех сообщений". Если одно и тоже приходится повторять трижды, то стоит обсудить это голосом. Если за три раза не удалось объяснить, то четвертая-пятая-шестая-... попытка, скорее всего, тоже будут неуспешны.

Митинги

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

Конечно же, большая часть написанного относится к common sense и не является каким-либо моим личным ноу-хау. Но, как показывает практика, иногда даже простое и очевидное приходится объяснять :)