Постановка задач для начинающих тимлидов

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

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

На что ещё обратить внимание


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

Комментарии 21

    +7
    Вы разбиваете задачи программистам с точностью до 10 минут?
    Очень жесткая у вас контора, на мой взгляд.
      +1
      Нет, конечно :) Извините за провокацию, поправлю.
      Обычно — с точностью до часов. Но в «действиях» могут иногда проскальзывать совсем маленькие пункты, да.
      +3
      по-моему, такая детализация подходит лишь для управления стажерами, которые жаждут наставничества. Эффективность нормальных программистов просядет от отсутствия автономии. К тому же, детализируя так сильно, вы теряете много собственного времени, в итоге управлять сможете лишь очень маленькой группой.
        0
        Юрий, для разных типов производств немножко отличается специфика.
        Не всегда автономный программист, которому на вход дали задачу «на языке менеджера» = «эффективный программист».

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

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

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

          0
          O — какие действия надо делать
          Т2 — как понять, что мы на правильном пути
          Е — как понять, что мы дошли до финала
            0
            Ставлю задачу по этой же схеме
            T1 — я знаю чем отличается T1 от E
            O — пишете, чем отличается E от T1 (а не что оно делает)
            T2 — в одном преложении есть E и T1; и предложение описывает разницу, а не общие черты.
            E — я знаю чем отличается T1 от E
              0
              Я увидел DPE
              D — description — краткая формулировка
              P — plan — полан действий, даже для опытных кодеров, они, этот план могут сами для себя написать
              E — exit — use cases, короткий кейс тестирования, который может провести кодер сам, чтобы убедится, что задача завершена и ее можно отдавать в тестирование

              и все сложилось :)
            0

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

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

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

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

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

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

                        Задача имеет некоторый объем, идеальное время исполнения идеальным исполнителем — Вид.

                        Предположим:
                        Вид = 20 часов. Тогда, ожидания заказчика неоправданны. Кто должен разрулить эту ситуацию и как с этим поможет TOTE?

                        Вторая вероятность:
                        Вид = 10 часов. Ожидания заказчика неоправданны, но исполнитель выполняет задачу дольше, чем идеальное время исполнения. Кто виноват (если есть такие), кто должен разрулить эту ситуацию, и как с этим поможет ТОТЕ?
              +2
              О — Operation:
              На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
              Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.

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

              В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).
                0
                Спасибо, это ценное замечание.
                0
                Такое ощущение, что с аналитиками в проектах никто не работает. Заказчик сразу приходит к PM или тимлиду выкладывает им суть на листике, а те уже нарезают листик на куски отдают их разработчикам. Эти советы больше относятся к работе аналитиков, они для того и придуманы, чтобы переводить потребности заказчика в спецификации требований, пригодные для передачи команде разработчиков. А вот тут уже и должен вступать тимлид и бить спецификации на задачи и раздавать их разработчикам.
                  0
                  Не очень понимаю, как этот комментарий оказался тут.
                  Я пытался осветить как раз задачи, которые ставит тимлид, разбивая спецификации на задачи для разработчиков.

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

                Самое читаемое