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

Подробный гайд Agile-коуча и эксперта ScrumTrek Василия Савунова о том, какие данные помогут тимлидам поймать все яйца (зачеркнуто) справиться с лавиной из задач, выжить и победить хаос.

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

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

Понятно, что следующим закономерным, но отнюдь не здоровым шагом будет решение увеличить продолжительность рабочего дня, а потом недели, и вот вы уже в ловушке, работая 24/7. Что с этим делать?

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

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

Когда ученые сталкиваются с каким-то незнакомым объектом или явлением, они начинают наблюдать за ним, описывают, как он реагирует на внешние раздражители, и пытаются выявить некоторые закономерности его поведения, чтобы понять, как с ним можно взаимодействовать. В нашем случае предлагаю поступить аналогичным образом: представим, что наши рабочие процессы — это черный ящик. Этот чёрный ящик дает результаты, но мы пока не знаем, как он работает.

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

Вот какие данные нам пригодятся для начала:

1. Определить общую пропускную способность. Частая ситуация, когда количество принятых в работу и фактически реализованных задач не совпадает. Поэтому важно измерить, сколько задач ежемесячно подается на вход и сколько выходит готовыми за этот же период. Конечно, задачи разные, но нам пока нужно понять общую картину.

2. Определить пропускную способность по типам работ. Для этого необходимо разделить все поступающие задачи на категории, например дефекты, разработка нового функционала и т. д. И посмотреть, сколько задач разного типа «обрабатывает» за месяц наш рабочий процесс.

3. Определить время нахождения задачи в черном ящике. Мы можем измерить время от момента попадания задачи в черный ящик до момента выхода ее из него. Это время выполнения задачи (Lead Time) . Стоит посчитать, сколько оно составляет для любых задач и как изменяется в зависимости от типа задачи.

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

Хорошая новость: на дворе XXI век! Компании используют огромное количество трекеров задач (JIRA, TFS, Youtrack и др.) , которые позволяют получать разные срезы данных, комбинировать их и на основе полученных результатов формировать статистику и делать обоснованные прогнозы по срокам.

Скорее всего, прямо сейчас вы уже мониторите свои рабочие процессы в одном из таких трекеров. И первое, что необходимо замерить: время от момента, когда вы пообещали заказчику сделать задачу (точка принятия обязательств), до момента, когда вы передали готовое решение заказчику и он принял у вас работу (точка отдачи обязательств) . Большинство трекеров это позволяет сделать из коробки, если в вашем случае это не так, используйте вот такой Excel-шаблон, чтобы протестировать свои цифры или адаптировать этот вариант таблицы под себя. (Дисклеймер к шаблону: его надо будет изменить под вашу реальность, потому что ваши статусы задач и диапазоны ячеек для формул могут быть другими).

У кого-то может возникнуть вопрос: а мне это точно нужно, если в нашей компании используется Scrum? Согласен, в идеальной картине мира такая команда принимает задачу в одном спринте и в этом же спринте ее закрывает. Но давайте начистоту: как часто такое встречается на практике?

Обычная история, когда команда берет задачу в одном спринте, затем она переезжает во второй спринт, потому что не успели что-то доделать, и только в третьем спринте она, наконец, завершена. Что это значит с точки зрения статистики? Это значит, что у вас есть распределение времени выполнения от одного спринта до нескольких. И главный вопрос: знаете ли вы, как выглядит это распределение? Какую вероятность по времени выполнения из него можно достать? Чаще всего ответ: «Нет, не знаем».

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

Переходим к аналитике и выводам, которые мы можем сделать на основе собранных данных.

Если в течение длительного отрезка времени (3-6 месяцев) вы собираете данные о времени выполнения разных задач, то всё это можно отобразить на диаграмме распределения, которая строится так: по вертикали отмечаете количество раз, которое вы наблюдали одно и то же время выполнения задачи, по горизонтали — само время выполнения в днях.

В итоге получается диаграмма примерно такого вида, где мы можем заметить одну закономерность: задачи сосредоточены возле двух точек — 3 или 7 дней. С большой долей вероятности это разные типы работ, условно говоря, около 3-х дней может занимать работа над багами, а ближе к 7-ми — разработка несложного функционала. Теперь понимая эту разницу, мы можем разделить нашу статистику по типам работ.

На нашем графике мы выделили 2 типа работ: зеленые и красные задачи. Первое, что можно сказать определенно, глядя на эти данные: ни одна задача зеленого типа никогда не выполнялась дольше, чем за 4 дня. И это не чья-то экспертная оценка, а реальные данные статистики, с которыми очень сложно спорить.

Это значит, что мы можем обоснованно утверждать, что любая задача зеленого типа будет выполнена за 4 дня с вероятностью 100%.

Вопрос: а всегда ли нам нужна 100% вероятность времени выполнения? Скорее речь идет об исключительных случаях, например, когда регулятор (правительство, профильное министерство, Центробанк и т. п.) предписывает сделать задачу к определенному сроку, и нам никак нельзя опоздать, иначе отберут лицензию. Пример: профильное министерство издало новое законодательное требование к маркировке, которое должно быть выполнено к 1 января будущего года. Для таких задач обязательно надо знать срок выполнения с вероятностью 100%.

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

Давайте разберемся, как вычислить вероятность выполнения задачи в течение определенного срока?

Например, мы хотим понять из примера выше, с какой вероятностью можно сделать зеленую задачу за 3 дня. Для вычисления используем формулу, которая хорошо известна тем, кто знаком с теорией вероятности.

P = N успешных / M всего

В знаменатель попадет общее число наблюдаемых за данный период сделанных зеленых задач (= 10), в числитель — количество задач, которые были успешно завершены в течение 3 дней (= 8), в результате вероятность выполнить эту задачу за 3 дня равна 80%.

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

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

Как делить задачи по типам? Во-первых, у вас наверняка уже есть сложившиеся типы задач в команде, например: дефекты, новые корректировки, доработки, исследования и т.д. За основу можно взять эти типы и на их основе построить график. Позже на основе данных вы сможете увидеть ещё какие-то типы работ, которые не были очевидны изначально.

Выше мы разобрали, как правильно замерять время непосредственного выполнения задачи в системе производства. Условно назовем его System Lead Time. Оно важно для тимлидов, т. к. позволяет быстро дать прогноз — за сколько времени ваша команда сделает задачу конкретного типа.

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

Соответственно, необходимо замерять полное время ожидания заказчиком — от момента, когда задача попадает в бэклог, до момента, когда заказчик ее примет. Назовем этот отрезок времени Customer Lead Time.

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

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

Поэтому крайне важно замерять время первого касания (First Touch Time) : от момента появления задачи в бэклоге до фактического старта работ.

Имея все эти 3 времени на руках — System Lead Time, Customer Lead Time и First Touch Time — вам и заказчику будет доступна полная статистическая картина рабочего процесса, на основе которой можно прогнозировать время выполнения задач и загрузку вашей команды.

Пропускная способность — это объем задач, который ваша команда может выполнить за определенный период времени (неделя/месяц/квартал и т. д.). Для примера давайте посмотрим на реальный график одной из команд, где синим цветом отмечены входящие задачи, а зеленым – готовые. Ребята приступили к работе только в июле и первые 3 месяца «раскачивались», знакомились с тем, как все работает, срабатывались и набирали опыт – это видно на графике по первым 3-м месяцам. А в полную силу команда заработала с октября. На основе этого периода и следует оценивать реальную пропускную способность.

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

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

Как на это ответить тимлиду? Какие данные нам помогут?

Ответ находится в стоимости этих «вбросов» для компании. И мы это можем посчитать.

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

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

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

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

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

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

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

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

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

Очевидно, что детали происходящего в колонке In Progress скрыты от нас. Нам известен состав команд, этапы, которые проходит задача, но в текущем виде мы не можем определить, какие причины тормозят рабочий процесс и где на самом деле находится узкое место внутри команды. Чтобы лучше понять, как взаимосвязаны внутренние процессы и время выполнения, вы можете размасштабировать колонку In Progress: собраться с командой, отрисовать реальный рабочий процесс внутри команды и визуализировать его на доске. Учитывая, что пропускная способность разных этапов будет отличаться, полученная схема будет похожа на трубу, состоящую из элементов разного диаметра, что обозначает наличие большей или меньшей пропускной способности на каждом этапе выполнения задачи.

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

Зная это узкое место, вы сможете понимать, где конкретно требуются улучшения и можете придумать, какой рычаг следует задействовать, чтобы ускориться. Например, в команде разработки тестировщики часто становятся тем самым узким местом, так как в конце спринта на них ложится огромное количество задач по тестированию. Самое простое, что приходит в голову, это добавить людей. Только не забывайте, что увеличение мощности в одном месте может привести к снижению пропускной способности в другом дальше по процессу. Например, в рабочем процессе на картинке выше в случае резкого ускорения этапа тестирования начнет тормозить последующий этап регресса. Кроме того, найм новых людей – это согласование дополнительного бюджета, затраты времени на онбординг и погружение нового человека в текущие процессы, т. е. реальную пользу от принятого решения мы сможем ощутить только через 3-6 месяцев. Поэтому в данном случае вместо найма нового сотрудника выгоднее перекинуть мощности из другого этапа и усилить тем самым нужный участок. Например, почему бы аналитикам не помогать тестировщикам? Все равно для них нет смысла делать новые задачи до тех пор, пока на этапе тестирования образовался затор.

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

В качестве заключения еще раз делимся чек-листом для сбора данных за квартал, которые позволят увереннее прогнозировать сроки выполнения задач и принимать взвешенные управленческие решения:

– сколько задач поступило (Demand) ,

– сколько задач выполнили (Capacity) ,

– сколько задач начали, но отложили.