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

Проблема 4. Заказчик докидывает новые требования, которые ранее не обсуждались, когда задача уже готова. Что можно сделать: 1. Если ранее был письменно зафиксирован скоуп работ по задаче и те требования, которые заказчик выдвигает, действительно новые, то предложить заказчику выбор: если это критичный момент, то команда может взять это в работу сразу, но тогда сдвинутся ранее озвученные сроки вывода задачи в прод. Если момент не критичный, то можно предложить вывести в релиз то, что сделано сейчас, а новые требования реализовать отдельной доработкой. 2. Если требования не фиксировались письменно, начать это делать со следующих задач. Потому что все новые требования = новая доработка = новые сроки и стоимость, и это нужно доносить до заказчика, если он выходит за рамки обсужденного ранее. 3. Если это упущение ИТ-команды - тут все стандартно и очевидно, но решила все-таки оставить этот пункт. Признаем вину перед заказчиком, доделываем задачу по требованиям (сразу или отдельной доработкой - см. пункт 1) и потом на ретро с командой обсуждаем, как не допустить этого в будущем.

Проблема 5. Заказчик просит сделать быстро, но костыли (= порождает тех.долг). Что можно сделать: 1. Если риски такого тех.долга велики, то расписать по пунктам риски предлагаемого решения (например, более длительные доработки в будущем, невозможность новых доработок такого-то плана в таком-то функционале, снижение производительности системы и так далее) и предложить сделать задачу правильно, но потратить немного больше времени (если разница по срокам действительно небольшая). 2. Если риски высокие, а разница по срокам существенная, то лучше не злить заказчика, который просит срочную доработку, предложениями сделать правильно, но за 3 месяца вместо 2 дней :) И предложить сейчас сделать быстро и криво, но дальше команда берет в бэклог задачу техдолга и переделывает это быстрое решение на правильное. 3. Если потенциальный тех.долг не влечет серьезных рисков, а сроки правильной реализации существенные, то лучше просто забить) Баланс скорости-качества тоже очень важен. Можно договориться о том, что эта задача тех.долга будет добавлена в бэклог в низком приоритете и взята в работу, когда будет свободное время, но в случае большого потока задач от заказчика нужно быть готовым, что до этой задачи так и не дойдут. Ведь зачем делать то, что не оправдывает свою стоимость?)

Проблема 6. Заказчик не доверяет оценкам команды по срокам доработок. Что можно сделать: 1. Декомпозиция общей оценки по задаче до самых мелких частей и указание детализированной оценки по каждой этой части. Например: задача аналитики на 2 дня, из них 4 часа на встречи и переписки с заказчиком по БТ, 6 часов на написание требований, 2 часа на сопровождение разработки, 2 часа на сопровождение тестирования, 2 часа на риски. 2. Работа над повышением уровня доверия заказчика к команде вместе с руководителем проекта, выявление причин такого поведения. 3. Эксалация на технических руководителей (аналитики/разработки/тестирования) для экспертного подтверждения/опровержения предоставленных ИТ-командой оценок.

Проблема 7. Заказчик идет напрямую к разработчикам, минуя аналитика. Что можно сделать: 1. Рассказать руководителю, команде и заказчику риски того, что с таким подходом на проекте не будет документации, а значит аналитик или другие члены команды не смогут участвовать в разработке нового функционала, т.к. аналитик не будет знать текущей реализации, что помешает ставить требования на будущие доработки, у тестировщика не будет документа, по которому нужно будет тестировать новые доработки и проверять, что все сделано по требованиям, и т.д. 2. Работа над повышением уровня доверия заказчика к аналитику вместе с руководителем проекта, выявление причин такого поведения.

А какие у вас были самые острые боли с заказчиками и как их решали?