Ну, дескать, цель должна быть Specific, Measurable, Attainable, Relevant, Time-bound.
И есть даже удивительные люди, которые пытаются это пихать программистам.
Но есть задачи, а есть задачи. И между ними большая разница!
Разработчик — существо потоковое, драйвовое. В отличие от проджект-менеджеров, тимлидов и прочих замечательных людей, которым неизбежно приходится переключать фокус внимания раз в 10 минут. И здорово, если процессы позволяют разработчику находиться в этом потоке и создавать код без отвлечения на точки согласований и ошибки коммуникации. Для этого есть модель TOTE. И есть мнение, что именно от неё нужно отталкиваться при формулировке таска разработчику. Поясню сначала, что за модель, а потом — как её применить.
TOTE
T1 — Test — желаемое состояние, к которому мы стремимся, какое оно?
О — Operation — какие действия мы должны делать, чтобы достигнуть результата?
T2 — Test2 — по каким признакам мы поймём, что продвинулись в сторону результата?
E — Exit — по каким критериям мы поймём, что результат окончательно достигнут?
Эта модель очень алгоритмична и хорошо подходит для задач до 20 часов (я надеюсь, вам не нужно объяснять, почему линейным разработчикам не нужно ставить задачи больше 4..8 часов? :) ).
Приведу пример, как это ложится на постановку тасков при плановой разработке. Конечно, приведённый рецепт не подходит в случае работы в стиле Research and Development, организации работ по эксплуатации или работы по срочному затыканию дыр.
Сперва (T1) идёт краткое описание, что мы делаем (не путайте с заголовком задачи!). Одно предложение, обобщающее, что и зачем мы делаем.
Вообще говоря нет смысла браться за задачу, если вы не можете это сформулировать. Это может выглядеть вот так: «Сделать стандартное REST API профиля пользователя, чтобы с ним работали фронтэнд приложения», «Учим метод создания брони принимать параметр gender и сохранять его», «Необходимо написать миграции, которые расставят ключи в соответствии со схемами из merge request (uml диаграммы таблиц)».
В качестве Operation и чуть-чуть T2 выступает глава «какие действия нужно сделать для достижения результата».
Это нумерованный список тех конкретных действий, что нужно сделать линейному разработчику. Возможно с оценкой по времени. Например:
1. Создать миграцию (30 минут)
2. Прописать модель с валидацией (2 часа)
3. Прописать контроллер (2 часа)
Важно, что он нумерованный и вы понимаете, сколько времени должно занять выполнение каждого шага. Особенно это важно — если вы работаете с джуниорами и миддлами. Ибо как только ваш разработчик «закопается», данный список — хороший способ быстро понять, на чём он застопорился и какие дальнейшие у него должны быть шаги.
Ну и в завершение глава «Ожидаемый результат» выступает в качестве правил Exit и немножко T2. «Ожидаемый результат» — это ненумерованный чек-лист проверки задачи. Фактически мы формулируем сценарии тестирования задачи, языком QA. То есть, они в идеале должны содержать как позитивные, так и негативные сценарии и не должны содержать отсылок к коду в стиле «написан класс такой-то». Только функциональные проверки.
Например:
— При создании пользователя через API, он появляется в БД
— Ответы API при создании пользователя соответствуют документации
— Пользователя можно создать только администратору
— Не-администратор при попытке создания пользователя получает 403 ошибку
К слову, высокий процент багов в сделанных задачах — это как раз повод уделить больше внимания «ожидаемому результату» при формулировке, чего вы хотите от разработчиков.
А не слишком ли много буков?
Конечно, на практике может быть не рентабельно прописывать все задачи таким образом. Нужно найти баланс, и об этом тоже хочется немного сказать.
Постановка задач через TOTE полезна как временная мера при подключении новичков, джуниоров и миддлов, пока они не освоятся с новой для них системой и подходами, принятыми в коллективе.
Можно смело упрощать постановку задач квалифицированным, проактивным и продвинутым сотрудникам. Можно смело урезать формулировки, если у вас один человек берёт один блок работ и безотрывно, без отпусков и болезней решает его с гарантированным результатом. Если с людьми приходится «играть в шашечки», перекидывать с задачи на задачу и тасовать их между командами, если блоки работ «ставятся на холд» — ТОТЕ необходим.
На что ещё обратить внимание
У вас могут быть ошибки в том, как нарезаются большие блоки работ на задачи. Может быть ошибка с целеполаганием блока работ в целом, с требованиями к блокам работ, с процессами в компании и банально, с компетенциями. ТОТЕ подход не решит этих проблем. И это совсем другая история.
Комментарии (18)
ganqqwerty
09.10.2017 13:40+3по-моему, такая детализация подходит лишь для управления стажерами, которые жаждут наставничества. Эффективность нормальных программистов просядет от отсутствия автономии. К тому же, детализируя так сильно, вы теряете много собственного времени, в итоге управлять сможете лишь очень маленькой группой.
may-cat Автор
09.10.2017 13:51Юрий, для разных типов производств немножко отличается специфика.
Не всегда автономный программист, которому на вход дали задачу «на языке менеджера» = «эффективный программист».
Вопрос потерь времени же нужно рассматривать комплексно. Вот вы быстро ставите задачу-тост разработчику и тот, решая её, генерирует багов на 40 часов. В зависимости от ставок и стратегии компании — это может быть как потеря, так и экономия.
Стратегии, ставки разработчиков — зависят, в среднем, от рынка, на котором живут компании.ganqqwerty
09.10.2017 17:03Хорошо, пусть так. Но какая тогда валентность получается у тимлида, может ли он потянуть больше пары-тройки разработчиков?
may-cat Автор
09.10.2017 17:44В приведённой схеме — да, три-четыре разработчика это предел. Соответственно, формируются команды. Команда вполне годно справляется с входящей в неё историей на 300..500 часов.
Мне кажется, у вас какой-то совсем другой опыт. Расскажете?
ncix
09.10.2017 14:42T1 — Test — желаемое состояние, к которому мы стремимся, какое оно?
О — Operation — какие действия мы должны делать, чтобы достигнуть результата?
T2 — Test2 — по каким признакам мы поймём, что продвинулись в сторону результата?
E — Exit — по каким критериям мы поймём, что результат окончательно достигнут?Не совсем понятен подход.
T1 — ок, понятно.
O — если мы говорим о коротких задачах, нужно формулировать только джуниору. Мидл сам должен принять решение как решать задачу, по этапам.
T2 — непонятно. Мы вслепую тычемся в разные стороны и у нас есть критерий, по которому мы решаем что последний "тык" был правильным?
E — я чего-то не понимаю, или E = T1 ?may-cat Автор
09.10.2017 15:17O — какие действия надо делать
Т2 — как понять, что мы на правильном пути
Е — как понять, что мы дошли до финала
ainu
10.10.2017 08:06Ставлю задачу по этой же схеме
T1 — я знаю чем отличается T1 от E
O — пишете, чем отличается E от T1 (а не что оно делает)
T2 — в одном преложении есть E и T1; и предложение описывает разницу, а не общие черты.
E — я знаю чем отличается T1 от E
senpay
09.10.2017 19:31А в чем сакральный смысл времени, выделенного на подзадачу, и кто его придумывает?
may-cat Автор
10.10.2017 17:19Прогноз времени как таковой нужен для трёх вещей:
— чтобы попытаться спрогнозировать время отгрузки результата
— чтобы поиграть в расчёты capacity производства
— чтобы вовремя обращать внимание на затупивших разработчиков и помогать им выйти из ступораsenpay
12.10.2017 11:02Между прогнозом времени и [видимом] временном лимите при постановки задачи есть существенная разница.
Имхо это создает ненужное психологическое давление и отвлекает внимание от важного (т.е. решение поставленной задачи). Я бы оценки делал, но оставлял их при себе — они помогали бы мне достигать все трех поставленных целей, но без лишнего давления на работника.
Как считаете?may-cat Автор
13.10.2017 11:31-1Я считаю, что число с оценкой — это не самое страшное из психологических давлений. И я бы не рассчитывал на разработчика, которого это выводит из равновесия.
senpay
13.10.2017 13:30Я бы переживал не насчет выведения из равновесия, а насчет неявного поощрения «срезания углов» за счет изначально неправильно поставленной задачи. Время выполнения не должно быть критерием успешности, по моему мнению.
[ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.
А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.may-cat Автор
13.10.2017 15:25Я соглашусь, время решения не должно быть единственным критерием успешности.
И я считаю, что если разработчик делает задачу хорошо на протяжении 20 часов, когда заказчик ожидает получить её через 2 часа (в силу его, заказчикового неглубокого понимания ситуации) — это негативная ситуация, которой нужно избегать.
bocharovf
10.10.2017 14:20+2О — Operation:
На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.
Детализация задачи (включая оценку времени) — это ответственность самого разработчика. Задача тимлида проверить эту детализацию, согласится с ней или попросить скорректировать. Такой подход гораздо лучше «масштабируется» + сразу ясно насколько разработчик понял требования
В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).
ARadzishevskiy
11.10.2017 14:20Такое ощущение, что с аналитиками в проектах никто не работает. Заказчик сразу приходит к PM или тимлиду выкладывает им суть на листике, а те уже нарезают листик на куски отдают их разработчикам. Эти советы больше относятся к работе аналитиков, они для того и придуманы, чтобы переводить потребности заказчика в спецификации требований, пригодные для передачи команде разработчиков. А вот тут уже и должен вступать тимлид и бить спецификации на задачи и раздавать их разработчикам.
VMichael
Вы разбиваете задачи программистам с точностью до 10 минут?
Очень жесткая у вас контора, на мой взгляд.
may-cat Автор
Нет, конечно :) Извините за провокацию, поправлю.
Обычно — с точностью до часов. Но в «действиях» могут иногда проскальзывать совсем маленькие пункты, да.