Уже написано множество статей на тему того, как быстро осуществлять запуск проектов. Сделайте простейшую версию которая будет показывать самую суть проекта и запускайте — говорят многие люди, имеющие опыт. И я с этим абсолютно согласен. Однако, не все проекты удается делать в таком динамичном формате. Вот о таких случаях хочется изложить некоторые свои мысли.
Все ниже написанное касается проектов, которые изначально не ищут инвесторов и их путь начинается не с презентаций и бизнес-планов, а с покупки домена и двух разработчиков. В свою очередь это не означает полного отсутствия планирования и бизнес-анализа.
Итак, у вас есть идея, хорошая такая идея, обдуманная, перспективная. Однако вы еще точно не знаете как именно она будет приносить доход. Можно сделать платные подписки, или продавать услугу “поштучно” или брать единоразовый платеж за регистрацию. Моделей монетизации кажется не много, какая-нибудь да сработает.
И вот она ошибка, которая даст о себе знать очень не скоро. Более того, иногда кажется что этой ошибки и нет вовсе — пользователи покупают, только как-то мало, на месяц подписались и все. Может быть продукт плохой? Скорее всего нет.
Дело в том ошибочном мнении в начале проекта — главное сделать, а продавать потом маркетологи будут. Если вы создаете продукт или услугу, которую изначально собираетесь продавать, нужно подумать о следующих вещах:
- Какой минимальный функционал можно продать?
- Что из этого можно сделать быстрее всего без потери качества?
- Сколько мы за это возьмем?
Ответить на эти вопросы довольно просто, потому что оценить 1-2 фичи гораздо проще, чем в конце прикидывать сколько будет стоить вся услуга в комплексе. Во-вторых необходимо как можно быстрее войти на рынок. Только он сможет вам показать наиболее эффективные пути развития сервиса в дальнейшем.
Казалось бы простые моменты, но они не редко забываются на фоне глобальных технологических задач, планов по развитию и стремлению сделать идеальный проект.
Причем делать это не обязательно в самом начале. Как только появилась какая-то масса функционала нужно просто выбрать тот, который можно предложить пользователю и запустить такой мини-сервис.
Наверняка многие из вас подумают: “Вот опять костыли городить”. Да, иногда это сопровождается не очень красивыми решениями. Однако, запуская такие небольшие части проекта вы избавите себя от проблемы жирных дедлайнов. Когда уже 4-5 месяцев идет разработка, но для того, чтобы выкатить то, что требуется нужно еще 3. И опять же, если проектировать архитектуру с учетом этого момента, то разработчики не очень сильно будут горевать по поводу говнокода.
Все вышесказанное по сути раскрывает мысль о том, что нужно запускаться как можно быстрее. Следующая проблема, которая похожа на предыдущую, только выражена больше в техническом плане.
Мы не знаем, что мы хотим получить в результате
Очень странно, как это так? А вот бывает и такое. Ваша идея весьма конкретна, однако как только она развивается в вашей голове, появляется множество ответвлений и все они кажутся очень клевыми и полезными. При этом суть почти не меняется. И тогда наступают периоды, когда одно направление получает больший приоритет, другое меньший и наоборот. В итоге всей этой кутерьмы мы получаем большую кучу сырого функционала, который дорабатывать долго, а продавать стыдно.
Решение так же во многом общее — берем то, что работает и пытаемся продать. Если хоть немного идет — развиваем, если нет — прекращаем разработку.
Скорее всего получится очень неоднозначная ситуация. Могут быть такие части проекта, которые нельзя бросать, потому что они являются фундаментальными и их необходимо сделать хорошо. И вот тут запуск мини-сервиса, собранного из кучи уже готовых частей даст вам время, чтобы комфортно и без спешки закончить важные вещи, не жертвуя качеством.
Этот же способ можно использовать менеджерам проектов, чтобы не нагнетать обстановку и не давить на разработчиков.
- Определяем список всех возможностей системы
- Выбираем те, которые можно продать
- Оставляем только готовые или требующие минимальных усилий для завершения
- Завершаем их и запускаем
Таким образом можно выходить из кризисов, когда все сроки вышли, а проект в непонятном состоянии. Очевидно, что такие экстренные релизы не должны занимать больше недели. Но в эту неделю нужно переключить все силы, а потом спокойно продолжать основную разработку.
И последняя проблема, о которой хотелось бы сказать
Сроки и инновации
Если ваш проект не состоит только из типовых решений, а предполагает некоторые исследования, то часто вы не сможете оценить точные сроки, а назначенные будут сорваны. Это происходит потому что нельзя точно определить сколько времени займет решение задачи, с которой команда ранее не сталкивалась или имела дело только частично.
Этот момент очень важно учитывать иначе можно потеряться в вопросах “когда?” и “почему?”
К сожалению еще не удалось найти какой-то системный подход к решению этой проблемы, который работал бы в каждом случае. И пока в наших проектах мы используем следующую методику.
Задается небольшой отрезок времени, скажем 1 день. Этими промежутками измеряется прогресс. Все начинается с того, что появляется вопрос “как решить задачу?” и далее строится цепочка таких “как?”. Рано или поздно, приходим к конечному решению. На всем пути поиска решения мы ставим время на появляющиеся задачи. Но без глобального дедлайна.
И так до тех пор, пока не будет четко определено сколько потребуется приложить усилий. Разумеется если прогресс приостановился, то производится анализ всего, что удалось решить и понять. Выявляются причины застоя и варианты продолжения исследования.
Получилось возможно немного сумбурно, поэтому подведу краткий итог.
Если у вас есть идея и вы решили её реализовать, то прежде чем окунетесь в проектирование, дизайн и программирование подумайте над следующими вопросами.
Монетизация
Вы собираетесь продавать. Это возможно не основная цель, но тем не менее важная составляющая. Поэтому решите, что конкретно вы сможете продать через месяц. А также подумайте о том, в каком формате вы будете это преподносить. Такие эксперименты лучше ставить как можно быстрее. Время вы точно сэкономите.
Идеал VS релизы
Разрабатывайте качественный продукт, иначе вы не почувствуете радости от проекта. Однако примите тот факт, что небольшие релизы с неэффективными или некрасивыми решениями позволят вам выиграть существенное кол-во времени на разработку основного продукта.
С ходу все сделать не получится, в процессе будет много корректировок разного характера. Если вы берете большой срок, и хотите к нему предоставить результат, то с большой долей вероятности вы не уложитесь. Потому что погрязнете в рефакторингах, желании что-то переписать и тп. Это произойдет в любом случае. Естественная эволюция наверное любого проекта. Но если понимать это и периодически делать “грязные” релизы, то основная разработка не будет похожа на сплошной возврат технических долгов и увязание в трясине дедлайнов.
Оценка времени на решение новых задач
Разделите весь пул задач на типовые, которые легко оценить и на исследовательские. Это избавит от ряда проблем с менеджментом. Дедлайны будут соблюдаться лучше, а разработчики будут довольны тем, что им дают решать интересные задачи и не торопят с результатами.
Все это является следствием личного опыта и отражает многие вещи, о которых пишут в книгах про стартапы. Но как показала практика, есть моменты, которые нужно прочувствовать, чтобы понимать их значимость. И вышесказанное описывает не только то, с чего стоит начинать проект, но и как можно его спасти, если описанные проблемы уже успели проявиться.
Автор: zarincheg
