Connect with us

Медиа

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

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

AppTractor

Опубликовано

/

     
     

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

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

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

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

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

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

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

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

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

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

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

  • Это позволит вам избежать головняков с юридической стороны
  • Вы не будете ограничены имиджем компании и ожиданиями пользователей, что продукт должен сразу быть безупречного качества
  • Вы можете позволить себе кучу такого, что не сможете позволить внутри своего приложения или в новом приложении вашей компании
  • Катите чаще, но меньше
  • У вас один релиз в неделю у команды? Это плохо! Релизить нужно каждую фичу, а фичи должны быть очень маленькими, разработчик должен релизить каждый день и это ваша задача, как нарезать задачу так, чтобы она состояла из кучи мелких работающих кусочков
Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
 
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.