Что нужно обсуждать с заказчиком?

Поездка к заказчику системы автоматизации – это всегда праздник. Не знаю как для вас, но для меня – точно. Получаем новую информацию, новые требования, общаемся, готовимся к установке программы или решаем проблемы работающего ПО.

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

Я уже поднимал тему сопротивления изменениям. В каждой встрече с заказчиком нужно готовиться к проблемам, которые возникнут в будущем. И так, есть некие бизнес-процессы, которые нужно автоматизировать. Есть некий документооборот, который нужно поставить на более или менее автоматизированный уровень. Если устанавливаемая программа будет сильно отличаться от того процесса, по которому привыкли работать сотрудники заказчика, то она встретит бурное сопротивление.

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

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

Какую информацию нужно собирать на первом этапе?

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

2. Информацию о том, как заполняются документы и формируются отчеты, алгоритмы получения той или иной цифры или заполнения того или иного реквизита.

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

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

Второй этап

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

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

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

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

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

Почему так, ведь так неправильно? Да потому что в то время, пока накладная выписывалась, за простой машины платили реальные деньги. Т.е. за задержку погрузки предприятие «попадало на бабки», поэтому все процессы в этот момент должны идти максимально быстро. Максимально быстро выписана накладная и максимально быстро машина отпущена. Затем в спокойной обстановке можно было ввести данные в справочники, сделать проводки к документу, провести другую работу по заполнению базы. Поэтому было принято такое решение, неправильное с точки зрения программистов, но правильное с точки зрения бизнеса. Ведь мы помним, что цели программистов и бизнеса – отличаются.