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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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