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

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

7 ошибок документирования

Всем привет!

Если вы читали Agile Manifesto, то, вероятно, обратили внимание на пункт касающийся документации - “Working software over comprehensive documentation”.

Нужна или не нужна документация? Если нужна, то в каком количестве и что именно описывать? Вопросы интересные, но их обсуждение выходит за рамки данного поста. 

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

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

Для простоты описания предположим, что:

•     решение "Документации на проекте быть!" принято;
•     авторы документации будут называться “аналитиками”;
•     речь идет об описании требований  (“ТЗ”, “спецификация”, “описание фич”, “user stories”, etc.).

 

Ошибки, проблемы, нюансы

1. отсутствие понимания сложности

Писать документы начали. Что-то даже описали. Потом забросили, потому что есть более важные дела. Позже вернулись к описанию, но не всего (другие приоритеты). Часть требований - описана,  другая- описана не полностью, третья - вообще без описания.  Какие-то документы уже неактуальны. Но не понятно какие.

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

Перед началом осознанного внедрения процессов связанных с ведением документации необходимо задаться вопросом: действительно ли вы готовы ?

Готовы ли вы к тому, что на документацию будет необходимо выделять ресурс?

Мало создать документ. Его нужно поддерживать в актуальном состоянии.
И чем более нестабильные требования/бизнес/заказчик, тем больше вы будете тратить ресурс на то что бы это делать.И делать это нужно будет на регулярной основе.

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

2. необязательное документирование

"Сначала зарелизим на продакшн, а опишем потом...".

Хорошо, если "потом" таки настанет.

Но, вполне вероятно, что вместо необязательного документирования, вы будете заняты, чем-то более “актуальным, срочным, важным”.

А документация со временем так и не появляется либо окончательно теряет актуальность.

3. документация не вовремя

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

К моменту возврата к работе над фичей документацию пришлось практически полностью переписать. В итоге - потратили в два раза больше времени на описание.

Чем ближе к agile (и, соответственно, дальше от waterfall) у вас методология выбрана для проекта, тем больше шансов что написанная "в стол" документация окажется устаревшей.

4. хаос коллективной работы

Аналитик описал требования к фиче в google docs.

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

совершенно очевидные для аналитика (т.е. в google docs так и не появились, а остались в месенджере).

Представитель заказчика немного подкорректировал и финализировал описания в google docs. Но...  уже после того аналитик перенес все описания в задачу tasktracker'а и отдал в работу на тех.команду.

В конце-концов фичу реализовали. Но с овертаймами, демотивированной командой и слегка перенервничавшим заказчиком.

Какие проблемы получили?

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

Добавить к этому списку дополнительные усложняющие обстоятельства (e.g. сжатые сроки) и головная боль вам как project manager обеспечена!

5. отсутствие версионирования

Аналитик сделал описание нового функционала.

Функционал был достаточно большой, что бы его решили деливерить в нескольких спринтах. Зарелизили в продакшн первую часть.

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

Внесли изменения в SRS по первой части, но вторую часть до продакшена не довели - заказчик поменял приоритеты.

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

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

  

6. нестандартные стандарты

Один аналитик делает описания требований plain текстом. Другой - любит описывать в виде mindmap с короткими пояснениями. Третий - не признает ничего кроме блоксхем. И все трое пишут на трех разных языках. 

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

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

7.  неудобный инструментарий

"Да не хочу я тут ничего описывать. Неудобно же!" -  сказал
аналитик, пытаясь создать табличку 9 на 64 в формате
wiki markup

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

А это - лишний  раздражитель.

 

Заключение

При настройке процесса работы с документацией необходимо уделить внимание и таким аспектам:

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

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

Технические PM'ы

Всем привет!

Есть мнение, что знания и навыки в project management'е универсальны.

 И, да, есть знакомый который перейдя из IT в агросектор прокомментировал "Да какая разница? Тут программистами управляешь,там - трактористами".

С одной стороны - это, действительно, так. С другой стороны - в IT наблюдается устойчивый спрос на project management, которые имеют технический бекграунд.

Попытаемся разобраться зачем нужны technical project manager, какие вопросы они должны закрывать и подходит ли вам эта роль.

Какие PM'ы нужны  ? 

Примеры того что могут ожидать от technical project manager как в небольших продуктовых компаниях, так и в лидерах рынка :

- ...Experience with hands-on technical delivery. Former developer is preferred. A deep understanding of digital technologies used to develop real-time web sites and mobile applications, including Java, Javascript, HTML, CSS, XML and JSON file transforms and handling...
- ...Knowledge of web architectures (AWS), CMS systems and modern online marketing tools...
- ... Development experience (open source in LAMP stack, HTML, CSS, JS). Deep Technology and Architectural Understanding...
-...A vision of future technologies and marketing trends...
-... Excellent understanding of wider industry context & trends, both technical & product

Т.е. технический бекграунд предполагается разный.

Где-то достаточно быть в курсе последних технических новинок.

Чаще в роли TechPM видят специалиста, который свернул с пути развития по технической вертикали в сторону менеджмента. Либо даже и не бросал активное участие в разработке, но приобрел некий менеджерский опыт.

Зачем опыт разработки PM'у?

Несколько реальных кейсов зачем могут понадобится PM'у технические навыки:

 1. расширение эккаунта, повышения доверия заказчика

 У компании-аутсорсера есть небольшой, но долгосрочный проект у заказчика в конкретном домене, и очень большие планы по расширению эккаунта. PM должен не только успешно выполнить текущий проект, но и постоянно предлагать заказчику варианты решения его бизнес потребностей смежных с проектными, повышая тем самым его доверие к PM'у/проекту/ компании.

2. роль СТО/техлид по совместительству

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

3.onsite менеджер в технической вертикали

Стремительный рост изначально небольшой out-staff команды инженеров "здесь" с руководством "там" приводит к проблемам в process & people management. Стало очевидно, что руководитель не может решить удаленно все возникающие вопросы. А так как в роли PM'а выступает СТО компании-заказчика, то и onsite PM был необходим с сильным техническим бэкргаундом, кто-то из "своей песочницы".

4. синхронизация команд

Проект с непростой организационной структурой: 4 agile команды  с общим количеством  40+ инженеров, scrum master'ов и product owner'ов.  По разработке продукта на уровне отдельных команд, вроде бы, все хорошо: фичи выпускаются, баги фиксятся, заказчики и исполнители в целом довольны. Но начали возникать существенные отличия  от команды к команде в процессах, технических стеках, инженерных практиках. Одна из задач, которую нужно решить PM'у - изменить ситуацию по образованию "зоопарка" решений и синхронизировать команды в выработке технических подходов и практик.

5. people management инженеров

TechPM понадобился в ситуации, когда инженеров нужно растить, а заниматься этим некому. HR недостает hardskills, а у лидов не хватает softskills/времени/навыков для того что бы растить команду. Development plan&performance review для разработчиков и QA? Нет, не слышали.

5. technical solution review

В команде есть solution architects/техлиды, но необходимо валидировать их технические верхнеуровневые решения. И это возлагается на PM'a. Очевидно, что при неизбежно существующей разнице в экспертизе, условный инженер доведет PM'a до границ (не) компетентности. Но чем глубже "знание предмета" у PM'a, тем дольше это будет длиться и тем больше правильных вопросов по обсуждаемой архитектуре/техническому решению PM успеет задать.

6. упрощение коммуникации с техническими специалистами в команде (в противовес позиции "Да ты же PM/бывший QA-аналитик! О чем с тобой вообще разговаривать?!");

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

С другой - встречающиеся проблемы со софсткиллами таких специалистов, смещение акцентов в менеджменте в IT с command&control в сторону servant leadership, потребность в людях пребывающих на стыке бизнес и технических интересов.

Ты - TechPM? 

Почему же не каждый, даже опытный, PM сможет осилить специфические задачи, которые возлагаются на technical project manager'а в описанных кейсах?

-  Отсутствие технического опыта. Речь об изначально нетехнических PM'ах.  Свитчеры из других отраслей, которые делали крутые проекты в аргосекторе, открывали крупнейшие в городе пивные магазины, запускали нашумевшие ТВ-проекты, могут быть хорошими управленцами, но в роли околотехнических PM'ов в IT скорее-всего не подойдут.

-  PMы с отсутствием интереса к IT-инженерии. Не всем интересно разбираться с технической составляющей проекта. Управления рисками, customer relationship management, WBS, PERT - интересно и вдохновляюще, а вот SOLID, git, SOAP API и Kibana ничего кроме уныния не вызывают. Если позиция подразумевает постоянное пребывание в контакте с инженерной проблематикой, то эта работа не для вас.

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

- Специфичность позиций. Иногда происходит подмена понятий и вместо teamlead'а (возможно с чуть более прокачанными определенными менеджерскими скиллами) ищут project manager'а. Т.е. изначально нужен разработчик, а не управленец.

Будь особенным!

Количество откликов на PM'ские вакансии согласно информации на dou на текущий момент составляет около 20 откликов на одну вакансию. Для сравнения - у технических специалистов в зависимости от профиля этот же показатель колеблется в пределах 5..10. И ситуация врядли будет кардинально меняться в сторону уменьшения.

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

Возможностей оставаться "в тренде" в наше время дистанционного обучения, технических блогов, многочисленных конференций и open-source проектов более чем достаточно. Дерзайте!

Правильные инструменты или 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 и не является каким-либо моим личным ноу-хау. Но, как показывает практика, иногда даже простое и очевидное приходится объяснять :) 

Замените разбитые окна!

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

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

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

Пример?
Опоздание на стендап... Все должны приходить вовремя, без вариантов.

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

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

Daily standup meeting. И у вас получится!

Практически во всех резюме, которые довелось читать последнее время, есть информация о
agile/scrum. Что первым делом вспоминает кандидат, когда спрашиваешь об этом опыте? Практически всегда -  daily standup meetings!  А иногда - это единственное, что он может внятно рассказать о гибких методологиях.

При внедрении мной daily standup meeting в разное время и с участием разных людей возникали однотипные вопросы либо озвучивались типичные "проблемы".
Где-то  эти вопросы были продиктованы зачаточным состоянием внедрения scrum'a, а где-то - каргокультовостью оного.

Мой ТОП5
1. "Зачем собираться? Одни митинги - работать некогда."
Страх перед выступлениями, нежелание брать на себя ответственность либо показывать свое безделье "отчитываться", негативный опыт с затратными по времени митингами... Причины  у каждого могут быть разные, но митинги таки вводились, участники втягивались в процесс и такого рода вопросы отпадали сами-собой, т.к. и польза и ненапряжность митингов становится быстро очевидной.

2. "...Вчера - кодил/тестировал, сегодня - аналогично..." 
Другой вариант  этого же - слишком детализированное описание ( "..Пришел, включил, почитал, ответил, встретил, поговорил и...")
Ориентация на результат, а не на процесс - это важно :) Собственно, это и объясняется в ответ. Люди, в большинстве своем, быстро приходят к нужному формату выступления, но нет-нет да и вылазит у кого-нибудь "работу работал".

3. "А зачем стоять? Так тяжело, давайте сидя!"

Только стоя! И это работает.  На практике случалось, что члены команды сами предлагали оптимизировать дейли стендап "потому что надоело и невозможно стоять по 30-40 минут". А командная самоорганизация - это ведь тоже важно :)

4. "...А давайте соберемся на 6 минут позже, а то я чай не успеваю приготовить."
Я люблю теорию "разбитых окон", которая говорит о том, что небольшие нарушения правил, тянут за собой чуть большие нарушения, а те в свою очередь еще большие, и в конце-концов игнорирование правил полностью..
А ведь выполнение командных договоренностей - это важно :)
Потому я борюсь с  переносами, опозданиями на митинги  всеми доступными средствами.

5. "...А вот здесь я расскажу по-подробнее.." или "Я только спросить!"
Боль и печаль стендап митингов - это растягивание времени проведения за счет дискуссий и выдачи излишне детализированной информации, которая неинтересна всей части команды.
Тут палка о двух концах: с одной стороны есть четкая структура выступления "вчера-сегодня-проблемы", с другой - порой стендап это единственное удачное время-место для того что бы рассказать нечто полезное-интересное либо здесь и сейчас по-быстрому порешать. И иногда бывает эффективнее потратить небольшое время на стендапе, чем собирать отдельно этих же людей для обсуждения в другое время и в другом месте. В любом случае модератор митинга должен контролировать развитие таких ситуаций.
Я в таких случаях даю, как правило, не более 5 минут и выношу обсуждение на afterstandup meeting.

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

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

Notes. Meetup with Benny Kenian, VP Engineering at Aol Video

Несколько заметок по мотивам митапа с Benny Kenian (VP Engineering, Aol Video) на котором удалось побывать 12.05.2017 (link).

Спикер - позитивный, с интересным опытом построения распределенной команды из 200+ человек на 10+ локаций. Рассказывал, какие проблемы пришлось решать, какие подходы применять.

ТОП 10 новых/интересных и известных/распространенных моментов из его выступления:
...если вы всем нравитесь, то вы что-то (все) делаете неверно.
...быть руководителем в моменты, когда вы кому-то поднимаете ЗП - легко,  более интересно - когда нужно кто-то уволить :)
...задача руководителя заключается не в том, чтобы делать сотрудника счастливым любой ценой.
...то что мы говорим, в значительной степени влияет на то как мы действуем, потому в формулировках членов команды Benny "мы" значительно больше чем "они". И, чтобы этого достичь, Benny пришлось приложить определенные усилия :).
...если есть возможность быстро увольнять, то слишком тщательный отбор нового члена команды - напрасная затрата ресурсов. Проще и дешевле проверить человека в работе.
.. распределенность команды дает возможность не ограничивать себя лишь одной локацией при поиске правильных людей для проекта. И Benny этим пользуется :)
...согласно исследованиям - компании/проекты со смешанной командой более жизнеспособны чем те, в которых все члены - более одинаковы.
...стройте правильные коммуникации в команде, между частями команд.
...используйте разные средства коммуникаций для разных целей... Чаты, телефон, переписка, Google documents - для всего своя ниша.
...члены команд Benny летали самолетом, чтобы решать вопросы с другими командами много и часто, т.к.  это более эффективно чем решать вопрос удаленно.

Благодарность организаторам и Benny!