В техническом менеджменте очень легко зациклиться на скорости.

Сколько задач закрыли за спринт. Сколько дней заняла фича. Как быстро команда выпускает релизы.

Но со временем я всё сильнее убеждаюсь:

скорость разработки сама по себе - не главная метрика.

Гораздо важнее то, сколько компании стоит каждое следующее изменение.

Потому что систему можно строить очень быстро.

Но если через год любая новая фича требует:

- менять пять сервисов; - согласовывать изменения с тремя командами; - руками проверять десяток зависимостей; - бояться затронуть старый код; - отдельно готовить сложный релиз;

то проблема уже не в скорости разработки.

Проблема в том, что стоимость изменений стала слишком высокой.

И наоборот.

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

- систему легко расширять; - зоны ответственности понятны; - изменения локальны; - тестирование и релизы предсказуемы; - новый функционал не требует переписывать полпроекта;

то такая команда в долгосроке может двигаться намного быстрее.

Для меня это один из важных сдвигов в мышлении CTO.

Не только:

"Как сделать быстрее?"

Но и:

"Как сделать так, чтобы следующее изменение стоило дешевле предыдущего?"

Иногда для этого нужно инвестировать время в архитектуру.

Иногда - в автоматизацию.

Иногда - в документацию.

А иногда - просто не усложнять систему раньше времени.

Скорость легко заметить.

Стоимость изменений становится видна позже.

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