Современные представления об управлении фокусируются на процессах, а не на отделах. Оргструктура производства при этом может вообще не быть иерархичной.
Фактически, когда вы предлагаете занять разработчиков рефакторингом или юнит-тестами — это тоже просто способы занять их на 100%. Вопрос только в том, кто за это заплатит в конечном счёте :)
Посчитать все задачи в процессе можно, но когда задач много, это неудобно. Всякий раз пересчитывать, прикидывать, успеют или нет… Это непрозрачно.
План по часам в целом выдерживается. Не вижу ничего сверхъестественного в том, что человек способен оценить время, необходимое на работу, тем более что сложные блоки раскладываются на более простые, которые уже и оцениваются. Исследовательские задачи в которых вообще ничего непонятно можно искусственно ограничивать оценкой (т.е., время в таком случае важнее результата). Это даёт управляемость процесса, нет такого, что все люди вдруг заняты, и некому сделать что-то срочное.
В то же время эта система защищает разработчиков от перегруза, когда всем всё надо сделать срочно. Есть план — в нём и разбирайтесь, кому из вас нужнее. Это хорошо влияет на качество.
Естественно, в этой схеме предусмотрены действия, что делать если человек ошибся с оценкой и как максимально безболезненно осуществлять перепланировку.
В целом я не пытаюсь доказать, что такая система однозначно лучше канбана. Она просто лучше в определённых условиях, когда есть много проектов, много задач, требуется быстрое реагирование и соблюдение каких-то локальных сроков.
Это хорошие, правильные рассуждения, но многое зависит от бизнес-модели. Где-то такая вот работа по техническому долгу, рефакторинг, увеличивает издержки по проекту, которые не будут покрыты заказчиком, и это очень печалит менеджеров, которые получают премию за рентабельность :)
Дисциплина — это исполнение правил. Если правила разрешают возить задачу из тестирования в разработку и обратно, в то время, пока в бэклоге лежит срочная задача — то никакая дисциплина не поможет.
Задачи со сроками могут быть не крупными проектами, а небольшими работами на три-четыре часа. Выделять под это собственный канбан и резервировать людей бессмысленно. Можно написать крупно дедлайн, но кому будет до него дело, если люди смотрят на те задачи, которые висят «в процессе».
По поводу «висят на доске» — видимо мы друг друга не поняли. Я имел в виду, что даже если вы ставите задачу в бэклог с высоким приоритетом, до неё может не дойти дело, поскольку исполнители уже заняты задачами «в процессе», которые там двигаются в тестирование и обратно. Вот эта неопределённость и мешает.
Почему планирование по дням помогает решить проблемы с дележом ресурсов? Потому что при таком подходе проще отследить, кто именно загрузил отдел работой в прошлом, в настоящее время, и в будущем. Это наглядно видно по календарю, а значит с этим можно работать. Менеджеры могут буквально до часов делить ресурсы отдела на следующую неделю и это легко контролируется.
Сейчас в этой компании задачи от клиента формализованы менеджером или разработчиком и оценены разработчиком в часах. Планирование по дням позволяет запланировать работу по задаче на определённый день. Оставшийся риск в этой схеме — это риск неправильной оценки задачи разработчиком. (Практики снижения этого риска уже выходят за рамки обсуждения, конечно они тоже применяются.) Таким образом, мы проблему решили: существует план, по плану задача в четверг, значит она будет в четверг, и любые движения без предварительных согласований невозможны.
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна. И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
Это хорошая система на производстве, но в проектах ПО может так оказаться, что в один момент бутылочное горлышко будет на тестировании (делаем что-то, сложное в тестировании), а через месяц уже в разработке.
Ну фактически так и будет. Пробка накопится, по цепочке: мы завалим тестирование, потом остановится разработка, потому что она не сможет ничего передать вперёд, потом аналитика, потому что ей тоже некуда передавать задачи вперёд и всё, все сидят и ждут.
Вы почему-то не настроены на продуктивную беседу. Возможно я не владею нативной терминологией этой практики, но это не мешает рассуждать в общем.
В компании, куда я пришёл заниматься организацией деятельности, использовалось нечто, что они называли канбаном. У них были карточки с ограничением количества в работе и прочие вещи. А компании нужна была прозрачность и понимание того, в какой день какая задача будет готова. Всю эту систему мы заменили на планирование по дням, потому что, как мне кажется, система подобная канбану такого дать не может, у неё другие преимущества.
Вы мне пытаетесь доказать, что в канбане можно гарантировать исполнение какой-то задачи в конкретный день. Я и спрашиваю вас, как? Статистические значения здесь не годятся, потому что сроки бывают жёсткими.
То есть, вы говорите, что главный профит здесь заключается в том, что суммарное количество карточек на всех этапах процесса ограничивается, таким образом, вы не можете окончательно завалить отдельный этап работой, из-за которой всё станет совсем непредсказуемо. Правильно?
То есть, если, например, в приведённой схеме «Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> Развертывание» этап тестирования перегружен, то аналитик не может взять себе новых задач и будет сидеть без дела?
В командах, разрабатывающих ПО, практика канбана чаще сводится к тому, что это, дескать, очень наглядно: в любой момент видно, как много задач мы сделали, и как много ещё предстоит сделать. Хотя очевидно, что если команда использует хоть что-то похожее на учёт задач, то всё то же самое достигается одним простейшим отчётом.
Когда я говорил «ваша команда», то имел в виду не вас, а некоторую абстрактную команду, использующую канбан, равно как и пример заказчика с телевизором тоже выдуман из головы, не принимайте на свой счёт.
Лично я, пока участвовал в организации работы отдела разработки, предпринял для повышения предсказуемости следующее — предложил избавиться от канбана и внедрить старое-доброе планирование работы по дням недели, что впоследствии очень хорошо сказалось как на предсказуемости результатов, так и на производительности труда, и на прозрачности всего процесса в целом.
Если я правильно понимаю вашу терминологию, lead time — это статистика, показывающая, в среднем, как долго задача добирается до статуса (in-progress? completed?). В любом случае, статистика — это вероятностная величина. Её нельзя пообещать клиенту, которому, например, надо запустить лэндинг к четвергу, потому что у него стартует реклама по телевизору, которая стоит дороже чем вся ваша команда с её канбаном.
Скажу от себя, что Канбан плохо подходит для клиентской поддержки. Казалось бы, он даёт инструмент для быстрого реагирования, но зато полностью отбирает возможность получить какую-либо определённость в сроке исполнения задачи, потому что любая работа может быть сдвинута на неопределённый срок другими задачами.
Да и в целом, я бы не стал называть Канбан методологией. Это скорее удобная практика, которую можно применять в подходящих случаях.
Такое бывает, что подобный вопрос не лишён смысла. Если брать крупных корпоративных клиентов, которые отдают работу с сайтами на аутсорс, то там часто бюджет отдела маркетинга или IT известен заранее (это нормально, если в большой компании есть нормальное финансовое планирование). Но опять же, даже в этом случае, это такой вопрос, который я бы не стал задавать слишком прямо, и слишком быстро.
Ну, вряд ли здесь такая ситуация, в которой надо искать кто прав, а кто не прав. Важно подумать, как лучше поступить, чтобы, по возможности, заключить сделку и получить потом по ней прибыль.
Я бы никогда не стал в лоб спрашивать, какой бюджет — они и сами могут не знать (они и задачу-то свою могут не знать, мало ли что в ТЗ понаписали). Со своей стороны я всегда стараюсь максимально кратко и доходчиво объяснить, почему трудно оценивать уникальные решения. Раз уж ТЗ прилагается — всегда можно назвать и вилку цены, но объяснить, по каким причинам названа вилка, за счёт чего цена может снизиться или вырасти (если мы делаем этот блок сложно, то дороже, если вот этот проще, ну и так далее).
Главное больше спрашивать о задаче, узнать о бизнесе клиента, постараться лучше уловить, какой именно уровень бюджета он ожидает, какой уровень проработанности решения он ожидает. В общем, это практика продаж, здесь готового решения нет.
В этой постановке вопроса достаточно считать бюджет просто ещё одним требованием.
Иногда он очень важен, иногда жёстко зафиксирован, поэтому и озвучивается раньше прочих требований. Довольно часто бывает и наоборот, конечный бюджет не так важен, как другие требования.
План по часам в целом выдерживается. Не вижу ничего сверхъестественного в том, что человек способен оценить время, необходимое на работу, тем более что сложные блоки раскладываются на более простые, которые уже и оцениваются. Исследовательские задачи в которых вообще ничего непонятно можно искусственно ограничивать оценкой (т.е., время в таком случае важнее результата). Это даёт управляемость процесса, нет такого, что все люди вдруг заняты, и некому сделать что-то срочное.
В то же время эта система защищает разработчиков от перегруза, когда всем всё надо сделать срочно. Есть план — в нём и разбирайтесь, кому из вас нужнее. Это хорошо влияет на качество.
Естественно, в этой схеме предусмотрены действия, что делать если человек ошибся с оценкой и как максимально безболезненно осуществлять перепланировку.
В целом я не пытаюсь доказать, что такая система однозначно лучше канбана. Она просто лучше в определённых условиях, когда есть много проектов, много задач, требуется быстрое реагирование и соблюдение каких-то локальных сроков.
По поводу «висят на доске» — видимо мы друг друга не поняли. Я имел в виду, что даже если вы ставите задачу в бэклог с высоким приоритетом, до неё может не дойти дело, поскольку исполнители уже заняты задачами «в процессе», которые там двигаются в тестирование и обратно. Вот эта неопределённость и мешает.
Почему планирование по дням помогает решить проблемы с дележом ресурсов? Потому что при таком подходе проще отследить, кто именно загрузил отдел работой в прошлом, в настоящее время, и в будущем. Это наглядно видно по календарю, а значит с этим можно работать. Менеджеры могут буквально до часов делить ресурсы отдела на следующую неделю и это легко контролируется.
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна. И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
В компании, куда я пришёл заниматься организацией деятельности, использовалось нечто, что они называли канбаном. У них были карточки с ограничением количества в работе и прочие вещи. А компании нужна была прозрачность и понимание того, в какой день какая задача будет готова. Всю эту систему мы заменили на планирование по дням, потому что, как мне кажется, система подобная канбану такого дать не может, у неё другие преимущества.
Вы мне пытаетесь доказать, что в канбане можно гарантировать исполнение какой-то задачи в конкретный день. Я и спрашиваю вас, как? Статистические значения здесь не годятся, потому что сроки бывают жёсткими.
То есть, если, например, в приведённой схеме «Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> Развертывание» этап тестирования перегружен, то аналитик не может взять себе новых задач и будет сидеть без дела?
В командах, разрабатывающих ПО, практика канбана чаще сводится к тому, что это, дескать, очень наглядно: в любой момент видно, как много задач мы сделали, и как много ещё предстоит сделать. Хотя очевидно, что если команда использует хоть что-то похожее на учёт задач, то всё то же самое достигается одним простейшим отчётом.
Лично я, пока участвовал в организации работы отдела разработки, предпринял для повышения предсказуемости следующее — предложил избавиться от канбана и внедрить старое-доброе планирование работы по дням недели, что впоследствии очень хорошо сказалось как на предсказуемости результатов, так и на производительности труда, и на прозрачности всего процесса в целом.
«серебренная» => серебряная
Скажу от себя, что Канбан плохо подходит для клиентской поддержки. Казалось бы, он даёт инструмент для быстрого реагирования, но зато полностью отбирает возможность получить какую-либо определённость в сроке исполнения задачи, потому что любая работа может быть сдвинута на неопределённый срок другими задачами.
Да и в целом, я бы не стал называть Канбан методологией. Это скорее удобная практика, которую можно применять в подходящих случаях.
Я бы никогда не стал в лоб спрашивать, какой бюджет — они и сами могут не знать (они и задачу-то свою могут не знать, мало ли что в ТЗ понаписали). Со своей стороны я всегда стараюсь максимально кратко и доходчиво объяснить, почему трудно оценивать уникальные решения. Раз уж ТЗ прилагается — всегда можно назвать и вилку цены, но объяснить, по каким причинам названа вилка, за счёт чего цена может снизиться или вырасти (если мы делаем этот блок сложно, то дороже, если вот этот проще, ну и так далее).
Главное больше спрашивать о задаче, узнать о бизнесе клиента, постараться лучше уловить, какой именно уровень бюджета он ожидает, какой уровень проработанности решения он ожидает. В общем, это практика продаж, здесь готового решения нет.
Иногда он очень важен, иногда жёстко зафиксирован, поэтому и озвучивается раньше прочих требований. Довольно часто бывает и наоборот, конечный бюджет не так важен, как другие требования.