Вступление от автора блога.
Некоторое время назад Максим Школьник написал большой материал в 4х частях на тему coding for equity. До сих пор это один из самых читаемых материалов в моем блоге. В этом материале Макс рассказал, о тонкостях вопроса на стороне заказчика. Думаю, что читателям будет интересно посмотреть на то, как этот же процесс виден по другую сторону баррикады. У нас в гостях Антон Рудич, который как раз и делал работу для Макса. Думаю, материал будет полезен, как предпринимателям, так и компаниям, которые делают для стартапов разработку. Буду благодарен за лайки, ретвиты и остальные плюшки.
Вот ссылки на материал Макса:
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
А вот, собственно, и первая часть материала от Антона.
Ваш, ДД.
Coding for equity. Обратная сторона медали. Часть 1.
Программирование за долю в бизнесе – определенно не самый распространенный и легкий способ взаимодействия между предпринимателем и компанией-разработчиком, выступающей по сути дела инвестором в проект при создании программного продукта.
Многие из аспектов, возникающих при таком взаимодействии, уже были описаны Максимом Школьником (проект Address.ua) с точки зрения предпринимателя. Я же изложу мнение компании-инвестора на процесс, отмечу основные сложности и преимущества данного стиля взаимодействия.
Address.ua не был для нас первым проектом, в котором мы полностью или частично финансируем R&D, рассчитывая на дальнейшее успешное развитие проекта и получение дивидендов или выход из него. Более десяти лет назад мы начали работу над британским проектом Intellitracker.com (в 2011 году переименован в Cognesia), имея опцион на долю в бизнесе. А в этом году мы начали работу над проектом Smailex, в котором отвечаем за техническую реализацию проекта и полностью финансируем разработку. Можно сказать, что мы профессионалы в программировании на свой страх и риск.
Кроме разработки заказных проектов мы активно развиваем собственные и имеем большой опыт выведения проектов на хорошие финансовые и рейтинговые позиции (RABOTA.ua, TURNE.com.ua, IZUM.ua, poehalisnami.ua), что вносит дополнительную специфику в наши взаимоотношения с остальными участниками проекта. Наработанные знания и опыт позволяют нам принимать активное участие в обсуждении вопросов, которые выходят далеко за рамки процесса разработки и позволяют нам помогать проектам в таких аспектах бизнеса как финансы, маркетинг, построение продаж, разработка и модификация продуктов. Для себя мы даже определили стиль программирования и взаимодействия с заказчиком для достижения ЗАКАЗЧИКОМ максимального результата как бизнес-программирование, т.е. программирование, при котором выигрывает бизнес заказчика. Но описание нашего понимания бизнес - программирования не является темой данного поста.
Для начала о том, в каком случае программистским компаниям интересно работать по схеме coding for equity. Необходимые условия такого подхода: наличие у компании-разработчика свободных человеческих и материальных ресурсов и присутствие у руководства компании достаточной доли авантюризма. Нужно заметить, что чаще всего в качестве подрядчиков на разработку будут выбирать компании с опытом работы в данной сфере, что накладывает определенный отпечаток на взаимодействие с заказчиком.
Максим в своих постах достаточно четко описал технические особенности оформления прав владения для компаний-разработчиков и я не буду касаться данных формальных вопросов и больше внимания уделю фактическим проблемам взаимодействия и эффективности данной схемы.
Основные особенности построения процесса разработки
1. Определение ролей в проекте. Возможно, это в большей степени проблема X-tend Software Development как части X-tend Group. У наших порграммистов огромный опыт активного участия в разработке успешных проектов-лидеров. Набив шишки в одном проекте очень сложно повторять те же ошибки в следующем, даже если «тебе до этого нет дела», т.е. не ты определяешь что и как должно быть сделано. При этом такие чувства испытывают не только руководители программисткой фирмы, но и сами разработчики. Видимые нами «ошибки» могут быть как на уровне не правильно определенном продукте для продажи, так и на уровне мелких неточностей в верстке или деталях функционала, предлагаемом заказчиком.
Разработчик в любом случае всего лишь исполнитель и должен в первую очередь быть сосредоточен на выполнении своих прямых обязанностей. Консультации по остальным аспектам бизнеса с компанией разработчиком или некоторыми специалистами такой компании – это абсолютно другая роль и ее нужно по возможности отделить от роли разработчика. Желательно даже проводить совещания по «левым» темам отдельно от обсуждения текущего состояния разработки
2. Время обсуждения и время реализации. В принципе эта проблема свойственна любой разработке, в рассматриваемом нами случае она просто становится более явной.
При любой разработке есть время демократии, когда все (?) могут высказывать свои предложения и время диктатуры, когда руководящий орган принимает решение что и как делать и все остальные должны просто выполнять поставленные задачи. В случае coding for equity (если разработчики знают о схеме финансирования проекта) сама атмосфера развития проекта предполагает большую демократию, чем при программировании за конкретные деньги. Естественно, это требует большей диктатуры при выполнении принятых решений. Легко сказать, но очень сложно применить для своих любимых, свободолюбивых, дефицитных программистов!
3. Невозможность точной оценки проекта на стадии принятия решения. Это факт, не стоит его даже обсуждать. В очень многих проектах сейчас нет точного ТЗ, а при схеме coding for equity это проявляется еще более явно. Нужно программировать идеи и на вопрос выгодно ли это исполнителю (фирме-разработчику) нужно отвечать на основании предыдущего опыта, знании партнера-заказчика и других неформализуемых величин. Суть стартапа заключается в высокой динамике внедрения, поэтому принимать решение нужно достаточно быстро. В итоге все сводится к решениям типа «нравится - не нравится, верю -не верю».
4. Компромисс между желанием заказчика сделать все и желанием разработчика сделать минимум. Этот вопрос вытекает из предыдущего пункта. Не все может быть определено в ТЗ (если оно вообще есть), исполнитель тратит конкретные деньги при увеличении трудоемкости и необходимо действительно искать компромисс. В связи с этим возникает вопрос о совместимости основного заказчика и разработчика, т.е. вопрос взаимоотношений между конкретными людьми. Вопрос очень непростой и лучше подумать «смогу ли я сработаться с Васей» на берегу, причем обеим сторонам.
Некоторое время назад Максим Школьник написал большой материал в 4х частях на тему coding for equity. До сих пор это один из самых читаемых материалов в моем блоге. В этом материале Макс рассказал, о тонкостях вопроса на стороне заказчика. Думаю, что читателям будет интересно посмотреть на то, как этот же процесс виден по другую сторону баррикады. У нас в гостях Антон Рудич, который как раз и делал работу для Макса. Думаю, материал будет полезен, как предпринимателям, так и компаниям, которые делают для стартапов разработку. Буду благодарен за лайки, ретвиты и остальные плюшки.
Вот ссылки на материал Макса:
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
А вот, собственно, и первая часть материала от Антона.
Ваш, ДД.
Coding for equity. Обратная сторона медали. Часть 1.
Программирование за долю в бизнесе – определенно не самый распространенный и легкий способ взаимодействия между предпринимателем и компанией-разработчиком, выступающей по сути дела инвестором в проект при создании программного продукта.
Многие из аспектов, возникающих при таком взаимодействии, уже были описаны Максимом Школьником (проект Address.ua) с точки зрения предпринимателя. Я же изложу мнение компании-инвестора на процесс, отмечу основные сложности и преимущества данного стиля взаимодействия.
Address.ua не был для нас первым проектом, в котором мы полностью или частично финансируем R&D, рассчитывая на дальнейшее успешное развитие проекта и получение дивидендов или выход из него. Более десяти лет назад мы начали работу над британским проектом Intellitracker.com (в 2011 году переименован в Cognesia), имея опцион на долю в бизнесе. А в этом году мы начали работу над проектом Smailex, в котором отвечаем за техническую реализацию проекта и полностью финансируем разработку. Можно сказать, что мы профессионалы в программировании на свой страх и риск.
Кроме разработки заказных проектов мы активно развиваем собственные и имеем большой опыт выведения проектов на хорошие финансовые и рейтинговые позиции (RABOTA.ua, TURNE.com.ua, IZUM.ua, poehalisnami.ua), что вносит дополнительную специфику в наши взаимоотношения с остальными участниками проекта. Наработанные знания и опыт позволяют нам принимать активное участие в обсуждении вопросов, которые выходят далеко за рамки процесса разработки и позволяют нам помогать проектам в таких аспектах бизнеса как финансы, маркетинг, построение продаж, разработка и модификация продуктов. Для себя мы даже определили стиль программирования и взаимодействия с заказчиком для достижения ЗАКАЗЧИКОМ максимального результата как бизнес-программирование, т.е. программирование, при котором выигрывает бизнес заказчика. Но описание нашего понимания бизнес - программирования не является темой данного поста.
Для начала о том, в каком случае программистским компаниям интересно работать по схеме coding for equity. Необходимые условия такого подхода: наличие у компании-разработчика свободных человеческих и материальных ресурсов и присутствие у руководства компании достаточной доли авантюризма. Нужно заметить, что чаще всего в качестве подрядчиков на разработку будут выбирать компании с опытом работы в данной сфере, что накладывает определенный отпечаток на взаимодействие с заказчиком.
Максим в своих постах достаточно четко описал технические особенности оформления прав владения для компаний-разработчиков и я не буду касаться данных формальных вопросов и больше внимания уделю фактическим проблемам взаимодействия и эффективности данной схемы.
Основные особенности построения процесса разработки
1. Определение ролей в проекте. Возможно, это в большей степени проблема X-tend Software Development как части X-tend Group. У наших порграммистов огромный опыт активного участия в разработке успешных проектов-лидеров. Набив шишки в одном проекте очень сложно повторять те же ошибки в следующем, даже если «тебе до этого нет дела», т.е. не ты определяешь что и как должно быть сделано. При этом такие чувства испытывают не только руководители программисткой фирмы, но и сами разработчики. Видимые нами «ошибки» могут быть как на уровне не правильно определенном продукте для продажи, так и на уровне мелких неточностей в верстке или деталях функционала, предлагаемом заказчиком.
Разработчик в любом случае всего лишь исполнитель и должен в первую очередь быть сосредоточен на выполнении своих прямых обязанностей. Консультации по остальным аспектам бизнеса с компанией разработчиком или некоторыми специалистами такой компании – это абсолютно другая роль и ее нужно по возможности отделить от роли разработчика. Желательно даже проводить совещания по «левым» темам отдельно от обсуждения текущего состояния разработки
2. Время обсуждения и время реализации. В принципе эта проблема свойственна любой разработке, в рассматриваемом нами случае она просто становится более явной.
При любой разработке есть время демократии, когда все (?) могут высказывать свои предложения и время диктатуры, когда руководящий орган принимает решение что и как делать и все остальные должны просто выполнять поставленные задачи. В случае coding for equity (если разработчики знают о схеме финансирования проекта) сама атмосфера развития проекта предполагает большую демократию, чем при программировании за конкретные деньги. Естественно, это требует большей диктатуры при выполнении принятых решений. Легко сказать, но очень сложно применить для своих любимых, свободолюбивых, дефицитных программистов!
3. Невозможность точной оценки проекта на стадии принятия решения. Это факт, не стоит его даже обсуждать. В очень многих проектах сейчас нет точного ТЗ, а при схеме coding for equity это проявляется еще более явно. Нужно программировать идеи и на вопрос выгодно ли это исполнителю (фирме-разработчику) нужно отвечать на основании предыдущего опыта, знании партнера-заказчика и других неформализуемых величин. Суть стартапа заключается в высокой динамике внедрения, поэтому принимать решение нужно достаточно быстро. В итоге все сводится к решениям типа «нравится - не нравится, верю -не верю».
4. Компромисс между желанием заказчика сделать все и желанием разработчика сделать минимум. Этот вопрос вытекает из предыдущего пункта. Не все может быть определено в ТЗ (если оно вообще есть), исполнитель тратит конкретные деньги при увеличении трудоемкости и необходимо действительно искать компромисс. В связи с этим возникает вопрос о совместимости основного заказчика и разработчика, т.е. вопрос взаимоотношений между конкретными людьми. Вопрос очень непростой и лучше подумать «смогу ли я сработаться с Васей» на берегу, причем обеим сторонам.
Комментариев нет:
Отправить комментарий