Обычно возникает 2 глобальные проблемы между аналитиком и разработчиком, и в этом посте я расскажу, что можно сделать, чтобы их решить.

Проблема 1. Разработчик делает все сам, не по требованиям или даже не ждет требований от аналитика.

Что можно сделать: 1. Чаще всего возникает, когда разработчики - сеньоры, и могут делать задачи по одной озвученной заказчиком идее. если причина именно в этом, то стоит внедрить совместное обсуждение по реализации аналитиком и разработчиком перед взятием задачи в работу, но условиться, что аналитик в требованиях к оговоренной реализации укажет все детали, которые выяснит у заказчика, и разработчику эти детали нужно будет обязательно сделать. если хочет начать разработку до аналитики согласно тому, что проговорили - пусть начинает, но нужно попросить разработчика учесть, что нужно будет потом доделать и/или переделать детали функционала после получения финальных требований. 2. Принять в команде правила, что задачи берутся в работу только по готовности. аналитика только после готовности БТ, разработка только после готовности требований аналитика и т.д. 3. Озвучить всем стейкхолерам риски, которые могут возникнуть в ходе такой работы: как минимум - переделывание функционала -> увеличение сроков и стоимости доработки; как максимум - инцидент на проде -> репутационные и пр. риски компании в зависимости от специфики дорабаотываемого продукта. 4. Эскалация на руководителя.

Проблема 2. Аналитик переписывает БТ заказчика чуть другими словами и отдает в разработку / пишет технические требования, но они некачественные (неполные, противоречивые и т.д.).

Что можно сделать: 1. Объяснять аналитику, почему таких требований недостаточно (если слова не дают результатов - показать на живом примере: реализовать то, что не регламентировано требованиями, так, чтобы это стало проблемой при тестировании/приемке (не обязательно все ломать, достаточно сделать бессмыслицу где-нибудь в одном месте :) ), а разработчик мог сослаться на то, что в требованиях это никак не описано и пришлось додумывать реализацию; этот совет нужно применять аккуратно - он “вредный”, хоть и рабочий, т.к. разработчику тоже может прилететь за то, что не спросил аналитика, а также это показывает отсутствие командности) 2. Внедрение ревью требований в команде как минимум со стороны лида аналитики, а в идеале - и со стороны разработчиков и тестировщиков 3. Если совсем плохо, эскалация на руководителя с поднятием вопроса о замене аналитика

А как вы решаете эти конфликты?

Если у вас были какие-то иные конфликты между аналитикой и разработкой, пишите в комменты, возможно сделаю часть 2 по этой теме)