Версия для печатиОтправить другу

Ситуация:
Вы руководитель проекта по доработке внутренней ИТ системы среднего размера компании со стороны подрядчика. Вашу компанию выбрали на основе конкурса на разработку небольшого модуля, обеспечивающего дополнительный сервис для административно-хозяйственного подразделения. Данный сервис ранее не был автоматизирован. Для вашей компании важен собственно не этот проект по доработке, а возможность получить данного заказчика для дальнейших работ. Подписан договор, разработано техническое задание. В техническом задании не прописан внешний вид интерфейса пользователя, т.к. сама система выполнена со стандартным Windows интерфейсом, менять который не планируется. Проект стартует, вы активно вовлекаете заказчика в обсуждение логики работы системы, доработка выполняется, но в связи с короткими сроками проекта (полтора месяца), вы предоставляете пользователю готовый продукт, без предварительного прототипа. Однако, когда, вы демонстрируете продукт заказчику, появляется недоумение вызванное пользовательскими интерфейсами. Ожидания заказчика полностью не совпадают с реализованным стандартным интерфейсом системы, хотя и не противоречат идеологии системы. У вас есть вариант настаивать на том, что задача реализована в соответствии с техническим заданием, либо существенно переработать интерфейсы.
 
Вывод:

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