Один из самых простых и действенных способов повысить эффективность команды разработки, это введение обязательных критериев приёмки при постановке задач.
Критерии приёмки
Критерии приёмки — это ответ на вопрос “мы считаем что задача полностью выполнена, если…”.
Часто термин “критерии приёмки” сокращают до аббревиатуры КП. Так и будем называть в этой статье.
КП добавляются в задачу в вашем любимом трекере задач в виде списка пунктов.
Пример
КП для задачи “сделать регистрацию и авторизацию”:
- Пользователь может зарегистрироваться в системе через Email.
- Пользователь может залогиниться.
- Пользователь может разлогиниться.
- Для регистрации используется капча от Яндекса чтобы отсеять ботов, для логина капча не используется.
Прописав в задаче такие условия, мы освобождаемся от необходимости реализовывать то, что в КП не входит, например восстановление и смену пароля.
Разумеется, только в том случае, если эти дополнительные части не будут добавлены в КП при обсуждении задачи.
Ключевое отличие
Чем использование КП отличается от “обычного способа” формулировки задачи?
Обычно задача формулируется в виде “нам нужно сделать это и это”. То есть мы перечисляем что мы делаем, детализируем действия.
КП позволяет взглянуть на задачу абстрагируясь от действий по её выполнению, рассматривая исключительно результат.
В КП нельзя написать “создать таблицу в БД, эндпойнт АПИ”. Это технические детали, то “что мы делаем” а не то что получит в итоге заказчик.
В КП пишем строго результат: “посетитель может добавить товар в корзину”, “посетитель может оплатить заказ”.
Фокусируясь на результате, мы развязываем себе руки в способах достижения этого результата.
Кто пишет КП
КП определяет тот, кто принёс задачу, представитель бизнеса или заказчик. Это может быть менеджер, тимлид, ответственное лицо в компании или сам заказчик.
Он прописывает КП в задаче когда её формулирует, в команду разработки задача должна попасть с уже сформулированным КП.
Что делаем в команде
- Просим указывать в задаче “для чего мы это делаем”, чтобы сформулировать цель, ценность, пользу для заказчика.
- Просим указать КП в задаче, тем самым ограничиваем объём работы.
- Если задача уже пришла в виде набора инструкций “что делаем” то пробуем поговорить с заказчиком и выяснить КП через вопросы и выстраивание логических цепочек (ответы на вопросы “зачем?”, “чтобы что?"), если конечно задача серьëзная: более 1-2 дней.
- Если КП неполное и не отвечает на вопросы “обязательно ли сделать такую-то часть” то при обсуждении задачи до того как взяли её в работу задаём уточняющие вопросы представителю заказчика, и вносим новые пункты в КП.
Что НЕ делаем
Также бывает полезно описывать в задаче не только то, что мы должны сделать, но и то, что мы намеренно решили НЕ делать в рамках этой задачи.
Либо от чего-то отказались, либо временно упростили, либо оставили “на потом”, либо вынесли в другую задачу.
Фиксируем в задаче, так же выписываем список пунктов. “Не делаем то-то и то-то”, можно добавить причины почему решили не делать, будет ли это сделано потом или в рамках другой задачи и так далее.
Это здорово сокращает объём работы и снижает недопонимание “а я думал что вы вот это тоже сделаете”.
Преимущества
- Не тратим время на то что не просили.
- Делаем проще где могли выбрать сложный вариант.
- Не тратим время на переделку.
- Не заставляем заказчика делать подробное ТЗ.
- Концентрируемся на том что хотим получить а не “как сделать”.
- Вытаскиваем полезные знания из заказчика.
- Разматываем причину задавая вопросы “чтобы что”, выстраиваем логическую цепочку.
- Получаем исходные причины для задачи.
- Освобождаемся для выбора вариантов решения, так как определение проблемы и наш кругозор даëт многообразие вариантов.
- Получаем чëткие критерии для выполнения задачи и всегда чётко можем сказать, готова задача или нет.