Ping-Pong

Мне показалось это наиболее подходящей метафорой к такому стилю работы с задачами.

Если задача есть, значит её нужно сделать самому, либо передать тому, кто может сделать, либо закрыть, но не задерживать у себя. Сделав свою часть оставить комментарий и передать задачу коллегам.

Ничего сложного, самый обычный разговор, но записанный на бумаге. Пока что наиболее эффективный инструмент решения задач для коллектива разнесённого географически или во времени.

Чем сложнее задача, тем больше вовлечено в неё людей. Новые участники могут появляться на поздних этапах обсуждения и они должны по самой задаче и комментариям к ней получить представление о проблеме и решениях, которые уже были или еще будут опробованы. Если  нельзя понять по описанию задачи, что происходит, тогда задача становится обузой для всей команды, а часто и для большего круга людей. И чем хуже описание и комментарии, тем сложнее будет эту задачу решать. Нередко такие задачи переходят в статус вечных, причем не потому что решения нет, а потому что никто не помнит, что уже делали и никто не хочет возвращаться к решению, потому что уже было потрачено слишком много сил и времени. Однажды в разговоре девелопер такую ситуацию пояснил проще «Слишком хлопотно, а пользы мало – одна головная боль».

Один из моих любимых примеров стоимости отношения к трекингу работы.

Я долго работал с разработчиком, который о фиксах писал так «Fixed in b.1.1». Проблем с этим не было никаких, пока на вполне тривиальный фикс в комментария не появилось «Fixed in Prod A b.1.2 & Prod B b.4.4». В CVS изменения были сделаны в более чем сорока файлах. На следующий день, после комита, разработчик ушёл в отпуск.

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

Кстати баг можно было и не исправлять, он не был виден пользователям и в целом они бы о нём никогда бы и не узнали и через несколько месяцев часть, на которую было потрачено столько сил, была полностью переписана. Но ни информация о планах разработки, ни видимость ошибки не попала в комментарии к задаче. Стоимость этого не трудно посчитать приблизительно вычислив финансовые затраты на двух разработчиков ($100x2 в день) и одного тестировщика ($60 в день) за всё время потраченное на исправление ошибки, анализ исправлений и переписывание кода ($260 долларов  в день в пустую, не считая косвенных убытков и того, что время могло быть потрачено на более ценные задачи).

Это кстати ещё одна вариация неявного саботажа работы (по недомыслию). Но здесь практика работы с задачами могла бы предотвратить трату времени.

Leave a Reply

Your email address will not be published. Required fields are marked *