Читать книгу Откровения бизнес-аналитика - Анна Федорова - Страница 12

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

А зачем, спросили меня, заказчику нужен аналитик как третья, самостоятельная сторона в сделке? Если мы заказываем продукт какой-то компании, то пусть они самостоятельно решают вопрос ресурсов и выделяют аналитика из своих имеющихся или ищут его специально под конкретный проект.

Объясняю: потому что именно аналитик управляет тем, с какой точностью бизнес-задачи заказчика транслируются в конечный продукт. Этим управляет не менеджер компании-исполнителя. Менеджер лишь формирует планы, сроки и бюджет на основе полученной от аналитиков и от разработчиков информации. И только потом передает конечную оценку заказчику. Сам менеджер оценить сложность работы не может. Сами разработчики могут оценить также лишь сложность и объем своей работы. Но всю систему целиком и все ее связи и зависимости, внешние и внутренние, а также пути расширения продукта по мере изменения отдельных входных параметров, видит только аналитик.

Поэтому производителю программных решений выгодно иметь аналитиков в своей команде: это дает возможность манипулировать стоимостью и объемом работы в своих интересах. Эта модель сделки является сейчас преобладающей на рынке.

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

Во-первых, недостаточная техническая квалификация такого специалиста. В этом случае он не дает никакого уменьшения рисков, а просто создает дополнительный объем работы и коммуникации. Однако заказчику будет казаться, что риски устранены – они ведь наняли человека, выделили его на проект. Это довольно популярная история на рынке, с которой я сталкивалась неоднократно. Требования от таких аналитиков все равно полностью переписываются на стороне компании-исполнителя. И только после этого включаются в договор.

Во-вторых, технический персонал и, в-частности, разработчики, могут просто не захотеть устанавливать коммуникацию с такими специалистами. И причины этого будут уже чисто психологическими. Они будут просить транслировать эти требования через «своего» человека. В итоге вы получите опять увеличение объема коммуникации и дополнительные искажения информации. И эта ситуации тоже очень типична для рынка, хотя в большинстве случаев хватает и первого условия, чтобы надежно все испортить.

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

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

И даже если вся команда разработчиков внезапно заболеет или растворится в тумане, вы сможете передать входной документ с требованиями абсолютно любой команде подходящей квалификации, и ваш проект будет продолжен, а не перезапущен с нуля.