Неочевидное № 1. Функция тимлида в команде
Многие думают, что главная роль лидера в команде — следить за тем, чтобы все его работники были заняты. А если вдруг у кого-то нет работы, значит, её надо найти. Но это заблуждение.
Главная функция менеджера — доставлять бизнес-ценность клиенту, то есть приносить деньги компании. И лидеру нужно фокусироваться не на том, чтобы просто занимать сотрудников, а на том, чтобы через команду проходил поток работы.
Тимлиду важно следить за тем, чтобы работы завершались и не накапливались. Для этого есть определённый набор инструментов, который стоит изучить. Их вы можете найти в книге Дональда Рейнертсена The Principles of Product Development Flow.
Не надо следить за тем, чтобы все были заняты, продуктивность сотрудников от этого не зависит. Лидеру нужно наладить поток работы через команду.
Неочевидное № 2. Понятие «рабочий процесс»
Мы привыкли видеть, как люди в команде передают работу друг другу. Аналитик проанализировал бизнес-запрос, сформулировал требования и передал системному аналитику. Системный аналитик в свою очередь подумал, как это разместить в IT-системах компании, написал требования и передал разработчику. На производстве — заводах и фабриках — всё так и работает, но рабочие процессы в IT-сфере устроены по-другому.
Инженеры отличаются от работников на заводе тем, что каждый день решают новые задачи, которые не повторяются. Например, программист ищет решение проблемы — собирает что-то на коленке, продумывает алгоритм. То, что потом он облекает в код, это уже механическая и часто неинтересная работа. Рабочий процесс на самом деле — это накопление знаний.
Накопление знаний — процесс односторонний. Когда вы сфокусированы на создании ценности, задача переходит из тестирования в разработку, а разработчик приходит в тестирование и исправляет свою ошибку. Эта концепция должна сильно изменить ваше представление о том, как управлять потоком работы в команде.
Рабочий процесс — это не то, как люди передают друг другу задачки, а то, как они накапливают знания. Работа идёт через активности, а люди присоединяются к ней.
Неочевидное № 3 и 4. Оценка и распределение задач в команде
Есть разные инструменты для планирования, вроде диаграммы Ганта, которые придумали ещё в прошлом веке. Когда их начали использовать в IT, почему-то это стало работать не так эффективно, как в материальном производстве.
В начале 2000-х несколько ребят в разных концах мира решили устроить эксперимент. Взяли разные фичи, прогнозы сроков их разработки, реальное время, за которое их сделали, и попытались найти математическую корреляцию между этими значениями. Выяснилось, что никакой корреляции нет.
Тогда встал вопрос: «От чего зависит время, за которое можно выполнить тот или иной запрос?» Оказалось, что оно больше зависит от того, как команда относится к работе и сколько работы находится в процессе.
Оценка задач и вклад индивидуального контрибьютора не коррелирует со временем реализации фичи или проекта. В нашей индустрии время реализации зависит от того, сколько работы находится уже в процессе, и от того, как люди относятся к работе.
Ещё в прошлом веке, чтобы распределять процессы в системе, придумали теорию очередей. Но эта теория снова не работает в IT-индустрии, потому что всегда появляется срочная и неожиданная задача, которая идёт вне очереди. С этим тоже нужно уметь работать, и вот что может в этом помочь.
Время производства. Время разработки фичи складывается из времени работ, которые делают разные инженеры — аналитик, разработчик, тестировщик и т. д. Если вы взяли в команду один запрос, то пока сотрудник в цепочке занят работой, остальные уже готовы подхватить эстафету (график 1 на рисунке).
Чтобы сотрудники не ждали и не простаивали просто так, скорее всего, вы будете брать ещё запросы, пока их загрузка не достигнет оптимальных 70–80%. Но в какой-то момент кого-то в команде начнёт не хватать на все эти запросы и между передачей задач от одного к другому появятся временные разрывы (график 2 на рисунке).
Со временем, если вы будете брать всё больше и больше запросов в работу, количество этих разрывов увеличится (график 3 на рисунке). Тогда встаёт вопрос: «Какое количество временных промежутков ожидания считать нормальным к чистому инженерному времени работы?» Этим же вопросом задались когда-то другие люди и посчитали, что в нашей индустрии она зачастую колеблется в пределах 1–15%.
Соотношение чистого времени работы инженера к времени производства называют эффективностью потока.
Эффективность потока. Я бы не рекомендовал использовать эту метрику в работе и ставить какой-то KPI по её улучшению, потому что чем хуже вы измеряете, тем лучше результат. Так можно легко начать себя обманывать.
Чтобы поток работы был эффективным, надо мерить время простоев и искать системные способы эти простои убирать. Для этого важно, чтобы команда была ограничена по количеству работы, которая может в ней находиться. Не по трудозатратам, сколько работы туда влезет, а по количеству этой работы.
Тогда появляется практика, которая называется «ограничение незавершённой работы», — ваша команда должна быть ограничена, и это будет её ёмкость.
Диаграмма распределения. Чтобы понять, когда вы сможете закончить работу, которую уже взяли, можно использовать диаграмму распределения. Для этого рисуем ось по горизонтали и откладываем на ней время, за которое выполняются задачи, — одна неделя, две, три и т. д. А по вертикали отмечаем количество запросов, которые удалось сделать за это время (график 1 на рисунке).
Когда вы собрали какую-то небольшую статистику времени по каждой из фич, например через полгода, вы можете оценить время выполнения и посчитать вероятность завершить задачу за конкретный промежуток времени (график 2 на рисунке).
Чтобы сделать прогноз с какой-то конкретной вероятностью, нам нужно использовать перцентиль — точку, которая делит график на две части. Например, если мы берём 80-й перцентиль, значит делим график так, чтобы слева оставалось 80%.
И если ваш заказчик просит назвать сроки выполнения запроса с вероятностью 95%, вы отмеряете на графике 95-й перцентиль и смотрите, за какое количество недель справитесь. Причём на этом графике уже учтено всё: неожиданные срочные задачи, события, которые шли не по плану, и задачи, которые вы делали фоном, второстепенно.
Важно запомнить: не вся работа одинаковая. Разные типы работ идут из разных источников и имеют разные жизненные циклы. Собирайте статистику по разным типам работ. Обнуляйте статистику, если приходите в новый проект или меняете состав команды.
Класс обслуживания. Так же как в самолётах есть пассажиры экономкласса и бизнес-класса, у нас есть клиенты, которых мы обслуживаем по-разному. Запросы одних клиентов вы можете выполнять в порядке очереди, а запросы других — ставить в приоритет над остальными.
И когда мы говорим об оценке времени, которое уйдёт на производство, нужно учитывать класс обслуживания конкретного запроса. Если большой по трудозатратам запрос выполнять в режиме «бросай всё и делай», то его можно закончить быстрее, чем небольшой по трудозатратам запрос, который вы делали в обычном темпе.
В реальной жизни в нашей индустрии нет очередей. У нас всегда прилетает что-то неожиданное, и сопротивляться этому бесполезно, надо научиться с этим работать.
Советы начинающим тимлидам
- Не верьте мне — проверьте сами
- Не изобретайте велосипед — изучайте менеджмент
- Идите же и сделайте что-нибудь!