Харитон Матвеев (Skyeng): Катите чаще, но меньше!

Харитон Матвеев, со-основатель и Chief Product Officer Skyeng, в своем Facebook раскрыл все секреты быстрой мобильной разработки.

Основные идеи

Команды маленькие, но очень сильные

• Если хотите программировать в 2 раза быстрее, в 2 раза больше разработчиков вам не помогут
• Лучше меньше разработчиков, но более сильных по качеству (разработчики отличаются в цене в небольшом диапазоне: максимум в 2 раза, но вот в скорости могут отличаться на порядок)
• Непрерывно ищите игроков класса А (например, у нас всегда открыты вакансии, даже если команды полностью укомплектованы)
• Умейте прощаться со слабыми, даже если это тяжело и больно
• Если команда небольшая, то мы стараемся договориться с ребятами на условия, когда они работают больше 40 часов: 50 или 55 часов в неделю

Широкий full-stack: от дизайна до деплоя

• Учите разработчика выкатывать на сервер, писать скрипты автоматизации деплоя
• Учите разработчика элементарному дизайну: если у задаче нет простого дизайна, чтобы он ничего не ждал, а накидал решение сам
• Если нам нужен перевод в задаче, а его нет — переведите в Translate или сами, пусть будет опечатка или ошибка, но главное мы будем быстро двигаться
• Учите разработчика элементам продуктового менеджмента, чтобы он думал когда программирует, решает ли он проблему пользователля, все ли он предусмотрел и мог сам дополнить требования, если это требуется
• Сделайте как принцип: разработчик ответственен не за то, чтобы формально выполнить условие задачи, а за то, чтобы решить конкретную бизнес-проблему — согласно этому принципу и в тестировании становится заинтересованным тестировщик (сделайте хороший staging сервер, где он сможет посмотреть что получается на боевых данных перед деплоем)

Максимальная автономность: в коде, процессах, деньгах, механизмах принятия решений

• Режьте код на независимые системы, которые общаются по API
• Если разные команды хотят разный процесс или разные инструменты, не стоит их в этом ограничивать: большая автономность даст большую скорость
• У команды должны быть под рукой все необходимые ресурсы: быстрые деньги, согласования, ресурсы — вы отвечаете за это
• Формируйте и культивируйте в вашей команде принципы, как инструменты принятия решений: это позволит вашим сотрудникам не бегать друг к другу или вам за принятием решений, а они смогут принимать их самостоятельно, даже если это важный и стратегической вопрос

Берите больше рисков: дайте разработчику катить, не бойтесь уронить сервер, иногда можно деплоить без тестирования

• Ронять продакшен не страшно: главное, чтобы в трёхмерном пространстве (время, охват пользователей, охват функциональности) было наименьший объём «взрыва»
• Для уменьшения времени от того как вы выкатили и что-то сломали до времени, как вы почините, вам помогут: обученность команды и техническая возможность откатиться на предыдущий коммит, дашборды с продуктовыми фичами, на которых вы сможете увидеть что что-то пошло не так, настроенные процессы эскалации в технической поддержке которые скажут вам, что где-то прошёл сбой
• Так же для более быстрой обратной связи сформируйте пул из ваших клиентов (например, их можно позвать в Telegram аккаунт) и они будут держать вас в курсе, если вы сделаете что-то явно не то
• Нет никаких правил, мол процесс должен быть такой и всё, мол тестировать нужно всегда перед деплоем: научитесь понимать границы применимости правил, и использовать их там и тогда, когда это нужно, а где можно и выгодно нарушайте их
• Помните, что большая доходность только там, где большие риски

Если вас тормозят ограничения вашего крупного бренда, сделайте прототип или второе приложение для экспериментов, с no-name брендом

• Это позволит вам избежать головняков с юридической стороны
• Вы не будете ограничены имиджем компании и ожиданиями пользователей, что продукт должен сразу быть безупречного качества
• Вы можете позволить себе кучу такого, что не сможете позволить внутри своего приложения или в новом приложении вашей компании
• Катите чаще, но меньше
• У вас один релиз в неделю у команды? Это плохо! Релизить нужно каждую фичу, а фичи должны быть очень маленькими, разработчик должен релизить каждый день и это ваша задача, как нарезать задачу так, чтобы она состояла из кучи мелких работающих кусочков