Комментарии 11
Может быть, я не совсем верно понял, но, может быть, нужно было просто вместо столбца "в работе" сделать несколько столбцов, отражающих все этапы процесса? Ну там аналитик, дизайн, показано заказчику и тд?
Мм, в работе находится весь инкремент. По нему могут одновременно работать разные сотрудники. Плюс есть инкременты, где половина команды не участвует вообще. Поэтому нам удобней так. Но в целом столбцы могут быть любыми.
Ну тогда это выглядит как обычная декомпозиция большой задачи (инкремента в вашей терминологии) на подзадачи. Так примерно всегда и делается: есть Story, в ней детально прописано что именно надо сделать и критерии готовности ("что должно получиться"). Каждая Story разбивается на подзадачи для дизайнера, программиста, тестировщика и тд.
Возможно, в вашей статье есть определенный смысл (как удобно сделать это в Битриксе), но сейчас она выглядит так, как будто вы заново изобрели велосипед, который и так повсеместно используется. Заранее прошу прощения, если я что-то недопонял.
PS. И лучше исправить фазы типа "стандартный «канбан» вида" на "стандартная канбан-доска вида".
Выглядит как ведение задач (ценность для заказчика) с разбивкой на подзадачи (todoшки для команды).
Языком Jira это будут Story (Task), нарезаемые на Sub-Story (SubTask).
Можно назвать это и горизонтальной декомпозицией ?
Я не помню детально интерфейс джиры. В принципе, наверное, да. Но для меня плюшка еще в том, что я могу хранить хронологию инкремента:
Договоренности с заказчиком/Записи со встреч;
Срок завершения (дедлайн);
Стоимость для заказчика (мы подвязали под инкременты документооборот);
Ожидаемый результат (критерии готовности, согласованные с заказчиком);
Мысли и заметки участников команды.
И они находятся в общей хронологии вместе с выполненными задачами, поэтому удобно искать. Инкремент может идти и 3 месяца, поэтому история часто востребована.
В Битре есть скрам и канбан, можно и в них заворачивать. Мы пробуем строить процесс именно так.
Мне в скраме (как во фрейворке) не зашло, что спринт планируется жестко (нельзя потом ничего довключить) и имеет конечный дедлайн. У нас из-за этого постоянно происходило расхождение того, что в доске, и того, что в реальности.
Поэтому я из скрама подобрал для тебя понятие "инкремента". Также пользуюсь технологие живой повестки проекта (в статье не озвучил, но по сути это видно).
Поделитесь потом вашим опытом использования скрама в битре. Мне было бы крайне интересно <!>
Во-первых, спасибо за то, что делитесь опытом. От этого ИТ сообщество становится лучше и на рынке больше порядка должно быть.
Во-вторых, философский вопрос про бизнес ценность. Соглашусь, что если речь идёт об автоматизации нового бизнес процесса, то да, без всей автоматизации его часть не имеет ценности. Но если её грамотно разробить на задачи то начинает иметь, а вот поддержка или доработка существующего автоматизированного функционала почти всегда это бизнес ценность.
Привожу примеры: новый блок автоматизации, задача автоматизировать 100% выборочный контроль продукции новой партии товаров (2 упаковки нужно проверить из 200, к примеру). ТЗ: документ заказ на 100% ВК, печатная форма к заказу, документ проведения контроля, печатная форма проведения, отчёт для руководителя по всем заказам и результатам. Что я хотел сказать: часть "документ заказ на 100% ВК, печатная форма к заказу" уже бизнес ценность и может быть выложена заказчику как 1 этап.
Пример 2. Автоматизированный контроль каждой продукции в ходе производства детали и прохождения ею этапов производства. Уже есть документ ввода значений брака, представим его себе таблицей где сотрудник вводит новую строк, выбирает товар и далее заполняет в строке таблицы 10-15 колонок. Так вот, пока я не увидел то, что они для 30-40 однотипных случаев все это делают руками по каждой строке не было новой, конечной бизнес ценности сделать фичу заполнения этих 10-15 колонок по выделенным строкам. А это условно 30 сек. на строку, что 15-20 минут высвобожденного времени для сотрудника заняться другой работой.
Идея группировок тасков хороша. Я её применял на проект целиком. Проект имеет свою ценность, общая сумма. Проект делю на этапы (бюджет этапа). Этап включает в себя таски.
Как-то так)
Вопрос: вы этот инструмент ведения под себя писали или брали что-то готовое?
Спасибо и вам за комментарии и ваш опыт!
мы пока нарезаем большой проект на инкрименты "по ощущениям", то есть инкрементом может быть и печатная форма отдельно или весь процесс. В зависимости от того, насколько далеко вперед прочитывается задача.
Тема "что автоматизировать, а что нет" - это отдельный объемный топик. У меня есть некоторые размышления по этой теме. Может скоро поделюсь отдельной статьей.
Мы свое не писали - сделали на битриксе24 с использованием смарт-процессов)
Очень круто дойти до этого самостоятельно. Но есть покороче: ITIL Foundation курс талдычит об этом всю дорогу.
Как менеджеру проектной команды превратить поток задач во что-то управляемое