Григорий Петров: Системы управления задачами

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

Еще из практики. У тим лида беда-печаль: разработчик сделал, но совсем не то, что нужно. При этом сам разработчик уверен, что именно такое задание ему неделю назад поставил тим лид! Даже слова его цитирует. Только вот сам тим лид помнит, что говорил совсем другие слова. И теперь не знает — то ли в своей вменяемости начать сомневаться, то ли подозревать разработчика в нехорошем.

Эти и многие другие случаи объясняет любопытная гипотеза (пользуясь случаем, отвечаю на вопрос: все, что не проверено рандомизированным контролируемым двойным слепым исследованием, для меня гипотеза) что мозг постоянно переписывает память. Да-да, и эта драгоценная память из детства о первом стаканчике мороженого уже тысячу раз перезаписалась другими стаканчиками мороженого, и “того самого вкуса из детства” нет и не будет. Мы запоминаем не то, что было на самом деле, а то, что укладывается в нашу картину мира. А потом перезаписываем свежими впечатлениями раз сто. Поэтому разработчик запомнит не задачу, а то, что “приходил тим лид, ругался”. Через неделю поверх перезапишутся его собственные идеи по развитию продукта, разговоры коллег, общение с тим лидом — и в результате, когда руки дойдут писать код, память предложит разработчику совсем не то, что ожидает тим лид.

Костыли для памяти

Системы управления задачами (далее — трекеры, от английского “issue, task and bug tracker”) бывают разные. Тем не менее, основу их составляет набор костылей для нашей памяти:

• Память постоянно перезаписывается, поэтому ненадежна. Опытные разработчики записывают в трекер каждую мелочь. Не потому, что они педанты или у них склероз. А потому, что знают: что-нибудь из этого память обязательно потеряет. Что именно будет потеряно – никогда не угадаешь, поэтому целесообразно записать все. Целее будет.
• Память содержит не то что было на самом деле, а то, что прошло через призму нашего восприятия. “Приходил тим лид, поставил задачу” легко запоминается как “приходил тим лид, ругался”. Письменная постановка задач через трекер позволяет использовать нейтральные и более-менее однозначные формулировки. А в случае непоняток — попросить прокомментировать, что в письменном виде работает намного лучше, чем в устном — не задевает социальные аспекты коммуникаций.
• В долговременную память запоминается не все: в основном то, что связано с эмоциями. А с какими эмоциями связана перекраска кнопки в зеленый цвет? Большинство людей просто физически не способны помнить десятки задач. А наша индустрия славится как раз тем, что мелких задач много.
• Память — не компьютер, большинство из нас не в состоянии запоминать большие объемы информации. Специфика же IT в том, что любая задача может в любой момент начать обрастать подробностями: обсуждениями, скриншотами, приаттаченными файлами.

Чему менеджер может научить разработчиков

Использовать трекер для работы с задачами — контринтуитивно. Если до этого разработчик, к примеру, записывал все на бумажках или полагался на свою память и письма в аутлуке — то весь его жизненный опыт будет бунтовать против “новой, непонятной, ненужной работы”. Будут истерики, заявления “не надо меня микроменеджерить, я взрослый мужик, сам разберусь!” и много других социальных штук. К этому надо быть готовым и помнить: если дать слабину, то ваши коллеги ее тут же почувствуют, и задачи будут по прежнему “я все запомню, не надо никуда записывать”. Когнитивные искажения — страшная сила.

Построение коридоров — хорошая и полезная штука. Чтобы побороть естественное сопротивление нашего мозга ко всему новому и “ненужному”, работу с задачами удобно возвести в ранг ритуала. Нет тикета? Нет задачи. Тикет не отрезолвлен? Задача не выполнена. Так же как со стендапом, о правилах игры нужно договориться заранее и строго их придерживаться — только в таком случае наш мозг проникнется серьезностью момента и не будет пытаться “обмануть систему”.

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