Коллективный заказ разработок

Предлагаю идею.

Суть

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

Однако, реализовывать их по разным причинам я либо не собираюсь вообще, либо не собираюсь в ближайшее время. Например, потому что я уже занят реализацией одной из идей, либо это для меня неподъёмная задача.
Т.е. если коротко — у меня нет возможности инвестировать в реализацию свои время и усилия.
Однако, в таких случаях у меня обычно есть другой ресурс, который можно инвестировать — деньги.

Те же самые потребности могут возникать и у других таких же людей, а это значит, что на реализацию какого-то сервиса/программы все вместе все эти люди могут потратить ещё больше денег.

Т.о. вокруг некоторых потребностей будет собираться столько денег, за сколько найдётся и человек, который его реализует. При наступлении какой-то критической массы можно будет и на каком-нибудь free-lance.ru заказывать реализацию.

Подробности на примере

Потребность
Итак, у меня появляется потребность. Например, я хочу полноценную поддержку Perl'а в NetBeans. И я заплатил бы за соответствующий плагин от 1т.р. до 5т.р.

Расскажем о ней
Я иду на этот сервис и регистрирую потребность.
Для этого мне приходится указывать её точное место в иерархическом каталоге, где попутно мне показываются соседние потребности. Если я угляжу в них свою потребность, я просто присоединюсь к ней вместо того, чтобы регистрировать новую.

Опишем её по пунктам
Практически, я пишу ТЗ. По пунктам описываю всё, что мне нужно (подробности ниже).
Заодно я могу отметить некоторые из этих пунктов — минимум, за который я заплачу только 1т.р., среднее — 3т.р., а реализация всех пунктов подразумевает максимум — 5т.р.

Обозначим серьёзность намерений
Я вношу свои 1 или 5 т.р. на эту потребность. Если в течение указанного мной периода, на который я готов заморозить свои 5 т.р. ради реализации моей хотелки, не найдётся человека, который её реализует, либо цена не будет существенно снижена (об этом ниже), мне автоматически возвращаются мои деньги.
Впрочем, я и так могу забрать их в любой момент, если никто не приступил к работе.

Поделимся идеей с релевантной публикой
Я описываю свою идею в профильных сообществах (ru_perl, например), где находятся такие же, как я, люди, которые присоединяются к потребности в т.ч. своими деньгами.

Дополнение потребности
Другие люди с той же потребностью могут желать каких-то особенностей. Для этого они берут мой список пунктов ТЗ, убирают оттуда то, что им не нужно, и добавляют то, что нужно.
И так же как и я отмечают наборы пунктов: минимальный, средний, максимальный.

Формирование предложения исполнителям
В результате потенциальные исполнители, которые конечно же ходят по сайту в поисках работы, а так же люди с бирж типа free-lance.ru (куда можно автоматом постить заказы) видят следующее:
  • Задачу минимум — это задача, состоящая из минимального набора пунктов ТЗ, который кто-либо отмечал в этой потребности, список заказчиков (этот минимальный набор мог отметить не один заказчик, а несколько) и общую сумму, которую эти заказчики готовы выделить на этот минимум;
  • Задачу максимум — то же самое, но со всеми пунктами вместе — соответственно все заказчики и общая сумма;
  • Промежуточные варианты ТЗ.
Он отмечает, за какой набор пунктов он готов взяться за какую сумму.

Рынок
Когда потенциальных исполнителей больше одного, заказчики могу коллективно проголосовать, кому и на какой набор пунктов заказать разработку.

Опять же, когда потенциальных исполнителей больше одного, они могут соревноваться в цене друг с другом — а ля аукцион наоборот.

Ну и для каждого потенциального исполнителя должен быть рейтинг и комментарии заказчиков, который те могут оставлять только после успешной или неуспешной сделки.

Когда конечная цена меньше суммы денег, выделяемой изначально заказчиками, вклад каждого из них уменьшается так, чтобы за каждый покупаемый ими пункт ТЗ они платили поровну.

Сделка
После того, как заказчики выбрали исполнителя, их деньги замораживаются (они смогут их достать только если исполнитель не выполнит свой контракт в указанный им срок), а исполнитель приступает к работе.

Попутно должна быть возможность общения между исполнителем и заказчиками, а так же изменение ТЗ и сроков по согласию сторон.

После того, как исполнитель сделает свою работу, он предъявляет её заказчикам, которые принимают её или не принимают.
Если исполнитель не согласен с решением заказчиков, он может обратиться к администрации, которая будет проверять только соответствие проделанной работы пунктам ТЗ.

Если в результате сделка успешна, оговоренные замороженные деньги переводятся на счёт исполнителя, иначе — размораживаются для заказчиков.

Если после закрытия сделки остаются невыполненные пункты ТЗ, можно привлечь ещё одного исполнителя.

Монетизация

Очевидно, через небольшой процент со сделки.

2.0'ность

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

Поскольку исполнителем здесь может стать каждый, а не только большие (и не очень) софтверные компании, то и покрытие спроса будет более естественней, гибче и больше.


0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.