Блог

Дмитрий Денисов
Заместитель директора по информационным технологиям

Зачем таск-трекер, когда есть e-mail, скайп и переговорка?

Термин. Таск-трекер (task tracker, «отслеживатель задач») — специализированный сайт или программа на компьютере, куда разработчики отправляют заказчиков заводить задачи, смотреть статусы, отвечать на вопросы. Существует великое множество разных таск-трекеров, которые могут размещаться как на сервере компании, так и в облаке, например: Atlassian JIRA, Redmine, Microsoft TFS (который умеет много чего еще) и т. д.

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

Мотив заказчика понятен: зачем где-то специально регистрироваться, потом разбираться в интерфейсе, потом заполнять форму на 100 500 полей, потом еще рыться среди кучи задач, чтобы найти среди них свою. Гораздо проще написать все письмом (e-mail ведь общепринят в бизнес-коммуникациях?), в скайп или просто голосом проговорить (это мы предполагаем, что заказчик еще не отказывается формулировать бизнес-требования к задаче).

Попробуем теперь разобраться в мотивах разработчиков. Сразу отбросим распространенный стереотип про их интроверсию. Программист-профессионал умеет задавить в себе боязнь людей :)

Вариант 1. Команда разработки не слишком большая (до 5–8 человек — two pizza team), а заказчиков, ставящих конкурирующие между собой задачи, — много (4, 5, 10 и т. д.).

Когда заказчиков много, поток задач может принимать характер лавины. Каждый просит то, что ценно и важно для него прямо сейчас. Скорее всего, не зная о приоритетах остальных заказчиков. В конечном счете это приводит к одному из двух плохих исходов. Разработчики «продавливаются» под самого весомого/самого активного заказчика. Обещают ему с три короба. Успевают не всё, часто бросают задачи на половине (так как пришло что-то новое, еще более срочное). Главный заказчик, может быть, доволен, может быть — нет. Остальные заказчики абсолютно недовольны. Либо — наоборот. Разработчики, натерпевшись непрерывного потока задач и постоянно изменяющихся приоритетов, изолируются и избегают любых контактов. Что через эту стену просочилось, то и делают. Часто не то, что нужно, и не когда нужно. Хуже если они начинают с заказчиками открыто конфликтовать. Довольных в этой ситуации также нет.

Таск-трекер при таком варианте позволяет видеть все задачи в одном месте (и приоритизировать/сформировать очередь выполнения). Очень важно, что заказчики могут договориться об очереди между собой, не привлекая разработчиков. Лавина структурируется. В хорошем варианте, если разработчики проставляют в таск-трекере актуальные статусы задач, заказчики получают возможность еще и прогнозировать сроки готовности.

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

Вариант 2. Команда разработки достаточно большая (10–20 человек и более), заказчиков-конкурентов за ресурсы команды все равно сколько.

10–20 человек — это уже очень большая команда. Скорее всего, если она разрослась до такой численности, в ней сложилась специализация (как минимум выделены тестировщики и менеджеры, как максимум — еще и разработчики с различающимися компетенциями). Итого — когда в команду приходит задача, у нее возникает некий оптимальный маршрут: заданная последовательность рук, через которые она должна пройти, прежде чем будет сделана. Некий аналог технологической цепочки в материальном производстве. Но не в массовом производстве с конвейером и выпуском сотен-тысяч-миллионов единиц одинаковой продукции, а в штучном. Сначала задачу возьмет менеджер Сережа. Потом она попадет серверному разработчику Васе. Потом — БД-админу Маше. Потом — обратно Васе. Потом — front-end программисту Лене. Потом — тестировщику Пете. Потом — обратно Сереже для сдачи результата заказчику. У второй задачи будет свой маршрут. У третьей — другой. И таких задач на периоде в пару недель — месяц может быть несколько десятков, хотя какая-то часть из них, разумеется, выполняется в одно действие.

Если такая работа управляется недостаточно аккуратно, неминуемо возникает то, что в системе управления производством Тойоты звучно именуется muda — время и ресурсы, потраченные впустую.

Главная причина в том, что часть технологических цепочек (возможно, что совсем не меньшая) окажутся разорваны, какие-то из них — навсегда. Если переводить на человеческий, это значит, что задачу начали делать, а потом на каком-то шаге она взяла и... потерялась. Время и силы потратили, причем не только разработчиков, а еще и заказчика, который эту задачу придумал и поставил. А результата никакого от слова «совсем», в том числе и отрицательного, как если бы задача сделалась, но не привела к нужному бизнес-выхлопу.

Да, какие-то задачи из общего потока на особом контроле, и они будут сделаны. Но невозможно удержать в голове детали по нескольку десятков одновременно идущих задач. И почта здесь мало помогает, а в худшем раскладе — вредит: от основной переписки появляются ответвления, в каких-то из них теряются важные участники переписки. Слишком легко запутаться.

Чем здесь полезен таск-трекер?

Во-первых, никакая задача не потеряется. Даже если она зависнет, она будет видна.

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

В-третьих, появляется инструмент для обнаружения бутылочных горлышек. Если на серверном Васе висит 20 задач (при его мощности в 1 условную задачу в день), не нужно набрасывать на него еще 5, а потом дергать его с вопросами, когда он их сделает. Нужно либо подождать 20 дней, либо (что правильнее) посмотреть внимательно на те 20, перекинуть какие-то с Васи на менее загруженных коллег. Либо убрать те, что уже не актуальны совсем.

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

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

Вариант 3. Команда маленькая (two pizza team или еще меньше), конкурирующих заказчиков — 1–2.

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

Я здесь нарочно не говорю про преимущества и недостатки конкретных трекеров, только про традицию их использования вообще. Любой трекер можно настроить по-разному. Вокруг любого трекера можно выстроить работоспособные процессы. К примеру, команда, в которой работает автор, использует далеко не идеальный Redmine, к тому же не самую свежую его версию. Но процессы вокруг него выстроены и дают свои результаты.

P. S. И — да. Мы в команде справочных систем не работаем по agile. За исключением редких случаев, когда заказчик — один, а команда разработки продукта или продуктика — маленькая.