Меня зовут Темчина Мария, я работаю в Инфостарте директором по проектам.
То, про что я буду рассказывать, немного связано с моим увлечением – я увлекаюсь парусным яхтингом и часто обращала внимание, что чем сложнее та ситуация, в которой ты находишься, тем важнее использовать компетенции всех членов команды (экипажа).
Это же утверждение верно и для проектов.
Точка зрения каждого – важна
В последнее время при организации работы по проектам есть тенденция перехода от директивного управления к коллегиальному.
Мне очень понравился образ из книги Юргена Аппело «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), минимальный продукт, обладающий ценностью – то, без чего нет смысла выпускать продукт
-
А дальше – то, что войдет в последующие релизы.
-
Это не единственная возможная структура карты:
-
Можно сверху размещать тему.
-
Дальше – истории, которые относятся к этой теме.
-
И критерии приемки.
Данная структура подходит для продукта меньшего размера, чем в первом примере, когда у нас критерии приемки выносятся внутрь истории.
Можно выносить релизы не по вертикали, а по горизонтали – от ближайшего к последующему.
Карту вы можете выстроить как угодно – можно обсудить это с вашей командой
Карта становится удобнее, если в ней присутствуют:
-
Связи с задачами
-
Теги (Фронтент/Бэкенд и др.)
-
Ответственные
Условия успеха для внедрения инструментов
Важно подойти к вопросу внедрения инструментов достаточно серьезно, потому что существует две наиболее неочевидные ошибки, почему может не получиться:
-
Во-первых, когда на карте нет всех задач – нет всех историй, даже выполненных. Потому что в этот момент у нас карта перестает выполнять свою основную функцию, отвечать на вопрос – ничего ли мы не забыли.
-
И второй момент – чтобы спокойно работать с картой пользовательских историй, не должно быть сильной спешки. Если мы вынуждены действовать в условиях «хватай мешки, вокзал уезжает», то обычно вы начинаете экономить время на формулировке четких требований, формулировке критериев приемки. Есть иллюзия, что это вам ускоряет движение к цели. На самом деле, это иллюзия, потому что, к сожалению, приходится очень много переделывать – в том числе, то, что уже выпущено в эксплуатацию.
Конечно, возможности общих досок далеко не исчерпываются несколькими инструментами, про которые мы говорили.
Главное, к чему я хочу вас призвать – это использовать коллективное обсуждение и собирать точки зрения со всех членов команды, когда это возможно!
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта".
