Хабрахабр

[Перевод] Мнимые проблемы — причина плохого софта

То, что их интересно решать, не означает, что они кому-то нужны


«Группа людей проводит мозговой штурм над ноутбуком и листом бумаги», фото Стефана Стефанчика с 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.

13. Это порочный круг решения воображаемых проблем: от генерального директора, который не понимает, что кража ещё 30 миллионов не даст ему родительской любви, до стажёра, который не понимает, что новая кнопка «Отправить» на Angular-Material-Bootstrap 19. 5 не изменит того, что пароли хранятся обычным текстом (и используются для проверки куков).

Они могут понять, что в углу офиса Дебра уже десять лет смотрит на графики безотказной работы кластера серверов, хотя пять лет назад компания переехала на AWS. Но всем приходится и дальше решать воображаемые проблемы, потому что если они перестанут это делать, то начнут фокусироваться на реальных проблемах — и поймут, что вся система сломана. И это осознание трудно принять, осмелюсь сказать, даже невозможно для большинства. Они могут понять, что 99% их задач нужно только для сохранения чьей-то чужой работы. Поэтому большинство находит способ адаптироваться.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть