Vexor был разработан в Evrone, чтобы ускорить внутренние процессы. Потом продукт вырос, у него появились клиенты. Вместе с этим пришёл новый опыт. Мы решили сделать последний день нашего марафона вдохновляющим, поэтому делимся советами Александра Кириллова, нашего технического директора, которые он сформулировал во время работы над сервисом непрерывной интеграции (CI).
Это был продукт для наших внутренних DevOps-задач, но мы увидели в нём потенциал. Он получил не только выделенных разработчиков и менеджеров, но и дизайн-поддержку. Работа над Vexor помогла нам получить огромное количество хорошего, «боевого» опыта, который часто ждут клиенты. В том числе в пиаре, менеджменте продуктов.
Я собрал эти советы для молодых стартап-команд и инди-разработчиков, а также для всех разработчиков, которые работают в продуктовых компаниях.
Скорее всего, вы недооцениваете уровень задач, которые решает ваш продукт
Не стоит бояться сложных задач. Если есть возможность, с первого дня углубляйте свою экспертизу в технологиях, на которых построен ваш продукт. Читайте документации, статьи. Найдите open-source продукт, который похож на ваш, и изучите код. Сходите на конференцию и пообщайтесь с будущими конкурентами.
Не надо стесняться отсутствия экспертизы и того, что вы пока что не погружены в тему — это легко исправляется практикой. Всегда есть кто-то, кто знает, что делать. И он, возможно, готов поделиться советом.
Не бойтесь конкурентов, бойтесь не решить проблему
Если вам кажется, что в вашей идее есть хоть что-то, что отличит вас от конкурентов, поставьте себе челлендж и запустите MVP. Особенно, если в команде есть тот, кто подкрепляет техническую уверенность исследованием рынка, бизнес-планом, маркетинговой стратегией.
Гораздо вреднее брать на себя сложные и новые задачи just for fun. Не зная, какую пользу принесёт ваше решение, вы не получите весь возможный технический опыт.
Начинайте делиться знаниями с первого дня разработки
Среда, в которой вы создаёте продукт, должна быть настроена на обмен экспертизой. Фиксируйте идеи, способы их реализации и изменения. Сохраняйте информацию в вики-порталах, записывайте важные созвоны и демовстречи.
Исследования будут бесполезны, если вы не сохраните данные, а просто примете решение на их основе. Позже вы не сможете подобрать нужные метрики, потому что просто не вспомните, откуда взялась та или иная фича.
Такая стратегия также избавит от ситуации, когда единственный знающий разработчик ушёл в отпуск или уволился. А ещё новым людям в команде будет значительно легче погружаться.
Выбирая технических партнёров, смотрите на решаемые ими задачи, а не популярность
Расширяя функциональность Vexor, мы перепробовали все возможные платёжные системы от Яндекс.Денег до Робокассы. В итоге работали с CloudPayments. Мы выбрали их потому, что только они могли делать нужные нам рекуррентные платежи с API и библиотеками на Ruby.
Когда создаёшь что-то новое, приходится быть первооткрывателем в каких-то технологиях. Большое корпоративное решение может просто не заботиться о нужной вам, редкой реализации своего продукта. Поэтому не стесняйтесь пробовать: ошибки всё равно будут, но «своих» вы найдёте.
Свой продукт — лучший университет
Это именно то, что вы искали — идеальная площадка для обучения. Junior-специалисты смогут набраться опыта на небольших задачах, Middle и Senior — обкатать новые технологии. Работая над Vexor, мы узнали кучу нюансов микросервисной архитектуры, на бэкенде поработали с Ruby, Go, Rust.
Не бойтесь экспериментировать «под капотом» продукта, но делайте так, чтобы для конечного пользователя это имело только позитивные изменения.
Любая обратная связь хороша. Но вам нужны критерии её оценки
Ранние пользователи вашего продукта — аудитория, которая больше остальных готова давать обратную связь. Будьте готовы к тому, что они будут делать это даже тогда, когда вы не просите.
Увидели гневные комментарии? Ускоряйте разработку, а не посыпайте голову пеплом. Чем быстрее выкатите фичи, тем быстрее получите обратную связь. Чем быстрее получите обратную связь, тем менее больно будет смириться и переделать. Не ждите полгода, шлифуя функции до идеала, пробуйте MVP-версии, proof-of-concept и собирайте данные. Только данные вместе с обратной связью помогут принять взвешенное решение.
Конечно, иногда вы и вправду будете знать лучше своего клиента, что ему нужно. Правильные критерии оценки связи от него помогут доказать свою правоту.
Главное — не впадайте в отчаяние и игнорируйте хейт.
Я надеюсь, что эти советы помогут кому-нибудь сделать смелый шаг. Ставьте серьёзные цели, пробуйте новые технологии, жадно учитесь. Кто знает, может именно вы создадите новый GitHub!
С наилучшими пожеланиями всем, кто пишет код,
Технический директор Evrone
Александр Кириллов.