Как быстро запустить сложный проект?


    Три недели назад мы выступали на коференции 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, проект с минимально достаточной функциональностью. Мы пришли к этому самостоятельно и призываем вас запускать проекты, а не держать их в дальних уголках жестких дисков!

    В комментариях предлагаем обсудить плюсы и минусы разных подходов, желательно из опыта. А начнем мы сами.
    Буруки
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 21

      +3
      не плохо изложено! Новичкам стоит прочитать
        +2
        Причем, не новичкам в смысле разработки, а в смысле старта новых проектов. Опытный разработчик, привыкший к размеренному течению жизни в большой компании может неправильно расставить приоритеты, когда результат должен быть важнее процесса.
          0
          Ну вообще речь про стартапы, так что я имел ввиду новичков — стартаперов!
        +14
        Из негативного опыта долгого запуска.

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

        Но:
        1. Разработчики выдохлись, они видели результат только на dev машинах и отчеты тестеров.
        2. За время разработки ландшафт изменился и изначально привлекательная идея была разгромлена несколькими уже запущенными проектами
        3. Получивший монстр мог всё, но большинство из функций было нужно только воображению менеджеров.

        Такие дела.
          +1
          Коль скоро вы говорите сейчас у вас получился пример успешного запуска проекта — он хоть какие-то деньги уже приносит, или статус «Beta» ещё будет висеть неопределенно долгий срок? Все-таки весной запустились — уже полгода прошло практически. Т.е. разработка вышла 1.5 месяца… а сколько это по деньгам получилось? И как искали разработчика, который все это так здорово за 1.5 месяца замутил? И в конце-концов, куда вы дели половину того несчастного разработчика, кто не дожил до момента сдачи прототипа, заказчику?
            +4
            Половина разработчика — это я, и я не несчастный ;-). Целый разработчик — это друг со школы и университета, с которым мы до этого работали над буруками, теперь он руководит разработкой sociate.ru

            Проект запустился полтора года назад, в 2012 году и он полностью обеспечивает себя со второго месяца работы. Я не говорю,, что наш опыт можно повторить и со 100% вероятностью запуск будет успешен, вариантов масса, мы лишь предлагаем «один из»
          0
          Кратко статью можно охарактеризовать известной фразой: «Лучшее, враг хорошему».
            0
            да, можно и так.
            0
            Вопрос. А почему питон и джанго? Выбирали язык и платформу под требования проекта или просто изначально оба уже имели большой опыт разработке на данной платформе?
              0
              Второй вопрос вдогонку. Вы говорите что лучше брать порой готовые решения, даже если может потребоваться немного заплатить за них. Если не коммерческая тайна, можете показать содержимое requirements.txt(какие библиотеки питона и джанги брали готовые)?
                0
                Питон и джанго потому, что мы их знали. Не теряли время на изучение. req.txt — весь бесплатный, мы платили только за амазон, рассылку смс (транзакционные, а не спамные ;-)) и сервера помощнее, чтобы не заниматься оптимизацией кода в первые дни.
                  +1
                  Просто любопытно какой набор библиотек использовали. ;-)
                  Нагрузка сейчас(и в пиковые дни) какая в сутках?
                  Амазон ради s3 и выноса туда статики?

                  Администрирование сервера своими силами осуществляете или привлекали дополнительные человеческие ресурсы? Сервер выделенный или в облаках? :)
                    +1
                    Всё сами.

                    Библиотеки — только по надобности, ничего лишнего и ради украшательства. Сам список не будет полезен публике, он решает именно наши задачи
                      +1
                      Амазон — да, ради s3 и ses.
                      И то и другое вполне себя оправдывает.

                      Нагрузка на фронтенд мало что скажет, т.к. основная часть ресурсов задействуется на бэкенде.
                0
                Слайды, конечно, эмоциональны, да…
                  0
                  промахнулся
                    +1
                    Третий вопрос в этой теме. :)
                    Проектирование, тз, цели, расписание этапов(альфа, бэта, ...).
                    Как много времени вы потратили на проектирование и как много на чисто техническую сторону?
                    Я про альфа версию, когда вы ещё не видели готового продукта с мнениями пользователей.

                    Четвёртый. Продвижение продукта как я понимаю было сарафанным радио? Или другие способы использовали?
                      +1
                      Проетировали из головы, этап один — делать.

                      1.5 месяца — только разработка.

                      Продвижение шло за счет сарафана и партнерской программы.
                      +1
                      Согласен с каждым словом автора статьи. Лично я всегда был приверженцем MVP. Пару лет назад работали с одним заказчиком из солнечной Канады — ему надо было сделать что-то вроде сервиса поиска попутчиков («Такого-то числа еду из Торонто в Оттаву, есть 3 свободных места»). Я ему предлагал много раз выпустить сервис с минимальным набором функций и изучить отзывы пользователей, а, затем, избрать дальнейший вектор развития. Но… Он захотел кучу невразумительного функционала, который, от силы, мог бы пригодится 10 пользователям из 1000, плюс к этому, за неделю до предполагаемого релиза, ВНЕЗАПНО решил поменять дизайн. В результате, мы свою работу сделали, получили за это деньги, а сервис так и умер не родившись, т.к., по сути, был никому не нужен в том виде, в котором он получился.
                        +1
                        Если работа идет на заказчика — максимум можно советовать ему и не принимать близко к сердцу странные на ваш взгляд вещи, все-таки он платит деньги. А если речь о собственном проекте, то мы за МВП
                          0
                          Основная проблема того проекта была в том, что вещи были объективно странные :) Плюс, невнятная модель монетизации: пользователи должны были оплачивать подписку, которая, по сути, ничего им не давала, кроме расширения функционала личного кабинета — возможность «зафрендить» пользователя, добавить объявление в избранное. Т.е. всё то, что должно быть бесплатным и по-умолчанию доступным любому зарегистрированному пользователю.

                      Only users with full accounts can post comments. Log in, please.