Есть много обстоятельств, которые могут быть катализаторами создания плохого ПО: используемые инструменты, качество коммуникаций в команде, персональные качества разработчиков, методологии и т.д. И есть среди них одна вещь, которая является корнем почти всех остальных: воображаемые проблемы.
Большинство сложного или забагованого программного обеспечения не планировалось быть сложным и, уж тем более, забагованым. Оно просто было создано для выполнения не тех задач, которые лежали в основе первоначального замысла.
История о подкастах
Давайте представим себе, что вы записываете популярный подкаст и в какой-то момент задумались о создании собственного сайта — ну, знаете, с информацией о вашем подкасте, записями прошлых выпусков, статьями, ну и возможно, кое-какой рекламой. В самом деле, ну сколько можно делиться прибылью с какими-то там посторонними издателями?
И вот вы решаете нанять людей, которые сделают для вас этот сайт. Вы пишете для них абсолютно чёткие требования:
- Быстрая загрузка сайта в Северной Америке
- Поддержка загрузки прошлых выпусков подкастов и трансляции в реальном времени текущих
- Трансляция не должна падать или замирать в течении первых 15 минут для 99.99% пользователей. Желательно вообще никогда, но хотя бы так.
- Интеграция с Google Adwords (а в будущем, возможно, и с аналогами)
- Интеграция с трансляциями Facebook, поскольку там вы провожу свои передачи. Если можно создать альтернативное решение, которое будет позволять стримить более удобно — ещё лучше.
Вы даёте эти требования разработчикам и, возможно, немного общаетесь с ними. Проходит 2 месяца. Они показывают вам демо и вы покрываетесь красными пятнами. Становится понятно, что вы только что выбросили в пропасть 15 000 $. То, что вам показали, совершенно неприемлемо ни с какой стороны, просто куча мусора. Вы хотите назад свои деньги, но поезд уже ушел.
Разозлиться при виде продемонстрированного сайта очень просто. При первом открытии всё просто замерло. Потом вроде заработало и вы спросили, как изменить тип рекламы, которая будет демонстрироваться на сайте. Вам показали вырвиглазно-велосипедный интерфейс для этого, который самостоятельно освоить просто нереально. Трансляции с Facebook тормозят. Всё ужасно.
Но команда разработчиков не понимает, почему вы расстроены. С их точки зрения они подвиг совершили, всего за 2 месяца сделав столь сложный продукт. Они вложили в него весь свой талант, всю душу. Посудите сами, какие замечательные фичи они в него добавили:
- Восхитительную систему рекомендаций
- Алгоритм распознавания речи, выводящий субтитры под вашей трансляцией В РЕАЛЬНОМ ВРЕМЕНИ!!!
- Главная страница сайта загружается за 200 мс в любой точке планеты
- Вещательный протокол и клиент написаны с нуля, а Facebook в них добавлен плагином. В любой момент можно добавить плагины для других платформ!
- Есть возможность интеграции с 20 разными рекламными платформами
Вы уже видите, в чём здесь беда, верно? Вы попросили вполне конкретный, узкоспециализированный продукт с парой нужных вам дополнительных фич. Команда разработки услышала это иначе. Для них все ваши «желательно», «более удобно» и «в будущем» превратились в захватывающую задачу по разработке общего, расширяемого, масштабируемого и дополняемого продукта огромных масштабов, по ходу реализации которого можно героически решить кучу интересных задач. Ну и, конечно, нечего отвлекаться на такие мелочи, как полировку и доведения до идеала базового функционала продукта — у нас вон какие масштабы, не время сейчас на это размениваться!
Ещё одна проблема в том, что вы, скорее всего, не общались напрямую с непосредственными разработчиками системы. Вы играли в испорченный телефон: поговорили с каким-нибудь продажником, который передал задачи кому-то из среднего звена руководства своей компании, там написали бизнес-спецификации, отдали менеджеру проектов, он написал технические спецификации и отдал их тимлиду, который разбил их на задачи и раздал разработчикам. Ну и каждый из разработчиков тоже понял и реализовал свои задачи в контексте своего понимания.
Механизм избегания реальности
Воображаемые проблемы решать интереснее, чем реальные. Очень умные люди играют в сложные игры, решают математические проблемы, пишут книги на абстрактные темы — бесплатно или почти бесплатно. При этом средней руки программист за вполне себе стандартное мобильное приложение выставит вам вполне существенный счёт. Это не потому, что среднего программиста сложнее найти, чем гения. Это потому, что интересные задачи делать легко и приятно, а рутину — нет.
Большинство программистов хотят и работать над интересными задачами, и получать за это хорошие деньги. Достичь этого сложно. Конечно, можно порассуждать о том, что такое «интересная задача», но для большинства разработчиков это что-то такое, что находится очень близко к границе области теоретически разрешимых задач. Что-то, чего достичь сложно, но возможно.
Дайте разумному человеку много рутинных, не автоматизируемых задач и рано или поздно вы доведёте его этим до ручки. Человеческий , однако, после миллионов лет эволюции, выработал достаточно много различных трюков для поддержания себя в адекватном состоянии. Как жертвы насилия способны убегать в мир своих фантазий, так и невинно обречённые к годам энтерпрайз-разработки или веб-фриланса со временем находят спасение в решении воображаемых проблем.
Количество и сложность придуманных проблем являются функциями от уровня воображения программиста и сложности его реальных задач. Нужно отметить, что сам подобный подход не уникален для разработчиков ПО. Менеджеры, продажники, HR, поддержка, юристы и бухгалтеры находят свои уникальные способы создания и героического преодоления несуществующих бед. Они вовлекают себя в принятия решений, которые находятся вне их компетенции, выступают на совещаниях, где их присутствие является чистой формальностью и так далее. Также они переоценивают масштаб проблем и свою роль в их решении («Наше новое приложение Дневник Собачки должно на 101% быть совместимым с GDPR с первого же дня! Мы не можем ждать, когда клиент пожалуется!»). Они раздувают штат для создания видимости важности работы своей команды, а затем занимаются решением проблем роста, масштабирования и логистики (а в большой команде такие проблемы будут всегда).
Многие из разработчиков умны, но многие из поставленных им задач — достаточно тупы. Это противоречие заставляет умных людей придумывать себе другие, пусть не существующие в реальности, зато интересные задачи.
Архитектура «испорченного телефона»
Иногда воображаемые проблемы не являются следствием фантазий скучающих разработчиков. Иногда это результат «испорченного телефона».
Я иногда работаю на фрилансе. Когда я только начинал, то не мог позволить себе перебирать клиентами. Это означало необходимость брать всех подряд и наблюдать во всех красках самые разнообразные проявления отклонений человеческой психики. Я видел цепочки из сотен писем на тему совершенно несущественных деталей прототипа. Я видел людей, меняющих абсолютно каждый абзац спецификации каждую неделю. У меня были клиенты, которые для проектов каких-нибудь тривиальных сайтов спрашивали о возможности сразу выйти с ними на ICO или прикрутить к ним искусственный интеллект.
Были и вполне здравомыслящие клиенты, которым, однако, не доставало знаний (или словарного запаса?) чтобы выразить все свои требования в понятных формулировках. Само по себе это не проблема. Частью работы разработчиков ПО как-раз и является сбор требований и написание спецификаций. Это то, за что нам в том числе платят деньги и эту работу даже можно более-менее нормально сделать, если у вас есть нормальный доступ к клиенту и достаточно времени. Беда в том, что иногда этого доступа нет и между вами находятся несколько посредников.
Большинство компаний любят иметь на отдельных выделенных должностях «продажников». Это специальные люди, которые ищут потенциальных клиентов, обсуждают с ними задачи, сроки и цены. Именно эти люди могут выяснить больше всего полезного и задать больше всего вопросов. Но это не те люди, которые будут писать данный проект. Между продажниками и программистами стоит 2, 3, 4 или больше слоёв менеджеров среднего и низшего звена, архитекторов, аналитиков и тимлидов. Да, это могут быть очень квалифицированные люди. Но всё же — это дополнительные слои. Как бы они не старались, информация, проходя через них, будет меняться. Кто-то отбросит что-то (на его взгляд) неважное, другой уточнит что-то неуказанное, но (по его мнению) очевидное, третий заменит дурацкую формулировку на правильный (как он уверен) термин — и вот первоначальную задачу уже не узнать. Продажник может бросить заказчику фразу типа «а за 39 999 сверху мы это можем и на блокчейне сделать». Если клиент клюнет — команде разработчиков двумя уровнями ниже придётся ломать голову, а как же вот ЭТО возможно сделать на блокчейне. Но ведь уже продано и оплачено, будем делать.
Таким образом изначальная проблема теряется в домыслах и переосмыслениях. Между новыми придуманным проблемами зияют дыры (ещё бы им там не зиять) и найдутся люди, желающие заполнить их своими собственными воображаемыми проблемами и их блестящими решениями. Потому, что это всё же свобода, а не рутина.
Искусственная усложнённость и натуральный отбор
Часто есть и ещё более тёмная сторона. Придумывание воображаемых проблем и методов их решения может стать драйвером роста компании, а в будущем, возможно, и её основным бизнесом, важнейшей частью её существования, от которой невозможно отказаться.
«Люди, отобранные для решения сложных задач, не имеют стимулов решать простые» — Талеб
Вы слышали о той тройке инженеров, которые вдруг выяснили, что онлайн-банкинг это, в общем-то, достаточно простая штука? Они создали простое и потому безотказное ПО, использовали правильные методики и языки программирования, а затем перевели на свою платформу все основные банки.
Нет, не слышали? Это потому, что такого не было. Зато вот, что было, есть и будет — отдельные команды из тысяч программистов, работающих на разные банки и за каких-то буквально полгода способных силами всей команды реализовать такую фичу, как «откат транзакции». Вот так и пишется банковское ПО, да.
И это, понятное дело, не потому, что переместить цифру из одной колонки в другую так сложно, нет. Это не сложно. Вот проиндексировать весь Интернет, а после этого выдавать релевантные поисковые результаты за долю секунды — вот это сложно. Однако пара ребят в гараже это сделала. А для отката транзакции нужно 1000 человек и полгода.
Проблема здесь в том, что банковская экосистема невероятно хорошо справляется со своей основной задачей — поддержкой банковской экосистемы. Колёсики крутятся, бумаги шуршат и завтра всё будет так же, как было вчера. Всё имеет инерцию. И, если мы последние 5 лет работали над воображаемой проблемой, мы и завтра тоже будем над ней работать.
«Тяжело заставить человека что-то понять, если он получает свою зарплату за то, чтобы этого не понимать» — Эптон Синклер
И все продолжают работать над вымышленными задачами, потому, что если они на минутку остановятся и взглянут на реальные, то станет понятно, что вся их система сломана. Вдруг может оказаться, что Вася, сидящий вон в том углу, последние 10 лет мониторит состояние внутренней серверной фермы, миграция с которой в AWS успешно прошла 5 лет назад. Вдруг окажется, что вся работа Маши состоит в пересылке кому-то отчётов Даши. Подобные осознания очень тяжелы и люди подсознательно стараются избегать ситуаций, в которых их можно случайно сделать.
И мы продолжаем решать воображаемые проблемы.
Автор: tangro
