Как менеджеру прогнозировать сроки выполнения задачи с вероятностью 80-90%?

06.05.24

Управление проектом - Канбан и поставка ценности

Менеджерам постоянно приходится отвечать на вопрос «когда сделаете?» или «когда будет готово?». Но любой менеджер знает – чтобы гарантированно уложиться в срок, нужно заложить трехкратный запас времени. Заказчики этот принцип тоже знают и стремятся срезать срок, насколько это возможно. Обе роли «торгуются» и давят друг на друга, пока кто-нибудь не продавит свое решение. В итоге недовольными, как правило, оказываются все. Попробуем прервать этот порочный круг, используя немного математики и теории вероятностей. Расскажем, как прогнозировать срок задачи на основе объективных данных с вероятностью 80%.

 

Меня зовут Василий Савунов, я в прошлом разработчик, а в последние семь лет выступаю как Agile-коуч – активно учу менеджеров и разработчиков тому, как делать хорошо. Я буду рассказывать про Канбан-метод.

 

 

Как ни печально, для многих, и даже для меня как для Канбан-тренера, основная ассоциация с Канбан-методом – это стикеры и доски.

 

 

Большинство людей считает, что Канбан – это когда повесили стикеры на доски, и наступило счастье. А почему должно наступить счастье? Что такого происходит? Это главный вопрос, на который я хочу ответить.

 

 

Канбан-метод – это не только стикеры и доски, в Канбан-методе заложено много всего:

  • и коучинг;

  • и вероятностное прогнозирование;

  • и теория ограничений – очень много чего.

 

 

Мы сегодня поговорим о двух вещах, которые, на мой взгляд, играют очень важную роль в понимании того, что такое Канбан-метод – это вероятностное моделирование (прогнозирование) и визуальный менеджмент.

 

Чем Канбан-метод может помочь менеджеру?

 

 

Итак, Канбан-метод – доски и стикеры. Чем это может помочь менеджеру?

Под менеджерами я понимаю широкий круг людей – это люди, которые управляют теми или иными заданиями для своих подчиненных. Это либо руководители проектов, либо линейные руководители, либо еще кто-нибудь.

 

 

У менеджеров всегда есть бизнес-заказчик, который постоянно придумывает какие-то задачи.

 

 

Например, он требует внести какие-то правки в код – конечно же, это нужно сделать срочно, и чтобы все-все-все сразу заработало. Он спрашивает: «Когда будет сделано?» И ему нужно срочно ответить.

Вы же для этого и работаете руководителем проекта, чтобы отвечать на такие вопросы, правильно?

 

 

Вы, как умный человек, говорите: «А ТЗ есть? Будет ТЗ – будет оценка». Без ТЗ и результат получится так себе – все же об этом помнят?

 

 

Бизнес-заказчик тоже не дурак и уже давно играет с вами в эту игру, он говорит: «Дайте примерный срок, мне для себя нужно понимать – это долго или нет».

 

 

Но вы же знаете, что есть риск. Если назвать примерный срок, он легко превратится в дедлайн – я думаю, многие из вас неоднократно испытали это на своей шкуре.

 

 

Поэтому многие руководители проектов в ответ на этот вопрос говорят: «Мне надо поговорить с техническим специалистом, который занимается этой проблемой (этой системой, компонентом – чем угодно). Я с ним поговорю и приду уже с уточненным сроком».

 

 

Идете к своему специалисту, который тихонечко программировал, ничего не подозревая, и просите его оценить задачу: «Там что-то придумали наверху, Нужен примерный срок».

Специалист, конечно, задает вопрос: «А есть ли ТЗ?» Он тоже уже давно в эту игру играет, чуть ли не всю жизнь – он может еще мастер похлеще вас в этом плане.

 

 

И когда он слышит: «ТЗ нет, но нужен примерный срок», он напрягается. И я его прекрасно понимаю – никто из разработчиков не любит, когда его выдергивают из комфортного программистского мирка.

В результате, проклиная все на свете, специалист называет завышенный срок – например, месяц на какую-то маленькую доделку. Либо чтобы отстали, потому что слишком долго. Либо, чтобы точно было время на то, чтобы в его загруженном графике сделать все.

 

 

Окей, берем этот срок и идем к нашему бизнес-заказчику.

Тут многие руководители проектов включают прошлый опыт, вспоминая, что срок от специалиста называть нельзя. Он его посчитал примерно, а что там по ходу дела будет – никто не знает. Надо заложить буфер – например, умножить это число на «пи» и прибавить 20%, тогда гарантированно успеем.

 

 

Вы говорите заказчику, что сделаете задачу за четыре месяца вместо одного, и глаза у него становятся вот такие.

 

 

Он в голове считает, что будет с его контрактными обязательствами, сколько будет стоить отодвинуть дедлайны, и говорит вам в ответ что-то неприятное.

А дальше начинается торг. Он говорит: «Я вам столько времени не дам». А вы говорите, что при текущем уровне проработки задачи и ресурсов уложиться в меньшие сроки – нереально.

 

 

В итоге он срезает обозначенный вами срок раза в два, и все довольны. Потому что, если бы вы месяц попросили, он бы вам только две недели дал. А теперь у вас два месяца есть – все вообще шикарно и замечательно, правда?

Эту ситуацию я в менеджменте наблюдаю очень много лет. И мне так обидно всегда за этих людей, потому что и бизнес-заказчик, и руководитель проекта, и специалист – они же все умные люди, институты заканчивали. Я уверен, что они все хотят хорошего – я еще не встречал человека, который приходит на работу с намерением сделать работу плохо.

Не бывает же такого, чтобы программист приходил на работу с мыслью: «Вот я сегодня наговнокодю…»

И не бывает руководителей проектов, которые думают: «Завалю-ка я парочку проектов сегодня…»

Нет, все хотят хорошего, но почему-то получается какое-то «колесо Сансары».

 

 

Проходит два месяца… Заказчик ваше обещание себе записал, напоминалку в календарь поставил – он же ничего обычно не забывает.

 

 

Но через два месяца вполне может оказаться, что вы скажете: «Извините, мы не успели. У нас ресурсов не хватило».

Получается, что при всех этих наших «умножим на число пи, прибавим 20%», мы все равно можем не попасть в срок. Все это потому, что будущего никто не знает.

Предсказывать будущее пока еще никто не умеет – может быть, искусственный интеллект что-то поменяет, но мы как люди пока этому не научились.

 

 

Мы опять слушаем эти неприятные слова, и все повторяется заново.

Давайте порассуждаем, на основании чего обычно дается оценка или прогноз срока:

  • Либо это прошлый опыт – если мы задачу в прошлом за такой срок делали, значит и в будущем за такой срок сделаем.

  • Либо это экспертное мнение сотрудника – я как раз такой пример приводил.

  • Либо это просто бюджетные и временные ограничения – когда у нас срок и бюджет четко прибиты гвоздями. А вы – как хотите, так в эти ограничения и влезайте.

 

 

Но погодите, мы же с вами живем в 21 веке. У нас под ногами валяется куча данных во всяких наших системах – в трекерах задач, в диаграммах Ганта, в чем угодно.

 

 

Это же просто золото, на котором мы с вами сидим – почему бы нам это не использовать?

 

 

Почему бы не превратить эти исторические данные во что-то, что позволило бы нам давать сроки, не отвлекая специалистов? Чтобы мы могли хотя бы с вероятностью 80% попадать в этот срок.

Неплохо было бы? По-моему, неплохо.

 

Вероятность времени выполнения для разных типов задач

 

 

Рассмотрим реальный процесс разработки.

Все знают, что Канбан – это стикеры и доски. Но не все знают, что на Канбан-доске есть две важные точки.

  • Первая точка – это точка принятия обязательств, когда мы говорим заказчику: «Да, мы эту работу сделаем».

  • Вторая точка – это точка отдачи обязательств, когда заказчик принял у нас работу и сказал: «Все, претензий больше не имею».

Время между этими двумя точками в Канбан-методе называется Lead Time (или время производства) – у нас появляется очень полезный материал для прогнозирования.

 

 

Допустим, мы собрали данные по этим временам завершения за три месяца или за полгода – замерили, за сколько дней, недель, месяцев завершались задачи.

Раскладываем эти сроки на такой диаграмме.

  • По оси x – само время – один день, два дня, три дня.

  • А по оси y – сколько раз мы такое время наблюдали.

Видно, что за пять дней завершилась одна задача, за три дня – четыре задачи, за восемь дней – тоже одна. Т.е. количество крестиков – это столько задач завершилось.

Первое, что интересно на этой диаграмме – мы видим какие-то пики или горбики. Почему-то какой-то пласт задач тусуется возле времени три дня, а какой-то пласт задач – возле времени семь дней.

С точки зрения статистики – это некое вероятностное распределение. А с точки зрения Канбан-метода – это с большой долей вероятности разные типы работ.

 

 

Например:

  • зеленая область – это какие-то мелкие дефекты, которые мы дорабатываем до трех дней;

  • а розовая область – это уже небольшие доработки бизнесового характера, которые занимают до недели.

Разная природа работ диктует разное распределение по времени.

 

 

Либо мы можем пойти от обратного, и заранее поделить задачи по типам работ – дефекты, доработки, исследования, интеграции – и тоже отобразить их на графике.

 

 

Когда мы эту статистику поделили по типам задач, оказалось, что с вероятностью 100% любую задачу типа «зеленый» мы никогда не делали дольше, чем за четыре дня.

Причем, это уже не мое экспертное мнение – это я взял данные за длинный период, разложил их на частотной диаграмме и могу с уверенностью сказать, что с вероятностью 100% срок по «зеленым» задачам – 4 дня.

Если мой заказчик хочет этим поспорить – ради бога. Только не со мной надо спорить, а с данными, которые я собрал. Пожалуйста, они все открыты, хотите – перепроверьте. Если в данных ошибка – мы их поправим, и тогда придется поверить тому, что я говорю. Если в них нет ошибки, значит, я прав – это действительно реальный срок, на который можно ориентироваться.

Но в каких задачах действительно нужно 100% попадание в срок? Только если это какое-нибудь регуляторное требование от министерства или от правительства – когда с какой-то определенной даты стартует новая норма или маркировка, и мы обязаны к этой дате все сделать. В этом случае для оценки мы берем самый длинный срок – самый пессимистичный, 100%.

Но для большинства задач нет необходимости брать самый пессимистичный срок. Если вы как менеджер смотрите на эту статистику и спрашиваете: «Окей, 4 дня – это 100%. А какая вероятность сделать зеленую задачу за 3 дня?»

Те, кто в университете изучали теорию вероятностей, эту формулу знают.

  • в знаменатель ставим общее количество попыток;

  • а в числитель – количество нужных нам исходов.

То же самое мы делаем с этой диаграммой.

 

 

Итак, общее количество задач «зеленого» типа на этой диаграмме 10 штук – мы видим здесь 10 зеленых крестиков.

 

 

При этом в течение 3 дней было сделано 8 задач – 8 зеленых крестиков в период до 3-х дней.

Соответственно, вероятность сделать «зеленую» задачу в течение трех дней равна 80%. А в течении двух дней – 40%.

Смотрите, как интересно – я теперь могу давать прогноз с заданной вероятностью.

Никакой магии. Я просто собрал данные, правильно их обработал и посчитал по формуле.

 

 

Из практики Канбан-метода известно, что для большинства бизнес-задач достаточно использовать вероятность 80-90%, потому что для обычных задач несколько дней – не особо критично. Критично, только если у нас регуляторная задача – тогда срок измеряем по 100% вероятности.

 

 

То же самое и по остальным типам работ: любую «красную» задачу мы 100% можем сделать за 11 дней, а с вероятностью 77% – за 7 дней.

Теперь можно даже не теребить наших разработчиков – можно просто собрать статистические данные от ИТ-отдела и посмотреть временные характеристики, которые характерны для этого отдела.

Если очень хочется, можно их поделить на данные по конкретному разработчику – за сколько он примерно сделает.

Эти данные можно нарезать как хотите – на любые слои и любые подуровни.

 

 

Но иногда бывает, что отдельная задачка – хотя и «красная», но все «красные» тусуются здесь, а она улетела куда-то влево.

Это как-то странно – приходится копаться в этой задаче.

Смотрите, это по-прежнему красный крестик – это один и тот же тип работ.

Но часто выясняется, что этот красный крестик к нам принес генеральный директор со словами: «Меня не интересует, что вы обычно делаете задачи за 8 дней, эта должна быть сделана за 2 дня максимум». Вы напряглись, напрягли своих программистов, аналитиков, и они сделали вам задачу за 2 дня.

По сути, вы для данной задачи подняли класс обслуживания – это все та же «красная» задача, но теперь с другим классом обслуживания.

 

 

Что это нам дает? Если в рамках конкретного типа работ мы правильно разделим их на классы обслуживания и соберем статистику по отдельным классам, то мы можем очень спокойно отвечать на вопросы:

  • когда будет сделана срочная задача;

  • когда будет сделана задача типа «норма»;

  • и когда будет сделана задача типа «когда-нибудь».

Наложение типа и класса обслуживания дает нам большую точность в прогнозировании.

 

 

Например:

  • приходит «красная» задача с классом обслуживания «Горим» – мы ее можем сделать за 2 дня;

  • приходит «красная» задача обычного класса – мы ее можем сделать не больше чем за 8 дней;

  • приходит «красная» задача класса «когда-нибудь» – мы ее можем сделать за 11 дней.

Все это статистика и математика – никакой магии.

 

 

И получается, что стикеры и доски, о которых я в самом начале упомянул – это инструмент сбора данных.

Если мы правильно спроектировали доску, правильно работаем с ней – не просто вешаем стикеры на доску, а осознанно перемещаем их и отмечаем время, которое они провели на доске – у нас появляется когорта данных. На основе этой когорты можно делать вероятностные прогнозы.

Как именно это делать, я сейчас не буду рассказывать, но в конце доклада покажу книгу, где это очень хорошо описано.

 

Реальный кейс применения Канбан-метода в компании SOKOLOV

 

 

Хочу рассказать реальный кейс применения такого подхода в реальной компании SOKOLOV, с которой я активно сотрудничаю в последние 3 года.

 

 

Так как компания занимается различными направлениями деятельности – от производства до распространения, у них достаточно большое количество бизнес-подразделений. И руководителям этих бизнес-подразделений каждый день требуются аналитические данные по разным срезам: производство, логистика, какие-то финансовые отчеты и так далее.

У них есть аналитический отдел, куда стекаются хотелки этих подразделений о том, какие отчеты им надо автоматически на регулярной основе собирать и отсылать.

Каждый из этих отчетов сам по себе – это такой мини-проект. Потому что надо понять, что там внутри – достать данные, все это оформить. Потом надо обсудить с заказчиком, правильно ли мы все сделали, и так далее – очень много действий.

 

 

И когда я туда пришел, там была ситуация следующая.

  • Заказчики были недовольны тем, что сроки непредсказуемы, они долгие, и аналитический отдел не может точно спрогнозировать, когда что будет сделано.

  • А ребята из аналитической группы – дата-инженеры, бэкенд-программисты, фронтенды – были перегружены, и им никто не помогал в важных для них вопросах.

С этого состояния мы начали.

 

Первое, что я сделал, это спросил: «А как вы ведете задачи?» Они мне показали вот такую доску в системе YouTrack.

 

 

На этой доске мы с руководителем проекта выяснили, что:

  • Точка принятия обязательств находится между колонками «Разобрано» и «Можно брать». Это какой-то накопитель, куда перемещаются задачи, по которым руководитель проекта сказал: «Да, мы это сделаем».

  • А точка отдачи обязательств находится после колонки «На проверке». На этом этапе задачу проверяет бизнес-заказчик и задача переходит в «Готово».

Время прохождения задачи между этими двумя точками я попросил выгрузить.

 

 

Получился вот такой график.

Первое, что привлекло мое внимание – что основная масса данных до 40 дней, и есть какие-то непонятные задачи, которые очень далеко. Это вызывает вопросы.

 

 

Если увеличение срока по таким задачам произошло по регулярным причинам, и мы каждый день сталкиваемся с чем-то, что отбрасывает срок наших задач очень далеко, тогда 100% срок выполнения в рабочей системе будет равен 78 дней, что довольно долго.

 

 

А если это какие-то случайности, аномалии, то, наверное, для долгосрочного прогнозирования я могу их отбросить из рассмотрения.

 

 

Стали разбираться, что это было.

  • В одном случае там произошло все, что могло пойти не так. Заказчик заболел, разработчик уволился, сервер сломался. Все, что могло пойти не так, пошло не так, поэтому отчет делали очень долго – 78 дней.

  • В другом случае у отчета было 6 заказчиков и один неопытный исполнитель. Пришлось его спасать – от этого срок тоже уехал.

  • И еще один момент был, когда был период отпусков, и на одного разработчика свалилось все сразу – из-за этого он одну задачу не удержал, она уехала по срокам.

Все эти три случая не являются чем-то, что происходит каждый день – это что-то форс-мажорное, исключительное, аномальное.

 

 

Поэтому я с чистой совестью мог отбросить эти значения и ориентироваться на 95-процентный прогноз, который составлял 32 дня. Это уже лучше, чем 78.

В итоге первым поинтом разговора с бизнес-заказчиком стало обещание о том, что в течение 32 дней мы сделаем любую задачу – вообще любую, какую бы нам ни закинули. Я предложил ориентироваться на это время, а время, которое кратно меньше этого, считать явно очень оптимистичным и маловероятным.

 

 

Дальше я обратил внимание, что на диаграмме есть не очень ярко выраженные «горбики», и захотел разобраться, какого типа задачи преобладают в каждом таком «горбике».

Мы с ребятами недельку потратили на это, и выяснилось, что в каждом «горбике» повторяется какой-то один из типов работ, которые мы делали: новый отчет, аудит отчета, какие-то доработки и так далее.

Зная эту типологию, я смог разделить статистику по типам работ.

 

 

Например, вот так выглядит статистика реализации первой версии аналитического отчета.

Первой версии – потому что на тот момент, когда мы собирали данные, ребята не умели мерить время одновременно и по первой версии, и по доработкам. Никто не пытался их в единую цепочку склеить, это были отдельные задачи.

Теперь, когда заказчик приходит с вопросом: «Когда будет сделан такой-то отчет?», ему можно ответить: «С вероятностью 78% – 10 дней, ориентируйся на этот срок».

А доработки – до 5 дней.

Соответственно, можно прикинуть среднее количество доработок, умножить, и вот мы получаем примерный срок реализации практически любого отчета.

 

 

То же самое по всем остальным типам работ.

Аудит отчета – это когда они цифры проверяли.

Задачи Service Desk – это когда по техподдержке что-то прилетало.

 

 

Доработка рассылок, технические работы и так далее.

 

 

Теперь мы заказчику уже могли говорить предметно, какое ожидание по данному типу работ он себе должен заложить в свои планы.

Конечно, это не было простым разговором, но трое заказчиков из шести сказали: «А это интересно. Наконец-то у вас есть данные на которые можно опираться!»

Эти три заказчика действительно стали пилотными, с которыми мы начали работать по этой структуре. Они закладывали эти сроки в свои планы и на них ориентировались при разработке. Это позволило несколько стабилизировать нагрузку на ребят, упорядочить ее, и спустя буквально месяц-два эти показатели стали подтверждаться все более и более точно.

Благодаря этому мы остальных заказчиков тоже смогли убедить и затащить в эту схему.

 

 

Помимо точки принятия обязательств и точки отдачи обязательств мы увидели еще одно интересное время – это время от момента, когда реальный сотрудник (бэкенд-программист или дата-инженер) взял в руки какую-то задачу и начал что-то делать до момента, когда он ее отдал. Это другое время.

 

 

Мы тоже его посмотрели и сравнили с показателями общего времени жизни задачи:

  • Слева на слайде – диаграмма общего времени жизни задачи, про которую я вам уже рассказал.

  • А справа – время, за которое делается задача от момента, когда реально технический специалист ее начал, до момента, когда он ее отдал.

Обратите внимание, наиболее вероятное время, пока заказчик ждет задачу – 24 дня, а делаем мы ее примерно 7 дней. Разница в три раза. Как-то очень странно.

 

 

Стали выяснять, что происходит. И действительно выяснилось, что в колонке «Можно брать» задача с большой долей вероятности валяется до 17 дней – она чего-то ждет.

А с точки зрения Канбан-метода, если в какой-то колонке копится работа, это означает, что процесс после этой колонки, не вытягивает задачу с такой скоростью, в которую мы в него напихиваем. Если бы он быстрее вытягивал, там бы ничего не копилось. А раз копится, значит, исполнители не успевают сделать то, что им напихивают.

Это было вторым пунктом к разговору. О том, что пропускная способность нашего аналитического отдела не бесконечна, она имеет пределы. И вы, дорогие заказчики, ориентируйтесь на завышенное значение наших возможностей. Вы хотите чего-то большего, а мы при текущем уровне ресурсов и инфраструктуры этого не можем. Давайте ориентироваться на более реалистичные показатели пропускной способности.

 

 

Дополнительно мы посмотрели медианные значения каждого из этапов – на слайде можно увидеть, что:

  • 20 дней задача чего-то ждет,

  • 9 дней над ней работают,

  • И 7 дней ее заказчик принимает. Причем на время приемки заказчик мог повлиять непосредственно – достаточно принимать в течение одного дня, а не семи, и уже существенно сэкономится время.

 

 

Дальше мы подумали, что надо бы посмотреть вглубь. Например, у нас была одна колонка «В работе», и было непонятно, что там происходит. Мы не могли это померить, а в Канбан-методе, как вы поняли, все на метриках и на измерениях.

 

 

Я сел с ребятами, которые непосредственно работают руками, и мы расписали с ними их рабочий процесс в виде value stream map (потока создания ценности). Это схема, где видно – куда задача попадает, кто ее берет первый, как она потом идет и т.д.

 

 

В этом потоке создания ценности мы выделили ряд этапов, которые повторялись постоянно, для большинства задач.

И теперь у нас появилась возможность замерять время не в целом на колонку «В работе», а на отдельных ее этапах. Чтобы увидеть, какой именно этап тормозит больше всего, и, покопавшись там, найти причину и ее устранить.

Забегая вперед, хочу сказать, что самым долгим оказался этап «Подготовка источников». Они забирали данные из 1С:Бухгалтерия, из Битрикса и других систем, которыми владели другие подразделения. А у тех подразделений была своя очередь, свои приоритеты, они не жаждали помогать. Эти задержки не давали возможности аналитическому отделу выполнять задачи так быстро, как мы бы могли.

Это и стало главной проблемой, которую мы дальше решали.

 

 

Мы стали собирать факты, когда нас стороннее подразделение, другое в этой компании, блокировало.

Если сотрудник с утра на планерке говорил: «Я ничего по этой задаче сейчас сделать не могу – я запросил у соседнего подразделения доступы, а доступы мне не дали», мы обозначаем эту задачу специальным маркером – блокером.

Эти блокеры мы коллекционируем и в конце месяца выясняем, каких блокеров было больше:

  • внутренних – когда мы неправильно сделали;

  • или внешних – когда соседнее подразделение нас задержало.

Дальше мы статистику переводим во временные и денежные показатели, и идем с ней в подразделение со словами: «Дорогой отдел логистики, по нашей статистике вы за последний квартал нас задержали на 21 день. Суммарно это составило вот столько примерно денег. Мы с этой статистикой пока еще никуда не ходили, мы к вам первым пришли. Давайте поговорим». И дальше там диалог завязывался.

Там было два характерных случая:

  • В одном случае соседнее подразделение работало по Scrum. Они нам сказали: «Вы к нам приходите посреди спринта. Мы посреди спринта не можем вам в моменте что-то обещать. Приходите, когда у нас планирование, и мы будем договариваться о квоте». Договорились о точках, когда приходить, и все стало нормально.

  • А отдел логистики сказал: «Ну да, мы долгие. Давайте ориентироваться на 21 день. Вы себе будете закладывать это в SLA, что мы вам будем отдавать за 21 день. Если на 18-й день мы вам ничего не отдали, вы нам пишете. Если на 20-й день мы вам ничего не отдали, вы нам звоните. А на 21-й день мы сами себе злобные бакланы – эскалируете, что делать».

Появляются какие-то правила взаимодействия. И это начало выравнивать дальше наш рабочий поток и его предсказуемость.

 

С чего стоит начать?

 

 

Теперь о том, с чего начать.

Первое, что надо сделать – это определиться с тем, от какого момента до какого надо мерить время.

И тут главная проблема – определить точку принятия обязательств и точку отдачи обязательства. Если мы это сделаем неправильно, статистика будет кривая.

Дальше нужно дать кому-то задание делать выгрузку по отчетам Lead Time.

 

 

А что делать, если доска физическая? Конечно, после двух лет пандемии я в этом сомневаюсь, но вдруг у кого-то до сих пор вся деятельность в офисе.

В этом случае – все то же самое, просто чуть сложнее.

 

 

Вы определяете, где у вас находится точка принятия обязательств. И в момент, когда стикер переходит эту точку, пишете стартовую дату – это значит, что работа над задачей началась.

 

 

А когда стикер переходит финишную черту, вы пишите финишную дату.

И в конце месяца собираете эти стикеры, подсчитываете время и строите диаграмму, которую я вам показал.

Это то, с чего стоит начать, если вы хотите прогнозировать сроки выполнения задач и понимать возможности вашей команды. А потом уже можно пойти глубже – разделить задачи по типам работ или что-то еще с ними сделать.

 

На слайде – книги, которые я рекомендую.

  • «Цель» и «Цель 2» Голдратта – я думаю, многие знают. Теория ограничений в данном случае имеет огромное значение. Эти книги написаны в формате бизнес-романа, там все довольно понятно. Когда я был техническим директором, эти книги перевернули мое мировоззрение.

  • Доминика Деграндис «Визуализируйте работу» – о том, как проектировать Канбан-доски и использовать стикеры, чтобы можно было снимать статистику.

  • И толстый том «Канбан-метод» от Майка Барроуза. Он хорошо написан, понятным языком – очень рекомендую к прочтению. Можно почитать «Канбан. Альтернативный путь в Agile» от Дэвида Андерсона, основателя Канбан-метода, но он довольно занудный, а вариант от Барроуза повеселее.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4728    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3715    0    user1853337    8    

29

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6415    0    stnslv    5    

25

Канбан и поставка ценности Бесплатно (free)

Часто перед менеджерами возникает вопрос, каким управленческим подходом пользоваться, чтобы реализовать проект максимально эффективно для команды и для заказчика. Свое видение на этот счет с позиции работы с содержанием высказал автор множества книг, статей и курсов по проектному управлению Иван Селиховкин.

23.05.2022    2876    0    Selikhovkin    1    

6

Канбан и поставка ценности Бесплатно (free)

Директор по проектам Инфостарт Мария Темчина на конференции Infostart Event Post-Apocalypse делала большой доклад о внедрении Канбан-систем. В преддверии старта курсов Марии по управлению ИТ-проектами редакция Инфостарт решила поделиться с читателями докладом о работе ИТ-команд с Канбан. В статье вы узнаете, зачем внедрять такую систему работы, и как она помогает договариваться разработчикам и бизнесу.

22.04.2022    4302    0    MariaTemchina    1    

19

Канбан и поставка ценности Бесплатно (free)

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    6017    0    MariaTemchina    17    

25

Канбан и поставка ценности Бизнес-аналитик Руководитель проекта Бесплатно (free)

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    12022    0    MariaTemchina    13    

33

Канбан и поставка ценности Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Россия Бесплатно (free)

Слово "Канбан" слышали все, кто работает в производстве, в поддержке и в ИТ-разработках. В этой статье я попробую рассказать про Канбан подробно, обобщить принципы и опыт (мой и ближайшего окружения) по внедрению на практике этой системы с упоминанием возникающих при этом "граблей" и рекомендаций по борьбе с ними.

08.08.2018    33899    0    MariaTemchina    66    

85
Оставьте свое сообщение