Разработка

Варианты архитектуры обсуждаете и выбираете вы сами, но для сложных случаев всегда можно привлечь команду архитекторов. Все важные рабочие вопросы: по какой методологии работать, как оценивать задачи, каким будет код-стайл, как проводить код-ревью, во сколько созваниваться и т.д — тоже прерогатива команды. Некоторые команды пишут свои правила и успешно живут по нему.

Мы работаем в гибком графике и распределенно, поэтому самостоятельность и умение работать на результат очень важны. Например, уже через неделю после прихода в компанию разработчик впервые катит в прод. Вообще, "самоходность" помогает расти — как профессионально, так и в должности.

У нас программисты влияют на продукт, а потому должны уметь мыслить его категориями. Все решения — что и когда писать, внедрять ли новинку и пр., мы прогоняем через призму "а что это даст бизнесу и пользователям".
А еще мы любим упрощать и не делать лишнего.

Нашим основным продуктам несколько лет и, конечно, у нас есть легаси. Но кроме одного случая — новой CRM — мы не создавали заново, а просто научились договариваться с бизнесом о том, как работать с техническим долгом. Как - читай на Хабре.

Каждая входящая задача описывает проблему и обсуждается разработчиками на техревью — так мы вырабатываем собственное решение и его оценку. Задача не попадает в разработку, пока непонятно, как и ради чего ее делать.

Общаемся между командами, обсуждаем решения: если кто‑то сделал что‑то хорошее, раскатываем его на всех, чтобы не плодить сущности. Например, научились темизировать UI Kit на разные продукты, чтобы каждая команда не тратила месяцы на создание своего кита.