Как стать автором
Обновить

Комментарии 8

Самая серьезная проблема, с которой я сталкиваюсь в проекте внедрения ERP системы это изменение требований. Причем данные изменения вполне обоснованы — на разработку и внедрение требуется масса времени, а бизнес в это время не стоит на месте — идут постоянные изменения требований.
Согласна с Вами. В проектах по внедрению проблема изменений ощущается острее, чем при разработке продукта. В продукте мы обобщаем требования и можем «сгладить острые углы», при работе же с одним заказчиком – приходится отстаивать с боем каждую доработку.
А привлекается ли к оценке требований архитектор продукта? По идее, он должен снижать вероятность возникновения «айсбергов», т.к. точно знает, какое изменение в системе к какому списку связанных баг/фич приведет.
Да, разумеется, архитектор проводит оценку и может выявить внутрисистемные связи с точки зрения разработки. Однако определение «айсберга» на уровне бизнес-логики – задача целиком аналитика.
Архитектор тоже не супергерой, который по любому запросу через пол часа выдаст список хотя-бы потенциальных фитч. В любом случае анализ порой является довольно сложным и ресурсоемким процессом и на практике (правда довольно редко) эти «айсберги» всплывают чуть ли не на стадии тестирования.
У нас – супергерой :) Если серьёзно, то мы в производстве пересмотрели подход к оценкам, ещё на этапе анализа каждая фича проходит трёхуровневое ревью – главным бизнес-аналитиком, архитектором и представителем группы тестирования. Это значительно повышает шанс на обнаружение неучтенных нюансов и возможных проблем, хотя и повышает в целом время, затраченное на проектирование.
Вы так и до коллективной оценки по методу planning poker дойдете…
Метод этот, несомненно, интересный, но, боюсь, в нашем случае неприменим – для тяжёлых фич такие оценки будут из разряда потолочных.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.