3.6 ОРГАНИЗАЦИЯ РАБОТЫ
Авторы раздела:
Потапова Е. Г.
Романов Ф. А.
Малахов А. А.
Коротких С. С.
Для работы с использованием гибких подходов необходим обмен информацией о планах, задачах и продукте. Для этого предлагается набор инструментов визуализации и планирования — от досок и стикеров до ИТ-сервисов коллективной работы.
Для работы с использованием гибких подходов необходим обмен информацией о планах, задачах и продукте. Для этого предлагается набор инструментов визуализации и планирования — от досок и стикеров до ИТ-сервисов коллективной работы.
3.6.1 ИНСТРУМЕНТЫ СОВМЕСТНОЙ РАБОТЫ КОМАНДЫ
3.6.1 ИНСТРУМЕНТЫ СОВМЕСТНОЙ РАБОТЫ КОМАНДЫ
Время чтения: 9 мин.
Современное П О, предназначенное для командного взаимодействия и постановки задач, обеспечивает удобную и быструю совместную работу команды, прозрачность и систематизацию, позволяет определить приоритетные задачи и передавать их друг другу, накапливать информацию по проекту и т. д. Все инструменты можно разделить на категории:
- управление задачами;
- коммуникация;
- библиотека знаний.
Время чтения: 9 мин.
Современное П О, предназначенное для командного взаимодействия и постановки задач, обеспечивает удобную и быструю совместную работу команды, прозрачность и систематизацию, позволяет определить приоритетные задачи и передавать их друг другу, накапливать информацию по проекту и т. д. Все инструменты можно разделить на категории:
- управление задачами;
- коммуникация;
- библиотека знаний.
Управление задачами
Инструменты для управления задачами, которые сочетаются с двумя самыми популярными фреймворками — Kanban и Scrum:
Для эффективной работы будут полезны удобные инструменты коммуникации и фиксирования договоренностей, например:
Для ускорения процессов и обучения новых сотрудников требуются библиотеки знаний:
Инструменты для управления задачами, которые сочетаются с двумя самыми популярными фреймворками — Kanban и Scrum:
- Trello (https://trello.com) — онлайн-версия доски Agile, описанной ниже. Это очень популярный сервис, который используют по всему миру.
- Kaiten (https://ru.kaiten.io) — российский аналог Trello.
- JIRA (https://ru.atlassian.com/software/jira) — инструмент для постановки задач и контроля их выполнения, он имеет весьма широкую функциональность, но достаточно сложный и требует определенного времени на освоение, удобен как для малых, так и для больших (особенно) проектов и команд. Также существует огромное число различных модулей и расширений Jira, в том числе от независимых разработчиков.
- Basecamp (https://basecamp.com) — интуитивно понятный и простой инструмент постановки задач, подходит скорее для небольших команд.
- Redmine (https://www.redmine.org) — еще один достаточно масштабный инструмент управления проектами, включает в себя отслеживание ошибок, требует дополнительного времени на освоение.
Для эффективной работы будут полезны удобные инструменты коммуникации и фиксирования договоренностей, например:
- Slack (https://slack.com) — удобный корпоративный мессенджер, который используется по всему миру.
- Skype (https://www.skype.com/ru/) — распространенный мессенджер со многими бесплатными функциями, интегрирован с почтовым сервисом Outlook.
- Dialog (https://dlg.im) — российский аналог Slack.
Для ускорения процессов и обучения новых сотрудников требуются библиотеки знаний:
- Confluence (https://ru.atlassian.com/software/confluence) — популярный международный и универсальный инструмент, у которого есть полномасштабная интеграция с JIRA. Позволяет структурировать любые типы информации.
- Gitlab, Github и др. (https://github.com) — инструменты для хранения программного кода и документации и управления программным кодом.
- Системы управления знаниями, сделанные по принципу Wikipedia, например на основе Mediawiki (https://www.mediawiki.org).
3.6.2 ИНСТРУМЕНТЫ УПРАВЛЕНИЯ
3.6.2 ИНСТРУМЕНТЫ УПРАВЛЕНИЯ
Пример доски, созданной с помощью сервиса Trello. см.: Сервис «Спортивная страна» // Trello. URL: https://trello.com/b/g9XkLqfv/сервис-спортивная-страна.
3.6.2.1 ДОСКА ЗАДАЧ
Доска задач — один из основных инструментов Agile-подхода, позволяющий отслеживать всю работу. На доске размечены столбцы, в которых размещаются карточки (на физической доске — стикеры). Каждая карточка — это результат, которого должна добиться команда в рамках разработки. Результатом считается улучшение продукта, которое доступно для пользователя вашего продукта. Каждый столбец — это процесс, который должна пройти карточка, чтобы перейти в статус «выполнено». Смысл доски в том, что визуализируется ход проекта по всем направлениям для всех участников, у них появляется возможность быстро вычленить сложные и проблемные этапы или элементы и внести корректировки (рисунок 9).
Доска задач — один из основных инструментов Agile-подхода, позволяющий отслеживать всю работу. На доске размечены столбцы, в которых размещаются карточки (на физической доске — стикеры). Каждая карточка — это результат, которого должна добиться команда в рамках разработки. Результатом считается улучшение продукта, которое доступно для пользователя вашего продукта. Каждый столбец — это процесс, который должна пройти карточка, чтобы перейти в статус «выполнено». Смысл доски в том, что визуализируется ход проекта по всем направлениям для всех участников, у них появляется возможность быстро вычленить сложные и проблемные этапы или элементы и внести корректировки (рисунок 9).
Рисунок 9. Пример Agile-доски. Сервис «Спортивная страна»
Как правило, на доске отображается следующий процесс:
- «Бэклог» (Backlog) — «Бэклог продукта» (см. раздел 3.2.1);
- «Нужно сделать» (To Do) — «Бэклог спринта» (см. раздел 3.2.4);
- «В процессе» (In progress) — все задачи, находящиеся в работе;
- «Нужно проверить» (To Verify) — все выполненные задачи, находящиеся на проверке после разработки;
- «Готово» (Done) — выполненные задачи, проверенные согласно критериям DoD (см. раздел 3.2.1).
Рекомендуем разбить колонку «В процессе» на собственные этапы разработки с учетом специфики вашего продукта, а остальные оставить без изменений. Колонки от «Нужно сделать» до «Готово» являются вариантами визуализации диаграммы сгорания (см. раздел 3.6.2.2).
3.6.2.2 ДИАГРАММА СГОРАНИЯ
Диаграмма сгорания (Burndown Chart) — это инструмент, позволяющий оценивать динамику выполнения задач, поставленных на спринт (рисунок 10). В качестве «сгорающих» элементов выступает какая-либо метрика объема работы (например, часто используются человеко-часы, или количество задач, или количество задач, взвешенное с учетом их относительной сложности). Диаграмма обновляется каждый раз, когда завершается какая-либо задача.
Диаграмма сгорания (Burndown Chart) — это инструмент, позволяющий оценивать динамику выполнения задач, поставленных на спринт (рисунок 10). В качестве «сгорающих» элементов выступает какая-либо метрика объема работы (например, часто используются человеко-часы, или количество задач, или количество задач, взвешенное с учетом их относительной сложности). Диаграмма обновляется каждый раз, когда завершается какая-либо задача.
Рисунок 10. Диаграмма сгорания
Что такое Gemba // Six Sigma URL: https://sixsigma.ru/lean-six-sigma-articles/gemba-walk/
3.6.3 «ГЕМБА»
3.6.3 «ГЕМБА»
В концепции бережливого производства (см. раздел 1.5) особая роль уделяется понятию «гемба». «Гемба» — место, где формируется продукция или предоставляются услуги, площадка. Согласно методам управления, так или иначе связанным с практикой компании Toyota, считается, что для полноценного понимания ситуации необходимо прийти на «гемба» — место, где происходит рабочий процесс, провести наблюдение, собрать факты и непосредственно на месте принять решение.
«Гемба» является прекрасным методом для обнаружения зачастую неизмеримых явлений или элементов, которые являются критическими для компании. По мнению экспертов компании Global Six Sigma, «этот метод позволяет выявить реально существующие проблемы, а также выявить узкие места в процессе и те процессы, которым не уделяется достаточно внимания. Другими словами, идея… „гемба“ имеет целью проанализировать, что происходит в процессах в реальности, увидеть процесс своими глазами (а не через призму отчетов, документов или даже дэшбордов), а также выявить потенциальные пути решения существующих проблем».
«Гемба» является прекрасным методом для обнаружения зачастую неизмеримых явлений или элементов, которые являются критическими для компании. По мнению экспертов компании Global Six Sigma, «этот метод позволяет выявить реально существующие проблемы, а также выявить узкие места в процессе и те процессы, которым не уделяется достаточно внимания. Другими словами, идея… „гемба“ имеет целью проанализировать, что происходит в процессах в реальности, увидеть процесс своими глазами (а не через призму отчетов, документов или даже дэшбордов), а также выявить потенциальные пути решения существующих проблем».
Кейс 11. При создании медицинской информационной системы команда Александра М. из компании «Софт-М» постоянно была в контакте с заведующими и наиболее активными сотрудниками подразделений. Вся команда располагалась на территории заказчика: члены команды утром туда приходили, вечером уходили. Требования также собирались непосредственно на площадке. Александр М. рассказывает: «Был отдельный процесс управления требованиями к спринтам, мы сначала шли к функциональному заказчику. Например, если мы работаем над бизнес-процессом „Оперблок“, мы сначала идем к заведующему оперблоком. Вместе с ним разрисовываем все бизнес-процессы, которые у нас существуют. Превращаем их, по сути, в частное техническое задание (аналог бэклога). На обходы мы тоже ходили, смотрели, как врач выдает назначения, как медсестра на посту исполняет назначения. Я попробовал себя в роли пациента: у меня миопия в связи с работой на компьютере, и вот я пошел в физиокабинет, мне прописали физиопроцедуры, я сходил на них. Таким образом удавалось создавать только тот функционал, который реально был нужен пользователям и помогал им в их ежедневных операциях». Кейс команды, которая уделяла особое внимание работе на площадке и непосредственному контакту с пользователями, иллюстрирует полезность практики «гемба» в реализации гибких проектов.
Кейс 11. При создании медицинской информационной системы команда Александра М. из компании «Софт-М» постоянно была в контакте с заведующими и наиболее активными сотрудниками подразделений. Вся команда располагалась на территории заказчика: члены команды утром туда приходили, вечером уходили. Требования также собирались непосредственно на площадке. Александр М. рассказывает: «Был отдельный процесс управления требованиями к спринтам, мы сначала шли к функциональному заказчику. Например, если мы работаем над бизнес-процессом „Оперблок“, мы сначала идем к заведующему оперблоком. Вместе с ним разрисовываем все бизнес-процессы, которые у нас существуют. Превращаем их, по сути, в частное техническое задание (аналог бэклога). На обходы мы тоже ходили, смотрели, как врач выдает назначения, как медсестра на посту исполняет назначения. Я попробовал себя в роли пациента: у меня миопия в связи с работой на компьютере, и вот я пошел в физиокабинет, мне прописали физиопроцедуры, я сходил на них. Таким образом удавалось создавать только тот функционал, который реально был нужен пользователям и помогал им в их ежедневных операциях». Кейс команды, которая уделяла особое внимание работе на площадке и непосредственному контакту с пользователями, иллюстрирует полезность практики «гемба» в реализации гибких проектов.
3.6.4 ОРГАНИЗАЦИЯ ИНФРАСТРУКТУРЫ
3.6.4 ОРГАНИЗАЦИЯ ИНФРАСТРУКТУРЫ
Культурные и организационные изменения часто поддерживаются изменениями рабочей инфраструктуры или даже ребрендингом организации. Ярким примером является опыт Сбербанка, когда Agile-трансформация сопровождалась переездом всех формируемых Аgile-команд в новый офис, специально спроектированный для эффективной командной работы, его назвали Agile Home. Рабочее пространство и доступные инструменты совместной работы поддерживают либо затрудняют внедрение цифровой или Аgilе-культуры и гибких подходов к управлению.
Проектные команды работают значительно результативнее, если постоянно размещены в одном помещении, например в переговорной комнате или в офисе с открытой планировкой. Для командных обсуждений должна быть возможность использовать проектор, маркерные доски / стены / поверхности для визуализации и обсуждения результатов и идей, цифровые инструменты командной работы.
Ниже даны рекомендации, как изменить инфраструктуру в органах государственной власти и подведомственных организациях:
- Проведите опрос сотрудников, какие изменения рабочего пространства им необходимы. Выработайте видение целевого состояния рабочего пространства. Поймите, что требует времени и/или дополнительного финансирования, а что можно сделать быстро, бесплатно или с использованием текущего бюджета.
- Проведите изменения первой волны, не требующие дополнительного финансирования / капитальных вложений («быстрые победы»), и соберите обратную связь.
- Подайте экономичную заявку на финансирование второй волны изменений. Объясните руководству влияние рабочего пространства на результативность работы, покажите позитивную обратную связь после изменений первой волны.
- Проведите изменения второй волны, получите обратную связь от сотрудников.
Выводы раздела
Выводы раздела
Гибкий подход складывается из многих составляющих, среди них основные — правильно подобранная команда, ориентация на пользователя, разумное планирование, использование определенных способов работы над продуктом (итерации, формирование бэклога, выпуск минимального жизнеспособного продукта и т. д.), использование ряда инструментов.
Команда гибкого проекта должна быть небольшой, но со всеми необходимыми компетенциями и полномочиями, кросс-функциональной, самоорганизующейся.
В гибких проектах продукт создается спринтами длительностью от одной до четырех недель, в ходе которых команда стремится достичь цели спринта — доставки ценности конечному пользователю в объеме, определенном в ходе планирования спринта. Для планирования работы над продуктом в целом используется бэклог продукта, для планирования спринта — бэклог спринта. В ходе итерации создается инкремент, которым может быть, например, минимально жизнеспособный продукт (MVP) — версия продукта с минимально необходимым набором характеристик.
Важнейшая роль в гибких подходах отведена взаимодействию с пользователями. Для этого предусмотрен ряд инструментов и процедур. Команде важно сформировать видение продукта в начале работы, исходя из первичного понимания потребности пользователей. Требования к продукту также фиксируются «глазами пользователей», с помощью пользовательских историй. После того как продукт подвергся изменениям, команда должна регулярно получать обратную связь, чтобы учитывать пожелания пользователей при планировании следующих шагов.
Команда гибкого проекта должна быть небольшой, но со всеми необходимыми компетенциями и полномочиями, кросс-функциональной, самоорганизующейся.
В гибких проектах продукт создается спринтами длительностью от одной до четырех недель, в ходе которых команда стремится достичь цели спринта — доставки ценности конечному пользователю в объеме, определенном в ходе планирования спринта. Для планирования работы над продуктом в целом используется бэклог продукта, для планирования спринта — бэклог спринта. В ходе итерации создается инкремент, которым может быть, например, минимально жизнеспособный продукт (MVP) — версия продукта с минимально необходимым набором характеристик.
Важнейшая роль в гибких подходах отведена взаимодействию с пользователями. Для этого предусмотрен ряд инструментов и процедур. Команде важно сформировать видение продукта в начале работы, исходя из первичного понимания потребности пользователей. Требования к продукту также фиксируются «глазами пользователей», с помощью пользовательских историй. После того как продукт подвергся изменениям, команда должна регулярно получать обратную связь, чтобы учитывать пожелания пользователей при планировании следующих шагов.