[Перевод] Логический долг гораздо разрушительнее технического
Жили-были разработчики ПО, игнорировавшие рекомендованные методики наподобие предметно-ориентированного проектирования (Domain-Driven Design); они срезали углы, чтобы выпускать продукты быстро. Они думали: «Нам платят за написание кода, а не за проектирование!»
Менеджер по продукту, в свою очередь, игнорировал то, что игнорировала команда разработки. Он даже не мог сказать, чем именно они пренебрегали. Он был убеждён, что всё, не касающееся написания кода — пустая трата времени. Он думал: «Клиенты платят нам за работающее ПО!»
Спустя полчаса после запуска «работающее ПО» внезапно рухнуло из-за непредусмотренного (а значит, и неуправляемого) наплыва большого количества одновременных пользователей. Клиент считал, что менеджер по продукту и команда разработки должны немедленно устранить критическую проблему. Запуск был отменён.
После бессонной ночи, когда в решениях, предпринятых для экономии времени на этапе разработки «работающего ПО», обнаружились огромные ошибки, казалось, что критическая проблема решена. Менеджер по продукту и команда разработки с нетерпением ждали, когда пользователи снова попробуют продукт.
На следующий день исправленный продукт снова стал доступен пользователям. Спустя полчаса после релиза в офисе менеджера по продукту раздался звонок.
«Все пользователи сообщают о том, что ваш продукт не работает! Даже самые простые действия требуют непонятных шагов!», — кричал CEO клиента.
«Мы выпустили то, что максимально возможно, исходя из использованных технологий. Во фреймворке API 13.19.9 был патч с серьёзными изменениями», — решительно ответил менеджер по продукту.
«Вы что, издеваетесь?», — заорал CEO клиента.
«Это программное обеспечение, вы должны понять…», — попытался продолжить менеджер по продукту.
«Это вы должны понять, что я плачу за сервис! Меня не волнует, что там происходит внутри! Все сложности должны быть от меня скрыты! Пользователи должны быть продуктивными благодаря вашим сервисам, а не вопреки им!!!», — снова проорал CEO клиента и повесил трубку.
Спустя много бессонных недель менеджер по продукту, начавший понимать всю глубину несоответствия между образом мышления бизнеса и разработчиков, осознал, что архитектура проекта была неверной и хуже того — нецелостной. Он поделился своими выводами с разработчиками.
«Мы интегрировали наилучшие из доступных технологий, чтобы уложиться в time-to-market, как вы просили. Если вам нужно было так много уникальных поведений, то нам бы пришлось написать 80% с нуля, и это заняло бы примерно ещё один год», — ответили разработчики.
«Я верю вам, но вы не ответили на мой вопрос: проектировали ли вы продукт на основании сценариев работы пользователей?», — ответил менеджер.
«Но вы не дали нам никаких сценариев. Мы проектировали продукт для поддержки любого пользовательского сценария. Пользователи могут делать всё, что хотят», — гордо заявил руководитель команды разработки.
«Я хочу лучше разобраться, покажете мне логическую структуру, позволяющую нашему продукту делать всё, что пожелают пользователи?»
«Мы интегрировали готовые сервисы. Каждый сервис отвечает за набор поведений. О поведении сервисов можно узнать из их документации».
«Мы имеете в виду, что разрабатывали продукт без учёта глобальной структуры?», — спросил менеджер по продукту, всё больше волнуясь.
«Разумеется, у нас есть схема архитектуры продукта! У нас есть аж целая белая доска, вот, посмотрите!», — ответил возмущённый руководитель команды разработчиков.
С https://c4model.com/: «попросите разработчика ПО показать архитектуру программной системы в диаграммах, и вы получите сбивающий с толку хаос из прямоугольников и линий».
«Да тут же ничего не понять!», — пожаловался менеджер по продукту.
«Это ПО, и это ваша проблема, если вы не понимаете архитектуру», — завопил в ответ руководитель команды разработки.
«Нет, это наша проблема! Наш клиент ушёл от нас и купит продукт конкурента», — объяснил менеджер по продукту.
Все замолчали.
«Ушедший клиент сказал то, чего мы не услышали: «Я плачу поставщикам за решение проблем! Вместо этого вы продаёте мне нестабильные решения, полностью не соответствующие проблемам пользователей! Это неприемлемо! До свидания!», — подвёл итог менеджер по продукту.
«Мы всегда так работали. И добивались успеха», — сказали разработчики.
«Я тоже. Но на этот раз мы ошиблись», — ответил менеджер по продукту.
Эта история демонстрирует логический долг в действии. Люди ведут себя так, как «работали всегда» и делают упор на решениях, почти полностью игнорируя определение проблемы, которая и является единственной причиной, по которой клиенты и пользователи платят за ПО и сервисы.
Влад Хононов сказал в Learning Domain-Driven Design:
Имея знания о проблеме бизнеса, вы гораздо эффективнее будете выбирать подходящее решение.
Это крайне просто! Настолько просто, что разработчики могут забыть об этом, как о самом очевидном.
Команда из приведённой выше истории (менеджер по продукту и разработчики ПО) начала разрабатывать свой продукт, основав его структуру на интеграции кучи технологий, которые должны были удовлетворить любому сценарию использования. Они сделали упор на решении, подобном серебряной пуле, которого не может существовать.
Вместо того, чтобы придумывать решение на основании чётко очерченного набора проблем своих пользователей. они попытались обеспечить максимально широкий спектр решений для бизнеса их продукта. Они делегировали определение проблемы интегрируемым ими технологиям. И это упрощение оказалось фатальным.
Почему? Вернон Вон в Domain-Driven Design Distilled даёт такой ответ:
Разработчики не уделяют достаточно внимания именованию объектов и операций согласно выполняемой ими бизнес-цели. Это приводит к образованию большой пропасти между имеющейся у бизнеса ментальной моделью и выпускаемым разработчиками ПО.
Это и есть источник логического долга: несовпадение ментальных моделей между теми, кто создаёт продукты и теми, кто его покупает, кто платит за решение своих проблем.
Всё очень просто: когда что-то продаёшь, поставь себя на место потенциальных покупателей и думай, как они, используя их слова и концепции.
