Почему мы нанимаем сотни людей, чтобы писать код медленнее
Есть два проекта в двух разных компаниях — оба о том, как затащить дело в крупных корпоратах. Первый: 50 человек персонала, результата практически нет, еле успели доделать всё за год. Второй: людей втрое меньше, и по успешности всё сильно лучше, чем в первом проекте.Давайте посмотрим на суровую реальность. График роста численности персонала в первой компании летит вверх по экспоненте. Они нанимают, нанимают, нанимают. А рядом — график продуктивности (Time-to-Market), который падает с каждым релизом. Фонд оплаты труда растёт, а скорость поставки фич снижается. Теперь второй график: людей становится не так чтобы сильно больше, а график продуктивности растёт. Почему так?Очень часто это проблема архитектуры. Я примерно пять лет занимался системной архитектурой крупных систем, а сейчас ушёл в управление. И вот после этого опыта могу рассказать, в чём там дело, уже детально. Самое интересное, что это не заложенное заранее свойство системы, это именно выбор подхода к проектированию реализуемых сервисов решения. Если очень коротко, это пути зависимостей модулей сервиса. В чистой архитектуре они должны быть направлены только внутрь, в сторону ядра (бизнес-логики системы). Если архитектура выстроена плохо, мы получаем систему с сильной зависимостью от технических деталей реализации. Изменение в одном месте требует правок в пяти других.Сказать это очень просто, а вот сделать на практике — ГОРАЗДО сложнее. Сложнее не технически, а именно с точки зрения внутренней дисциплины команды и осознания важности проектирования. Читать далее