Когда люди говорят о постановке задач — они очень любят вспоминать про SMART.
Ну, дескать, цель должна быть 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)


  1. VMichael
    09.10.2017 12:39
    +7

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


    1. may-cat Автор
      09.10.2017 12:54
      +1

      Нет, конечно :) Извините за провокацию, поправлю.
      Обычно — с точностью до часов. Но в «действиях» могут иногда проскальзывать совсем маленькие пункты, да.


  1. ganqqwerty
    09.10.2017 13:40
    +3

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


    1. may-cat Автор
      09.10.2017 13:51

      Юрий, для разных типов производств немножко отличается специфика.
      Не всегда автономный программист, которому на вход дали задачу «на языке менеджера» = «эффективный программист».

      Вопрос потерь времени же нужно рассматривать комплексно. Вот вы быстро ставите задачу-тост разработчику и тот, решая её, генерирует багов на 40 часов. В зависимости от ставок и стратегии компании — это может быть как потеря, так и экономия.
      Стратегии, ставки разработчиков — зависят, в среднем, от рынка, на котором живут компании.


      1. ganqqwerty
        09.10.2017 17:03

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


        1. may-cat Автор
          09.10.2017 17:44

          В приведённой схеме — да, три-четыре разработчика это предел. Соответственно, формируются команды. Команда вполне годно справляется с входящей в неё историей на 300..500 часов.

          Мне кажется, у вас какой-то совсем другой опыт. Расскажете?


  1. ncix
    09.10.2017 14:42

    T1 — Test — желаемое состояние, к которому мы стремимся, какое оно?
    О — Operation — какие действия мы должны делать, чтобы достигнуть результата?
    T2 — Test2 — по каким признакам мы поймём, что продвинулись в сторону результата?
    E — Exit — по каким критериям мы поймём, что результат окончательно достигнут?

    Не совсем понятен подход.
    T1 — ок, понятно.
    O — если мы говорим о коротких задачах, нужно формулировать только джуниору. Мидл сам должен принять решение как решать задачу, по этапам.
    T2 — непонятно. Мы вслепую тычемся в разные стороны и у нас есть критерий, по которому мы решаем что последний "тык" был правильным?
    E — я чего-то не понимаю, или E = T1 ?


    1. may-cat Автор
      09.10.2017 15:17

      O — какие действия надо делать
      Т2 — как понять, что мы на правильном пути
      Е — как понять, что мы дошли до финала


      1. ainu
        10.10.2017 08:06

        Ставлю задачу по этой же схеме
        T1 — я знаю чем отличается T1 от E
        O — пишете, чем отличается E от T1 (а не что оно делает)
        T2 — в одном преложении есть E и T1; и предложение описывает разницу, а не общие черты.
        E — я знаю чем отличается T1 от E


  1. senpay
    09.10.2017 19:31

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


    1. may-cat Автор
      10.10.2017 17:19

      Прогноз времени как таковой нужен для трёх вещей:
      — чтобы попытаться спрогнозировать время отгрузки результата
      — чтобы поиграть в расчёты capacity производства
      — чтобы вовремя обращать внимание на затупивших разработчиков и помогать им выйти из ступора


      1. senpay
        12.10.2017 11:02

        Между прогнозом времени и [видимом] временном лимите при постановки задачи есть существенная разница.

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

        Как считаете?


        1. may-cat Автор
          13.10.2017 11:31
          -1

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


          1. senpay
            13.10.2017 13:30

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

            [ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.

            А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.


            1. may-cat Автор
              13.10.2017 15:25

              Я соглашусь, время решения не должно быть единственным критерием успешности.
              И я считаю, что если разработчик делает задачу хорошо на протяжении 20 часов, когда заказчик ожидает получить её через 2 часа (в силу его, заказчикового неглубокого понимания ситуации) — это негативная ситуация, которой нужно избегать.


  1. bocharovf
    10.10.2017 14:20
    +2

    О — Operation:
    На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
    Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.

    Детализация задачи (включая оценку времени) — это ответственность самого разработчика. Задача тимлида проверить эту детализацию, согласится с ней или попросить скорректировать. Такой подход гораздо лучше «масштабируется» + сразу ясно насколько разработчик понял требования

    В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).


    1. may-cat Автор
      10.10.2017 17:18

      Спасибо, это ценное замечание.


  1. ARadzishevskiy
    11.10.2017 14:20

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