Мы - небольшая IT-команда, которая работает на несколько заказчиков одновременно. Каждый заказчик поставляет задачи: от крупноблочных до мелочей. Задачи приходят на ежедневной основе в живом режиме и формируют наш бэклог.
Разумеется, каждый заказчик хочет получать результат (решение своего вопроса), команда хочет работать удобно, а я - как менеджер проектов - не сойти с ума.
Иными словами - стандартный «канбан» вида:
Был для меня неинформативным, поэтому не подходил. Как сделать его наглядным для менеджера проектов?
Для организации рабочего процесса команды я пробовал спринты из скрама, канбан и другие популярные фреймворки. Из каждого приживалась только часть. В итоге мы с течением времени высекли из камня свой метод управления проектами.
Какие были боли менеджера проектов:
Сделать так, чтобы сотрудники были сфокусированы на создании Business Value, а не «делали задачки»;
Чтобы я мог управлять не «по ощущениям», а видеть приоритет задач: что поставить в работу в первую очередь;
Заказчики всегда получали результат по своим запросам (даже маленьким), а я по итогам месяца мог понять - какие работы выполнялись и за что выставлять счет.
Далее расскажу, как мы настроили свои рабочие доски, чтобы жить стало легче:) На истину и уникальность не претендую - это наш субъективный опыт.
Кому может подойти?
Небольшим командам (3-10 чел), которые ведут несколько клиентов на аутсорсе (агентства, разработчики);
Руководителям отделов внутри компании, которые обслуживают пул внутренних заказчиков (например, ИТ-службы, юридические отделы).
Вводим новый признак задачи
Допустим, есть 3 клиента, по каждому из них идет постоянная работа: подключаем новую интеграцию, настраиваем новый отчет, запускаем новый раздел сайта. Эти «фичи» назовем далее инкрементами (мозговой штурм за более благозвучный вариант названия предлагается провести в комментариях :)).
Инкремент (от англ. increment «увеличение, приращение») - это тот самый Buiseness Value, которого жаждет заказчик. Заказчику не важен красивый макет сам по себе, ему нужно решить свою болячку.
Если я теперь сгруппирую задачи по смысловым блокам (инкрементам), то канбан будет выглядеть так:
Каждая задача теперь привязана к инкременту. Даже если инкремент состоит из одной задачи. Примерно так:
При этом у инкрементов есть своя доска со статусами, примерно так:
Из чего состоит инкремент
Инкремент - это не просто набор задач, наша карточка инкремента включает также:
Договоренности с заказчиком/Записи со встреч;
Срок завершения (дедлайн);
Стоимость для заказчика (мы подвязали под инкременты документооборот);
Ожидаемый результат (критерии готовности, согласованные с заказчиком);
Мысли и заметки участников команды.
Пример:
У нас есть договоренность: я и любой участник команды складывает все ценные материалы в карточку инкремента. И искать ответ на вопросы по задаче также принято сначала тут. Таким образом я для себя снизил количество вопросов по задачкам от команды.
Ожидаемый результат VS Процесс
Любой менеджер проектов знает, что между «Разработчик всё сделал» до «Заказчик всё принял и доволен» часто бывает пропасть. Сотрудник убежден, что задача выполнена, а заказчик спрашивает, когда будет готово.
Я, как менеджер проектов, хочу чтобы участники команды смотрели на задачи глазами клиента. Для этого стараюсь формулировать задачи в виде ожидаемого результата.
Людям свойственно выбирать самый легкий и короткий путь. Если сказать человеку, что нужно сделать - он сделает ровно это и ничего больше. Мы стараемся ставить задачи «что должно получиться», а не «что нужно сделать». Еще несколько примеров:
Настроить форму отчета > Бухгалтерия приняла форму отчета и Марина умеет выгружать отчет самостоятельно;
Написать статью для Хабра > Статья вычитана, выложена, прошла модерацию и есть первые просмотры;
Выставить счет за декабрь > Получена оплата работ за декабрь.
Инкремент - это своего рода «макро»-задача. Поэтому он также имеет прописанный ожидаемый результат. Например, так выглядят критерии готовности для инкремента «Делаем дизайн оформления заказа»
На планерках мы обсуждаем не задачи, а инкременты и эта информация регулярно попадается на глаза команде.
Резюме
Чем стала лучше моя жизнь с тех пор, как такой подход прижился:
Я могу определять приоритеты в очень неоднородном беклоге;
Команда ориентирована на результат (сдачу инкремента), а не на процесс (сделал сегодня 5 задачек);
Легко собрать информацию по выставлению счета за период;
Легко готовиться и проводить демо.
Я не буду затягивать дальше - тема довольно простая. Я решил написать об этом потому, что пару лет путем проб и ошибок искал для себя способ организации своей работы с командой, заказчиками и финансами.
Благодарю тех, кто дочитал. Хочется общаться в комментариях.
Комментарии (11)
Scellar
04.02.2022 04:22Выглядит как ведение задач (ценность для заказчика) с разбивкой на подзадачи (todoшки для команды).
Языком Jira это будут Story (Task), нарезаемые на Sub-Story (SubTask).
Можно назвать это и горизонтальной декомпозицией ????
pkramin Автор
04.02.2022 04:27Я не помню детально интерфейс джиры. В принципе, наверное, да. Но для меня плюшка еще в том, что я могу хранить хронологию инкремента:
Договоренности с заказчиком/Записи со встреч;
Срок завершения (дедлайн);
Стоимость для заказчика (мы подвязали под инкременты документооборот);
Ожидаемый результат (критерии готовности, согласованные с заказчиком);
Мысли и заметки участников команды.
И они находятся в общей хронологии вместе с выполненными задачами, поэтому удобно искать. Инкремент может идти и 3 месяца, поэтому история часто востребована.
vlad_stv
04.02.2022 04:22В Битре есть скрам и канбан, можно и в них заворачивать. Мы пробуем строить процесс именно так.
pkramin Автор
04.02.2022 04:31Мне в скраме (как во фрейворке) не зашло, что спринт планируется жестко (нельзя потом ничего довключить) и имеет конечный дедлайн. У нас из-за этого постоянно происходило расхождение того, что в доске, и того, что в реальности.
Поэтому я из скрама подобрал для тебя понятие "инкремента". Также пользуюсь технологие живой повестки проекта (в статье не озвучил, но по сути это видно).
Поделитесь потом вашим опытом использования скрама в битре. Мне было бы крайне интересно <!>
maksal
04.02.2022 15:58Во-первых, спасибо за то, что делитесь опытом. От этого ИТ сообщество становится лучше и на рынке больше порядка должно быть.
Во-вторых, философский вопрос про бизнес ценность. Соглашусь, что если речь идёт об автоматизации нового бизнес процесса, то да, без всей автоматизации его часть не имеет ценности. Но если её грамотно разробить на задачи то начинает иметь, а вот поддержка или доработка существующего автоматизированного функционала почти всегда это бизнес ценность.
Привожу примеры: новый блок автоматизации, задача автоматизировать 100% выборочный контроль продукции новой партии товаров (2 упаковки нужно проверить из 200, к примеру). ТЗ: документ заказ на 100% ВК, печатная форма к заказу, документ проведения контроля, печатная форма проведения, отчёт для руководителя по всем заказам и результатам. Что я хотел сказать: часть "документ заказ на 100% ВК, печатная форма к заказу" уже бизнес ценность и может быть выложена заказчику как 1 этап.
Пример 2. Автоматизированный контроль каждой продукции в ходе производства детали и прохождения ею этапов производства. Уже есть документ ввода значений брака, представим его себе таблицей где сотрудник вводит новую строк, выбирает товар и далее заполняет в строке таблицы 10-15 колонок. Так вот, пока я не увидел то, что они для 30-40 однотипных случаев все это делают руками по каждой строке не было новой, конечной бизнес ценности сделать фичу заполнения этих 10-15 колонок по выделенным строкам. А это условно 30 сек. на строку, что 15-20 минут высвобожденного времени для сотрудника заняться другой работой.
Идея группировок тасков хороша. Я её применял на проект целиком. Проект имеет свою ценность, общая сумма. Проект делю на этапы (бюджет этапа). Этап включает в себя таски.
Как-то так)
Вопрос: вы этот инструмент ведения под себя писали или брали что-то готовое?
pkramin Автор
04.02.2022 17:24Спасибо и вам за комментарии и ваш опыт!
мы пока нарезаем большой проект на инкрименты "по ощущениям", то есть инкрементом может быть и печатная форма отдельно или весь процесс. В зависимости от того, насколько далеко вперед прочитывается задача.
Тема "что автоматизировать, а что нет" - это отдельный объемный топик. У меня есть некоторые размышления по этой теме. Может скоро поделюсь отдельной статьей.
Мы свое не писали - сделали на битриксе24 с использованием смарт-процессов)
GOshaSaveiko
04.02.2022 15:58Очень круто дойти до этого самостоятельно. Но есть покороче: ITIL Foundation курс талдычит об этом всю дорогу.
Merrynose
Может быть, я не совсем верно понял, но, может быть, нужно было просто вместо столбца "в работе" сделать несколько столбцов, отражающих все этапы процесса? Ну там аналитик, дизайн, показано заказчику и тд?
pkramin Автор
Мм, в работе находится весь инкремент. По нему могут одновременно работать разные сотрудники. Плюс есть инкременты, где половина команды не участвует вообще. Поэтому нам удобней так. Но в целом столбцы могут быть любыми.
Merrynose
Ну тогда это выглядит как обычная декомпозиция большой задачи (инкремента в вашей терминологии) на подзадачи. Так примерно всегда и делается: есть Story, в ней детально прописано что именно надо сделать и критерии готовности ("что должно получиться"). Каждая Story разбивается на подзадачи для дизайнера, программиста, тестировщика и тд.
Возможно, в вашей статье есть определенный смысл (как удобно сделать это в Битриксе), но сейчас она выглядит так, как будто вы заново изобрели велосипед, который и так повсеместно используется. Заранее прошу прощения, если я что-то недопонял.
PS. И лучше исправить фазы типа "стандартный «канбан» вида" на "стандартная канбан-доска вида".