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

На первый взгляд разработчику достаточно требований. Есть экран, несколько состояний, запрос к серверу — можно декомпозировать и поставить условные 5 story points.

Но одного описания функциональности часто недостаточно.

Допустим, задача звучит так: «Добавить повторную попытку операции при ошибке сети». - Можно просто показать кнопку «Повторить».

- А можно сделать автоматическое восстановление, сохранить состояние операции, обработать перезапуск приложения и исключить повторное выполнение.

Оба варианта формально решают задачу.

Чтобы понять, какой из них нужен, важно знать: что это за операция и почему бизнесу важно, чтобы она завершилась? Если это второстепенное действие, которое пользователь легко повторит, простого решения может быть достаточно. Если это оплата, загрузка важных данных или ключевой этап регистрации - требования к реализации будут другими. Вместе с ними изменится оценка.

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

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

Потому что нужно оценить именно ту реализацию.

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

При этом я считаю, что разработчику не стоит просто механически выполнять сформулированные требования.

У нас есть собственный опыт, знание системы и понимание технических ограничений. Если мы видим, что задачу можно решить надёжнее, проще или дешевле — это стоит предложить. Это ОБЯЗАТЕЛЬНО нужно предложить.

Не потому, что разработчик лучше знает продукт. А потому что каждый участник команды смотрит на задачу со своей стороны и может добавить важную часть общей картины.

Поэтому вопросы: «Сколько времени займёт задача?» и «Какого результата мы на самом деле хотим добиться?» для меня тесно связаны.

Чем лучше разработчик понимает второй вопрос, тем точнее сможет ответить на первый.