Site icon AppTractor

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

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

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

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

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

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

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

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

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

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

Exit mobile version