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

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

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

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

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

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

Мне очень понравился образ из книги Юргена Аппело «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), минимальный продукт, обладающий ценностью – то, без чего нет смысла выпускать продукт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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