Метод эффективного выявления и согласования требований с заказчиком

Никольская Е.Ю.
Выпускница группы ITM-22
Школы IT-менеджмента
РАНХиГС при Президенте РФ
Бизнес-аналитик
Команда по разработке ПО «КПД 99»
nikolsk.elena@gmail.com

В основу моей работы лег мой опыт в качестве бизнес-аналитика и в частности опыт моего последнего проекта в составе команды КПД 99. Основным условием Заказчика было сделать проект по созданию совершенно новой программы за 6 месяцев.
Итак, допустим, что Вы Заказчик… и я хочу задать Вам несколько вопросов:

• Знаете ли Вы все бизнес-процессы у Вас на фирме?
• Охотно ли Вы поделитесь этой информацией с незнакомым Вам человеком?
• Поймете ли Вы меня, если я скажу, что данные на форме будут отображаться в виде грида, а выбрать нужную вам информацию вы сможете из листбокса?
• Если я попрошу Вас описать какой-нибудь бизнес-процесс на листе бумаги, сможете ли Вы это сделать без единой правки, т.е. последовательно?
• А какое письмо вы охотнее прочтете, состоящее из нескольких строк или из нескольких абзацев?
• Много ли у Вас времени на работе для того чтобы пообщаться с аналитиком из др. фирмы, осознавая что при этом Вашу работу никто за Вас не сделает?
• Знаете ли Вы методологии проектирования: UML, ARIS…?
• Знаете ли Вы что Вам нужно сейчас?

       Нет? Вам нужно подумать? Скорее всего, я угадала ваши ответы, в противном случае можете считать себя уникальным заказчиком, но такие, к сожалению, мне не попадались. Поэтому я столкнулась с перечисленными проблемами.

Что же мне c Вами (драгоценный Вы мой Заказчик) делать?
Для решения этих проблем, нужно применить метод, который позволил бы быстро и эффективно в полном объеме собрать и согласовать все требования, иначе мы просто провалим проект и не получим запланированную прибыль.

Что же это за метод?
Я могла бы применить к Вам (Заказчик) следующие методы:

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

Остаются 4 метода:

• Интервьюирование, 
• Проектирование,
• Прототипирование,
• Гибкие (agile) методологии.

       Когда мы друг друга быстрее поймем - если я буду рисовать услышанное от Вас, или если я буду это описывать текстом? Конечно – рисовать! Почему? Потому что рисунок человек воспринимает и охватывает одним взглядом, а текст требует прочтения от начала до конца.
Но что рисовать? А то, что требуется задокументировать и согласовать, в данном случае это процесс и поэтому рисовать будем диаграммы.
Как рисовать? А так как это будет понятно, прежде всего, Вам (мои уважаемые Заказчики). Т.е. адаптировать методологию под Вас исходя из Ваших предпочтений, особенностей и стандартов. Например, для данного заказчика лучше всего подошла нотация ARIS.

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

Процесс нарисовали, идем дальше. Нарисуйте-ка мне глядя на данную диаграмму формы будущей программы?
Какая вероятность, что Вы нарисуете такие же формы, которые задумала я? А чем это нам грозит?
Тем, что Вы получите не то, что Вам нужно и не заплатите мне денег за работу.

Что мне делать?
Было бы неплохо  дать Вам программу еще до того как она будет создана. Т.е. мне нужно дать Вам прототип и прямо сейчас и под подпись, потому что потом вы передумайте и скажете переделать!

Я создавала прототипы в Microsoft Visual Studio, который позволяет быстро нарисовать формы, вставить туда рисунки будущих таблиц и графиков, элементы управления, собрать их в небольшую программу и отправить Заказчику по почте. Заказчик, запустив данную программу, может четко представить, как будет происходить его работа уже с готовой программой. Основная польза этого процесса остается невидимой для заказчика – я подготавливаю его к тому, за что он заплатит деньги. А заказчик начинает работать на меня – он участвует в дизайне!

Данный метод дал просто потрясающие результаты.

• Я выявила производные требования, обнаружились огромные пробелы в изначальных требованиях, тем самым я смогла сделать вовремя соответствующие изменения, до того как эти части были пущены в разработку (команда избежала переделок за свой счет) и мы договорились о новой цене проекта связи с увеличением объема работ. Ничто так не огорчает покупателя как непредвиденные затраты – нельзя доводить до этого!
• Прототип и формы, потом пошли в разработку и использовались при постановке задач. Смотрите на счастливые лица разработчиков -  они теперь точно знают, что от них хотят.

Обратите внимание на таблицы excel – вы думаете это настоящие таблицы? Нет, я же не программист, это всего лишь рисунок, вставленный в форму J

Вуаля! Во мне «спит» фокусник, судя по тому, с каким интересом заказчик приходил на представления!
А что мы с Вами при этом подпишем? Мы подпишем каждую форму на этом прототипе. И попробуйте после этого придраться ко мне и сказать, что Вы хотели, чтобы например таблица была не справа, а слева? А я буду тыкать пальцем в вашу подпись, и прикладывать рисунок над ней к экрану для сравнения. Нет, нет, … я понимаю, что Вы тогда еще не знали, но теперь вы знаете и мы знаем, и это дополнительная работа, которую неплохо было бы оплатить.

Как хорошо, что в этих «разборках» мое присутствие не требуется – мой прототип работает без меня, а я могу думать о хорошем в это время.
А как вы думаете, сколько времени у меня ушло на создание такого прототипа? 1 час. Прототип, который занимает много времени это уже не прототип!

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

Что же мне с Вами делать?

А что если ваше руководство заплатит вам денег, чтобы вы поделились информацией со мной? Уверена, Вы сейчас улыбнулисьJ.  Это сработает!

А почему Ваше руководство пойдет на это?
Да потому что, оно заплатит вам меньше, чем заплатило бы мне за долгий сбор требований на допросах со светом лампы в Ваши глаза. Я на почасовой ставке!

Итак, что у нас получилось:

• Срок выявления и согласования требований снизился в несколько раз, за счет того, что мы избавились от длинных спецификаций, которые никто не хотел читать, а так же за счет того, что Вы (мои дорогие Заказчики) стали более охотно делиться информацией.
• Ваши фирмы сэкономили деньги на консалтинге, аналитике и на переделках продукта. Т.к. Вы уже умеете работать с данной программой, знаете в каком меню, что находится и можете научить других.
• Уверена Вам было приятно читать мой текст и смотреть картинки, т.к. я говорила на понятном для Вас языке, а Вы, надеюсь, получили то, что хотели.
• А что же получили мы? А мы сделали проект вовремя без непредвиденных расходов.

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

Список литературы:

• Корнипаев Илья Александрович. Курс лекций «Управление требованиями». 
• Сирота Владислав Ефимович. Курс лекций «Управление процессами». 
• Сирота Владислав Ефимович. Курс лекций «Управление проектами». 
• Практические рекомендации Менеджера проектов команды КПД 99.
• Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. 2002. Вильямс