Как стать автором
Обновить
116.38
Рейтинг
Luxoft
think. create. accelerate.

Исследуем ожидания разработчиков от уровня постановки задач аналитиком

Блог компании LuxoftАнализ и проектирование систем

Недопонимание по поводу качества постановки задачи — частое явление в командах. Мне стало интересно разобраться в вопросе, и для этого я обратилась к 4 тимлидам. Формат — интервью. Моей целью было получение обратной связи: какие ожидания от требований есть у разработчиков и как они воспринимают постановку задач. В данной статье приведены результаты моего исследования.



Интервью проводились с тимлидами, которые имеют совершенно разный опыт и стаж. Стаж респондентов респондентов – 5, 10, 12 и 22 года работы в сфере продуктовой и заказной разработки. Так как статья не является пиаром, данные о респондентах я не указываю.


В ходе интервью я задавала следующие вопросы:


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

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


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


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

Важно понимать, зачем вообще заведена задача. Поэтому первый и обязательный пункт в задаче – это формулировка проблемы, которую мы решаем (Problem Statement). Этот пункт в том числе помогает аналитику понять, нужна ли вообще эта задача и есть ли на самом деле проблема.

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

В части формата изложения требований респонденты отдали предпочтение атомарным требованиям. При этом все тимлиды сказали, что важно наличие accaptance criteria к задаче. Разработчикам и тестировщикам необходимо понимать, по каким критериям будет проводиться приемка и каким должен быть необходимый минимум по задаче.
Наиболее опытный из респондентов тимлид поделился своей формулой успеха: "решаемая задача — формат требований". Думаю, она вполне рабочая:


Я считаю use cases самым удобным форматом требований. Из него уже можно продумывать реализации. Когда я вижу use case, я получаю максимальную гибкость для достижения цели, у меня включается творческое начало.
Обширные ТЗ хороши для согласований. В то же время они приводят к неэффективным тратам ресурсов – это те ситуации, когда исполнители не видят смысла в том что делают и делают «формально по букве».
Gherkin хорош когда надо кропотливо описать flow со всеми нюансами. Это уровень swagger — когда надо посмотреть как это должно работать в деталях, для справки. Я не видел ситуации, чтобы проектирование выполняли на Gherkin.
Бывают задания, в которых лучше описать атомарными требованиями, например: когда постановка – это следствие очень специализированного процесса с неочевидными ограничениями.

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


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

Я просто люблю когда, все адекватно и просто оформлено. Сам стараюсь пользоваться markdown, еще обожаю одну фичу gitlab — когда можно в markdown задавать чекбоксы для чеклиста в задаче. Шрифты и оформление «как в Word» точно делать не стоит=)

С точки зрения уровня детализации, все ответы сошлись к тому, что нет универсального решения. Уровень детализации, как и наполнение задачи — это рабочий момент. Если аналитик и команда разработки периодически общаются по задачам, обмениваются обратной связью, то происходит сонастройка и уровень детализации становится негласным знанием проекта.


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

Последний вопрос касался того, как формулировать постановки для неоднородной команды. Бывает, что на проекте одновременно работают сеньоры, джуны, мидллы. Соответственно, одним важно получать максимально детальные описания, других будет мотивировать поиск решения по бизнес-задаче. Если распределение тасков происходит уже после подготовки тикетов в таск-трекере, то возникает вопрос: на кого ориентироваться?
Тут мнения разошлись. Кто-то считает, что в таком случае нужно описывать задачу детальнее для всех. Кто-то считает, что задачи должны сначала ставиться тимлиду в общем виде, а возникшие вопросы тимлид сам донесет джуну. Здесь тимлиду и аналитику можно только посоветовать договариваться о формате работы "на берегу".


Надеюсь, результаты исследования были вам полезны. Спасибо респондентам за помощь!




Мой блог "Путь аналитика": https://t.me/analyst_way
Теги:требованияacceptance criteriaпостановка задачи
Хабы: Блог компании Luxoft Анализ и проектирование систем
Рейтинг0
Просмотры784

Похожие публикации

Лучшие публикации за сутки