У вас всегда будет больше проблем, чем у инженеров.

Как справиться с печальной реальностью.

Всем известно, что отладка в два раза сложнее, чем написание программы. Итак, если вы настолько умны, насколько это возможно, когда вы пишете это, как вы вообще будете его отлаживать?

- Брайан Керниган

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

Гораздо меньше (хотя, что забавно, все еще бесконечно).

Даже если игнорировать все ошибки, которые разработчики программного обеспечения создают сами, инженеры-программисты составляют всего около 0,3% населения мира. Мать-природа и остальные 7,7 миллиарда человек не сидят без дела. Да, многие из этих людей решают проблемы без программного обеспечения, и, конечно же, не все проблемы, которые создают люди, можно решить с помощью программного обеспечения. Тем не менее, когда компании по всему миру пытаются использовать технологии для решения мировых проблем, они сталкиваются с непреложной истиной: проблем всегда будет больше, чем инженеров.

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

Расстановка приоритетов становится неразрешимой.

Компании зациклены на своих незавершенных работах. Они видят все эти проблемы и реагируют, нанимая целые команды менеджеров проектов, чтобы построить и расставить приоритеты на огромной доске Jira. Но когда вы понимаете, что у вас всегда будет больше проблем, чем у инженеров, оптимизация невыполненной работы не имеет смысла. Когда вы завалены проблемами, упорядочить — не самый важный навык, важнее фильтровать их. Самый ценный навык расстановки приоритетов — это просто сказать «Нет. Я не собираюсь решать эту проблему прямо сейчас».

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

Более сложная задача заключается в том, что даже если вам удастся сделать все это, большинство ваших проблем все равно не останется в невыполненной работе. Что подводит нас к следствию номер два:

Инженерам тоже нужны навыки расстановки приоритетов.

Большинство проблем не являются большими проблемами. Они не создают какой-то API или оптимизируют какой-то алгоритм. Они не исправляют какую-то ошибку и не тестируют 9000 вариантов Android. Большинство проблем маленькие. Такие вещи, как «Как мне назвать эту переменную?» или «Должен ли это быть список или карта?» или «Нужно ли Бобу знать об этом?» — проблемы настолько мелкие, что проводить встречи каждый раз, когда они возникают, нецелесообразно.

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

Намеренная оценка и инвестирование в навыки управления работой инженеров — хороший первый шаг к повышению эффективности инженеров. Это убережет их от перегруженности проблемами и в идеале поможет им сосредоточиться на важных. но этого не достаточно. Чтобы знать, какие проблемы ценны, а от каких следует отказаться, требуется контекст. Когда у инженеров есть только пользовательская история с оценкой, они не понимают этого контекста. Все, что они знают, — это критерии приемлемости и оценка — что делать и когда делать. Они не понимают, зачем это делать, какие компромиссы им следует использовать при этом или что они могли бы сделать вместо этого.

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

Фантастические планы становятся фантазиями.

Все любят, когда план приходит вместе. Нам нравится, когда замысловато спланированное ограбление заканчивается тем, что хорошие парни просто выходят из казино с добычей на буксире. Нам нравится, когда вселенную спасает какой-нибудь новичок, летящий по каньону лазерных турелей, чтобы наконец использовать свою историю жестокого обращения с животными во благо. Нам нравится видеть, как эти от 1 до 14 000 605 длинных кадров (и вложений в 22 фильма) окупаются.

Некоторые счастливчики, делающие невозможное, — это большая фантазия, но все это ужасныепланы.

Все они запутанные, с несколькими (маловероятными) вещами, которые должны произойти как раз вовремя, чтобы герои добились успеха. Это делает их хрупкими. Если одна часть плана сталкивается с проблемой, то все начинает разваливаться. Люди изо всех сил стараются держаться вместе и обычно принимают опрометчивые решения, а не несут ответственность за разрушение Большого плана. У вас будет больше проблем, чем у инженеров. Ваши планы должны будут учитывать это.

Давайте рассмотрим фильм с хорошим планом. В начале Ронина Сэм идет в кафе, чтобы встретиться с опасными незнакомцами. Многое может пойти не так. Он заранее осматривает кафе и составляет план. За кафе он прячет пистолет. Когда он входит в кафе, он спрашивает туалеты и использует это как предлог, чтобы открыть заднюю дверь. Если что-то пойдет не так, теперь у него есть более быстрый выход и оружие наготове, если это необходимо.

Дело в том, что Сэму не нужно было выполнять план. Встреча прошла гладко. Все мирно вышли за дверь, и он забрал пистолет. Большинство компаний считают это отходами. Работа, потраченная на что-то, что не представляло ценности? Есть что убирать! Есть что оптимизировать!

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

Прогресс — это беговая дорожка.

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

Это программная инженерия в двух словах.

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

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

У других сложнее. Им нужно видеть изменения. И это не работает, когда всегда будет больше проблем, которые нужно решить. Вы можете потратить всю свою жизнь на то, чтобы сделать свой уголок мира лучше, и при этом у вас будет целая жизнь работы. Это не значит, что вы ничего не добились. Наоборот! Но единственный способ увидеть это — оглянуться назад.

Лучший способ измерить прогресс — игнорировать проблемы и думать о том, что мы создали. Что мы можем сделать сегодня, чего не могли сделать вчера? Что стало проще сейчас? Что бы рухнуло, если бы нас не было? Эти вещи меняются. Мы можем оглянуться назад и увидеть, что сейчас все лучше, чем было. Да, новое программное обеспечение приносит с собой новые проблемы.

Всегда будет больше проблем.

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

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