1. Сколько стоит создать CPA?
На примере КМА допустим, со своим движком...знакомый по просьбе оставлял запрос на фрилансе, сначала предложили за 450 тысяч рублей сделать за 3-5 месяцев, после некоторого молчания те же люди предложили сделать за 250 тысяч. Какая все же разумная цена на ваш взгляд? И срок.
2. Реально создать CPA мирового уровня? Работающую не по конкретной стране, а по всему миру? Соединяющую вебмастеров и предпринимателей всего мира. Насколько это возможно как программно так и юридически? Сколько такое может обойтись? Мы готовы начинать с малого, но предпочитаем начинать с максимально возможного.
Какой размер %?
Ровно такой, чтобы каждый получил порядком больше, чем вложенный им объём труда стоит на рынке.
Мы хотим, чтобы людям нравилось с нами сотрудничать.
На каком языке писать CPA? - Мы не знаем, на каком лучше на том и надо, кстати, помогите определиться на каком все таки лучше...
Разные специализации, разные люди, это верно, можно каждому %, можно каждого нанять, можно взвесить с кем и как лучше договориться. Во всем этом проблемы нет.
Если заключить договор, то гарантированный журавль более серьезная добыча, нежели синица, так сказать инвестиции в будущее
Так сказать, раздать работу другим - не особо сложная работа
Сначала от 100 тысяч за готовый проект, потом пол миллиона за "демонстрационную версию", другой зп указывает стоимостью самого проекта. В общем спасибо, помогли.
от чего же? Человек может поднять кеш не обязательно с тем, что как-то связано с программированием? Это тоже самое, что автослесарь скажет, откуда у вас деньги на подъёмник, если вы мало понимаете в устройстве автомобиля? Вам не кажется это несколько глупым? Да, я постепенно черпаю что-то новое из неизвестной для меня области, благодаря вам в том числе, спасибо.
кстати, обычно когда кто то готов "выкинуть" деньги то желающий "работать" много, от чего с вами не так? Очень честный и совестливый человек?:)
Нагрузку надо выяснять в процессе, я не могу ее спрогнозировать и это уже вроде как выяснилось.
то что разные сервера понимаю, а вот то что от нагрузки зависит программное обеспечение честно говоря не уложилось в моей голове :) аналогию с фейсбуком я не очень понял, от чего это нельзя залипить фейсбук на плюшевый сервер, если нагрузка будет 1 клик в сутки?))
Это тоже самое, что автослесарь скажет, откуда у вас деньги на подъёмник, если вы мало понимаете в устройстве автомобиляИ автослесарь будет чертовски прав. Только не "откуда деньги", а "не надо открывать свою автостанцию если не понимаешь как устроен авто".
Вы невнимательно читаете текст, перечитывайте. Не я обсуждал и текст как раз о том, как люди берут цены с потолка.
Аналогию с фейсбуком я не очень понял, от чего это нельзя залипить фейсбук на плюшевый сервер, если нагрузка будет 1 клик в сутки
Вот буквально пара примеров из реальных документов, по которым надо было как-то оценивать объём работ и подписываться:
«Система должна обладать интуитивно-понятным графическим пользовательским интерфейсом», — в переводе на русский, это, скорее всего, означает что-то вроде: «Кроме консоли нужен GUI на русском и с большим количеством пояснений, потому что комплексом будет управлять секретарша». Скорее всего. Потому что может оказаться, что у заказчика есть свои представления об интуиции, и он будет настаивать именно на них. Но чаще всего эта фраза типовая для документации и, в целом, не очень опасная.
«Система должна обеспечивать простую и гибкую настройку прав доступа пользователя системы», — это уже на порядок хуже. Здесь не описано, какие бывают права, а разница в деталях сетевых ролей может повлиять на архитектуру. И, соответственно, на оборудование, которое нужно в проект.
Один раз встретилось после детального описания системы документооборота такое: «Срок хранения информации должен быть настраиваемым по периоду», — попробуйте угадать, что заказчик имел в виду. Вас интересует для начала, о какой именно информации речь и где она будет храниться. С равным успехом это может оказаться как обычная фраза о том, что должен быть доступен архив записей (что очень просто), так и то, что это должно быть резервное копирование на отдельную площадку.
Самая большая ошибка — предполагать, что проект пойдёт, как задумано.
Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений.
Начиная движение, проект сталкивается с сопротивлением окружающей среды. Дизайнер забывает учесть сложный случай. Клиенту не нравится дизайн. Программистов тормозит проблема в реализации. Кто-то заболевает. У кого-то ломается компьютер. Можно перечислять возможные сюрпризы, но в каждом проекте будут свои.
Проект движется и колеблется вокруг идеальной линии, и, возможно, придёт в совсем другую точку Б’:
Закон о потерях: нельзя реализовать задуманный проект за 100% времени, 100% денег, со 100%-й функциональностью и без потери качества. При отклонении от курса придётся чем-то пожертвовать. Чем именно — жизненный выбор.
Репутация зарабатывается годами, а теряется за один день. Поэтому жертвовать качеством — не вариант.
Фиксируем срок. Если команда не успевает доделать проект вовремя, обычное решение — сдвинуть срок запуска. Но время — невосполнимый ресурс, недаром deadline происходит от слова «смерть». За отпущенное нам время мы успеем только то, что успеем. Чтобы не уходить в мрачные аналогии, мы сравниваем запуск проекта с наступлением Нового года. Отодвинуть его нельзя, даже если ты не успел купить подарки. Мы не сдвигаем срок.
Фиксируем бюджет. Когда проблемы в проекте решают деньгами, это означает одно из двух: либо оплачивают дополнительное время, либо расширяют команду. Первое не подходит. А увеличение команды нередко снижает управляемость проекта и только усугубляет его проблемы.
Флексим. Когда жертвовать сроком, бюджетом и качеством нельзя, методом исключения приходим к одному: жертвуем функциями, «флексим». Отрезаем то, что не успеваем сделать.
Этот вариант — большая удача:
Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой
Продукт как можно раньше начинает работать, выполнять своё полезное действие, зарабатывать деньги, расширять аудиторию.
Чем больше функций, тем больше их пересечений, а значит мест для ошибки. Поэтому отказ от функции помогает уменьшить количество узких мест и повысить качество первой версии.
Открытый вовремя продукт помогает быстрее узнать правду о продукте: изучить мнение пользователей и проверить гипотезы. Возможно, убранная функция никогда и не понадобится, и силы будет лучше потратить на другую.
Новый продукт с небольшим числом функций легче объяснить пользователям. Только мы знаем о том, что часть идей не реализовали. Пользователям они бы только добавили сложностей.
Когда отложенная функция добавится во второй версии, будет кого ей порадовать. Кроме того, новая функция — это информационный повод, лишняя причина рассказать о продукте.
Часть клиентов соглашаются с этим подходом, часть — нет. Но даже если клиент согласен, это не значит, что проблем не возникнет. Мы честно предупреждаем о подводных камнях.
Флексить страшно
Несмотря на плюсы, звучит устрашающе: в запущенном с нами продукте оказывается меньше функций, чем изначально планировалось. Мы понимаем, что наш подход к ведению проектов может выглядеть как шарлатанство в глазах некоторых клиентов.
Любой человек, если заказывает ящик апельсинов, а потом точно в срок получает отличные апельсины, но только пол-ящика, почувствует себя обманутым. Но доставка апельсинов — стандартизованная процедура с отлаженной логистикой. Риски предсказуемы и сразу заложены в цену.
С проектами иначе. У Колумба в экспедиции были бунты, болезни, поломки и штормы. И в результате он открыл вовсе не ту страну, на путешествие в которую собирал деньги.
Проект гораздо больше похож на экспедицию, чем на доставку апельсинов.
Флексить больно
В продукте будет меньше функций, чем изначально планировалось
Одно дело решить делать зарядку по утрам, другое дело — делать её. Когда приходит время отказаться от какой-то задумки, больно всем. Дизайнерам больно, потому что они придумали классную фишку, но её не будет в продукте. Разработчикам обидно, потому что они потратили силы на отладку функции, а её пришлось убрать. Но больнее всех клиенту, который придумал проект и имел от него свои ожидания.
Не все готовы к этой боли.
Клиент — предприниматель
Больнее всех — клиенту
Мы работаем напрямую с предпринимателем — человеком, который затеял проект и принимает в нём все решения. Обычно это директор компании. Мы привлекаем его с самой первой встречи, ведь самое главное говорится в начале.
Чтобы сделать проект без директора или с минимальным его участием, нужно либо лишить его права голоса (что звучит неправдоподобно), либо попросить его делегировать задачу человеку, которому он полностью доверяет.
Опыт показывает, что если мы будем пытаться угодить нескольким «клиентам» одновременно, проект получится болезненным, а продукт — беззубым и компромиссным. Мы не сможем взяться за проект, в котором больше одного командира.
Результат — это пуск
Работаем с тем, кто принимает решения
Обычно дизайнеры отдают клиенту картинки.
Но большинство дизайнерских решений принимается на этапе разработки. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404-я ошибка при ширине экрана 2000 пикселей? Поскольку дизайнер не позаботился об организации этого этапа, а клиент не подозревает о проблемах, все решения достаются бесконтрольным программистам:
Дизайнер кладёт скриншоты в портфолио, а на реальный продукт без боли не взглянешь.
Раньше бюро пыталось осуществлять авторский контроль над разработкой через клиента:
Дизайн не заканчивается на картинках
Дизайнеры спамят клиента замечаниями о том, что продукт не похож на картинку. Клиент передаёт программистам. Программисты кладут в баг-трекер. Список проблем растёт быстрее, чем его успевают разгребать. Дизайнеры паникуют, запуск несколько раз откладывается, в конце концов клиент вынужден открыть сырой продукт.
Чтобы повысить эффективность коммуникации в проекте, нужно оставить клиенту принятие ключевых решений, а общение о поведении кнопки на форме обратной связи вести напрямую с программистами:
Авторский контроль через клиента не работает
Решения в любом проекте принимаются постоянно. Ни подписание ТЗ, ни утверждение чертежа не способны зафиксировать конструкцию будущего самолёта. Если вы создаёте пользовательский интерфейс, большая часть решений во время его разработки будут дизайнерскими — кто бы их ни принимал. Лучше, чтобы решения принимали дизайнеры совместно с клиентом, а затем напрямую, через технического директора, транслировали их в разработку.
Дизайнерское управление разработкой гарантирует, что программисты будут работать не на ТЗ и баг-трекер, а на проект. Перед началом проекта мы тестируем разработчиков. В проекте — руководим ими. Это может не подойти вашему техническому директору.
Регулярные пуски
Руководим вашей командой разработки. Перед началом тестируем её. Вашему техническому директору это может не подойти
Предположим, в продукте задумано четыре функции, а разработка оценена в четыре месяца. Тогда, теоретически, через четыре месяца откроются эти четыре функции:
Но это теоретически. В жизни длинные проекты не идут по плану. Сначала дедлайн кажется бесконечно далёким и все расслабляются. К концу все устают от труда без видимого результата и опускают руки. Работа требует длительных вложений без информации о том, правильно ли приложена сила.
Мы разбиваем большой проект на короткие итерации. Результат каждой — пуск полезной функциональности:
Так каждая отдельная функция начнёт приносить аудиторию и доход гораздо раньше, а если в процессе работы мы поймём, что первоначальный набор функций и план были неверными, сможем скорректировать работу.
Ритмичные пуски держат команду в тонусе: во-первых, пуск всегда вот-вот, и расслабляться некогда; во-вторых, ничто так не вдохновляет команду, как объявление «Мы открылись».
Никаких сюрпризов
Разбиваем большой проект на короткие итерации с регулярными пусками
Как идёт проект по ФФФ? В самом начале мы пишем понедельный план от начала работы до пуска. Для каждой недели известна работа и результат.
За пуск проекта отвечает ведущий дизайнер: он понимает задачу, руководит работой дизайнеров, проводит презентации, согласовывает замечания с клиентом, передаёт задачи разработчикам и проверяет, чтобы всё было сделано вовремя. Если на очередной неделе что-то пошло не так и есть угроза сроку, вероятно, придётся флексить.
Самый страшный грех ведущего дизайнера — принести клиенту в последний день половину проекта и спокойно сказать «мы успели только это». Сколько бы ни обсуждался флекс перед началом проекта, любой клиент будет возмущён, если его просто поставят перед фактом, что чего-то не будет.
Когда возникает угроза сроку, приходится принимать решение об упрощении дизайна или ограничении функциональности. Ведущий дизайнер предлагает решение, клиент принимает его или предлагает своё. Достижение договорённости о «флексе» — наша взаимная ответственность с клиентом.
Вопросы
Решение о конкретном способе флекса принимаем вместе с клиентом
Часто ли реально приходится жертвовать функциональностью в проектах?
Всегда. Флекс — это не особый инструмент на случай редких исключительных ситуаций. Это часть любого проекта. Всегда что-то приходится корректировать по ходу: где-то упрощаем дизайн, где-то заменяем одно решение на другое, а где-то отрезаем функцию целиком.
Нельзя ли заложить достаточно времени, чтобы точно всё успеть?
При планировании мы берём небольшой запас, руководствуясь принципом «не впритык». Но жизнь преподносит сюрпризы. Сколько времени ни закладывай, гарантии «точно всё успеть» это не даст.
Если продукт открылся в срок, но без части функций, будут ли доделаны отложенные функции после пуска?
Возможно, по итогам пуска будет принято решение делать совсем не то, что планировалось изначально — сила подхода в том, что он позволяет своевременно скорректировать курс. Мы будем рады, если вы решите продолжить с нами работу над продуктом в новой итерации. Эта работа оценивается дополнительно.
Разве выпустить продукт без половины задуманных функций — это не «жертвовать качеством»?
В первом Айфоне не было диктофона, видео и буфера обмена (которые уже были даже в обычных Нокиях). Но то, что было, было сделано на отлично. Мы за такое.
Почему бы не реализовать ещё одну полезную функцию, вместо того чтобы отлаживать плавность анимации?
Мы сами за пользу. Но когда мы вместе с клиентом выбрали, какую функцию реализовать, надо сделать это хорошо. Тормоза, глюки и опечатки создают впечатление ненадёжного продукта. Поэтому мы считаем, что лучше отладить одну функцию, чем выпустить две сырые. И всегда закладываем в план существенное время на полировку.
Неужели в продуктах, выпущенных с вашим участием, не бывает проблем с качеством?
У нас случаются проколы. Это самая большая боль. Куда большая, чем недостаток фич.
Выходит, вы как американские юристы — тупо берёте деньги за время?
Нет. Мы отвечаем за выход продукта в срок и за то, что он будет решать поставленную задачу, даже если конкретное решение будет отличаться от задуманного изначально.
Правильно ли мы поняли, что по вашим принципам вы обещаете больше, а делаете меньше?
Нет, ровно наоборот. Мы сразу говорим, что всё сделать не получится и чем-то придётся пожертвовать. Если вдруг получится успеть всё, что задумали, пусть это станет приятным сюрпризом. Лучше недообещать.
Продукт как можно раньше начинает работать, выполнять своё полезное действие, зарабатывать деньги, расширять аудиторию.
Чем больше функций, тем больше их пересечений, а значит мест для ошибки. Поэтому отказ от функции помогает уменьшить количество узких мест и повысить качество первой версии.
Открытый вовремя продукт помогает быстрее узнать правду о продукте: изучить мнение пользователей и проверить гипотезы. Возможно, убранная функция никогда и не понадобится, и силы будет лучше потратить на другую.
Новый продукт с небольшим числом функций легче объяснить пользователям. Только мы знаем о том, что часть идей не реализовали. Пользователям они бы только добавили сложностей.
Когда отложенная функция добавится во второй версии, будет кого ей порадовать. Кроме того, новая функция — это информационный повод, лишняя причина рассказать о продукте.
Ценность денег невелика
раунд при наличии MVP можно поднять за 10-15% легко.
Вдобавок если у Вас постановка вопроса в стиле "есть NNN денег, хочу что бы люди создали CPA сеть" - оно не взлетит в любом случае, даже если Вы будете искать людей не на % а на рыночный фикс.
Что бы проект взлетел - у него должны быть либо явно понятные плюсы от существующих
либо ОЧЕНЬ много денег на маркетинг.
плохо сочетаются вместе, НЛ.
Сразу возникает ощущение что любой твой шаг будут проверять и обосновывать - смысл идти работать с людьми которые тебе не доверяют.
b) Вы путаете % прибыли и % компании. Доля в компании является средством удержания ключевых исполнителей (e.g проработай у нас 3 года без нареканий и получишь 10% компании).
c) В условиях подъема новых раундов - даже операционная окупаемость может наступить лет через 20, про полную окупаемость (возврат инвестиций) я вообще молчу. Uber, Amazon - все оцениваются в миллиарды и все операционно убыточны.
За % от проекта - очень плохая идея. Нужно просто нанять.
Проект может не взлететь.
А человек потеряет 2 года жизни, пока он будет жить на хлебе и воде.
Из ваших обмолвок я понял что у вас есть примерно полмиллиона рублей?
Этого достаточно чтобы сделать хороший демонстрационный образец (MVP) и попробовать поискать инвестиций.
Но этого недостаточно, чтобы получить рабочую систему.
СРА с минимумом функций на начальном этапе, никаких постбак (кстати если расскажите зачем он и как он применяется и какие полезные функции в себе несет буду рад), тех вебмастеров и рекламодателей что я буду привлекать на начальном этапе функции только пугают, поверьте, их даже слово оффер способно напугать, не говоря уже о ERC, CR, разных метриках и других отталкивающих их деталях, люди видят неясносность, создается иллюзия, что это все тяжело и лучше в это не лезть, а люди эти владеют существенным трафиком в своей стране, им лишь донести суть простым человеческим доступным для них текстом. Мне и пользователям на начальном этапе вполне достаточна система, показывающая количество кликов, заказов (подтвержденных, отклоненных (причины отклонения) ), холд, оплаченных заказов и выплат, все, базово. С дизайном и переводом полагаю помогут. Вывод на киви, вебмани (опять же смотря сколько стоит добавить вывод на вебмани я решу надо ли оно на старте).
Минимизация функций и расходов. Если рядом с оффером будет пост с возможностью публикации прям оттуда в соц.сети, паблики вк, страница инстаграма, возможностью публикации на отложенное время - то круто, но опять же, решение зависит от того во сколько обойдется такая функция.
Минимилизм, просто с возможностью протестировать возможные нагрузки и понять куда двигать дальше и двигать ли вообще, полагаю, для знающего немного толк и ТЗ здесь не нужно, чтобы дать примерную оценку того, что я хочу?
А еще, помимо оплаты за работу у вас будут приличные затраты на содержание серверов.
Убер, амазон - о гигантах и их окупаемости я понятия не имею и равняться на них на этом этапе просто бессмысленно, а вот начать с малого и стремиться ничего не мешает.Вы с одной стороны писали про 1000 трафика в сутки (кстати не понятно чего 1000 - лидов? успешных action? - в любом случае не много), но при этом пишите про "построить мировую сеть".
Неважно как назвать, да, вполне возможно путаю, имелось в виду, 80% чистой прибыли мои, 20% - рулевомуВы для начала с этим разберитесь, про формы собственности почитайте, про британское право, про ваши локальные отличия от него.
И да, давать % организатору, который верит, что проект может не взлететь, а значит, который не способен все проанализировать так, чтобы лишиться сомнений и обрести твердость - не то что бы даже неинтересно, а попросту опрометчиво.
поверьте, мне не нужно знать устройство автомобиля, чтобы владеть автосервисом и химический состав резины, чтобы построить и запустить шиномонтаж, мне даже не нужно уметь блестяще мыть автомобиль, чтобы открыть автомойку и я прекрасно понимаю, что лезть в сра или иную ит-сферу без знаний порядком сложнее, чем организовать выше обозначенные проекты.
Слизать простой готовый бизнес довольно легко если он перед тобой разложен по полкам, вот только сра бизнес не такой простой и передо мной по полкам не разложен.
У меня есть верные парикмахеры и пчеловоды, безработные, с мечтой иметь часть от собственной парикмахерской и пасеки и мне не нужно уметь ни стричь, ни добывать мед, чтобы увеличить свой капитал этими методами.
Вообще от Ваших постов веет аязом или бизнес молодостью.
Дерзайте, 3.5 млн не бог весть какие деньги, опыт по крайней мере получите.
Простых бизнесов - не бывает. Если какой-то бизнес кажется Вам простым - значит Вы нихрена о нем не знаете.
Что предлагаете, просто раздать бабки и сказать - делайте?
В стране полно людей без надежд, но с интеллектом, которые ох как будут рады иметь 20% от бизнеса не вкладывая в него и мало кто им такое предложит.
поверьте, мне не нужно знать устройство автомобиля, чтобы владеть автосервисом и химический состав резины, чтобы построить и запустить шиномонтаж, мне даже не нужно уметь блестяще мыть автомобиль, чтобы открыть автомойку
Зачем вы ему?
Это хоть и не дает гарантии, но приближает вас к реальному результату.
Допустим вы выгоните своего программиста, если что-то пойдет не так.
Знаете, что в первую очередь вам скажет следующий программист?
"Это говно нужно переписать с нуля".
И вот вы снова в начале пути.
Кто чем может помочь?
Советы, рекомендации, помощь в составлении ТЗ, разложить бизнес по полкам показав всю глубину, все расходы, бизнес план, и все остальное, что здесь необходимо
Мы хотим, чтобы людям нравилось с нами сотрудничать.
Мошенники лесом, деньги на руки никто не даст, расходными операциями будут заниматься доверенные лица
Это ну настолько каноническая фраза (опять же НЛ) что у меня прямо кипит.
Вакантно место организатора всего этого проекта, опять же, за постоянный % прибыли после полной окупаемости
Какой размер %?
Ровно такой, чтобы каждый получил порядком больше, чем вложенный им объём труда стоит на рынке.