День 2159. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 37. Не ждите, что без обучения и освоения передовых практик продуктивность повысится как по волшебству. Начало

Руководители часто думают, что у разработчиков ПО масса свободного времени. Может быть, они сами работают не в полную силу и имеют некий резерв, который смогут использовать, если на них надавить? Щелканье кнутом не может заставить лошадь бежать быстрее, если она уже мчится на пределе. Продолжая метафору, вы должны понять, почему лошадь бежит не так быстро, как вам хотелось бы, а после этого искать возможности для ускорения.

Команды можно мотивировать (или заставить) работать усерднее ради достижения краткосрочной цели, но не бесконечно. Уставшие люди совершают больше ошибок, что вынуждает их переделывать сделанную работу, и в конце концов выгорают. Если давить на людей слишком долго, они уйдут или станут саботировать работу. Героические усилия нигде и никогда не были устойчивой стратегией повышения производительности труда.

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

В чем проблема?
Первый вопрос, который вы должны задать: «Почему наша продуктивность не так высока, как хотелось бы?» Начинайте поиск решения с выявления причин проблемы. Изучите предыдущие проекты, чтобы увидеть, где могли скрываться дополнительные возможности для повышения эффективности и результативности работы. Вот некоторые вопросы, которые следует рассмотреть.
- Выполняет ли команда работу, которую не должна выполнять?
- Что делают люди из того, что повышает ценность проекта и, возможно, может быть использовано в дальнейшем?
- Чего не делает команда из того, что ускорило бы их работу?
- Что ещё вас тормозит?

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

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

3. Понять, на что тратится время. Приходится ли людям подолгу ждать других, прежде чем перейти к следующему шагу? Ускорьте действия, лежащие на критическом пути. Некоторые члены команды теряют продуктивность из-за слишком большого количества решаемых ими задач? Посмотрите, не препятствует ли прогрессу «сила трения».

4. Расширить возможности отдельных членов команды. Я всегда предполагаю, что люди работают максимально эффективно для имеющегося уровня знаний и рабочего окружения. И физическое, и культурное рабочее окружение влияет на продуктивность и качество работы разработчика. Выбор оптимальных процессов и технических приёмов может значительно улучшить качество и тем самым повысить продуктивность. Развитие здоровой культуры разработки ПО, мотивирующей и вознаграждающей желаемое поведение, способствует эффективной работе счастливой команды.

Окончание следует…

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 5.