В этом посте я хочу дать вам рецепт плодотворной работы над проектом. Под плодотворной работой я понимаю работу, результат которой удовлетворяет как заказчика, так и исполнителя. Рецепт на самом деле очень прост. Работая над проектом, необходимо решить конкретную проблему конкретного заказчика.
Первая заковыка в том, как найти ту самую проблему, которую призвана решить ваша работа. Не всегда она содержится в задании на проект, не всегда она лежит на поверхности. Почему? Лучше объяснить на примере.
Был у меня проект: система автоматизации страховой деятельности по конкретному виду страхования. Казалось бы, проблема, вот она, собственно система автоматизации, вернее ее отсутствие. Создавай систему, базу данных, кодируй программный комплекс по работе с этими данными, ввод первичной информации и получение отчетов по заданным формам с целью предоставления в контролирующие органы плюс собственная аналитика. Процесс накатанный и всем известный.
Ан нет. В процессе планирования и исследования проблемы, бесед с заинтересованными людьми - начальниками отделов, специалистами, операторами - были получены совершенно иные факты.
Сама система автоматизации нужна была не для отчетности и аналитики, а для ускорения качества обслуживания клиентов с целью увеличения клиентской базы и повышения финансовых оборотов по данному виду и удобства сбора данных с региональных представительств и отделений. Посему мной было принято решение: отказаться от централизованного приложения для аналитики и разработка максимально удобного, быстрого, ресурсонеприхотливого и надежного приложения без подключения к базе данных для конечных пунктов продаж полисов, центрального приложения для сбора и анализа данных и сервиса аналитики.
Причем на первое приложение было угрохано около 60% времени работы с целью повышения юзабилити и отказоустойчивости. Немного нестандартное решение для полностью централизованной системы, правда?
Что имеем в результате?
Юзеры писают кипятком, начальство видит писающих юзеров и писает само, скорость обслуживания - 1 клиент за 1,5 минуты. Данные стекаются в “центр” ежемесячно, анализируются и агрегируются.
Формально ТЗ соблюдено: есть возможность централизованной обработки и контроля, но 90% контроля и обработки делается на местах!
Что было бы, если следовать ТЗ? Тяжелое приложение с подключением к ЦБД на всех рабочих местах, куча аналитики, пики нагрузок, ненадежные линии связи, перегруженность приложения функциями (очень не рекомендуется для юзеров “ниже среднего”) - и вся эта махина с трудом вращаясь и скрипя, выполняла бы функцию автоматизации предприятия. Почувствовали разницу?
“Зрите в корень”, как говорится.
Автор: Дядя Эдик.
Полезные ссылки в тему:
Комментарии:
Сергей
ну ты Дядя Эдик как напишешь порой - ну ни добавить ни отнять..
Стас
Безусловно, очень важно понять, какая именно задача стоит перед заказчиком. Вы выяснили много деталей при общении с людьми, которые работают с этой системой. Но я не совсем понял из статьи, утверждали ли вы с заказчиком изменение ТЗ, или согласовывали изменения каким-либо другим способом. Ведь нельзя же в одностороннем порядке изменять функциональность. Иначе высок риск того, что в ответ можно получить “это не то, о чем мы договаривались”.
Дядя Эдик
Конечно утверждал. ТЗ в этом случае было гарантией оплаты. Своим ТЗ я показал заказчику на то, ЧТО на самом деле надо было решить. Самое сложно, кстати, было указать руководству, принимающему решения, на ДЕЙСТВИТЕЛЬНЫЕ, а не ВООБРАЖАЕМЫЕ проблемы. В конце концов, все остались довольны результатом, а это самое главное.
0 коммент.:
Отправить комментарий
Ваш комментарий появится в блоге после проверки администратором