Про кранч

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

Это мне напоминает попытки гнать в час пик по большому городу 150 км/ч между светофорами, чтобы поскорее успеть на свидание. В этой гонке неправильно все: 
- огромные риски, которые вообще не стоят масштаба мероприятия;
- в половине случаев вы уезжаете со светофора первым, чтобы стоять с теми же машинами на следующем светофоре;
- половину поездки вы все равно проведёте, стоя в пробках и на светофорах;
- ничего страшного не будет, если вы опоздаете на 5 минут;
- нет ничего сложного в том, чтобы выйти на 15 минут раньше;
- в час пик вообще очень часто на метро быстрее.

Про переработки

Вот и с разработкой так же: вы выигрываете чуть-чуть, загоняете разработчиков до выгорания, рискуете наплодить багов. Хотя очень часто достаточно просто либо критически оценить скоуп, либо даже подвинуть сроки, если позволяет ситуация.

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

При переработках люди выгорают, устают, в среднем работают менее эффективно. Что эти 5-10% дополнительных трудозатрат дают? Экономию на ФОТ? Ну снизьте вы вилку при найме тогда на те же 5-10%; все равно специалист, в итоге, будет примерно того же уровня.

Умный в гору не пойдёт

Я кстати уже писал, что главный способ ускориться или сэкономить - не выжимать все соки из разработчиков, а отложить или выкинуть ненужные задачи. Это не только те, про которые все знают, что они не нужные. Это, в том числе, те, про которые вы думаете, что они нужные, а, на самом деле, это не так. И тут надо искать способ обнаружить свое заблуждение как можно раньше.

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

С чего это я вообще завёлся

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

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