Культура ведения задач в трекере (пара правил для Руководителей)

Сегодня будет про культуру ведения тикетов в трекере.

Раз за разом я долдоню своим менеджерам одно и тоже, а все равно стоит отвлечься, и треш, с которым я веду войну, просачивается в процесс разработки. Я не претендую тут на идеальную картину мира и идеальный процесс разработки, у каждой команды свои правила работы, но есть пара моментов, которые вымораживают при любом процессе. И, вроде, они настолько очевидны, что даже не стоят кликов по клаве, чтобы писать, но почему-то каждый раз мне приходится объяснять это новеньким.

Наверное, просто надо один раз написать и потом слать ссылку на текст. Для этого и напишу 😊

Это очередная статья, посвященная софтскилам и лайфхакам, о которых руководителям не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие мои статьи здесь, на Хабре.

Есть много правил ведения тикетов, есть много уникальных процессов — для каждой компании свой. Есть много фремворков и трекеров. Но есть два базовых правила, про которые, я считаю, надо помнить всегда. Эти правила применимы всегда и всюду, независимо от ваших процессов и стиля работы команды. По крайней мере, я еще не видел процесса разработки, которому бы они вредили 😊

Зачем это в каналах про руководство проектами и продуктами? А потому, что ставят задачи и контролируют работу по тикетам уважаемые господа менеджеры. И если в трекере бардак, то это не вина команды, а вина менеджера, который:

• не умеет выстроить нормальный процесс и

• не следит за культурой ведения задач.

Поэтому начинающим и не очень менеджерам я расскажу всего пару моментов, после внедрения которых жить 100% станет лучше и им, и их команде.

Моментов всего два.

1. Оформление постановки на тикет: никаких односложных постановок, постановки должны быть четкими и понятными.

2. Никаких новых задач в каментах: каменты только для обсуждения постановки вверху, никаких дополнительных задач в каментах быть не должно.

Пункт 1 облегчает жизнь исполнителям задач (хотя усложняет менеджеру, ему иногда приходится включать свою голову). Пункт 2 облегчает жизнь вообще всем.

Если вы все это итак знаете, можете дальше не читать, у вас все хорошо, статья не про вас. Хорошо, что есть люди, которые это итак знают.
Если вы не понимаете, зачем делать эти два пункта – читайте дальше.

Постановка

Постановка должна быть полной и понятной. Это закон. Но закон можно трактовать как угодно. Что такое «полной»? Что значит, понятной?

Тут надо определить эти два термина: полная – это когда учтено все, что надо сделать, на взгляд того, кто ставит, понятная – это когда исполнитель, который будет делать, сказал, что все понял и вопросов нет.

Разумеется, полнота – понятие относительное. Постановка на разработку может быть в виде детального todo типа: «по получении запроса в виде таком то, пойти в таблицу такую то, взять параметр такой то, преобразовать так то и отправить туда то и туда то», а может быть «требуется при получении запроса данных от системы А, отдавать параметр Б в виде текста». Детализация разная, самое важное – ее должен понять ваш исполнитель.

Так что оба параметра субъективны, но это не значит, что можно писать постановки вида:

• «надо написать ТЗ на создание системы» и все;

• «спросить меня подробности» и все;

• Или «макетов пока нет, надо начать делать так, а потом добавим» ну и разумеется, потом послать ссылку в мессенджере, а в тикет не добавить, потому что некогда 🙁

За такие постановки надо сразу бить клавой по рукам.

Для чего вам, как руководителю, нужны нормальные постановки:

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

2. Вы можете ждать, что в указанное время задача будет готова, а исполнитель вам не скажет «в тикете надо было спросить Васю, но Вася был занят и не мог говорит, я жду».

3. Когда бы будете делать ретро по проекту или будете приводить тикеты в порядок, вам не надо будет отчаянно морщить лоб, вспоминая, «а чего же тут имелось ввиду и почему на тикет с такой постановкой потратили неделю?!»

4. И отдельно, такой подход очень помогает вдолгую. Бывает, всплывает вопрос «а кто и когда эту фичу и в рамках чего добавил?» и вот тогда вы лезете в ваш трекер, находите постановку и – вуаля — достаете все данные, которые важны (кто, когда, что именно и почему сделал).

Еще раз. Я в курсе, что хорошая постановка требует времени. И вообще «чтобы получить ответ на вопрос, надо знать половину ответа». Решение о полноте тикета индивидуально для команды и условий ее работы, от наличия аналитиков, уровня разработчиков, процессов компании. Но здесь это неважно.

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

И напоследок, менеджерам: вы можете забить на постановки, вы можете вообще не ставить задачи в трекере, а договариваться 1 на 1 с исполнителем, но каждый раз вам будет больно. Больно переобъяснять исполнителям, что надо сделать, больно лажать по срокам, больно искать фактуру в трекере. Выбор за вами: страдать или сразу делать нормально.

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

Это мое самое «любимое».

Это когда есть тикет, а в каментах начинается обсуждение, что постановка не очень, и вообще надо иначе, а вот, смотрите, тут дизайнер сделал дизайн получше, и надо сделать по дизайну, а «ой, еще пришел заказчик и попросил тут допилить немного». И это длится 20 каментов, и ты уже сходишь с ума, читая это. А потом туда приходит тестировщик, дооолго разбирается с постановкой, проклиная того, кто это все накреативил, тестирует и выкатывает огромный перечень замечаний тудаже, в каменты.

Дело сделано, и крышка гроба захлопнулась. Мы получили тикет, который не закрывается почти никогда. Тикет-эпик, Тикет-фича и Тикет-проект. Настоящая Вавилонская башня.

Разобраться в этом сходу невозможно. Оценить степень готовности невозможно, а предсказать время завершения можно только полностью прочитав все-все каменты (а вдруг упустишь что-то в духе: «бага 3 из списка выполнена» или не поймешь, к какому каменту это было). И так надо все перечитывать каждые 2-3 дня, чтобы не выпасть из контекста. А теперь представим, что таких тикетов у вас 10 и все – ваше свободное время на этом закончилось, уважаемый менеджер.

Часто такие обсуждения – это производная от проблемы 1 выше. Как говорится: «какая постановка, так и решаем». Прибежал Чайка менеджер, наорал, создал тикет, бросил: «разбирайтесь», и вот народ пытается разобраться прямо в тикете. Выглядит максимально кринжово, кровь из глаз.

Поэтому закон номер два для меня: никогда, ни за что, никаких постановок в каментах. Если в ходе выполнения задачи всплыл новый функционал – пожалуйста, делайте новый тикет.

По багам возможны разные подходы. Я предпочитаю гибкий подход: если задача небольшая, можно просто ее вернуть с каментом, что не работает. Если задача объемная и ошибок много, то лучше трекать их отдельно: так будет понятнее статус и сходимость решения.

Итого. Всего два простых правила для руководителей.

1. Делайте сами и следите, чтобы у вас на проекте были полные, понятные вам и вашим исполнителям постановки. Как минимум, и исполнитель, и вы должны спустя время прочитать и понять «а что там надо было сделать?».

2. Никогда, ни за что не допускайте новых задач в каментах. Бейте по рукам тех, кто так делает. Каждый раз, когда вы так делаете, вы сами в себя втыкаете иголки. Вроде сразу не чувствуется, а потом ходить очень больно.

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