Как быстро разрабатывать (SkyEng)

Быстрая разработка — мечта любого продакта. Конспект основных идей

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

• Если хотите программировать в 2 раза быстрее, в 2 раза больше разработчиков вам не помогут

• Лучше меньше разработчиков, но более сильных по качеству (разработчики отличаются в цене в небольшом диапазоне: максимум в 2 раза, но вот в скорости могут отличаться на порядок)

• Непрерывно ищите игроков класса А (например, у нас всегда открыты вакансии, даже если команды полностью укомплектованы)

• Умейте прощаться со слабыми, даже если это тяжело и больно

• Если команда небольшая, то мы стараемся договориться с ребятами на уловия, когда они работают больше 40 часов: 50 или 55 часов в неделю

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

• Учите разработчика выкатывать на сервер, писать скрипты автоматизации деплоя

• Учите разработчика элементарному дизайну: если у задаче нет простого дизайна, чтобы он ничего не ждал, а накидал решение сам

• Если нам нужен перевод в задаче, а его нет переведите в Translate или сами, пусть будет опечатка или ошибка, но главное мы будем быстро двигаться

• Учите разработчика элементам продуктового менеджмента, чтобы он думал когда программирует, решает ли он проблему пользователля, все ли он предусмотрел и мог сам дополнить требования, если это требуется

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

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

• Режьте код на независимые системы, которые общаются по API

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

• У команды должны быть под рукой все необходимые ресурсы: быстрые деньги, согласования, ресурсы вы отвечаете за это

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

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

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

• Для уменьшения времени от того как вы выкатили и что-то сломали до времени, как вы почините, вам помогут: обученность команды и техническая возможность откатиться на предыдущий коммит, дашборды с продуктовыми фичами, на которых вы сможете увидеть что что-то пошло не так, настроенные процессы эскалации в технической поддержке которые скажут вам, что где-то прошёл сбой

• Так же для более быстрой обратной связи сформируйте пул из ваших клиентов (например, их можно позвать в Telegram аккаунт) и они будут держать вас в курсе, если вы сделаете что-то явно не то

• Нет никаких правил, мол процесс должен быть такой и всё, мол тестировать нужно всегда перед деплоем: научитесь понимать границы применимости правил, и использовать их там и тогда, когда это нужно, а где можно и выгодно нарушайте их

• Помните, что большая доходность только там, где большие риски

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

• Это позволит вам избежать головняков с юридической стороны

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

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

🔸 Катите чаще, но меньше

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

#skyengsecrets