Coding for equity: человеческий фактор

В предыдущем постах мы говорили о том, что для успешного стартапа, в котором предприниматель и разработчики сотрудничают на условиях coding for equity, важны два момента:
1. Правильная договоренность о распределении акций. Нужно передавать права на распоряжение акциями при достижении фиксированных целей.
2. Необходимо обсудить на старте основной объем работ и построить договоренность, что будет происходить в случае возникновения потребности в дополнительных объемах разработки.
Есть еще один важный момент, и обратить на него внимание надо предпринимателю. Помните о том, что разработчики - это не просто некая удаленная команда, с которой достаточно подписать ТЗ и потом переписываться и созваниваться, требуя выполнения той или иной задачи. С ребятам надо постоянно общаться лично, самому понимать, что они делают, а также рассказывать о том, что происходит с бизнес-частью проекта. То есть не просто быть на связи, а быть в связке. Иначе возникает вакуум в общении, разработчики перестают понимать, что происходить с проектом – каждый день они видят только код. И проект для них становится обезличенным кодом. Крайне важно, чтобы разработчики получали информацию о маркетинге, продажах, ключевых бизнес договоренностях - все это добавляет мотивации их работе, помогает осознать зачем они работают в проекте, что именно нужно для клиентов, быть полноправным участником проекта.
Если с бизнес-часть возникают проблемы, о них также обязательно надо говорить с разработчиками. Во-первых, они могут дать очень дельный совет для предпринимателя, ведь знают продукт изнутри и у них незамыленный взгляд на ситуацию. Во-вторых, они равно настолько же заинтересованы в успехе продукта, насколько и предприниматель. Поэтому, не сообщив им о проблеме, вы можете разрушить сложившееся доверие между участниками проекта. А доверие, несмотря на все подстраховки в виде договоров и акций с ограничением, - это основа успешной работы команды. И если коммуникация нарушена, доверие может потеряться.
Почему Address.ua остановился именно сотрудничестве по модели coding for equity ?
Мы не искали партнерства именно по этой модели, мы искали профессиональную команду разработчиков, которая была бы в состоянии создать сложный и амбициозный продукт - портал по недвижимости Address.ua. И только потом решали, на каких условиях сотрудничать и в итоге остановились на Антоне Рудиче (Х-Tend Software Development) и его команде. Во многом по причине того, что Х-Tend - это не просто команда с хорошим опытом программирования. Это команда с уникальным опытом реализации интернет проектов с бизнес точки зрения. В их портфеле такие проекты как Rabota.ua, Izum.ua, Turne.com.ua. Поэтому мы больше принимали решение не столько в пользу coding for equity, сколько в пользу команды.
До того, как портал стали разрабатывать ребята из X-tend, у Address.ua был внутренний департамент разработчиков, и все процессы финансового планирования тем или образом крутились вокруг такого понятия, как ежемесячная зарплата разработчикам. Например, мы планировали: первый этап делаем за два месяца и это будет стоить соответственно две ежемесячные зарплаты департамента. После того, как срок разработки по первому этапу превысил четыре месяца, фактический R&D бюджет удвоился… Когда же создавалась договоренность с Х-Tend, стали искать модель, которая бы ориентировала разработчиков на достижение результата, а не на ежемесячную оплату, поэтому договорившись об объеме работ, мы договорились о привязке оплаты к произведенным релизам. Для меня их согласие стало дополнительным подтверждением того, что это именно те люди, которых мы искали – они уверены в своих силах и готовы свою уверенность трансформировать в договоренности. Более убедительное подтверждение профессионализма и веры в продукт сложно найти.
Итак, подведу итоги:
Преимущества coding for equity:
1. Не вымывается кеш из проекта. $X тыс. долларов, которые надо заплатить разработчикам, можно теперь вложить в достижение других ключевых бизнес целей, что очень полезно для стартапа.
2. В проект привлекаются люди, которые, как правило, имеют повышенную мотивацию в разработке проекта, т.к. думают как собственники.
3. Планирование расходов на разработку смещается от категории месяца к категории релиза. Ни один план по разработке продукта не выполняется в те сроки, в какие планируется. В данном случае риск по срыву планов берут на себя разработчики.
Все это возможно если:
1. На старте созданы и зафиксированы четкие договоренности об этапах развития проекта. И, особенно, о том, что команда будет делать в случае необходимости увеличить объем работ.
2. Выбрана правильная юридическая схема передачи акций и денег.
3. Вы действуете исходя из того, что предприниматель и разработчики - одна команда, у которой одна общая цель.

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

Остальные части

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