Timeline and Risk: How to Piss Off Your Software Developers | Rob Walling

Сроки и риск: как взбесить своих разработчиков

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

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

В контексте высокоэффективной команды одни разработчики обладают врождённым даром самомотивации и всегда стремятся к лучшему. Для других руки на клавиатуре удерживает командная динамика. По мере того как разработчик учится полагаться на товарищей и между ними складываются доверительные отношения, ему становится трудно филонить — из страха подвести группу и из-за мысли о том, что его назовут слабым звеном. Именно этот сплав соперничества и товарищества помог таким компаниям, как Google, Apple и Microsoft, доминировать на своих рынках и убедить сотрудников работать 90 часов в неделю и получать от этого удовольствие.

Но вернёмся к сути: что же это за одна фраза, которая злит разработчиков?

Возможно, вы думаете, что это коварное:

«Этот баг воспроизводится только в Opera v0.3 для Commodore 64, но всё равно почини его», или вечно любимое:

«Дизайна у нас ещё нет, но начинай строить хоть что-нибудь, потому что дедлайн никто не сдвигает».

Нет, ни то, ни другое.

Фраза, о которой я говорю, — менее известная:

«Делайте более качественное ПО за то же время».

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

Сама по себе фраза делайте более качественное ПО за то же время не доведёт ваших разработчиков до бунта. Но давайте разберём заложенный в ней посыл.

Треугольник

Качество и скорость — две из трёх сил знаменитого треугольника качества, скорости и стоимости. Это довольно известный бизнес-принцип: вы можете выбрать две из трёх сторон этого треугольника; всякий, кто утверждает обратное, пытается вам что-то продать. Кстати, если вы купитесь на то, что он продаёт, напишите мне на почту, потому что у меня тут завалялись Beanie Babies, от которых я хочу избавиться.

Существует множество определений «качества», но в этой статье я имею в виду ПО, которое хорошо спроектировано и хорошо написано так, чтобы обеспечивать высокую доступность (высокий аптайм) и легко поддаваться сопровождению и расширению.

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

Можно попросить разработчиков работать больше часов. Какое-то время это, вероятно, сработает — по крайней мере временно, ведь больше времени обычно даёт больше производительности. Спорно, способен ли человек, выполняющий настолько требовательную к концентрации работу, как программирование, хорошо функционировать после плотных 8+ часов, но в этом вопросе я дам вам фору. И всё же исследования показали, что «продолжительные плановые переработки оказывают сильное негативное влияние на производительность». Так что в краткосрочной перспективе мы можем достать кнут и ожидать небольшого скачка производительности, но если нам нужно что-то, что продержится дольше нескольких месяцев, и мы не хотим столкнуться с текучкой кадров в духе McDonald’s (потому что это неизбежно увеличит нашу стоимость и снизит качество нашего ПО), давайте выбросим этот вариант в окно.

Другой вариант — нанять более сильных людей. У этого есть неплохой шанс со временем повысить качество, но это не то решение, которое можно внедрить за одну ночь. С командой из 20 разработчиков вам, вероятно, потребуется девять-двенадцать месяцев, чтобы избавиться от менее продуктивных сотрудников и заполнить эти места крепкими специалистами — при условии, что в вашей команде есть несколько менее продуктивных участников. Однако если ваша команда разработки уже состоит из «машин кодинга» или если ваша цель — реализовать что-то немедленно, то нужно искать другой путь, даже если этот вариант вы решите развивать в долгосрочной перспективе. Обучение и/или наставничество — это разновидность данного варианта со схожими преимуществами, но и со схожим горизонтом времени.

Ещё одна альтернатива — просто заставить ваших людей работать усерднее.

Хм… вот это интересно. Если вы принимаете то, что я сказал в начале статьи, — что большинство разработчиков уже работают на пределе или близко к нему в силу личных или социальных причин, — то эта гипотеза не очень-то работает. Как может тот, кто и так работает на высоком уровне продуктивности, вдруг начать работать усерднее? Заставить человека работать усерднее, просто попросив его об этом, — это… ну… трудно понять как.

И именно поэтому говорить кому-то «делай более качественное ПО за то же время» оскорбительно: ведь по сути вы говорите ему, что он выкладывается не в полную силу. Что он отлынивает.

А это людей злит.

Откуда я это знаю? Потому что на днях такое сказали мне. И не только мне — на самом деле всей нашей команде разработки.

Лучшее ПО

Нетехнический менеджер заявил нам, что мы должны делать лучшее ПО за то же время, и даже добавил фразу «Никаких отговорок».

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

Поводом для разговора стал недавний инцидент, когда некоторые высоконадёжные системы лежали бо́льшую часть дня. Эти системы писались на протяжении более чем 4 лет под рискованными графиками «марша смерти», практически без QA, потому что мы торопились выпустить их в свет. Когда они упали, люди запаниковали — и не зря, ведь многие наши клиенты были в бешенстве.

В результате руководство выразило обеспокоенность ситуацией, указав, что в дальнейшем нужно что-то предпринять. Слушая, я понимал это как «Делайте ПО лучше; снижайте риск отказов». С чем согласится большинство разработчиков, это отличный подход, и за него уже довольно давно ратовали несколько членов нашей команды. Я воодушевился при мысли о том, чтобы обеспечить достаточный QA и добавить в наш код больше предохранителей. Но моё ликование вскоре накрыло метелью, когда я услышал: «Я не хочу слышать отговорок о том, что это займёт больше времени. Мы можем делать всё быстро И лучше». И вот тогда я понял, что мне нужно написать эту статью.

Но погодите, это ещё не всё.

Было проведено сравнение нашего ПО с ПО крупной финансовой организации (представьте Wells Fargo или Washington Mutual). Если вы думаете «Я не припомню, когда в последний раз кто-то из них надолго ложился», вы правы; они обычно не лежат, а если и лежат, то ненадолго. Но интересная вещь, которую я узнал за последние несколько лет, — это то, что цикл разработки ПО у них дли-и-инный, раза в 2–3 длиннее наших сроков.

Иными словами, они решили взять сторону «времени» своей пирамиды и сделать её очень большой в обмен на очень большую сторону «качества». И молодцы, ведь они явно сделали мудрый выбор, о чём свидетельствует их доступность.

Теперь, когда перед нами встала та же дилемма, пора платить по счетам и признать, что нам нужно снизить риск, одновременно признав и ту жертву, которую это в конечном счёте потребует: время.

Мораль

У этой истории есть как минимум две морали.

Первая: рано или поздно вы пожнёте то, что посеяли, поэтому не идите на компромиссы в проектировании. Бейтесь зубами и когтями и отодвигайте сроки, если придётся. Это будет нелегко, так что удачи. Дайте мне знать, если откроете какие-то секреты, — я был бы рад их услышать.

Вторая: снижение риска требует времени. Здесь стоит добавить, что это наша обязанность как технических специалистов — просвещать тех, кто этого не знает. Концепция, которая кажется нам столь очевидной, может быть совсем не очевидна человеку вне IT-отдела. Только мы по-настоящему понимаем сложность систем, которые строим, и последствия того, что на проектирование или QA тратится слишком мало времени.

Снижение риска очень похоже на страховку: если вы решаете её иметь, за неё придётся платить.

Отправьте эту статью менеджеру или коллеге, который пытался убедить вас в обратном.