Миру – Miro: Общие доски для управления проектами в распределенной команде

28.06.21

Управление проектом - Инструменты управления проектом

При работе над проектом в распределенной команде важно использовать коллективные обсуждения на любом этапе – для создания иерархической структуры работ, понимания рисков и обсуждения текущих планов. Чем сложнее задача, тем полезнее могут оказаться точки зрения всех членов команды. О том, как использовать общие доски для структурирования требований и анализа рисков рассказала директор по проектам компании Инфостарт Мария Темчина.

Меня зовут Темчина Мария, я работаю в Инфостарте директором по проектам.

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

Это же утверждение верно и для проектов.

 

 

Точка зрения каждого – важна

 

 

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

 

 

Мне очень понравился образ из книги Юргена Аппело «Agile менеджмент». Когда человек работает со сложными проектами, то он не может удержать в голове всю картинку (полный образ проекта) – поэтому для эффективной работы нам нужно будет взять кусочек картинки у одного сотрудника, второй кусочек у другого и т.д.

 

 

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

Мы можем использовать коллективные обсуждения на любом этапе – от создания иерархической структуры работ, понимания рисков, обсуждения каких-то текущих планов, сбора требований и т.д. Это позволяет:

  • собрать больше деталей;

  • посмотреть на ситуацию с разных сторон;

  • обеспечить участие людей;

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

 

Инструменты для групповых обсуждений при удаленной работе

 

 

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

Мне понравился анекдот: «Китайский календарь не обманул: 2020-ый год и правда оказался годом мыши. Только мыши летучей…»

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

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

В видео https://www.youtube.com/watch?v=DYu_bGbZiiQ вы можете видеть, как выглядела бы онлайн-конференция, если бы она происходила в реальной жизни.

 

 

Поскольку текущая ситуация усложняет работу, мы ищем инструменты, которые могут максимально упростить групповые обсуждения.

В качестве такого инструмента я призываю использовать общие доски (Shared Board), которые позволяют одновременно разным людям писать, печатать, рисовать и т.д. И все сразу имеют доступ к тому, что нарисовано.

Главное преимущество общих досок по сравнению с тем, что кто-то просто расшаривает свой экран в отсутствии так называемой «власти маркера». Когда у нас один человек конспектирует обсуждение, именно он решает, что записать, как это записать, какие вещи подчеркнуть, какая мысль неважная. А когда в обсуждении участвуют все, такая возможность есть у всей команды. Это дает преимущества:

  • выше включенность;

  • быстрее фиксируем;

  • нет «власти маркера».

 

 

Есть масса разных досок – не буду подробно перечислять.

Мне ближе всего доска Miro.com – там есть неплохой комплект бесплатной функциональности, и есть платная версия.

 

 

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

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

 

Диаграмма Исикавы «Рыбья кость»

 

Начнем с шаблона диаграммы Исикавы «Рыбья кость». Это – инструмент для анализа рисков и разбора полетов, который помогает найти возможные причины проблемы из разных областей.

 

 

На слайде показано, как выглядит диаграмма «Рыбья кость»:

  • справа – голова рыбы (проблема, которую мы описываем);

  • слева – хребет;

  • и в костях хребта мы размещаем те сферы, к которым относится указанная проблема (сферы, которые могут являться источниками этой проблемы);

  • и дальше на эти кости дальше нанизываются причины, объясняющие, что привело к этой проблеме.

 

По моему опыту, диаграмму «Рыбья кость» удобно применять в двух случаях:

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

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

 

 

В какой ситуации нам действительно помогает использование диаграммы «Рыбья кость»:

  • Во-первых, несомненно, важна экспертиза участников, люди должны иметь свою экспертную точку зрения по предметной области, потому что иначе получается: «А вы, друзья, как ни садитесь – всё в музыканты не годитесь»

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

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

 

 

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

 

Второй инструмент – карта пользовательских историй User Story Map

 

 

Второй инструмент, который мы сегодня рассмотрим – это карта пользовательских историй User Story Map, структурированный набор требований к продукту, которые у нас на данный момент есть, оформленный в виде User Story или пользовательских историй.

 

 

Пользовательская история (User story) – это привычная многим форма записи требований, где мы указываем роль, само требование и критерии приемки.

Например:

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

 

 

Зачем нужны пользовательские истории? К сожалению, если мы не формализуем наши требования, то иногда пользователи могут вас попросить реализовать невыполнимое, как в видео https://www.youtube.com/watch?v=UoKlKx-3FcA

 

 

В чем преимущества формата User Story:

  • Самое главное, что требования в формате User Story написаны на языке пользователя

  • И у нас есть приставка «для того чтобы», которая объясняет цель. Это важно, потому что когда нам человек говорит, что ему нужен микроскоп для того чтобы забивать гвозди, у нас больше шансов понять, что это неоптимальный инструмент для решения данной задачи.

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

  • Компактные кусочки работы

 

 

Мне нравится критерий пользовательских историй INVEST – это аббревиатура из первых букв предлагаемых к рассмотрению атрибутов качества пользовательских историй. Что каждая история должна быть:

  • I (Independent) – независимой от других: когда зависимостей нет, планировать легче

  • N (Negotiable) – обсуждаемой: детали добавляются при сотрудничестве

  • V (Valuable) – ценной: приносить ценность заказчику

  • E (Estimable) – оцениваемой: слишком большую или неточную оценить трудно

  • S (Small) – небольшой: можно сделать в течение одной итерации

  • T (Testable) – тестируемой: иметь четкие критерии приемки

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

 

 

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

 

 

На слайде вы можете видеть список пользовательских историй:

  • слева в виде списка;

  • а справа в виде канбан-доски, где у нас требования перемещаются из бэклога в очередь, в разработку, в тестирование.

Проблема в том, что глядя на любой из этих списков нам очень трудно ответить на вопрос «Про все ли необходимые функции мы продумали?»

 

 

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

 

Варианты структурирования карт пользовательских историй

 

 

Структурировать пользовательские истории можно по-разному.

Мне нравится, когда структура строится так:

  • Роль (В интернет-магазине – роль покупателя)

  • Активность (Просмотр/ покупка товара)

  • Внутри каждой активности у нас ведутся истории – что нужно делать данному пользователю для реализации своих целей. Эти истории мы группируем по релизам продукта:

    • Сверху – MVP (minimum viable product), минимальный продукт, обладающий ценностью – то, без чего нет смысла выпускать продукт

    • А дальше – то, что войдет в последующие релизы.

 

 

Это не единственная возможная структура карты:

  • Можно сверху размещать тему.

  • Дальше – истории, которые относятся к этой теме.

  • И критерии приемки.

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

 

 

Можно выносить релизы не по вертикали, а по горизонтали – от ближайшего к последующему.

Карту вы можете выстроить как угодно – можно обсудить это с вашей командой

 

 

Карта становится удобнее, если в ней присутствуют:

  • Связи с задачами

  • Теги (Фронтент/Бэкенд и др.)

  • Ответственные

 

Условия успеха для внедрения инструментов

 

 

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

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

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

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

Главное, к чему я хочу вас призвать – это использовать коллективное обсуждение и собирать точки зрения со всех членов команды, когда это возможно!

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта".

См. также

Инструменты управления проектом Продуктовый подход Работа с заинтересованными сторонами Бесплатно (free)

В девятнадцатом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, чем продуктовый подход отличается от проектного, особенности заказной разработки и в каких ситуациях продуктовый подход применим в заказной разработке.

19.05.2025    201    0    Radio_Analyst    0    

2

Инструменты управления проектом Бесплатно (free)

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

12.05.2025    440    0    user1551153    0    

2

Коммуникации Инструменты управления проектом Россия Бесплатно (free)

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

09.04.2025    481    0    Alex_tut    0    

1

Инструменты управления проектом Бесплатно (free)

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

08.04.2025    723    21    Dziden    0    

3

Инструменты управления проектом Внедрение изменений Бесплатно (free)

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

12.03.2025    940    0    margarita_mak    0    

4

Инструменты управления проектом Бесплатно (free)

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

05.03.2025    1392    0    support    8    

23

Интеграции Кейсы автоматизации Инструменты управления проектом Бесплатно (free)

Задачи производственного планирования решить на 1С сложно – не хватает средств гибкой визуализации, недостаточно производительности для анализа и расчетов в реальном времени, недоступны многопоточные вычисления в режиме in-memory. Расскажем о том, как интегрировать APS-систему с 1С:ERP УХ, спрятав ее за фасадом привычного 1С-интерфейса.

20.02.2025    923    0    user1934826    1    

2

Инструменты управления проектом Продуктовый подход Канбан и поставка ценности Бесплатно (free)

Когда команда начинает применять в разработке продукта гибкие методологии, возникает масса вопросов – подойдет ли Scrum, как организовать структуру Kanban-доски, как сбалансировать загрузку команды и вовлечь всех участников в развитие продукта. Расскажем об организации слаженной работы не кросс-функциональной команды и опыте применения гибких методологий в продуктовой разработке.

23.01.2025    1175    0    AleksKate    1    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Yashazz 4853 28.06.21 14:53 Сейчас в теме
...и только теперь я понял истинный смысл выражений "свой в доску", "пустить по доске" и слова "досконально"...

Главное, к чему я хочу вас призвать – это использовать коллективное обсуждение и собирать точки зрения со всех членов команды, когда это возможно!
Прям так и вижу, как с каждого члена точку собирают. Главное, заранее подготовить!
2. Olenevod 34 04.07.21 19:16 Сейчас в теме
Великолепная статья. Очень верно, что коллективное обсуждение членов команды важно. Особенно на старте проекта.
Говорю так потому что как раз этого не было в одном из моих случаев, и я попал на проект где все было решено без меня. Здорово пришлось хлебнуть.
3. AlbinaAAA 1505 10.09.21 14:25 Сейчас в теме
Спасибо, интересно очень. Будем пробовать..
Оставьте свое сообщение