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

Когда мы определили на каком этапе жизненного цикла находится наш продукт и после оценки существующих метрик(если есть) — об этом можно почитать в предыдущей статье, мы пришли к выводу о желании и необходимости доработки продукта, то я предлагаю начать разбор с процессов. Я поделюсь своим опытом, который помог не только повысить производительность отдельных команд, но и в целом улучшить работу департамента. Мы поговорим о том, какие процессы нужны, когда их действительно стоит внедрять, как избежать карго-культов и неэффективных митингов, а также разберёмся с внутренними и внешними процессами, наймом и постепенным внедрением изменений.

Это первая вводная статья из цикла про рефакторинг больших систем. В ней я опишу продукт, департамент, в котором я находился, а так же расскажу про то, какие методы оценивания состояния системы можно использовать.

Люди приходят в разработку из разных профессий. Наверняка вы слышали о случаях «карьерного перерождения», когда вчерашний токарь или, скажем, менеджер по продажам захотел стать востребованным программистом, и у него получилось. Часто такие истории используют в рекламе всевозможных ИТ-курсов.

Герой нашей статьи, старший фронтенд-разработчик МойОфис, также проделал путь из одной профессии в другую (и обратно). Маршрут вышел замысловатым: в начале ИТ-карьеры он решил попробовать себя в роли модели, больше года совмещал кодинг со съемками в Европе, а затем полноценно вернулся в разработку — и понял, что стал специалистом 2.0.

Как моделинг меняет человека и чем может быть полезен разработчику? Рассказываем по порядку.