понедельник, 2 октября 2017 г.

Чего на самом деле хочет заказчик?

заказчик

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

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

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

Ан нет. В процессе планирования и исследования проблемы, бесед с заинтересованными людьми - начальниками отделов, специалистами, операторами - были получены совершенно иные факты.

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

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

Что имеем в результате?

Юзеры писают кипятком, начальство видит писающих юзеров и писает само, скорость обслуживания - 1 клиент за 1,5 минуты. Данные стекаются в “центр” ежемесячно, анализируются и агрегируются.

Формально ТЗ соблюдено: есть возможность централизованной обработки и контроля, но 90% контроля и обработки делается на местах!

Что было бы, если следовать ТЗ? Тяжелое приложение с подключением к ЦБД на всех рабочих местах, куча аналитики, пики нагрузок, ненадежные линии связи, перегруженность приложения функциями (очень не рекомендуется для юзеров “ниже среднего”) - и вся эта махина с трудом вращаясь и скрипя, выполняла бы функцию автоматизации предприятия. Почувствовали разницу?

“Зрите в корень”, как говорится.

Автор: Дядя Эдик.

Полезные ссылки в тему:




Комментарии:


Сергей
ну ты Дядя Эдик как напишешь порой - ну ни добавить ни отнять..

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

Дядя Эдик
Конечно утверждал. ТЗ в этом случае было гарантией оплаты. Своим ТЗ я показал заказчику на то, ЧТО на самом деле надо было решить. Самое сложно, кстати, было указать руководству, принимающему решения, на ДЕЙСТВИТЕЛЬНЫЕ, а не ВООБРАЖАЕМЫЕ проблемы. В конце концов, все остались довольны результатом, а это самое главное.


Другие посты по этой теме:



0 коммент.:

Отправить комментарий

Ваш комментарий появится в блоге после проверки администратором