Типовая процедура развития договорных отношений

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

Обязательные условия реализации

Постоянный контакт с заказчиком.
Заказчик должен участвовать в проектировании системы.
Постоянный контакт с прямыми и потенциальными пользователями продукта.
Поэтапная предоплата проекта.

Что мы иногда делаем «хорошего» для достижения успеха

Привлекаем специалистов со стороны фирмы – заказчика в проектную и разработческую группу.
Привлекаем непосредственных пользователей будущего продукта к проектированию интерфейса и описанию бизнес-процессов.
Устраиваем по срочному договору бизнес-аналитика в фирму заказчика для анализа бизнес-процессов, т.е. для более глубокого понимания процессов, которые необходимо формализовать в виде программы.

Что мы иногда делаем «плохого» для достижения успеха

Отказываемся от реализации «заоблачного» функционала. – Безупречно работает только то, что просто и понятно.
Не беремся за реализацию того, что уже имеется на софтверном рынке или морально устарело.

Памятка заказчику

В чем Заказчик никогда не виноват:

В том, что часто ошибается в сроках реализации проекта.
В том, что всегда хочет качественно, быстро и дешево.

В чем Заказчик всегда прав:

В том, что музыку заказывает он, а играть ее приходиться нам (даже если композиция не всегда нам нравится).

Чем рискует Заказчик

Мы можем не рассчитать время разработки. Такое, к сожалению, случается не редко, особенно если приходится разрабатывать что-то новое, оригинальное и сложное.
Проект, за время его реализации, может морально устареть, но это редко существенно влияет на коммерческий успех проекта.
Заказчик может не уложиться в смету затрат, а мы будем вынуждены урезать функционал программы.
Заказчик может разочароваться в концепции проекта, а мы будем вынуждены адаптировать существующие наработки под новую концепцию и тратить на это лишнее время и деньги.
В виду объективных причин, как правило, связанных с временными рисками на НИОКР, Заказчик может не дождаться выпуска окончательной версии программы как раз к тому моменту, когда программа чрезвычайно необходима.