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