00:00:04 Введение в программную Франкенштейнизацию.
00:00:35 Влияние программной Франкенштейнизации на B2B программное обеспечение.
00:01:31 Как запросы клиентов влияют на программную Франкенштейнизацию.
00:02:32 «Шрамы» в программном обеспечении и их последствия.
00:05:33 Затраты на обслуживание программной Франкенштейнизации.
00:08:00 Проблемы и затраты на внедрение новых функций программного обеспечения.
00:08:57 Функции без сложности: взгляд B2C.
00:10:36 Проблемы подхода B2B к программным решениям.
00:13:18 Опыт Lokad: правильно против быстро и технический долг.
00:15:14 Envision: решение компании Lokad для борьбы со сложностью.
00:16:30 Скриптинг, специфичный для домена: избежание ограничений и конфликтов.
00:17:43 Решение проблемы раздутого программного обеспечения в цепочках поставок.
00:18:01 Стратегии упрощения сложного программного обеспечения.
00:20:54 Управление “технологической массой” в программных системах.
00:22:00 Синергия ИТ, цепочки поставок и маркетинга при изменениях в системе.
00:22:43 Проблемы чрезмерной настройки программного обеспечения.
00:23:48 Проверка надежности поставщика ПО посредством настройки.
00:24:00 Приобретение влияния на стратегию разработки продукта.
00:26:08 Выбор компактного, целенаправленного ПО для избежания кастомизации.
Резюме
В Lokad TV Йоаннес Верморель представляет концепцию программной Франкенштейнизации, описывая, как B2B-программное обеспечение развивается через случайные изменения, не соответствующие исходному замыслу. Он сравнивает эти изменения с «шрамами», способствующими созданию сложного, эволюционировавшего программного комплекса. ERP-системы приведены в качестве примера, подчеркивая дилемму между сохранением архитектуры ПО и удовлетворением новых требований. Верморель предостерегает от поспешных решений, которые, по его словам, часто приводят к появлению шрамов в программном обеспечении и росту затрат на обслуживание. Признавая неизбежную сложность управления ПО, Верморель акцентирует внимание на том, как важно учиться на примерах B2C-моделей для контроля взаимодействия функций. Ответ Lokad на эту проблему — «Envision», специализированный язык программирования, который разделяет инфраструктурные и специфичные для домена задачи.
Расширенное резюме
В последнем выпуске Lokad TV обсуждается концепция программной Франкенштейнизации, термин, введенный основателем Lokad Йоаннесом Верморелем. Он использует этот термин для описания трансформации B2B-программного обеспечения с течением времени, особенно долговечных систем и ПО для цепочек поставок, которые развиваются благодаря постоянным переговорам и крупным сделкам между поставщиками программного обеспечения и их клиентами.
Верморель объясняет, что программная Франкенштейнизация происходит, когда в ПО вносят изменения в ответ на требования клиентов. Эти изменения зачастую не соответствуют исходной архитектуре, философии и дизайну программы. В результате, со временем программное обеспечение накапливает эти модификации, или «шрамы», превращаясь в то, что Верморель описывает как «монстра Франкенштейна» — составную и странно эволюционировавшую систему.
Он дополнительно отмечает, что это явление особенно заметно в ПО для цепочек поставок, но также характерно для многих типов B2B-приложений. Тем не менее, он уточняет, что термин «шрам» не следует воспринимать как исключительно негативное явление. Эти изменения могут улучшать программное обеспечение, добавляя новые функции и повышая его функциональность.
Верморель приводит в пример системы планирования ресурсов предприятия (ERP), которые предполагают, что сезонность можно описать фиксированными 52-недельными профилями. Такая конструкция работает до тех пор, пока не возникает требование, не вписывающееся в эту схему, например, моделирование китайского Нового года, Рамадана или Пасхи, для которых действуют различные календари и которые ежегодно изменяют свои даты.
В таких случаях поставщик программного обеспечения сталкивается с необходимостью компромисса. Он может удовлетворить новое требование, внедрив «костыльное» решение, которое не интегрируется идеально в архитектуру ПО, но обеспечивает необходимую функциональность. Однако такой подход часто приводит к появлению новых «шрамов», способствуя процессу Франкенштейнизации программного обеспечения.
Подчеркивая быстроту переговоров с крупными клиентами в сфере программного обеспечения, Верморель предупреждает, что эта срочность может непреднамеренно привести к «шрамированию» ПО. Он определяет это как процесс, при котором поспешно внедренные функции увеличивают сложность и затраты на обслуживание программного обеспечения с течением времени.
Объясняя тонкости архитектуры программного обеспечения, Верморель отмечает, что каждая строка кода или функция требует обслуживания. По мере добавления новых функций взаимосвязи становятся все сложнее, что приводит к «проблеме квадратичной сложности». По сути, возможное количество взаимодействий растет экспоненциально с увеличением числа компонентов, что вызывает разнообразные проблемы, такие как ошибки, сбои и угрозы безопасности.
Верморель подчеркивает важность тщательной архитектуры программного обеспечения для контроля количества взаимодействий между функциями. Он утверждает, что цель должна заключаться в том, чтобы при удвоении числа функций затраты на обслуживание увеличивались лишь вдвое, а не вчетверо и более, как это часто происходит при поспешной разработке.
На вопрос о том, как программным компаниям внедрять новые функции без излишнего усложнения, Верморель предлагает учиться у B2C-компаний, таких как Google и Netflix. Они уделяют время тому, чтобы понять конкретные проблемы, которые пытаются решить, и разрабатывают решения, охватывающие широкий спектр схожих задач. Он противопоставляет этот подход миру B2B, где клиенты часто приходят не только с проблемами, но и со своими предлагаемыми решениями.
Относительно того, как Lokad решает эти вопросы, Верморель рассказывает об их первоначальных трудностях в нахождении баланса между правильным выполнением задач и быстрым удовлетворением запросов клиентов. Они заметили рост технологического долга в первые годы, что, по признанию Вермореля, оказалось губительным. Поняв, что добавление функций для удовлетворения отдельных клиентов может казаться выгодным в краткосрочной перспективе, в долгосрочной же приводит к созданию сложного, непоследовательного и трудноуправляемого продукта.
В ответ на это осознание, компания Lokad разработала уникальное решение: специализированный язык программирования под названием «Envision». Цель Envision — разделить инфраструктурные задачи и задачи, специфичные для домена, что позволяет Lokad более эффективно управлять добавлением и обслуживанием новых функций без избыточного усложнения.
Верморель продолжает рассказ о том, как программные продукты, особенно в индустрии цепочек поставок, часто сталкиваются с проблемой раздутия из-за обширной кастомизации для каждого клиента. Хотя кастомизация нацелена на предоставление индивидуальных решений, она зачастую приводит к созданию сложной, труднообслуживаемой системы, требующей значительных усилий для поддержки и обновления. Чтобы избежать этого, Верморель делится тем, как Lokad использует специализированный скриптовый язык Envision для создания высококастомизированных, но при этом управляемых решений для своих клиентов.
Затрагивая тему сложности программного обеспечения, Чендлер спрашивает, что могут сделать компании, чтобы предотвратить раздутие ПО. Верморель отвечает, что сценарий зависит от того, имеет ли компания доступ к своему ПО. Если нет, компании приходится мириться со сложностью приобретенного программного обеспечения. Однако, если доступ имеется, ПО можно упростить, выявив и удалив неиспользуемые элементы, что значительно снижает его сложность.
Переключаясь на обязанности специалистов по ИТ и управлению цепочками поставок, Верморель отмечает, что, несмотря на высокий технический уровень ИТ-специалистов, им часто не хватает понимания бизнес-ценности определенных функций. Это приводит к разрыву между необходимыми и ненужными возможностями. Поэтому руководители бизнеса должны тесно сотрудничать с ИТ для определения приоритетов и упрощения системы.
Верморель дает советы руководителям цепочек поставок, планирующим инвестиции в новое программное обеспечение. Он предостерегает от требования чрезмерной кастомизации, поскольку это может привести к появлению дополнительных проблем. Вместо этого руководителям следует поддерживать регулярный контакт с менеджерами по продукту или техническими директорами поставщика, чтобы напрямую озвучивать свои потребности. Цель должна заключаться не в навязывании конкретных функций в контракте, а в представлении проблем тем, кто способен разработать решения.
Наконец, Верморель советует компаниям выбирать программное обеспечение, которое выделяется в одном направлении, вместо всеобъемлющих решений. Такой целенаправленный подход облегчает внесение улучшений и снижает сложность, вызванную множеством взаимосвязанных функций. Поддерживая тесный контакт с теми, кто контролирует дорожную карту, и выбирая узкоспециализированное ПО, компании могут лучше управлять сложностью и повышать производительность.
Полная транскрипция
Kieran Chandler: Сегодня мы собираемся обсудить тему программной Франкенштейнизации. Итак, Йоаннес, эта тема довольно сложная для произношения, поэтому, наверное, я оставлю её тебе. Я полагаю, мы не говорим о каком-то большом зелёном монстре. О чем же мы говорим на самом деле?
Joannes Vermorel: Мы говорим о процессе, который определяет эволюцию программного обеспечения, в частности B2B-софта, а точнее – ПО для цепочек поставок. Это относится в первую очередь к долговечным системам B2B. Этот процесс, который я называю «Франкенштейнизацией», развивает программное обеспечение на протяжении многих лет за счет непрерывного потока крупных сделок, заключаемых между поставщиками ПО и их клиентами. Интересно, что именно в слове «Франкенштейнизация» заложено то, что каждая крупная сделка, заключенная между поставщиком и одним из его крупных клиентов, скорее всего оставит шрам в программном обеспечении.
Это постепенный процесс, в котором поставщик проводит переговоры с крупной компанией. У крупной компании есть требования, и чтобы удовлетворить их, в программное обеспечение вносятся корректировки, не соответствующие общей архитектуре, философии или первоначальному дизайну. Функция добавляется, но несколько костыльным способом. Это и есть шрам. Проблема в том, что если повторять этот процесс снова и снова на протяжении многих лет, то в итоге получается нечто вроде монстра Франкенштейна. Это существо, состоящее из множества шрамов, которые выглядят несколько отвратительно и суперкомпозитно. Оно эволюционирует странными способами, и именно так возникают эти «монстры Франкенштейна» в программном обеспечении. Это происходит практически в каждой базе данных, но в ПО для цепочек поставок – как будто на стероидах.
Kieran Chandler: Давайте поговорим об этих шрамах, как вы их называете. Какими они кажутся? Ведь они улучшают программное обеспечение, верно? Они добавляют дополнительные функции. Разве это так плохо?
Joannes Vermorel: Да, конечно, это компромисс. Вы хотите улучшить своё ПО, но программный продукт – это очень сложный объект. Он не похож на здание, в которое можно просто добавить этаж или красиво расширить. Программное обеспечение создается с учетом множества незыблемых дизайнерских допущений, заложенных на ранних стадиях, которые придают ему определенную целостность — архитектурную целостность.
Возьмем, к примеру, многие ERP-системы, которые были построены на идее учета сезонности с профилями ровно на 52 недели, представляющие данный год. Таким образом, у вас буквально есть таблица с 52 колонками, по одной на неделю, и есть все эти сезонные профили, которые можно применять к любому товару, который вы производите или продаете. Но что, если вы хотите смоделировать, скажем, китайский Новый год? Он не вписывается в эту 52-недельную сетку, так как переходит из года в год согласно традиционному китайскому календарю, а не григорианскому. С Рамаданом или даже Пасхой вы столкнетесь с аналогичными проблемами.
У вас есть это весьма привлекательное допущение, которое может разрушиться, когда сталкиваетесь с требованием, не вписывающимся в вашу систему. Это может проявляться в различных формах. Проблема в том, что как поставщик программного обеспечения, у вас на самом деле нет времени переписывать весь программный стек таким образом, чтобы новые функции полностью интегрировались в вашу архитектуру. В итоге, это выглядит несколько костыльным.
Kieran Chandler: Вы ведете переговоры с важным клиентом, так что у вас нет лет на заключение сделки. И затем, у вас нет лет на доставку будущего. Поэтому каждый раз всё должно делаться в условиях относительной срочности, просто потому что переговоры по сделке сверх обычных. Все спешат почти по плану. Но когда что-то становится шрамом, а когда – хорошей функцией? Ведь все эти программные продукты должны развиваться, меняться, работать для своих клиентов. Так что же их отличает? Как понять, что разрабатываемая вами функция не превратится в шрам?
Joannes Vermorel: Вопрос в том, сколько это будет стоить с точки зрения обслуживания. Каждая строка кода в вашем большом корпоративном программном обеспечении требует поддержки. Одно, что люди не всегда понимают, даже профессионалы в области ПО, состоит в том, что программное обеспечение похоже на сложный механизм, где каждая деталь должна каким-то образом взаимодействовать со всеми остальными. Это проблема квадратичной сложности.
Что это означает? Это значит, что если у меня есть десять компонентов, то потенциально может быть около 100 взаимодействий, то есть 10 x 10. Если у меня тысяча компонентов, и они все взаимодействуют, то получается 1000 на 1000 взаимодействий. Каждое потенциальное взаимодействие — это рецепт для самых разнообразных проблем: проблемы безопасности, ошибки, сбои, некорректные результаты или просто резкие замедления работы программного обеспечения.
Когда вы добавляете больше компонентов, число потенциальных взаимодействий между ними растет намного быстрее, чем число самих компонентов. И когда я говорю о компонентах, можно иметь в виду функции, возможности, экраны, опции данных или записи.
Если вы очень внимательно подходите к архитектуре вашего программного обеспечения, вы можете сохранить количество взаимодействий между функциональными возможностями под контролем. Если вы удвоите количество функций в вашем ПО, вы не захотите учетверять число взаимодействий, ведь это означает, что при удвоении функций вы на самом деле учетверяете объем обслуживания, который вам нужно проводить.
Но это очень сложно. Когда вы спешите, удваивая количество функций, вы фактически увеличиваете усилия на обслуживание в 4 раза или даже больше. Со временем затраты на обслуживание взлетают до небес, а ваша способность внедрять новые решения становится все ниже и ниже. Каждый раз, когда вы добавляете новую функцию, это запускает целую волну несовместимостей и странных непреднамеренных взаимодействий между разными частями, потому что функция не была полностью продумана. Боль нарастает со временем.
Киран Чендлер: Итак, давайте рассмотрим ситуацию с точки зрения софтверной компании. Как они могут внедрять эти новые функции? Как они могут реализовать эти функции, чтобы клиенты были довольны, не добавляя лишнюю степень сложности? Что они могут сделать?
Йоаннес Верморель: Думаю, урок здесь можно извлечь из мира B2C-программного обеспечения. Google не добавляет новые функции в Google Search, и Netflix не внедряет новые возможности для Netflix только потому, что привлекают нового клиента. Они не берут новых клиентов и не начинают с ними обсуждать: “О, если у нас нет этих функций, то вы не подпишетесь, так что нам нужно сделать это сейчас.”
Они работают иначе. Они думают о том, какова область применения, какую конкретную проблему они пытаются решить. Они стараются взглянуть на проблему с высокой перспективы, а затем уже действуют.
Киран Чендлер: Вы говорите об подходе, который нацелен на выработку решений для целой категории проблем, а не для одной микропроблемы. Это требует перестройки архитектуры программного обеспечения для решения широкого спектра похожих проблем. И это происходит постоянно. При общении с клиентами вы слушаете их проблемы, а не предложенные ими решения. В то время как в мире B2B клиенты склонны представлять не только свою проблему, но и решение. Это решение может подходить или не подходить к вашему существующему стеку программного обеспечения или к развитию этой проблемы. Так что, дело в том, что их на самом деле не слушают?
Йоаннес Верморель: Именно, здесь всё дело в том, чтобы действительно понять суть проблемы, а не зацикливаться на конкретном решении. Крупные компании, такие как Google и Netflix, являются отличными примерами этого.
Киран Чендлер: То есть, вы говорите, что компании на самом деле не слушают. Но как же насчет этих раздражающих всплывающих окон с просьбой оставить отзыв? Кто-то действительно обращает на них внимание?
Йоаннес Верморель: Всплывающие окна, о которых вы говорите, обычно являются нежелательными функциями. Но надо отдать должное таким компаниям, как Google. Эти всплывающие окна, где вам приходится соглашаться с условиями, появились не по их собственной воле. Их заставили внедрить их из-за нормативных требований. Так что, хотя это может казаться странной функцией, это не их дело. Кроме того, если посмотреть, кто победил в интернете, то дело не в компаниях с ужасно навязчивой рекламой. Победили такие компании, как Google, у которых реклама чистая и ненавязчивая. Они думали о своих клиентах, а не обесценивали свой продукт чем-то таким раздражающим. Они тратят время на то, чтобы тщательно продумывать свои функции.
Киран Чендлер: В компаниях, занимающихся B2B-программным обеспечением, особенно в сфере управления цепочками поставок, существует огромное разнообразие. Может быть сотни сценариев, и часто в последний момент люди договариваются о внедрении множества функций, которые почти всегда оказываются неудачными идеями через шесть месяцев. Так что, согласны ли вы с тем, что “франкенштейнизация” программного обеспечения — это плохо? И если да, что вы сделали иначе в Lokad, чтобы избежать этой проблемы?
Йоаннес Верморель: Абсолютно, «франкенштейнизация» программного обеспечения — это проблема. В первые несколько лет в Lokad мы столкнулись именно с этим вопросом. Это был тяжелый компромисс. Если вы хотите сделать всё правильно, это может занять год или два, что слишком долго. Если же сделать все быстро, можно завершить работу за несколько недель или месяцев, но потом у вас остается большой шрам, некрасивый хак. Вы накапливаете технический долг. Так что в первые несколько лет Lokad у нас не было решения, но мы всё больше осознавали проблему. Даже в статусе стартапа технологический долг накапливался, и это было тревожно. Именно в этот момент я понял, что тенденция неблагоприятная. Если заглянуть в будущее на пару десятилетий, можно увидеть, как конкуренты с их раздутым программным обеспечением для оптимизации цепочек поставок просто добавляют все больше и больше функций без какой-либо последовательности.
Киран Чендлер: Кажется, компании по разработке программного обеспечения постоянно добавляют новые функции, и в итоге получается путаный, раздутый продукт. Можете рассказать о вашем подходе к этой проблеме в Lokad?
Йоаннес Верморель: Абсолютно. Программное обеспечение становится раздутым, когда добавляется одна неудачная функция за раз. Если двигаться по этому пути в течение 20 лет, вы получите монструозный продукт. Дело не в том, что разработчики некомпетентны или глупы, они просто делают свою работу шаг за шагом, пытаясь завоевать одного клиента за раз. Однако такой подход пересматривает программное обеспечение клиент за клиентом, и итог обычно оказывается очень, очень плохим.
Таким образом, мы решили подойти к делу с совершенно другой стороны в Lokad, и это привело к созданию Envision — нашего предметно-ориентированного языка программирования. С Envision мы эффективно разделили все проблемы. Мы отделили инфраструктуру, инфраструктуру данных и инфраструктуру машинного обучения. Это долговечные продукты, которые мы хотим поддерживать и обновлять, и на это уходит несколько лет каждый раз, когда мы решаем их изменить или модернизировать.
Затем, отдельно, для каждого клиента мы создаем совершенно индивидуальную реализацию, написанную в виде скриптов на Envision. Поскольку Envision специально разработан для оптимизации цепочек поставок, мы можем создать что-то полностью кастомное для каждого клиента с высокой продуктивностью, оставаясь при этом уникальными.
Таким образом, мы начинаем с чистого листа, полностью его настраиваем, и тогда нам не приходится сталкиваться с ситуацией, когда клиент просит что-то, что мы не поддерживаем. Благодаря программным возможностям Envision, если нам придется сделать что-то особенное для клиента, в худшем случае написанный скрипт окажется не таким компактным, как обычно. Однако мы все равно сможем воспользоваться инфраструктурой, разработанной для облегчения решения определенного типа проблем.
Если вы внедрите продвинутые предметно-ориентированные программные возможности в вашу платформу, то вам внезапно не придется спешить с переговорами, которые оставят шрамы на вашем продукте. Вы сможете настроить систему в вашей программной среде, индивидуальной для каждого клиента, а затем продолжать выпускать обновления для вашей платформы по своему графику, который, скорее всего, не совпадет с графиком ваших клиентов.
Киран Чендлер: Вы достаточно рано заметили эту проблему. Какой совет вы бы дали другим компаниям-разработчикам ПО, сталкивающимся с подобным раздутым софтом? Могут ли они что-то с этим сделать? Стоит ли им начать удалять некоторые функции для упрощения?
Йоаннес Верморель: Ситуация зависит от нескольких факторов. Если вы крупная компания, которая владеет программным обеспечением, вроде WMS, ERP, MRP и тому подобного, то, возможно, у вас даже нет доступа к самому ПО — это может быть продукт поставщика. Если доступа к продукту нет, вы застряли с той сложностью, которую приобрели.
Если же у вас есть доступ к ПО и вы хотите его упростить, тогда да, вам следует начать с тщательного анализа всех неиспользуемых элементов и агрессивно их удалять. Многие опасаются удалять части существующего программного обеспечения, так как боятся потерять определенные возможности. Это правда, что если удалить возможности, вы их потеряете. Однако, если удалить то, что почти никогда не используется, можно также устранить целые классы проблем, вызванных наличием этой крошечной функции.
Мы часто видим реализации ERP в Lokad, где буквально тысячи таблиц. У вас может быть ERP с, скажем, пятью тысячами таблиц. Каждая таблица может содержать от 10 до 200 полей, что приводит к огромной сложности. Даже резервное копирование ERP может быть невероятно сложным.
Киран Чендлер: Поскольку у вас так много таблиц, вам нужна таблица для хранения списка таблиц и тому подобного. Это именно тот случай, когда, если вы сможете выявить массу таблиц, которые больше не используются, или экраны, которые больше не нужны, их простым удалением вы упрощаете всё.
Йоаннес Верморель: Именно, например, если вам нужно обновить одну версию вашей базы данных до другой, одна из проблем, с которой вы можете столкнуться, заключается в том, что придется обновлять куски логики, которые уже никто не использует. Каждая строка кода, будь то на Java, C# или SQL, – это то, что нужно поддерживать до тех пор, пока она существует. Если вы её удалите, то при следующей интеграции или миграции людям не придется задаваться вопросом, как перенести это на следующую версию системы или вообще на новую систему.
И это то, о чем должны задумываться руководители по цепочкам поставок. При покупке программного обеспечения они действительно должны придерживаться принципа экономии — если чего-то действительно не нужно, лучше не включать эту часть системы. Это просто станет обузой. Очень важно постоянно обращать внимание на технологическую массу решения, которое вы приобретаете и эксплуатируете.
Эта технологическая масса не достается бесплатно. Если у вас больше экранов, вам нужно больше людей для их обучения. Если удастся удалить парочку экранов, это уменьшит потребность в обучении, снизит число ошибок, конфликтов с IT и так далее. Все дело в управлении сложностью IT, но сложность в том, что обычно IT не имеет понятия об этом, потому что у них нет доступа к бизнес-ценности. Они не могут отличить действительно необходимые функции от абсолютно несущественных. Они не могут перевести таблицы, поля, экраны или возможности в евро или доллары. Это то, что могут сделать только специалисты по цепочке поставок или маркетинга, если речь идет о другой системе. Именно поэтому IT нужно, чтобы их поддерживали те люди, принимающие решения в компании, для определения приоритетов и упрощения системы.
Киран Чендлер: Итак, подводя итоги, вы упомянули, что если я, как руководитель цепочки поставок, хочу инвестировать в новое программное обеспечение для моей компании, мне, похоже, не стоит требовать чрезмерной настройки, потому что это приводит к проблемам. Что же мне следует искать?
Йоаннес Верморель: Да, запрос на индивидуальную настройку или специальные функции – это как рецепт для создания проблем. Если у поставщика вашего ПО и так недостаточно проблем, вы просто создаете новые, которые только ухудшат ситуацию. Так что действительно, этого делать не стоит. Если вы все же можете запросить настройку, пусть это будет тест, потому что если поставщик охотно обсуждает с вами настройку, это означает, что у него нет принципов. Это значит, что он делает так со всеми своими клиентами, а значит, даже если продукт хорош сегодня, через пять лет он станет кошмаром.
Во-первых, если вы запрашиваете настройку, это неплохо, и вы должны действительно ожидать, что такой запрос будет отклонен. Если нет – это уже проблема.
Киран Чендлер: Одно, что люди должны запрашивать, — это специальные функции, правильно? То есть, если есть что-то, что можно попросить, так это доступ к техническому директору или менеджеру по продукту со стороны поставщика. Включить это, например, в контракт? Например, требовать встречи с этим человеком на два часа раз в месяц. Почему?
Йоаннес Верморель: Если вы договоритесь о прямом доступе к людям, разрабатывающим дорожную карту поставщика, вы можете просто представить им свои изменения. Вам не нужно навязывать им свое решение; просто изложите свою проблему. Потому что, как инженеры, что они делают, когда им представляют проблему? Они начинают работать над решением. Если у вас будет регулярная встреча, на которой вы представляете свои проблемы, вам не нужно оговаривать конкретные функции в контракте. Через пару лет в продукте начнут появляться функции, которые, казалось бы, соответствуют именно той проблеме, которую вы озвучили.
Киран Чендлер: Можете объяснить это подробнее?
Йоаннес Верморель: Если посчитать, представьте технического директора софтверной компании. Сколько встреч с клиентами он может провести за месяц? Допустим, максимум 20. Если у вас одна встреча в месяц, фактически вы получаете около пяти процентов умственных ресурсов технического директора, который руководит технологическим развитием вашего поставщика. Это означает, что вашим проблемам уделяется значительное внимание.
Киран Чендлер: Итак, какой у вас совет?
Йоаннес Верморель: Мой совет, если вы хотите действовать умно, — это установить тесные связи с людьми, которые контролируют дорожную карту. Это умнее, чем поспешно договариваться о ненадежных функциях, которые, скорее всего, вы выбросите через шесть месяцев, потому что ваше решение оказалось неудачным или проблема изменилась. Также, другой совет — избегайте программного обеспечения, которое пытается делать слишком много. Лучше иметь ПО, которое делает одну вещь и делает её хорошо, чем систему с обширными возможностями, которая в итоге делает всё плохо.
Киран Чендлер: Можете подробнее рассказать об этом?
Йоаннес Верморель: Улучшать узкоспециализированное программное обеспечение гораздо проще, чем усовершенствовать гигантский фреймворк, который пытается делать всё. Каждый раз, когда вы собираетесь что-то менять, думайте о квадратичном числе взаимодействий. Если у вас есть тысяча функций и вы добавляете одну, вам нужно учитывать все взаимодействия с уже существующими 1000 функциями. Так что, если вы вводите одну функцию, вы анализируете все 1000 взаимодействий. Однако, если у вас всего 10 функций и вы добавляете одиннадцатую, то нужно рассмотреть всего 10 взаимодействий. Итак, снова – сосредоточьтесь на чем-то компактном и четко ориентированном на конкретную проблему, которую вы пытаетесь решить.
Kieran Chandler: Отлично! Боюсь, что на сегодня на этом всё, но, думаю, найдутся несколько генеральных директоров, которые не будут особенно благодарны за это и, вероятно, получат еще несколько звонков. Что ж, это всё на этой неделе. Мы вернемся на следующей неделе с новым эпизодом. До встречи, берегите себя.
Joannes Vermorel: Спасибо.
