Vvk’s mindflow

Выяснение требований

Есть такой подход к поиску проектов в аутсорсинге.

В компании есть некто, назовем его “сейлс”, отвественный за привод заказчиков и первичную формулировку требований. Дальше, когда с заказчиком уже “зацепились” - проект передается менеджеру проектов, который собирает команду разработчиков и стартует работы на основании этого документа. В процессе старта проекта менеджер также знакомится с заказчиком, и дальше общается с ним напрямую.

При таком подходе менеджера проекта поджидает элементарная, но коварная ошибка - менеджер принимает на веру документ, написанный сейлсом. Конкретизирую: менеджер, естественно, изучает документ; затем по непонятным местам задает заказчику вопросы; но понятные менеджеру места документа при этом с заказчиком уже не обсуждаются.

Далее имеем следующее. Сейлс написал только то что он понял и так, как он понял. Причем написал все в краткой форме, чтобы не тратить на писанину время, которое можно потратить на приведение новых проектов (обычно з//п сейлса завязана на процент от “привода”). Заказчик, который с идеей своего проекта живет уже не первый день, краткие формулировки воспринимает весьма по своему. Менеджер - обычно воспринимает именно то, что написано, не представляя все возможные детали.

Простой пример фразы из документации: “there should be 3 different views in the race - side, above and front - to allow the user to feel it 3D”. С точки зрения заказчика это оказалось требование по использованию 3D движка при визуализации гонки, с возможностью перемещения камеры между видами. С точки зрения менеджера - сделать 3 разных вида - сбоку, сверху и спереди, сделать можно обычным flash-movie. В результате - потеря недели на реализацию неправильной с точки зрения заказчика демки.

Для того, чтобы избежать такой ошибки и связанных с ней проблем есть один хорошо известный способ: не начинать проект без тщательно проработанного СРС! Когда весь функционал тщательно описан, дизайн продуман и утвержден - вариантов для fatal missunderstanding почти не остается.

Однако, в некоторых компаниях для мелких проектов написание СРС может не считаться целесообразным. Либо заказчик очень торопит и просит начать делать хотя бы демку до готовности СРСа. Либо есть любая другая причина, по которой проект надо стартовать на основании краткого описания требований.

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

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

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

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

Ну и еще - по результатам такого “знакомства” менеджера с заказчиком иногда можно принять решение о закрытии проекта…