Comments 16
Интересная статья, как раз не хватало мнения, что метрики это не главное в проекте.
Velocity, Story points...
И, кажется, уже понял, что поиск этой метрики не баг, а фича. Потому что в момент, когда ты найдёшь идеальную формулу, ты перестанешь думать.
Побуду капитаном очевидностью. Чтобы выполнить работу, нужно начать делать работу. Не придумывать метрики, не заниматься излишним планированием, не тратить время на бесконечные митинги, а просто выполнять работу. Чем больше работы выполнил, тем меньше её осталось. Не нужно ни с кем соревноваться, планировать закрытие задач к определённому сроку или празднику. Просто начните уже делать работу. Когда она будет сделана, тогда и будет готова. Да, вот так всё просто.
К сожалению, Scrum (а Velocity и Story points это атрибуты Scrum'а) породил кучу ритуалов и метрик, которые в последствии подменили собой цель. Теперь не важно, какой результат у тебя в конце получится, а важно, что ты соблюдаешь все ритуалы Scrum. В общем, типичный карго-культ.
Так как же тогда работать? Всё просто. Начните использовать в работе Канбан, а не Scrum. 1 раз в неделю собирается несколько человек, например, лид + аналитик + СТО и решают, какие задачи для них важны на эту неделю. А затем нарезают задачи в to-do, откуда исполнители их тягают себе по мере того, как выполняют свои текущие задачи. Сколько за неделю успели сделать, столько и будет. Не надо никуда спешить, ни на что отвлекаться. Взял задачку из to-do и выполняешь её в однозадачном режиме. Выполнил задачу, переместил её в done или тестирование, чтобы её потом себе взяли тестировщики. Взял другую задачу для решения.
Если задач до конца недели не хватило, т.е. сделали всё быстрее, то лид + аналитик + СТО нарежут ещё задач. Если какие-то задачи остались, то они переносятся на следующую неделю без каких-либо наказаний и глумлений. Работа - это поток. В этом и есть суть Канбан. Это сложно понять тем, кто привык к постоянной гонке в виде спринтов. Но если понять суть Канбан, то работать становится намного приятнее и комфортнее.
Отлично все описали. А теперь поставьте себя на место СТО и попробуйте ответить на несколько вопросов:
- нужно ли расширять штат, чтобы успевать сделать больше задач?
- можно ли текущим составом делать больше?
И команд не 1-5, а штук 50.
А задается этими вопросами СТО, потому что надо оставаться конкурентноспособными на рынке, надо держать рентабельность бизнеса, а еще и в будущее заглядывать и соломки подстилать.
- можно ли текущим составом делать больше?
Да, можно. Для этого необходимо устранять потери в работе, т.е. делать то, что реально приносит пользу. А то, что пользы не приносит, делать не нужно. Потери называются японским словом муда.
- нужно ли расширять штат, чтобы успевать сделать больше задач?
Смысл не в том, чтобы делать больше задач, а в том, чтобы делать только те задачи, которые реально приносят пользу бизнесу.
Касательно измерения скорости работы, то это делается легко. Берётся любой интервал времени, например, неделя, месяц или даже полгода и смотрится, сколько задач текущая команда выполняет за неделю или месяц. Это и будет производительностью команды.
И команд не 1-5, а штук 50.
Канбан работает во многих компаниях. Родоначальником Канбан является компания Тойота, которая насчитывает около 380 000 человек (по состоянию на 2024-2025 год). Заводы и операции Toyota присутствуют в более чем 170 странах. Так что управление 50 командами - это так, лёгкая разминка.
Также замечу, что СТО не управляет 50 командами и даже не управляет 50 руководителями этих команд. СТО управляет 5-6 руководителями управлений\департаментов, а они в свою очередь управляют руководителями групп, которые уже непосредственно управляют своими группами.
А задается этими вопросами СТО, потому что надо оставаться конкурентноспособными на рынке, надо держать рентабельность бизнеса, а еще и в будущее заглядывать и соломки подстилать.
Если вы используете Канбан и придерживаетесь принципов бережливого производства (lean), то всё это будет доступно из коробки. Для примера, вы можете внедрять новый функционал в 2 раза быстрее, чем конкуренты и тратя на это в 2 раза меньше усилий. При таком раскладе при любом кризисе на рынке вы останетесь на плаву, а конкуренты нет.
Если рынок поменяется, то опять таки вы сможете быстрее к этом адаптироваться, т.к. выпускаете функционал в 2 раза быстрее и тратя на это в 2 раза меньше усилий.
Ещё пара слов о проблемах со Scrum.
Scrum - это работа спринтами, т.е. предполагается, что команда на 1-2 неделю берёт себе некий объём задач и обязуется его выполнить к концу спринта. Кроме психологического давления в виде дедлайна, есть ещё проблема срочных задач.
Как только прилетает срочная задача от вышестоящего руководителя, весь спринт ломается нафиг и начинаются адские переработки, чтобы втиснуть в уже начавшийся спринт эту срочную задачу. Так как у руководителей команд, как правило, нет яиц, чтобы сказать нет, то лишняя задача становится проблемой исполнителей, что ведёт к их выгоранию, недовольствами и будущим конфликтам.
В Канбан с этим намного проще. У исполнителя установлен лимит в 2 активные задачи (WIP - Work in Progress). Исполнитель сосредоточен на выполнении одной задачи. Выполнил одну задачу, взял себе другую задачу.
И вот прилетает срочная задача. Что делает исполнитель в Канбан? Он просто заканчивает свою текущую задачу, т.е. доводит её до логического конца, после чего вместо второй задачи, которая у него была в In Progress, берёт эту срочную задачу и решает её как обычную задачу. Решил эту срочную задачу и потом вернулся к оставшейся в In Progress задаче.
В канбан можно спокойно поменять порядок выполнения задач. Попалось 2 срочные задачи - ок, сделаю их. Исполнителю в целом всё равно, обычная это задача или срочная, т.к. у исполнителя нет обязательств выполнить какой-либо объём работы в конкретному сроку. Нет никакой разницы, было выполнено 10 обычных задач или 8 обычных задач + 2 срочные.
При работе с Канбан намного проще планировать нагрузку, проще видеть производительность команды и отдельных её участников. А визуализация в виде досок Канбан позволяет руководителю видеть все пролбемы и своевременно их решать.
Также важный момент. В Канбан все видят работу каждого, т.е. если у кого-то затор в работе, то любой может подойти к нему и помочь. Также нет необходимости проводить утренние стендапы, т.к. все в любой момент видят работу каждого. Для этого достаточно подойти к доске Канбан. 100% прозрачность.
Если приходит высокий босс и говорит, что вы все пи....сы и ничего не делаете, то его можно подвести к Канбан доске и показать, какие задачи были выполнены вчера, позавчера, или даже неделю задач. Показать, какие задачи сейчас в работе и какую пользу они приносят бизнесу. После этого все вопросы к команде, как правило, отпадают.
В Scrum же каждый нацелен только на то, чтобы решить свои собственные задачи к концу спринта и чужие задачи его мало интересуют. Ведь если он не успеет выполнить свою работу, то придётся потом оправдываться.
Очень классно описали преимущества канбана и проблемы скрама для отраслей и ситуаций с высокой степенью неопределенностью, для задач с отсутствием внешних обязательств, давления и дедлайнов.
Для некоторый компаний и некоторых выбранных стратегий канбан действительно лучший выбор.
Тот же самый пример с Тойотой прекрасно это демонстрирует. Фокус на процесс был сквозной для всей компании, это лежало в основе стратегии. Это же и отразилось на продукции - автомобили стали эталоном надежности и сочетанием цены и качества. Этим они завоевали свою долю рынка. Но это не единственная успешная стратегия в автомобильной отрасли. Европейцы ставили на высокотехнологичность и были в этом сильнее японцев, но уступали в качестве. Итальянцы брали дизайном, но уступали во всем остальном. И европейцы, и итальянцы работали не по канбану и у них было совсем другое отношение к процессу работы.
Но организации разные и выбор методологии зависит от внутренних потребностей, компетенций и обстоятельств.
Чем меньше вокруг уровень неопределенности, тем больше ценится прогнозируемость, планируемость и попадание в срок с заявленным объемом и качеством.
Учитывая текущую ситуацию в мире и в РФ в частности, канбан для большинства малого/среднего/крупного бизнеса будет, действительно, оптимальным выбором. А вот корпорациям, госпредприятиям и компаниям со сложными продуктами надо выбирать методологии с большим количеством точек контроля.
Но изначально статья была не о том, какая проектная методология оптимальная. Вопрос не одномерный и это надо учитывать.
Ну и позабавила фраза, что надо "делать только те задачи, которые реально приносят пользу бизнесу". Для меня она звучит как "просто надо делать задачи без багов и технического долга" и все будет замечательно.
Но изначально статья была не о том, какая проектная методология оптимальная. Вопрос не одномерный и это надо учитывать.
Так в том то и дело, что пока люди ищут некую метрику, которая им покажет всё, что они хотят, работа в этот момент стоит на месте, т.е. нет движения вперёд. И чем больше люди тратят времени на поиск мистической метрики, тем дальше отдаляются от основной цели - выполнения работы. И очень часто сама метрика становится самоцелью.
Ну и позабавила фраза, что надо "делать только те задачи, которые реально приносят пользу бизнесу". Для меня она звучит как "просто надо делать задачи без багов и технического долга" и все будет замечательно.
Да, я специально так написал, чтобы не нагружать ещё сильнее свой коммент, иначе никто до конца его не прочитает. :)
Касательно метрик. У разных групп разные критерии оценки их результатов труда. У закупщика - купить побольше сырья и подешевле; у производственника - произвести как можно больше изделий; у маркетолога - расширить охваты и повысить узнаваемость компании; у продавцов - продать как можно больше, у разработчиков - закрыть как можно больше задач в Jira ))). И часто эти метрики могут друг с другом конфликтовать.
Так что тут приоритет задач будет определяться теми планами, что ставит на год\квартал директор или собственник компании. Метрики самой разработки - это дело десятое. Какая разница, какой был Velocity у команды или сколько Story points было выполнено, если квартальные задачи не выполнены. И наоборот, какая разница, если в этом году Velocity был в 2 раза хуже, чем в прошлом году, но все квартальные и годовые целы выполнены успешно.
Я к тому, что не нужно так сильно задрачиваться на метрики, т.к. они локальны (локальный оптимум), а во вторых - никакие метрики сами по себе задачи не выполнят, так что лучше рабочее время потратить на выполнение задач.
P.S. Всё, что написано ниже, это для тех, кто хочет углубиться ниже.
Если дочитали до этого места, то открою секрет. Есть метрики на уровне всей компании, например, Теория Ограничений Голдратта фокусируются на трёх ключевых финансовых показателях для оценки результативности системы: Пропускная способность (Throughput) — деньги, генерируемые системой; Запасы (Inventory) — деньги, вложенные в материалы и незавершённое производство (ТМЦ); и Операционные расходы (Operating Expenses) — деньги, потраченные на превращение запасов в пропускную способность, то есть себестоимость.
Поняв, что это за метрики на уровне всей компании и как отдел разработки на них влияет, вы можете создать новые метрики, которые реально будут полезны вашей компании. Для этого нужно понимать текущие цели и задачи менеджмента, активно общаться с ним, что не всегда возможно.
Метрики вида, Velocity, Story points, величина тех. долга и прочее - это просто мусор, т.к. это локальные метрики (локальными оптимумы), которые могут вредить общему процессу формирования добавочной стоимости.
Но писать о том, что текущие метрики это мусор, под статьёй, где человек старательно хочет найти нужную метрику - это было слишком грубо с моей стороны, поэтому я решил пойти другим путём и сообщить, что текущие метрики сильно переоценены, поэтому лучше рабочее время потратить на саму работу, а не на поиск метрики. Канбан позволяет просто спокойно выполнять работу, в то время, как Scrum заражён метриками от начала и до конца, поэтому чтобы отойти от метрик, придётся отойти от Scrum.
Например, компания хочет выйти на рынок новой страны и получить там 15 клиентов за 1 год. Сколько Story points мне для этого нужно? А какого Velocity должна придерживаться команда разработки? А какая величина тех. долга будет приемлемой для этой цели?
И вот тут становится понятно, что локальные метрики совершенно бесполезны. И что намного эффективнее пойти и пообщаться с людьми, которые участвуют в этом проекте и понять, как именно команда разработки может им помочь добиться общей цели - получить 15 клиентов за 1 год на новом для компании рынке. Может и разрабатывать ничего не нужно, а достаточно просто перевести интерфейс ПО на новый язык и купить подписку на сервис рассылок для менеджеров по продажам, вместо того, чтобы разрабатывать свой собственный рассыльщик.
Интересно вы рассуждаете. Метрика - это не цель, она не определяет деятельность. Метрика - это оценка деятельности.
Это как в школе: проходим тему по математике, а потом контрольная и учитель проверяет работу и знания, ставит оценку. Получаем метрику успеваемости. Но нельзя просто взять и подвинуть метрику. Нужно осваивать материал, глубже понимать предмет и тогда учитель выше оценит знания. И только после этого поднимется метрика успеваемости.
В статье поднималась тема оценок. Не глубины, не сути исполнения задач, а система оценок. Ведь именно оценки (метрики) дают понимания в момент нужно что-то корректировать или все идет хорошо. Они не говорят как корректировать.
На своем опыте сталкивался с разными ситуациями и да, легче всего отруливается личным общением, выяснением проблем, контекста с последующим внесением изменений. Но так же столкнулся с ситуацией, когда 200 разработчиков замедляются с каждым кварталом. Именно на уровне аутпута, а по низкоуровневым показателям все хорошо: раппортуют о том, какие трудности преодолели, сколько задач героически выполнили.
И, самое интересное, разработчики правы. Они просто делают задачи и стараются как можно лучше их выполнять.
Вот и получается парадокс: команды разработки делают все по как можно лучше, по отчетам и демонстрациям все отлично, а вот в целом медленно. Не абстрактно медленно, а относительно - медленнее и дороже с каждым кварталом, с каждым годом. Расходы растут и уже нет такой отдачи в деньгах. А задача любого управленца - приносить прибыль, увеличивать стоимость компании, капитала для акционаров.
P.S. а Голдратт написал отличную книгу, она очень помогает запустить мышление, но это бизнес-роман, не стоит его переоценивать. Почитайте Друкера, Гранта, Бэста.
Дао Винни Пуха ))
нужно начать делать работу
просто выполнять работу
просто начните уже делать работу
Скрытый текст
Как исполнитель, я тоже голосую за канбан. Но все остальные размышления довольны размыты и наивны. Из разряда "у тебя не будет плохих метрик, если у тебя изначально нет метрик")
делать только те задачи, которые реально приносят пользу бизнесу
Как или в чем оценить реальную пользу? Если чисто на словах, договоренностях и убеждении, то будущее таких компаний меня пугает. Из-за того, что в менеджмент просачиваются личности, умеющие красиво говорить и профессионально высасывать деньги из работодателя, разрушая при этом все - атмосферу в коллективе, эффективность работы и технологичность автоматизации.
В общем, чтобы воплотиться в жизнь, озвученные принципы требуют очень высокой осознанности и ответственности от каждого участника процесса. И даже, в каком-то смысле, это шаг в строну плоских горизонтальных структур управления. Строгая иерархия гораздо более привычна/понятна и гораздо более распространена, и она как раз требует таких же организованных в иерархию метрик. Хотя бы чтобы ими можно было управлять иерархическими же подходами.
На счет текста своего мнения не имею, т.к. его не читал из-за того, что тема меня не сильно интересует. А вот иллюстрация от нейросети вызвала небольшое раздражение. Я не против нейросетевой иллюстрации в принципе, но хотелось бы, чтобы автор что-то подчищал за нейросетью в этом плане. Издалека иллюстрация как иллюстрация, но для людей, которые всматриваются, я бы заменил цифры (хотя бы те, которые покрупнее) на валидные. В большинстве растровых редакторов это несложно сделать, а в векторных еще проще.
Цикломатическая сложность, поделённая на количество функционала/фич?
В идеале - постоянная, когда код становится неуправляемым - растёт.
Неэффективная эффективность