← Разработка

Взлет и падение сверхсложных систем (перевод)

11 минут, 17 секунд

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

Многие из нас утверждают, что простота стремится к процветанию, а сложность стремится к смерти. Мы раскапываем древние здания самой простой конструкции, в то время как сложные конструкции гниют до состояния опасной ветхости. Старые автомобили Mercedes 280E из 80-х годов все еще тянутся в самой темной Африке, потому что их легко ремонтировать с использованием простых и стандартных деталей, в отличие от многих современных автомобилей. Можно даже многому научиться из наших прошлых войн, отдавая предпочтение использованию простого оружия и сложной техники. Против арбалетов — луки. АК-47 против М16, например.

Еще в начале 2014 года небольшая команда, состоящая из меня, ведущего разработчика, кодера C# и аналитика отчетности, собрала систему, необходимую для обслуживания проекта развертывания национальной мобильной базовой станции в Австралии с 2013 по 2018 год. Система поддерживала несколько дисциплин в рамках проекта: финансы, градостроительство, управление недвижимостью, радиопланирование, логистика и управление этапами, и должна была обслуживать до 700 пользователей. Сначала это было немного грубо, но с первого дня это был действующий продукт, и он работал. Наша команда была достаточно ловкой, чтобы внести изменения, необходимые для созревания системы.

Между тем, в верхних эшелонах ИТ-менеджмента еще в 2014 году появился еще один проект по созданию системы управления работой «все поют, все танцуют», которая должна была обслуживать все проекты и всех клиентов в бизнесе. В течение 2017 года эта система все еще находилась в стадии разработки и нигде не была достаточно близка к использованию в качестве рабочего продукта, в то время как значительные затраты в двадцать раз превышали сумму, необходимую для создания более простой системы, над которой работала наша команда.

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

Застрял на острове с небольшим количеством воды

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

Теперь у избранных лидеров странной группы есть три варианта выбора.

1) построить большое количество небольших плотов, каждый из которых способен вместить три или четыре человека;

2) объединить все ресурсы вместе, чтобы построить гораздо большую лодку для размещения всех; или

3) сидеть и ждать спасения.

Каждый вариант имеет свои риски.

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

Второй вариант технически сложен. Более половины времени, вероятно, будет потрачено на проектирование лодки; в этот момент моральный дух, вероятно, опускается до небывалого минимума. Истечение времени до того, как одна часть лодки будет собрана вместе, является реальным риском. Если группе удалось построить лодку и построить ее правильно; конечно, риск разрушения ее морем значительно снижается, и вероятность того, что все доберутся до острова в целости и сохранности, высока. Когда сроки критичны, построение сложного решения крайне рискованно.

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

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

Когда сроки критичны, построение сложного решения крайне рискованно

Подожди… я забыл, зачем мы это делаем!

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

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

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

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

Чем яснее цель и результат проекта, тем легче сохранить систему сфокусированной и простой.

Будь проще...

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

Это никогда не перестает удивлять меня, как редко простота поощряется на ИТ-проектах. Мне очень повезло в моей карьере, что я сыграл важную роль в принятии решений по разработке систем для обслуживания проектов, которые просты в использовании и просты в дизайне. И вот самое интересное. Многие из них работают и по сей день. Они были построены на стандартных технологиях, со стандартными принципами, достаточно модульными, чтобы их можно было легко разобрать, полностью документированными и легко обслуживаемыми ИТ-специалистами с низким и средним опытом.

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

Для тех из нас, кто часто создает базы данных, мы привыкли принимать решение о простоте и сложности. Я однажды попался в эту ловушку в мои ранние годы, создав базу данных, которая была чрезмерно нормализована, чрезмерно универсальна и чрезмерно динамична. Блин, неужели я попал в кучу неприятностей, когда клиент внес серьезные изменения в требования! Мне практически пришлось расчленить его и начать с нуля; но на этот раз с более сбалансированным прагматическим подходом в его дизайне.

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

Совершенство — враг добра

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

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

Слишком часто очень многие в ИТ-индустрии пытаются разработать такие системы.

Стремление к совершенству в любой системе может легко привести к ее чрезмерному усложнению и компрометации.

Что-то здесь не так.…

Вывод

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

Если для удовлетворения конечных требований в систему должна быть встроена дополнительная сложность, то это может иметь место; однако целесообразно заранее изучить периферийные варианты, процедуры или методы работы. Например, взвешивание преимуществ внедрения сложной полностью автоматизированной системы, требующей незначительного или полного отсутствия человеческого взаимодействия, по сравнению с внедрением гораздо более дешевой, простой и менее автоматизированной системы, которая может потребовать более регулярного человеческого взаимодействия, требует тщательного изучения. Если что-то сломается в новой системе, может ли это быть исправлено теми, кто в ИТ-команде с базовыми всесторонними знаниями, или нужно будет нанять специалиста?

Иногда об этом стоит помнить. Меньше-значит больше!