Coding for equity: проблемная точка

Coding for equity: проблемная точка
Какие же основные критические точки в модели coding for equity?
Для coding for equity крайне важно, чтобы предприниматель и разработчик в максимально возможных деталях договаривались об объеме работ до начала проекта.
Если на начальном этапе создать неадекватные договоренности по объему работ, проект в результате может быть «завален». Как я уже писал, первому этапу отношений свойственен повышенный оптимизм и доверие к партнеру (я бы сказал «доверие авансом»). И это правильно, без доверия и оптимизма проект и не появился бы вообще. Но. Проходит время, эмоциональный всплеск, столь характерный для старта проекта, оседает. И приходит этап, когда работы сделано уже очень много, но до результата пока далековато. На этом этапе нередко появляется желание сократить объем работы, что по-человечески вполне понятно. Кроме того, по истечении времени что-то может забыться, и если задача не была прописана заранее на бумаге, она может восприниматься как новая, не оговоренная, следовательно, как повышенная нагрузка на разработчика.
Правда, это все еще мелочи по сравнению с тем моментом, когда продукт выводится на рынок и им начинают использоваться потребители. Даже если вы подробнейшим образом договорились обо всем на 100% наперед (что на практике практически невозможно), потребители и ситуация на рынке наверняка потребуют внесения изменений в план развития продукта, каких-то не оговоренных заранее усовершенствований. Первичные планы всегда отличаются от того, что получается в результате. Поэтому крайне высок риск, что вы легко залипнете, например, на споре «Что делать дальше – развивать запланированные 1500 фич или разрабатывать 500 фич, о которых написали пользователи».
Что делать? На самом первом этапе, когда все еще очень любят друг друга, надо договориться о том, как вы будете работать с дополнительными потребностями проекта. Потому что реализация неожиданно возникающих дополнительных потребностей в разработке программного продукта – это, одновременно, залог успеха всего бизнеса и корень зла в отношениях между предпринимателем и разработчиками. Это - потенциально проблемная точка для тех, кто собирается работать по модели coding for equity.
Поэтому команда разработчиков и предприниматель изначально должны иметь единое стратегическое видение того, как должен развиваться продукт и к какому конечному результату все вместе идут. Подчеркиваю - в продукт должны верить обе стороны, а не только «сумасшедший» предприниматель. Мотивация со стороны разработчиков, когда они работают по модели coding for equity, как правило заключается в том, что они верят в продукт, верят в команду, а не просто работают за деньги. И, если предприниматель с разработчиком договариваются о совмещенной модели (часть оплаты акциями, а часть деньгами), денежная составляющая должна быть минимальная – и это момент истины при выборе разработчика. Если девелопер готов работать за акции, которые получит в будущем, – это говорит о том, что он верит в продукт и между ним и предпринимателем есть большое доверие, а это – самая большая мотивация сделать все, чтобы проект был успешным. А также гарантия того, что в споре на предмет разработки дополнительных решений, IT-сторона будет руководствоваться интересами бизнеса, а не своими личными.

Максим Школьник

1 часть http://dennydov.blogspot.com/2010/10/coding-for-equity.html
2 часть http://dennydov.blogspot.com/2010/10/coding-for-equity_13.html
3 часть http://dennydov.blogspot.com/2010/10/coding-for-equity_14.html
4 часть http://dennydov.blogspot.com/2010/10/coding-for-equity_6827.html

Макс отвечает на вопросы http://dennydov.blogspot.com/2010/10/coding-for-equity_15.html