Выявление нужд пользователей

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

Примеры начальных формулировок задач приходят ко мне самые разнообразные:

С продолжением списка первых запросов по обратной связи можно ознакомиться по этой ссылке.

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

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

Откровенно говоря, я бы предпочел понять проблему заказчика, а как ее решать, лучше, чтобы заказчик доверил мне – у меня и выбор инструментов больше. Т.е. мне больше нравится формула: от заказчика – проблема, от меня – решение.

На заборах иногда очень интересные вещи написаны. Генри Форд: если бы я спрашивал, чего хотят люди, они бы до сих пор ездили на повозках.

В конечном итоге результатом выявления нужд пользователей должен стать документ, описывающий требования заказчика - BRD (Business Requirements Document) с заранее согласованной структурой, включающий в себя как описание бизнес процессов «As Is», «To Be», так и описание пользовательского интерфейса, варианты использования системы, а также тестовые сценарии, на основании которых будет приниматься программное обеспечение. BRD - основа для дальнейшей подготовки качественной документации.

Иногда и программисты, и заказчики предпочитают использовать другое название для описания задач клиента – техническое задание (ТЗ). Я не против. В самом деле, разделение документов на: BRD (Business Requirement Document), FSD (Functional Specification Document), TS (Technical Specification), - имеет смысл в крупных проектах, где есть бизнес-аналитики, системные аналитики и т.д. в нашем же случае есть я (и бизнес-аналитик, и программист - два в одном) и есть заказчик. И наша задача понять друг друга и договориться по деньгам и срокам с помощью некого контракта. И как этот контракт назвать: ТЗ или просто договор подряда – не так уж и важно. Важно расставить все точки над i.

Если же у вас нет времени и денег на «лишние телодвижения». Если ваши нужды вам предельно понятны, и у вас есть готовое ТЗ, а от исполнителя вы ожидаете фиксированную стоимость и сроки выполнения подряда, то убедитесь, как минимум в том, что в вашем ТЗ чётко определены объемы и критерии приемки работ. Если объемы работ заканчиваются фразой «и так далее», то и стоимость работ тоже будет заканчиваться фразой «и так далее».

Если вы готовы сами написать ТЗ, то вот вам шпаргалка в виде буллитов, что в BRD/ТЗ стоит упомянуть.:

  1. Общее описание создаваемой системы автоматизации
  2. Сколько пользователей планируется подключить к работе с системой, чем они будут заниматься, пока без детализации.
  3. Описание бизнес процессов As Is (до планируемой автоматизации)
  4. Описание бизнес процессов To Be (после внедрения нового решения)
  5. Технико-экономическое обоснование автоматизации. Документ не обязательный, но поможет мне лучше понять клиента.
  6. Ролевая модель (кто за что отвечает, какие права на доступ к данным и алгоритмам имеет и т.д.)
  7. Перечисление сущностей, используемых в автоматизации: продукция, заказы, клиенты, денежные потоки и т.д.
  8. Классификация сущностей на входные и выходные параметры.
  9. Описание систем, содержащих входные/выходные сущности.
  10. Какие входные данные генерируются непосредственно пользователями.
  11. Количество транзакций, создаваемых пользователями, в системе
  12. Перечень и описание пользовательских форм ввода, если есть требования к дизайну, то еще и с картинками.
  13. Перечень и описание «защит от дурака» для данных, вводимых пользователями.
  14. Перечень проверок для данных, поставляемых другими системами.
  15. Перечень спецификаций (в том числе и принятых на международном уровне) сообщений, которым должны соответствовать входные и выходные потоки данных.
  16. Требования к интеграции с другими системами автоматизации. Для интернет магазина это, например, интеграция с CRM, IP телефонией, загрузка заказов из систем партнеров, отслеживание этапов обработки заказов в курьерской компании и т.д.
  17. Требования к составу отчетов и к скорости построения отчетов.
  18. Описание алгоритмов расчетов.
  19. Требования к составу отчетов и к скорости построения отчетов.
  20. Критерии приемки (тест кейсы или программа и методика испытаний (ПМИ)) - для каждой конкретной работы. Именно по тест кейсам и ПМИ будет сдаваться и приниматься моя работа.

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

А можно ли начать работать без ТЗ? Ну, в самом деле, зачастую заказчик не знает в начале пути, что ему нужно. А в процессе приближения к решению его требования могут несколько раз кардинально поменяться. Мой ответ такой: можно. Но платить придется за отработанные часы (Time&Materials). Время и материалы это тип контракта, пришедший к нам из строительства, по которому заказчик соглашается платить подрядчику, исходя из времени, затраченного подрядчиком на выполнение работ, а также за материалы, используемые в строительстве, независимо от того, сколько работы требуется для завершения строительства. Обычно используются в проектах, в которых невозможно точно оценить размер проекта, или когда ожидается, что требования к проекту, скорее всего, изменятся. Но даже в этом случае обычно прописываются конкретные задачи на ближайшее время. Например, вот такое мини ТЗ.

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

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