Три недели назад мы выступали на коференции RockIT Conf, которая прошла в Таллине в формате баркемпа. На RockIT технические доклады сменялись выступлением рок-команд, в кулуарах царила неформальная атмосфера. Событие прошло в два дня — первый был стопроцентно боевой, на второй народ разошелся и было немного кисло. Организаторы обещали провести следующий ивент в Питере и учесть ошибки первого RockIT.

Мы выступили с рассказом о том, как быстро запустить сложный проект, перспективы которого можно оценить только по реакции публики. Мы сторонники реального фидбека, а не экспертных заключений. Доклад был посвящен тому, как весной 2012 года запускался sociate.ru — проект для автоматизированного размещения рекламных сообщений в сообществах ВКонтакте.

Многое из того, что написано ниже, можно смело вложить в уста Капитана. Да, это действительно так. Но! Я сам из технарей и сам знаю, как часто мы увлекаемся какой-то технической фитюлькой, крутым рефакторингом или внедрением новых технологий. В 90% случаев пользователь об этом не узнает, особенно, если проект новый.

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

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

Первый и, наверное, главный тезис — проект должен работать с максимально ранней стадии. Не обязательно выкладывать его в паблик. В мае 2012 года Сошиэйт открылся только для друзей и месяц проработал в таком режиме. Вряд ли это был лучший опыт в их жизни, но благодаря трудностям, которые преодолели наши друзья, первые реальные пользователи остались довольны сервисом в момент публичного открытия.
Лучший вариант — когда вы сами пользователь проекта, хотя бы в какой-то степени. Если нет необходимости использовать свой проект, обязательно найдите реального пользователя, чтобы не было вот так вот.

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

Некоторое время назад был популярен термин «mashup», означающий солянку технологий, рождающую новые ценности. Сейчас конечный результат на миксе гуглокарт и, к примеру, википедии можно встретить редко, перегорело. Но для технической стороны — это максимально актуально. Гитхаб, стековерфлоу, гугл и поехали!

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

Именно так мы начали работу над Сошиэйтом, параллельно развивая buruki.ru, это был такой бутстрап внутри компании. За год с небольшим мы доросли до самостоятельного проекта, но уже на старте багаж необходимого функционала был серьезный — биллинг, работа с большим набором внешних API, сложный бекэнд и развитая админка.
Если бы все это пилилось с нуля, только под наши нужды (было бы очень специализированным и на 100% отвечало нашим требованиям), то через полтора месяца у нас был бы не готовый проект, а развитой трекер, отличный гит флоу и долгая дорога до результата.

Все веб-студии имеют свою CMS, безусловно лучшую, безусловно родную. И на ней они делают свои сайты. Запуск проекта, если важен результат, а не процесс, — не время для новых технологий. Берите то, что хорошо знаете, то в чем разбираются ваши коллеги и то, с чем легко будет взлетать. В нашем случае — это Django, Python и их инфраструктура. Инфраструктура — это пожалуй, самое важное. Чтобы опять же не писать лишнего.

Для всех критических операций лучше брать проверенные технологии, даже если за них нужно заплатить немного денег. Нам важен результат. Мы могли сами пробиваться через спам-фильтры, gray-листы и другое, но это время лучше потратить на довольных пользователей, а не на бездушных почтовых роботов. Используйте хорошие сторонние решения — они дают время подумать о важном.

С первого дня нам нужен был биллинг, пользователи размещают рекламу через sociate, а она не бесплатна. Для запуска мы выбрали максимальное удобство пользователей, даже если это сопряжено с некоторой (не очень комфортной) комиссией. Используя платежный агрегатор вы экономите на всем — на времени подключения, на времени интеграции (обычно саппорт агрегатора отзывчивый, и есть библиотеки под популярные языки), на времени сбора разных сервисов в одном месте. Уже позже можно подключть несколько самых востребованных способов напрямую, снизив затраты на комиссию

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

Очень часто технарю для реализации идеи не хватает человека с чуством прекрасного. Сделать бекэнд, обычно, не так сложно, как фронтэнд. Бутстрап сотоварищи, наконец-то решают эту проблему, а в сочетании с темизацией (например, wrapbootstrap.com/) вы можете добиться уникального дизайна минимумом усилий.

Наверное, самый спорный и самый жестокий вопрос. Но, похоже, лучше пользователя никто не знает, что ему нужно. Он видит мир немного по-другому, нежели вы. Выкатывайте функционал чаще, держите связь с пользователем, причем максимально близкую! Никто не будет писать вам баг-репорты или сообщать об опечатках используя CTRL+ENTER, пользователю нужно простое средство обратной связи. Для buruki.ru — это Olark, установленный на каждой странице. Для sociate.ru — это суперактивная группа в ВК, в которой (бонус-трек) пользователи сами помогают друг другу.

То, что написано выше, по научному называется MVP — Minimum Viable Product, проект с минимально достаточной функциональностью. Мы пришли к этому самостоятельно и призываем вас запускать проекты, а не держать их в дальних уголках жестких дисков!

В комментариях предлагаем обсудить плюсы и минусы разных подходов, желательно из опыта. А начнем мы сами.

Автор: good_service

Источник