Как улучшить инженерные процессы?

Question

Accepted Answer

Улучшайте процесс путём **выявления реального узкого места с помощью данных, изменения одного элемента и измерения эффекта** — а не путём оптового внедрения методологии. Процесс существует, чтобы служить команде; когда он перестаёт служить, измените его.

## Цикл улучшения

```text
1. MEASURE       → where does work actually slow down? (cycle time, review wait,
                    deploy frequency, incident rate)
2. FIND THE CONSTRAINT → optimizing anything but the bottleneck is wasted effort
3. CHANGE ONE THING → small, reversible experiments
4. MEASURE AGAIN → did it help? keep, adjust, or revert
5. INVOLVE THE TEAM → they know the pain; they'll own the fix
```

## Пример

Если функции занимают три недели, но только два дня уходит на кодирование, ограничение — это *время ожидания* — очереди на код-ревью, доступность окружения, согласования — а не скорость разработчиков. Увеличение давления на кодирование ничего не даст.

## Ошибки

- **Карго-культ** — копирование процесса другой компании ("давайте делать, как Spotify").
- **Процесс ради процесса** — церемонии, которые потеряли смысл.
- **Изменение пяти вещей одновременно**, так что невозможно понять, что сработало.
- **Навязывание процесса сверху вниз** без согласия команды.

## Почему это важно

Маленькие улучшения процесса складываются.

Сокращение времени ревью или боли от нестабильных тестов освобождает часы каждую неделю для всей команды.

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