[Перевод] Мнимые проблемы — причина плохого софта
То, что их интересно решать, не означает, что они кому-то нужны
«Группа людей проводит мозговой штурм над ноутбуком и листом бумаги», фото Стефана Стефанчика с Unspalsh
Есть много факторов, которые приводят к созданию плохого ПО: выбор инструментов, общение в команде, личная незаинтересованность разработчиков в успехе, методология тестирования. Мне кажется, у всего этого есть главная первопричина: это воображаемые проблемы.
Чрезмерно сложное или не функционирующее ПО не было задумано таким. Оно просто спроектировано для чего-то иного, а не для реальной задачи.
Предположим, вы публикуете подкасты, и вам нужен сайт, где можно продавать сопутствующие товары, зарабатывать на рекламе и, самое главное, публиковать подкасты, видео и блоги.
Требования к этому маленькому веб-приложению могут выглядеть примерно так:
- Быстрая загрузка для Северной Америки с трансляцией подкастов в реальном времени
- Отсутствие сбоев в первые 15 минут для 99,99% пользователей, желательно полное отсутствие сбоев
- Хорошая интеграция с Google Adwords и, возможно, другими сторонними рекламными системами, если есть время
- Динамические ссылки на последние товары в магазинчике и, если возможно, рекомендации пользователям на основе просмотренных страниц
- Интеграция с плеером Facebook Live. Если можно легко сделать альтернативное решение для потоковой передачи без Facebook, то ещё лучше
Вы даете эти спецификации команде подрядчика и немного с ними беседуете. Кажется, все на одной волне. Но когда они через два месяца показывают прототип, ваше лицо наливается кровью. Вы потратили $15 тыс. на кусок мусора — и хотите вернуть свои деньги.
При первом открытии приложение зависает. Вы спрашиваете, как выбрать тип баннеров — и вам показывают уродливый, непонятный UI. Половина ссылок на товары в магазинчике побиты или там отсутствуют изображения, а прямая трансляция через Facebook лагает!
Но команда разработчиков не понимает вашего гнева. В самом деле, с их точки зрения, они сумели выполнить адски сложную работу.
Они вложили душу в создание приложения, у него же удивительные возможности:
- Самая современная система рекомендаций
- Алгоритм текстовой расшифровки всех аудиопотоков в режиме реального времени
- Главная страница загружается быстрее 200 мс по всему миру
- Протокол потокового вещания и клиент сделаны почти с нуля, если вы не хотите полагаться на Facebook Live
- Разработан сервис, позволяющий легко интегрировать более 20 рекламных бирж
Проблема в том, что вы просили базовый продукт с несколькими дополнительными функциями при условии, что они достаточно просты в реализации. А команда разработчиков поняла иначе. Они услышали несколько захватывающих задач, которыми можно заняться… и множество скучных, базовых функций, которые не стоят особого внимания и тщательного тестирования.
Хуже того, вы с разработчиками не общались напрямую — вы общались через испорченный телефон. Вы говорили с продажником, который проводил совещания с участием некоторых менеджеров среднего звена. Они писали какие-то бизнес-спецификации для менеджера проекта, который писал технические спецификации — и отдавал их тимлиду или архитектору, а уже он со своей командой начинал разработку продукта. Каждое звено вносило искажения по пути.
Мнимые проблемы часто интереснее решать, чем реальные. Люди с избытком интеллекта играют в конкурентные игры, придумывают и решают математические задачи и пишут книги, чтобы ответить на абстрактные вопросы о человеческом естестве — и всё это бесплатно, только для удовольствия. Но посредственный программист, вероятно, возьмёт с вас изрядную сумму за создание простого приложения для Android. Это не потому, что посредственных программистов труднее найти, чем гениев, а потому, что первые виды деятельности интересны, а последние — довольно скучны.
Большинство программистов хотят получать деньги и получать удовольствие одновременно. Конечно, определение «интересного» у всех разное, но для многих инженеров оно сводится к решению интересных и сложных задач, которые находятся в области разрешимости.
Дайте умному человеку слишком много скучных задач, которые невозможно автоматизировать, и вы в конечном итоге сведёте его с ума. Однако человеческий мозг после миллиардов лет эволюции стал очень изобретательным в сохранении рассудка. Подобно тому, как жертвы детских лишений или жестокого обращения находят спасение в фантастических книжках, жертвы корпоративного программирования и фрилансеры ищут спасение в решении воображаемых проблем.
Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Следует отметить, что эта проблема не уникальна для разработчиков. Менеджмент, продажи, HR, поддержка, юридические и даже бухгалтерские отделы — у всех есть собственные уникальные способы создания мнимых проблем. Одни стараются влезть в процесс принятия решения, когда их присутствие на собрании является просто формальностью или вообще не требовалось. Другие переоценивают мелкую проблему, связанную с их ролью, или нанимают намного больше сотрудников, чем необходимо, чтобы продемонстрировать свою важность.
Когда проблемы слишком глупы, умные люди найдут способ исправить ситуацию.
Но воображаемые проблемы идут не только от скучающих разработчиков. Они также порождаются в результате длинных цепочек коммуникаций.
Когда я только начал искать клиентов как фрилансер, то не мог позволить себе выстраивать коммуникацию на своё усмотрение. Так что приходилось иметь дело с длинными почтовыми тредами с сотнями писем, где обсуждались незначительные детали внутренних MVP. Люди в течение недели меняли каждое требование в проекте. У меня были клиенты, которые задавали такие вопросы: «Это будет совместимо с проведением ICO?» или «Можно здесь добавить немного ИИ?»
Конечно, у большинства клиентов достаточно опыта, но даже им часто не хватает знаний для формулирования или построения некоторых требований. Это нормально, поскольку часть моей работы в качестве «компьютерщика» — помочь людям понять, что они делают, а что им не нужно, исходя из их конкретной ситуации. Но это гораздо труднее определить, когда между вами и клиентом несколько прокладок.
Требования меняются, потому что кто-то или неправильно понял намерение, или попытался справиться с вышеупомянутой скукой
Большинство компаний любят заводить в штате продажника, который пристаёт к потенциальным клиентам, торгуется и в общем описывает продукт. Также есть специалисты с продвинутыми навыками общения с людьми, чтобы обсудить с клиентом более детальные спецификации и требования: это обычно такой же продажник, только немного с другим названием должности. И есть внутренняя корпоративная система, различные уровни менеджмента и, возможно, некоторая иерархия в технической команде.
Когда список требований клиента проходит через такое количество людей, даже если у этих людей лучшие намерения, в процессе неизбежно что-то теряется. Иногда это происходит потому, что исходное требование не имело смысла или его нужно изменить. Возможно, продажник заявил клиенту: «Всего за 39 999 сверху мы сделаем это на блокчейне». Тот согласился, а всем остальным остаётся гадать, что именно означает «сделать на блокчейне».
Чаще всего требования меняются или потому что кто-то или неправильно понял намерение, или попытался справиться с вышеупомянутой скукой, пытаясь сделать свою работу или работу своей команды более интересной и впечатляющей.
За всем этим теряются первоначальные требования — те реальные проблемы, которые необходимо решить. Они заменяются воображаемыми проблемами и пустотами, а у вас много людей, готовых и желающих заполнить эти пустоты своими воображаемыми проблемами, потому что реальные проблемы, которые они должны решить, скучны, а заполнение пустот даёт им удовлетворение.
Часто есть и более мрачная причина появления мнимых проблем: такие проблемы помогают команде или компании расти, они даже могут стать неотъемлемой частью её работы.
«У людей, которых выводят, отбирают и поощряют искать сложные решения, нет стимула внедрять упрощённые»
— Нассим Николас Талеб
Вы слышали о тех трёх программистах, которые нашли по-настоящему простое решение для безопасного веб-банкинга? Они разработали с нуля безупречный банковский софт, используя методологию функционального дизайна и безопасные языки, а затем начали переводить крупные банки на свою удивительную инфраструктуру.
Возможно, вы о них не слышали, потому что их не существует. Но есть много команд из тысяч разработчиков, которые не в состоянии усвоить простые понятия, такие как «откат на старую версию», и они постоянно заняты созданием банковского софта.
Хранение и передача цифр — не особо сложная проблема. Вот проиндексировать всё содержимое интернета и выдать соответствующий результат для запроса на естественном языке за доли секунды — другое дело. Но лишь нескольким умным парням удалось решить эту проблему.
Хронической проблемой онлайн-банкинга является то, что банковская экосистема действительно достигла совершенства в собственной иерархии присвоения денег. Её лидеры — это коррумпированные пиявки, которые присосались к телу общества, но лидеры организации лишь отражают состояние всей системы.
Я не говорю, что большинство обычных банковских сотрудников — злобные и вредные личности. Отнюдь нет. Как правило, это дружелюбные ребята, которые зарабатывают на еду, жильё и образование для своих семей. Но их главный стимул — не исправлять банковское программное обеспечение, а сохранить работу. Потеря работы в современной экономике — серьёзная проблема для некоторых людей, а в банковской отрасли неосторожное слово или излишняя инициатива — это простой способ предстать перед дисциплинарным комитетом.
Таким образом, банковские системы остаются прежними — не потому, что они эффективны, а из-за инерции. Эта инерция проявляется в виде решения мнимых проблем, чтобы избежать решения реальных проблем — решение которых, как уже отмечалось, угрожает работе других людей. Решение этих реальных проблем может привести к увольнению или, в случае некоторых особенно неприятных «учреждений» вроде Goldman Sachs, к нескольким письмам, которые разрушают жизнь бывшего сотрудника и заканчиваются странным самоубийством.
«Трудно заставить человека что-то понять, если его зарплата зависит от того, что он не понимает!»
— Аптон Синклер
Рядовые корпи игнорируют тот факт, что высший менеджмент тратит 90% времени на «встречи с клиентами», включая путешествия на тропические острова и миллионные бюджеты для «накладных расходов». В свою очередь, высший менеджмент закрывает глаза на коррупцию в рядовом составе.
Поскольку менеджеры среднего звена поощряет их фантазии в стиле «Волка с Уолл-Стрит», высшее руководство закрывает глаза на поведение этих менеджеров, которые покупают эксцентричные офисы, нанимают трёх секретарш и десяток стажёрок.
Поскольку рядовые менеджеры не жалуются о своих диктаторских фантазиях и жажде власти, менеджеры среднего звена закрывают глаза на тот факт, что они вместо сокращения расходов тратят время на презентации PowerPoint об «Улучшении нашей гибкой методологии Agile».
Поскольку тимлиды не обращают внимания, что их начальство даже не умеет правильно использовать Excel и заходит в офис пару раз в неделю, рядовые менеджеры закрывают глаза, когда тимлиды и архитекторы говорят о «следующем поколении взаимодействия между нашими системами через JRPC и микросервизацию с помощью Hibernate и Spring», когда эти чёртовы MySQL-запросы выполняются больше суток.
Поскольку разработчики как будто не замечают, что их тимлиды не пишут никакого кода, кроме диаграмм, тимлиды не жалуются на своих разработчиков, которые вместо того, чтобы ОБЪЯСНИТЬ тормоза вышеупомянутого запроса, в десятый раз за год переделывают UI на новом фреймворке JavaScript.
Это порочный круг решения воображаемых проблем: от генерального директора, который не понимает, что кража ещё 30 миллионов не даст ему родительской любви, до стажёра, который не понимает, что новая кнопка «Отправить» на Angular-Material-Bootstrap 19.13.5 не изменит того, что пароли хранятся обычным текстом (и используются для проверки куков).
Но всем приходится и дальше решать воображаемые проблемы, потому что если они перестанут это делать, то начнут фокусироваться на реальных проблемах — и поймут, что вся система сломана. Они могут понять, что в углу офиса Дебра уже десять лет смотрит на графики безотказной работы кластера серверов, хотя пять лет назад компания переехала на AWS. Они могут понять, что 99% их задач нужно только для сохранения чьей-то чужой работы. И это осознание трудно принять, осмелюсь сказать, даже невозможно для большинства. Поэтому большинство находит способ адаптироваться.
