Это все о процессе и управлении ожиданиями и очень мало общего с техническим. Ошибка (imho), которую совершают большинство клиентов, особенно с небольшими консультантами, заключается в том, что они заключают контракт с фиксированной ценой (возможно, с поддержкой, оплачиваемой T & M: время и материалы). Они делают это как упражнение по управлению рисками, так что это понятно.
Проблема в том, что они платят за этот более низкий риск тремя способами:
- Вы платите премию за меньший риск. Это фундаментальный принцип, который справедлив как в разработке программного обеспечения, так и на финансовых рынках;
- Разработчик (и) может быть подвергнут такому большому риску, что стоимость астрономически возрастает, что точно никому не выгодно (ну, это выгодно разработчику, пока все не пойдет катастрофически неправильно, что они почти всегда делают в конечном итоге); и
- Вы тратите так много времени на разработку спецификации и формализацию результатов и критериев приемлемости, что вы забываете при этом, что вы просто потратили 300 тысяч долларов на написание документа Word объемом 300 страниц вместо того, чтобы что-то кодировать.
Все это служит для того, чтобы сделать конечный результат более дорогим для клиента, демотивируя для разработчика (который хочет написать 300-страничную документацию Word? Серьезно!), И задерживает получение клиентом чего-либо (таким образом увеличивая риск охвата) ползучесть, которая прямо пропорциональна длине проекта).
Обе стороны часто лучше обслуживали бы, используя подход T & M в сочетании с некоторой формой методологии быстрого прототипирования с регулярными результатами или демонстрациями для клиента с интервалом не более 4-6 недель. Это идет к управлению ожиданиями. Если клиент видит, что что-то происходит, он успокаивает его и позволяет вам продолжить работу (а не в ожидании встреч на совещаниях по диаграммам Ганта).
Итак, что вы должны сделать, это попытаться убедить своего клиента пойти на ступенчатый подход (детские шаги), где он может видеть, что он получает, как он развивается и участвовать в процессе. Он дает результаты быстрее и в конечном итоге дешевле (обе стороны разделяют бремя риска).
Одна вещь, которую многие разработчики также забывают, это то, что они похожи на королевских подданных во Франции 15-го века. У них могут быть привилегии, даже богатства и много привилегий, но они служат в угоду королю (или королеве), который может обезглавить их по своей прихоти. Под этим я подразумеваю, что клиент в конечном итоге обладает властью, а вы, как разработчик, существуете, чтобы упростить свою жизнь, а не наоборот.
Если клиенту нужен розовый и зеленый веб-сайт, разработанный в Cobol on Rails, работающий на виртуальном сервере Vax / VMS на iphone босса, то это то, что он получает. Теперь вы можете использовать свой опыт и опыт, чтобы убедить их, что это не очень хорошая идея, но, в конечном счете, если они этого хотят, у вас есть два варианта: дать им это или прогуляться.
Слишком много разработчиков попадают в ловушку, давая людям то, что, по их мнению, они должны иметь, а не то, что они просят. БОЛЬШАЯ ОШИБКА. Часть процесса состоит в том, чтобы держать каналы связи открытыми с клиентом так, чтобы вы не сходили с ума, думая, что они чего-то хотят (или решая, что они должны что-то иметь), когда они ожидают чего-то совершенно другого.
Даже небольшой проект по разработке программного обеспечения может легко столкнуться с 6 цифрами. Обычно это большие инвестиции для тех, кто за это платит. Они имеют право не нервничать, а вы обязаны сделать их счастливыми.