Харитон Матвеев, со-основатель и Chief Product Officer Skyeng, в своем Facebook раскрыл все секреты быстрой мобильной разработки.
Основные идеи
Команды маленькие, но очень сильные
- Если хотите программировать в 2 раза быстрее, в 2 раза больше разработчиков вам не помогут
- Лучше меньше разработчиков, но более сильных по качеству (разработчики отличаются в цене в небольшом диапазоне: максимум в 2 раза, но вот в скорости могут отличаться на порядок)
- Непрерывно ищите игроков класса А (например, у нас всегда открыты вакансии, даже если команды полностью укомплектованы)
- Умейте прощаться со слабыми, даже если это тяжело и больно
- Если команда небольшая, то мы стараемся договориться с ребятами на условия, когда они работают больше 40 часов: 50 или 55 часов в неделю
Широкий full-stack: от дизайна до деплоя
- Учите разработчика выкатывать на сервер, писать скрипты автоматизации деплоя
- Учите разработчика элементарному дизайну: если у задаче нет простого дизайна, чтобы он ничего не ждал, а накидал решение сам
- Если нам нужен перевод в задаче, а его нет — переведите в Translate или сами, пусть будет опечатка или ошибка, но главное мы будем быстро двигаться
- Учите разработчика элементам продуктового менеджмента, чтобы он думал когда программирует, решает ли он проблему пользователля, все ли он предусмотрел и мог сам дополнить требования, если это требуется
- Сделайте как принцип: разработчик ответственен не за то, чтобы формально выполнить условие задачи, а за то, чтобы решить конкретную бизнес-проблему — согласно этому принципу и в тестировании становится заинтересованным тестировщик (сделайте хороший staging сервер, где он сможет посмотреть что получается на боевых данных перед деплоем)
Максимальная автономность: в коде, процессах, деньгах, механизмах принятия решений
- Режьте код на независимые системы, которые общаются по API
- Если разные команды хотят разный процесс или разные инструменты, не стоит их в этом ограничивать: большая автономность даст большую скорость
- У команды должны быть под рукой все необходимые ресурсы: быстрые деньги, согласования, ресурсы — вы отвечаете за это
- Формируйте и культивируйте в вашей команде принципы, как инструменты принятия решений: это позволит вашим сотрудникам не бегать друг к другу или вам за принятием решений, а они смогут принимать их самостоятельно, даже если это важный и стратегической вопрос
Берите больше рисков: дайте разработчику катить, не бойтесь уронить сервер, иногда можно деплоить без тестирования
- Ронять продакшен не страшно: главное, чтобы в трёхмерном пространстве (время, охват пользователей, охват функциональности) было наименьший объём «взрыва»
- Для уменьшения времени от того как вы выкатили и что-то сломали до времени, как вы почините, вам помогут: обученность команды и техническая возможность откатиться на предыдущий коммит, дашборды с продуктовыми фичами, на которых вы сможете увидеть что что-то пошло не так, настроенные процессы эскалации в технической поддержке которые скажут вам, что где-то прошёл сбой
- Так же для более быстрой обратной связи сформируйте пул из ваших клиентов (например, их можно позвать в Telegram аккаунт) и они будут держать вас в курсе, если вы сделаете что-то явно не то
- Нет никаких правил, мол процесс должен быть такой и всё, мол тестировать нужно всегда перед деплоем: научитесь понимать границы применимости правил, и использовать их там и тогда, когда это нужно, а где можно и выгодно нарушайте их
- Помните, что большая доходность только там, где большие риски
Если вас тормозят ограничения вашего крупного бренда, сделайте прототип или второе приложение для экспериментов, с no-name брендом
- Это позволит вам избежать головняков с юридической стороны
- Вы не будете ограничены имиджем компании и ожиданиями пользователей, что продукт должен сразу быть безупречного качества
- Вы можете позволить себе кучу такого, что не сможете позволить внутри своего приложения или в новом приложении вашей компании
- Катите чаще, но меньше
- У вас один релиз в неделю у команды? Это плохо! Релизить нужно каждую фичу, а фичи должны быть очень маленькими, разработчик должен релизить каждый день и это ваша задача, как нарезать задачу так, чтобы она состояла из кучи мелких работающих кусочков