Продолжаем рассказывать о том, как мы строили свой облачный бизнес 42Clouds, с какими проблемами столкнулись, и чему они нас научили. Наша история – искренняя и без прикрас. Если мы облажались, мы так и говорим: «Смотрите, какой факап!». Не потому, что у нас «ни стыда, ни совести», а потому, что знаем: любые грабли – это награда, если вместе с ударом по лбу приходит урок, благодаря которому ты становишься лучше.
Мы кропотливо собрали инсайты всех ошибок и вывели 42 урока, которыми и делимся с вами в этом цикле статей. Первая часть и первые пять уроков поведали о нашем старте. Кому интересно, велкам сюда:
Вторую часть мы решили посвятить разработке. В этот раздел мы включили шесть уроков, которые помогут не потерять время, деньги, сотрудников и собственные нервные клетки.
#6 Путь к отступлению
быстрый откат деплоя / план B
В первой статье мы говорили о том, как важно проводить тестирование перед запуском. Действительно, сухая статистика подсказывает, что это помогает выловить 83,3% багов до того, как они выкатятся на прод и испортят впечатление о вашей работе. А что тогда оставшиеся 16,7%? Увы, это количество багов, которые все же просачиваются на прод из-за человеческого фактора. Если вы сейчас подумали, что такие цифры – не про вас, что вы можете свести количество багов к нолю, то вы уже совершаете первую ошибку.
Даже сейчас у нас изредка бывает так, что мы не учитываем всех кейсов наших пользователей, отчего возникают ошибки. Но мы всегда успеваем исправиться (и не тратим на это больше часа даже в самых сложных случаях), потому что усвоили две истины:
1. Никогда не рассчитывать на оптимистичный сценарий.
2. Всегда иметь план B и возможность быстро откатиться до состояния «все, как было».
Главное, помнить, что ни один пользователь не будет ждать и прощать только потому, что вы хорошие. Он уйдет. И уйдет с негативом.
#7 Сценарии при разработке
сценарист-режиссер / user story
Каждый продуктолог в душе сценарист. И чем выше его сценарные навыки, тем легче пойдет разработка продукта. Сценарный подход позволяет разработчикам и продуктологу общаться на одном языке, предусмотреть все возможные проблемы и учесть все нюансы. Для каждой функции нашего сервиса мы делаем отдельный сценарий (юзер-кейс): последовательно прописываем, как именно пользователь будет использовать эту фичу. Сценарий включает в себя и подробные действия пользователя, и отклик личного кабинета. Так нам удается выявить проблемы и несоответствия еще перед этапом разработки. А ведь в сценарии все это поправить гораздо проще, чем в реальном процессе.
Мы используем сценарии и при разработке, и даже при продажах. Так мы можем видеть каждый шаг, всех ответственных и, главное, тот результат, к которому хотим прийти.
Так что если вы никогда не пробовали сценарный подход – испытайте. Уверены, откроете для себя много нового.
#8 Соберите свой театр
продажники – актеры / тестировщики – каскадеры / клиенты – зрители
Если посмотреть на грамотный процесс запуска проекта, можно обнаружить, что все действо напоминает… театр. Смотрите сами:
Продуктолог – сценарист. Его задача – подготовить сценарий, по которому спектакль пройдет идеально гладко, без накладок, провисаний и нелепых ляпов. Сценарист должен обладать логическим мышлением, быть последовательным и непременно обязан уметь планировать свое время (иначе как он будет планировать чужое?).
Продюсер – глава разработки. Сотрудники сцены – разработчики. Декорации, свет, звук – чем не продукт? Под руководством продюсера рождается сцена для нашего спектакля, и она должна быть ошеломительной.
Актеры – сотрудники, которые занимаются продажами и продвижением. Это харизматичные и эмпатичные люди с врожденным даром убеждения и любовью к длинным разговорам.
Каскадеры – это тестировщики. Люди, которые знают, что мир неидеален, и готовы это доказать. Отличительные черты – бесстрашие, дотошность, умение докапываться до сути и проверять все до мельчайшей детали.
Зрители – пользователи. Капризная взыскательная публика, которую не проведешь неубедительной игрой или картонками вместо качественных декораций. Главное – найти своего зрителя и не показывать «Ромео и Джульетту» дошкольникам.
#9 Аудируйте друг друга
обучение / рост спецов / чистый код
Недавно мы попробовали новую для нас практику – взаимный аудит разработчиков с разных проектов. Признаться, раньше мы относились к ней с опаской и некоторым недоверием, потому что на постсоветском пространстве еще жив стереотип о том, что указать на ошибку коллеги – значит «заложить». Но нас ждал приятный сюрприз.
Оказалось, что свежим взглядом ошибки вылавливаются куда эффективнее. Но самый большой профит с этой практики получают сами разработчики, и вот почему:
1. Они имеют возможность изнутри изучать чужой код, перенимать опыт и прокачивать собственный скилл.
2. После переключения на аудит чужого проекта они возвращаются к своему уже без эффекта «замыленного глаза».
3. Проверяют собственный профессионализм и подходят к задаче аудита с позиции помощи и менторства, а не с позиции злого учителя.
Если помнить, что все вы делаете одно дело, то взаимный аудит может органическим образом повысить дисциплину сотрудников и сплотить команду. Мы заметили, что при такой практике работники более ответственно подходят к задачам, а новички куда быстрее вливаются в процесс и подтягиваются к опытным сотрудникам по уровню профессионализма.
#10 С миру по сотруднику
новый рынок / новый опыт / экономия
Дружная команда, которая работает в опенспейсе с панорамными окнами и печеньками, отлично смотрится на экране кинотеатров. А в жизни аренда большой площади и зарплата сотрудников запросто может вбить последний гвоздь в крышку стартапа.
Так что не бойтесь собирать сотрудников по всему миру или хотя бы по всей стране. В удаленных регионах можно найти скиллового работника с некосмическими запросами по зарплате.
Географически разбросанная команда хороша еще и тем, что в разных часовых поясах проще поддерживать пользователей. И обмен опытом, конечно же, никто не отменял.
#11 АвтоТесты = стабильность
доверяй, но проверяй / ускоряй разработку
В общении с коллегами мы с удивлением обнаружили, что многие из них пренебрегают автотестами, считая их не такой уж важной частью разработки. Тогда как наша практика показывает, что написание автотестов – залог тотального сокращения количества вывозимых на прод ошибок.
Автоматическое тестирование ускоряет процесс разработки, экономит время самих разработчиков и здорово облегчает жизнь тестировщикам. Последним при этом приходится работать не с сырой болванкой, а с более качественным продуктом, так что он в итоге быстрее выезжает на прод.
До сих пор не юзаете автотесты? Не надо так.
Как видите, тут нет сакральных знаний, только логика, ответственность и желание сделать свое дело максимально хорошо. Многие предприниматели хотят поскорее проскочить этап разработки, чтобы сразу продавать и получать прибыль, но они забывают, что «втюхать» можно что угодно, а вот крутые долгосрочные отношения с клиентами можно построить только на основе качественного продукта. Так что иногда лучше якобы потерять месяц-другой на разработке, ведь это себя потом окупит с лихвой.