Типичные ошибки постановок

Алекс, на проектах с разными аналитиками всегда слышала от тебя недовольство постановками. Ничего, не путаю?

Верно, было такое.

Расскажи 3 типичные ошибки в постановках по версии Александра Синичкина?

1) Не хватало простоты в постановках. Либо это написанные казенным языком на несколько листов простенькие задачи. Либо расписано все до мельчайшей детали, но расписано так, что сложно уловить саму суть задачи.

2) Не хватало понимания, зачем вообще ставится эта задача (если фича, а не баг). Сухое описание "добавить кнопку, по нажатию которой выдается список юзеров" и все.

3) Дискоммуникация в терминах. Бывает так, что когда проект начинается, и термины еще не устаканились, их может лихорадить. Одна и та же сущность может иметь несколько названий. Это добавляет боль при коммуникации, но люди могут прийти, рано или поздно, к единым терминам. Но в коде так легко не поменяешь названия, и потому, разработчику в первую очередь приходится ориентироваться на код. Когда в постановке совсем другие названия, очень сбивает с толку.

Где бы ты провел грань между достаточными требованиями и слишком детальными?

Задача должна быть прочитана и осознана не более чем за минуту (пара минут, если с картинками). Соответственно, если задача крупная, то хочется видеть ее в формате декомпозиции. Если сложно сформулировать, то всегда можно проговорить с тим.лидом.

"...зачем вообще ставится эта задача",- ты имеешь в виду бизнес-контекст задачи?

Да. Программисты, чаще всего, умные ребята. Зная бизнес контекст, они могут предложить решение, которое будет взаимодействовать со всей системой (возможно только в будущем). Не зная его, программист есть мартышка, которая умеет печатать код. Сказали вывести список, он вывел, делов то.

Ты встречал в работе идеальные требования?

Идеала нет =) Но если вернуться к тому же списку пользователей, то как пример

При такой постановке детали реализации остаются за скобками

сколько должно быть юзеров на странице
тип пагинации
как фильтровать юзеров (онлайн, не онлайн)
какую именно инфу выводить в чате (там же не нужны все данные, только условные ник и айди). Тимлид, зная специфику приложения, уже может добавить важные детали, если они нужны. А дальше бэкендер уже сам счастливо делает задачу, периодически синхронизируясь с фронтедером, сами разберутся.

Пример, который ты привел написан в формате атомарных требований. А как ты относишься к постановкам в виде юз.кейсов?

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

Имхо, в юз.кейсах есть 2 хорошие вещи:

1. Структура

2. Разделение на основные кейсы, а на менее приоритетные логические ветки. Закон Парето как он есть=)

Что ты об этом думаешь?

> аккуратно отформатированно
Задача должна быть легко прочитана. Если накидать постановку как попало, ее просто не поймут. Ну или поймут, но потратят на это огромное количество времени. Так что я за форматирование. В конце концов, в коде я тоже требую соблюдение формата.

> Основные сценарии

Все от бизнеса зависит 🤷‍♂️ Есть время - продумываем логику по максимуму. Нет времени - только основные сценарии. Лучше первое. Но чаще всего второе

Бывает, что на проекте неоднородная команда: сеньоры, джуны, мидллы. Соответственно, в зависимости от квалификации нужна разная детализация задачи. Как бы ты советовал аналитику формулировать постановки в таком случае?

Никак. Пусть аналитик формирует задачи для тимлида. А тимлид уже сам решит кому, что делать. И, в зависимости от этого, добавит нужные детали.

Спасибо за интервью, было очень интересно и содержательно!