Откровения бизнес-аналитика. Анна Федорова
Чтение книги онлайн.
Читать онлайн книгу Откровения бизнес-аналитика - Анна Федорова страница 6
Объясняю: потому что именно аналитик управляет тем, с какой точностью бизнес-задачи заказчика транслируются в конечный продукт. Этим управляет не менеджер компании-исполнителя. Менеджер лишь формирует планы, сроки и бюджет на основе полученной от аналитиков и от разработчиков информации. И только потом передает конечную оценку заказчику. Сам менеджер оценить сложность работы не может. Сами разработчики могут оценить также лишь сложность и объем своей работы. Но всю систему целиком и все ее связи и зависимости, внешние и внутренние, а также пути расширения продукта по мере изменения отдельных входных параметров, видит только аналитик.
Поэтому производителю программных решений выгодно иметь аналитиков в своей команде: это дает возможность манипулировать стоимостью и объемом работы в своих интересах. Эта модель сделки является сейчас преобладающей на рынке.
Вторая модель подразумевает присутствие аналитиков на стороне заказчика. Она более целесообразна с точки зрения того, что аналитик защищает интересы заказчика на проекте. Но у нее также есть свои нюансы.
Во-первых, недостаточная техническая квалификация такого специалиста. В этом случае он не дает никакого уменьшения рисков, а просто создает дополнительный объем работы и коммуникации. Однако заказчику будет казаться, что риски устранены – они ведь наняли человека, выделили его на проект. Это довольно популярная история на рынке, с которой я сталкивалась неоднократно. Требования от таких аналитиков все равно полностью переписываются на стороне компании-исполнителя. И только после этого включаются в договор.
Во-вторых, технический персонал и, в-частности, разработчики, могут просто не захотеть устанавливать коммуникацию с такими специалистами. И причины этого будут уже чисто психологическими. Они будут просить транслировать эти требования через «своего» человека. В итоге вы получите опять увеличение объема коммуникации и дополнительные искажения информации. И эта ситуации тоже очень типична для рынка, хотя в большинстве случаев хватает и первого условия, чтобы надежно все испортить.
Если мы выносим анализ требований в отдельную, юридически самостоятельную функцию, то получаем независимость предлагаемых решений от конкретной команды разработчиков. При этом сохраняется точность отражения требований заказчика.
Естественно, все психологические нюансы коммуникации при этом остаются, как и в любых договорных процессах. Но, по крайней мере, мы исключаем риск навязывания заказчику неоптимальных решений только потому, что именно эти разработчики по-другому сделать не могут.
И даже