Бывает такое, что клиент не понимает, почему за разработку необходимо так дорого платить. Иногда это бывает из-за технической некомпетентности, как описано здесь: http://wiki4tech.ru/Проблема_понимания_клиентом_сложности_проекта. Но последнее время как правило бывают технически подготовленные клиенты, имеющие специальное профильное образование, но не ставшие на путь разработки и занимающиеся менеджментом. В этом случае сталкиваемся с непониманием другого рода. Будучи студентом решая различные лабораторные работы создается впечатление о том, что программирование — это достаточно легкое занятие. Довольно сложные задачи могут решаться быстро и впечатлять нас.
Дело в том, что лабораторная работа в сравнении со зрелым продуктом — это картонный автомобиль в сравнении с настоящим автомобилем. Смотрите, это же работает, какая красивая картинка. Но откуда берутся дополнительные часы и дни на разработку? Попробую перечислить, что же нам вставляет палки в колеса.
- Программа должна быть легко сопровождаема, необходимо писать красивый понятный код
- Программа должна быть протестирована самим программистом (а не только тестировщиком)
- В вузах как правило не преподают как эффективно проектировать интерфейс взаимодействия с пользователем. Интерфейс пользователя — это та неуловимая для многих вещь, которая заставляет писать дифирамбы программе, а иногда отбивает желание пользоваться.
- Программирование — это не спринт, а марафонский бег. Нужно достаточно хорошо подумать, чтобы что-то сделать.
- Иногда бывает, что время днями тратится на решение какой-то технической проблемы. При этом проблема не имеет какого-то понятного пользователю описания.
- Когда программисты работают в команде, необходимо тратить время на взаимодействие внутри команды.
- Любой проект с первого дня разработки начинает меняться и дополняться новыми требованиями. Если вы не меняете проект, то готовьтесь выкинуть его на помойку.
Как же решить эти проблемы с обоих сторон? Думаю, нам поможет модель Agile разработки ПО, которая учитывает непостоянство окружающего мира и в том числе процесса разработки. Эта модель построена на взаимном доверии, когда бюджет заранее не фиксируется, либо имеет ограничение сверху с запасом, позволяющее развивать проект. При подходе Agile программный продукт выпускается очень часто. Может быть каждую неделю, а может быть каждый день. Для больших проектов — это единственный путь, способствующий созданию успешного продукта. Подход Agile может существенно сэкономить средства на разработку и в короткие сроки создать работающий продукт. Старый подход, когда сначала пишется огромное ТЗ, а потом долго-долго реализуется часто приводит к провалу. А иногда даже к провалу до начала работы программиста.
Метки: разработка по
Что-то я не понял, у вас программисты проектируют интерфейс взаимодействия с пользователем? Не верю!
что то я чертовски мало заказчиков видел, которые бы оплачивали недоделанный проект. как правило наоборот говорят "мы хотим видеть полную цену"
vva,
Проблема в том, что заказчик часто не представляет себе в начале разработки, что он хочет получить. Модифицируя собственные запросы, он модифицирует постановку задачи.
В самом идеальном случае происходит то, что описал Андрей — постановка задачи на кратковременные этапы. На неделю-две вперед, оплата по факту выполнения этих задач.
Есть куча своих подводных камней, но в итоге система, для заказчика, работает серьезно эффективнее чем фиксированный договор+тз на долгий срок.
dmp,
я это всё понимаю, но вот объяснить это заказчику как то до сих пор не всегда получается.