Перевод на русский язык статьи Why Software Projects are Terrible and How Not To Fix Them.

Если вы хороший разработчик и работаете в дурной фирме, вам часто приходят в голову идеи об улучшении рабочего процесса.

Всем известный Тест Джоэля состоит из 12 подобных идей. Некоторые из них общеприняты среди разработчиков ПО (скажем, использование систем контроля версий), другие могут показаться спорными (TDD¹, например). Однако для каждой методологии, независимо от того, насколько она «принимается» сообществом, есть масса организаций эту методологию не применяющих. Существует множество магазинов, применяющих «тестирование Большого Взрыва²», эксплуатирующих принцип «Дизайн Прежде Всего³», использующих электронную почту для контроля версий или ещё что похуже. Что там происходит вообще? Должны ли эти фирмы вылететь из бизнеса?

Можно удовлетвориться объяснением некомпетентности руководства. Это определённо Принцип Питера. Но как Босс⁴ может быть некомпетентным, если у него уже работают десятки людей? Разве не должен мелкий стартап, использующий XP⁵, за час разнести в пух и прах подобные дурные фирмы? Если всё дело в лучших инженерных практиках, не должны ли лучшие инженеры всегда побеждать?

Многие разработчики, поддерживающие хорошие практики софтовой инженерии, строят свои убеждения и заключения на основе, как правило, 1—3 масштабных проектов в год. Но во время контрактной работы у меня была возомжность изучить множество больших фирм и написать некрологи по множеству ненормальных программных проектов. Я проанализировал кодовые базы сотен неудачных проектов. Вы можете посмотреть на любой из них и сказать, почему он провалился: из-за плохих инженерных практик — недостаточного или отсутствующего тестирования, из-за плохого контроля версий, без инкрементальной поставки⁶ и т.д. Но почему люди продолжают делать такие проекты? Почему эти подходы к разработке софта ещё используются? Нельзя на эти вопросы ответить, имея перед глазами коды всего трёх проектов. Глядя на них, можно сказать: «Тут нет тестов, поскольку ни Джефф, ни Билл, ни Том их не написали». Но я не такой тип ответов ищу.

У меня нет чётких объяснений, однако есть несколько теорий. Первая из них: в лучших практиках нашей индустрии нет никакого здравого смысла. Я не имею в виду, конечно, что они объективно хуже, это не так, они лучше. Но они неинтуитивны. Если вы кому-то скажете, что избыток ресурсов замедлит проект, вас сочтут сумасшедшим. Такое противоречит интуиции. Такое тяжело донести даже с учётом долгосрочных исследований, графиков, диаграмм и прочего. То же самое для Agile, TDD, инкрементальной поставки, product backlog — полного набора лучших практик. И каждая из них неинтуитивна. Иначе бы все ими пользовались.

Вы не пересекаетесь с реальным пользователем, кроме случая, когда общаетесь непосредственно с человеком, который будет лично пользоваться вашей программой. Вы встречаетесь с человеком, который должен будет объяснить человеку, который передаст следующему, а тот — ещё кому-то, кто объяснит реальному клиенту, что вы имели в виду. Совершенно недостаточно убедить сидящего напротив в том, что Agile — это круто. Он должен убедить своего начальника. А тот — своего. А этот уже должен донести информацию до отдела продаж. А люди с этого отдела должны убедить покупателя. Если покупатель — это b2b-фирма⁷, то деловой партнёр из этой фирмы, должен убедить своего начальника. Который будет общаться со своим шефом. Который расскажет всё конечному клиенту. Наверное. При условии, что клиент — это не b2b-фирма. Это очень долгая игра в испорченный телефон. Если товарищ, с которым вы говорите, думает про себя: «Всё это звучит очень круто, но сомневаюсь, что смогу это дальше донести», вы обречены. Не получится просто сказать «Это объективно лучше», вы обязаны показать, как можно всё описанное передать (и продать) дальше по цепочке.

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

Моя вторая теория заключается в том, что скорость реагирования на изменяющиеся бизнес-цели слишком маленькая. Реальная инженерия разработки ПО требует времени и дисциплины, однако на вас постоянно давит гигантское прессинг временных сроков. Открылось узкое окно возможностей и мы должны выкатить что-нибудь в течение трёх месяцев. Давление может быть внутренним — какой-нибудь продажник выставил безумный график, либо внешним — клиенту нужно решение через два месяца. Часто проблема оказывается «процентом» по техническому долгу⁸: мы сделали неудачный выбор A и отдали продукт, клиент в бешенстве, мы обязаны всё исправить как можно быстрее, сделав при этом такие же убогие шаги B, C и D. Аналитики испытывают желание менять стратегию каждые полгода, потому что если мы выберем одну и застрянем на ней, зачем тогда вообще аналитики нужны?

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

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

Конечно должны, но в далёкой перспективе. Как Кейнс лаконично заметил: «В долгосрочном периоде мы все мертвы». «В конечном счёте» — это значит долго. Месяцы, годы или десятилетия. Проект может заваливаться достаточно долго до момента, когда менеджменту это станет очевидно. И даже задолго до момента, когда это станет очевидно менеджменту менеджмента. А пока дойдёт до пользователя, пройдёт вечность. Всего год или около того понадобилось Mint, чтобы начать «откусывать» себе пользователей Quicken⁹. Однако Intuit¹⁰ занималась самоубиванием почти десятилетие до появления на сцене Mint. А когда на горизонте возникла угроза для Quicken, у Intuit было более чем достаточно денег, чтобы взять и купить Mint, чтобы потом тихо придушить. Intuit мог пережить десять таких угроз как Mint. Одна фирма за десять лет — это 100 лет ошибок или почти один миллион человеко-лет. Это дофига времени.

Рассмотрим Apple. Джобса уволили в 1985 г., а затем снова наняли в 1997. Прошло двенадцать долгих лет до признания ошибки. И даже после второго пришествия Джобса, когда он начал активную деятельность по развороту корабля, пришлось ждать 2006 года, когда стало понятно, что выбранная траектория правильная. Джобсу потребовалось 9 лет, чтобы развернуть Apple. За весь этот 21-летний период акционеры вполне могли прибить ныне самую успешную и крупнейшую компанию в мире.

Реальность неспешна. Она отстаёт на десятилетие от достойных инженерных практик. А большинство людей не хочет ждать десять лет. Они хотят всё сейчас, хотят презентацию в PowerPoint, которую можно представить на совещании «наверху» за десять минут, чтобы объяснить, как проект движется. Они не хотят реального решения, им нужно напустить тумана.

Вспомнилась очень сильная сцена¹² из «The Wire»¹¹. После того как департамент полиции почти на месяц был силой перенаправлен с решения уличных проблем на организованную преступность, а оттуда — на аресты за нарушения общественного порядка, а потом вообще был закрыт из-за недостатка финансирования по прихоти мэрии, офис мэра внезапно захотел узнать, почему же уровень преступности не снижается.

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

Как не решить проблемы¶

Множество разработчиков, в том числе из современных компаний, глядя на большинство софтверных магазинов, говорят: «Я могу сделать гораздо лучше», и на этой волне заключают контракты. Теория говорит: «Если я буду пользоваться лучшими инженерными практиками и писать великолепный софт, клиенты будут ко мне в очередь выстраиваться. Я могу найти проблемные проекты, захвачу их и своим непревзойдённым профессионализмом решу все проблемы». Это, пожалуй, самая большая ложь, которую программист может сам себе сказать.

У лучших практик есть одна фишка: они не секретны. Погуглите «software project management». Или сходите на Amazon. Да что там, даже у замшелого B&N¹³ на полках больше десятка книг по Agile, TDD, Scrum, Спольского¹⁴ и дофига ещё всякого. Если кому-то действительно нужно решить проблему, ответ будет лежать перед ним практически везде. Лучшие практики — это не «бессмысленный стартап». У Microsoft Press есть десятки книг про Agile, TDD, Scrum и так далее, заполненных энтерпрайзными заклинаниями. Если хотите делать лучше, делайте. Всё просто.

Давайте устроим мысленный эксперимент. Если вас назначили управлять «железным» промышленным проектом, полезете ли вы в гугл искать по фразе «управление инженерными проектами»? Закажете несколько книг с Amazon? Сходите в библиотеку? Запишитесь на лекции в местном университете? Попросите совета эксперта? Я бы именно так поступил. Перед началом проекта. И это бы избавило меня от головной боли.

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

Если переформулировать: плохие менеджеры проектов не следуют процессам разработки ПО. Они следуют процедуре «перевода стрелок». Мы добавим в контракт условие «нулевого количества багов», чтобы программисты вертелись как ужи на сковородке. Мы будем каждый день их стыдить, что уже сильно опаздываем. Всё это приведёт к бесконечному циклу совещаний, графиков, игр со статистикой, но не к улучшению продукта. Плохие менеджеры не хотят пошаговой разработки, они бы тогда оказались в замкнутной системе (и, значит, добавится больше ответственности). Они не хотят заниматься тестированием, поскольку если баг вывалится через трещины в продукте, это плохо отразится на их репутации. Как ни странно, создание качественного ПО тут вообще совершенно не важно. Важна статистика.

Если вы не сходили в книжный, не прислушались к Спольскому, Этвуду, Фаулеру, Бруксу, а также сотням и сотням других специалистов, если не потратили ни одного часа на изучение, как работают крупные компании-разработчики ПО, вас убедить не получится. Точка. Если извлечённый из могилы волшебной силой Стив Джобс персонально к ним обратится с призывом использовать лучшие практики, они всё равно не поменяются. Какой-нибудь антисоциальный программист, пытающийся изучить теорию продаж, не сможет их образумить. Вероятность этого нулевая. Они последуют за каким попало разработчиком, согласным с контрактом, где прописан нуль багов, то есть за некомпетентным разработчиком. А когда затея потерпит крах, они вновь возникнут на радаре с даже более нелепым графиком работ, набором требований и контрактом, возникшим от потери времени на двух последних провалах. И всё закрутится по новой.

Хорошо, а что дальше?¶

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

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

Если потенциальный работодатель протестует против участия в тестировании, начинает вычитывать ваши контракты строчку за строчкой, заводит разговоры о штрафах за опоздания в сроках и за баги — бегите. Они зациклены на переводе стрелок за ошибки, допущенные ранее.

Если вы продолжаете получать предложения на аутсорсинг проекта, давите в себе позывы написать статью, почему аутсорсинг Х — это плохо. Затем начнёте появляться в результатах поиска по строке «аутсорсинг Х». Вы никого не убедите, однако вызовете у людей желание искать аутсорсинговые проекты вместо настоящих.

Вместо этого рассказывайте об удачных вещах: TDD, Agile, Scrum, XP, CI — что угодны, главное, чтобы вы там успеха добились. Вы привлечёте внимание других людей со сходным складом ума, которые уже знают, что вы правы. Они также знают, насколько важно всеми силами удерживать проект от краха. Вот они — клиенты. Они будут вас слушать.