Как ставить задачи
На первой своей работе PM мне дали 2 проекта, которые начались еще во времена Тьюдоров, Задачи велись в YouTrack и когда я стал погружаться в довольно внушительный бэклог - какого зоопарка задач там только не было:
- хочешь - вот задача с одним заголовком и пустым телом;
- или задачи с заголовком в одно слово;
- ну или например задачи с телом и заголовком и 200 комментариев ниже и в одном из этих комментариев наконец-то написано, что именно надо сделать;
- задачу, которую поставил полгода назад себе разработчик, записал в нее время и забыл описать что делал.
Так как я был неопытен и онбординг в компании проходил в духе «кидай в воду – хай выплавит», то продолжал некоторое время вести проект в таком же духе - считая, что успех меня ждет если быстрее и формально ставить тикеты и быстрее направлять разработчика писать код.
Такой подход некоторое время позволял мне быть на плаву и создавать иллюзию моего «успевания». Но в какой-то момент это стало сильно меня обжигать проблемы:
- Бывало, что спустя даже неделю ни я, ни разработчик и ни Заказчик не могли вспомнить что делалось и для чего нужна была эта задача;
- На вспоминание всех сюжетных поворотов, чтение комментариев, уточнение у Заказчика стало тратиться уйму времени;
- Хуже всего было, когда возникали ситуации, когда в результате выполнения задачи мы понимали что я, программист и Заказчик понимали ее по разному;
- Особо хитрые представители Заказчика приобрели тенденцию стараться протащить «контрабандой» требования, которые не были заявлены при первоначальном обсуждении задачи.
С содроганием перечитывая этот сейчас этот список, вспоминая ситуации. Внутри компании и отдела не было регламентов постановки задач, что-то на уровне хорошего тона внушалось, что лучше бы расписывать задачи хорошо. Но и среди боссов этим многие пренебрегали.
Хорошо – если правил нет, придумаем их сами – как удобно нам.
В результате раздумываний, проб и набивание шишек я пришел к такому формату:
Название
Конечно, как положено, начинается с глагола несовершенного вида – что сделать?
Например: Разместить кнопку «Бренд1» (ведет на страницу бренда) под умным фильтром на страницу на всех страницах Каталога.
Cуть задачи
Краткая «выжимка» из того, что нужно сделать в 1-2 предложениях. Чтобы прочитать ее можно было быстро восстановить всю картину задачи.
Суть задачи: Кнопку «Бренд1» необходимо расположить под умным фильтром на всех страницах каталога товаров.
Бизнес-цель
Также кратко, со слов Заказчика нужно написать – в чем нам будет выгода от этой задачи?
Например: Бренд1 только выходит на рынок и сейчас на него ожидается спрос со стороны пользователей сайта. Поэтому размещаем его на странице Каталога как самой посещаемой странице сайта.
ToDo
Напишите разработчику, как вы видите его порядок действий. Не стесняйтесь своего уровня понимания, пишите как знайте, даже если не шарите. В любом случае, и если напишите чепуху – это подтолкнет самого молчаливого вашего программиста на диалог. Он cкорее всего он скажет - «тут ерунда». И тут Ваш ход: «А как надо делать?». И это уже ключик к обсуждению, декомпозиции, поиску нюансов. И после всего обсужденного – можно отредактировать первоначальный "туду".
- Проверить возможность размещение кнопки Бренд1 на страницах [ссылка1], [ссылка2], [ссылка3] на десктопной и мобильной версии сайта – результат оставить в комментарии к задаче;
- Взять шаблон кнопки из [figma_cсылка] и разместить в шаблоне страниц каталога.
- Приложить скриншоты в задаче по результату.
Демо:
Это те сценарии, которые вы сходу проверите и покажете Заказчику. Если у Вас есть в команде тестировщики – они проверят задачу как надо, но тебе нужно обеспечить доставку этих минимальных сценариев. Не всегда они явные в задаче, но если прощупываются лучше их написать. И показать Заказчику, кстати когда будете говорить ему о задаче.
- Я как неавторизованный пользователь сайта захожу на странице [ссылка1], [ссылка2], [ссылка3].
- Я как неавторизованный пользователь визуально не вижу нарушения композиции страницы;
- По клику на кнопку Бренд1 с десктопной и мобильной версии пользователи попадают на страницу бренда [ccылка_страницы Бренда].
Что позволяет такой подход:
- Легче ориентироваться в унифицированной структуре задач – даже пролистывая бегло, знаешь куда кинуть глаз.
- Легче потом отчитываться перед Заказчиком благодаря пункту «Бизнес-цель» – все стейкхолдеры понимают какую ценность, которую принесла моя команда этой задачей.
- Верхнее-уровне разработчик видит результат своих действий в бизнес-цели. Не просто задача в формулировке «размести кнопку сюды», а «размести кнопку сюды, чтобы вот сколько было пользы». Круто же - а еще это вполне укладывается в подход, который применяла Toyota - все работники должны быть в курсе бизнес-целей и понимать, на что они влияют.
- Даже если до этого не понимал, то начинаешь технологию разработки, благодаря практике написания "ToDo" и общению с разработчиками.
- Лучше предъявляешь задачу Заказчику. Говоришь: "вот эти сценарии, прописанные в пункте Демо будут работать". Их видит и Заказчик и разработчик - мы идем к этой цели. Все остальное - конечно протестируем.