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, для создания высоко настраиваемых, но управляемых решений для своих клиентов.
Адресуя вопрос о сложности программного обеспечения, Чандлер интересуется, что могут сделать компании-разработчики, чтобы предотвратить накопление ненужного функционала. Верморель отвечает, что сценарий зависит от того, имеет ли компания доступ к своему программному обеспечению. Если доступа нет, компания должна справиться со сложностью приобретенного программного обеспечения. Однако, если доступ имеется, программное обеспечение можно упростить, выявив и удалив неиспользуемые элементы, что значительно снизит сложность.
Переключаясь на обязанности ИТ-специалистов и специалистов по цепям поставок, Верморель отмечает, что хотя у ИТ-персонала обычно есть технические навыки, они часто не понимают бизнес-ценности определенных функций. Это приводит к разрыву между необходимыми и ненужными функциями. Поэтому руководители бизнеса должны тесно сотрудничать с ИТ-специалистами для определения приоритетов и упрощения системы.
Верморель дает советы специалистам по цепям поставок, которые хотят инвестировать в новое программное обеспечение. Он предупреждает от требования чрезмерной настройки, так как это может вызвать еще больше проблем. Вместо этого руководители должны поддерживать регулярный контакт с менеджерами продукта или техническими директорами поставщика, чтобы непосредственно общаться о своих потребностях. Вместо принудительного включения определенных функций в контракт, целью должно быть представление проблем тем, кто способен найти решения.
Наконец, Верморель советует компаниям выбирать программное обеспечение, которое выделяется в одной области, вместо того, чтобы выбирать всеобъемлющие решения. Такой фокусированный подход способствует улучшениям и снижает сложность, вызванную множеством взаимосвязанных функций. Благодаря близкому сотрудничеству с теми, кто контролирует дорожную карту, и выбору программного обеспечения с четкой фокусировкой, компании могут лучше управлять сложностью и повысить производительность.
Полный текст
Киран Чандлер: Сегодня мы собираемся затронуть тему “Франкенштейнизации” программного обеспечения. Итак, Джоаннес, это тема, которую довольно сложно произнести, поэтому я, наверное, оставлю ее вам. Я предполагаю, что сегодня мы не говорим о большом зеленом монстре. О чем именно мы говорим?
Джоаннес Верморель: Мы говорим о процессе, который определяет эволюцию программного обеспечения, в частности, B2B-программного обеспечения, а еще конкретнее - программного обеспечения для цепей поставок. Это в основном относится к долгоживущему B2B-программному обеспечению. Этот процесс, который я называю “Франкенштейнизацией”, развивает программное обеспечение на протяжении многих лет с помощью непрерывного потока крупных сделок, заключаемых между поставщиками программного обеспечения и их клиентами. Интересно то, откуда берется “Франкенштейнизация”, заключается в том, что каждая крупная сделка, заключенная между поставщиком и одним из его крупных клиентов, скорее всего, оставляет шрам в программном обеспечении.
Это постепенный процесс, при котором поставщик программного обеспечения ведет переговоры с крупной компанией. У крупной компании есть требования, и для их удовлетворения вносятся изменения в программное обеспечение, которые не соответствуют общей архитектуре, философии или исходному дизайну. Функция добавляется, но в несколько хакерском стиле. Это шрам. Проблема заключается в том, что если вы повторяете этот процесс годами, то в итоге получаете программное обеспечение, которое, в некотором смысле, является Франкенштейнским монстром. Это существо, состоящее из множества шрамов, которое выглядит весьма уродливо и сверхсоставным. Оно развивается странным образом, и вот как вы получаете эти программные монстры Франкенштейна. Это происходит в большинстве баз данных, но в программном обеспечении для цепей поставок это как будто на стероидах.
Киран Чандлер: Давайте поговорим о этих шрамах, о которых вы говорите. Как они выглядят? Ведь они улучшают программное обеспечение, верно? Они добавляют дополнительные функции. Это так плохо?
Жоанн Верморель: Да, очевидно, это компромисс. Вы хотите улучшить свое программное обеспечение, но программное обеспечение - это очень сложный объект. Это не так, как здание, где вы можете просто добавить этаж или расшириться красиво. Программное обеспечение имеет множество неприкосновенных проектных предположений, сделанных очень рано, которые придают программному обеспечению некоторую целостность - архитектурную целостность.
Давайте возьмем множество ERP-систем в качестве примера, которые были созданы вокруг идеи учета сезонности с помощью профилей, которые точно соответствуют 52 неделям, представляющим данный год. Таким образом, у вас буквально есть таблица с 52 столбцами, по одному столбцу на неделю, и у вас есть все эти профили сезонности, которые можно применить к любому производимому или продаваемому товару. Но что, если вы хотите моделировать что-то вроде Китайского Нового Года? Он не вписывается в эту сетку из 52 недель, потому что он будет перемещаться с одного года на следующий в соответствии с традиционным китайским календарем, а не григорианским календарем. Вы столкнетесь с аналогичными проблемами и с Рамаданом, и даже с Пасхой.
У вас есть очень хорошее предположение, которое может развалиться, когда вы сталкиваетесь с требованием, которое не вписывается в вашу структуру. И это может принимать множество форм. Проблема в том, что в качестве поставщика программного обеспечения у вас фактически нет времени переписывать всю программную платформу, чтобы эти новые функции интегрировались в вашу архитектуру полностью нативным образом. В конце концов, это немного хакерское решение.
Киран Чандлер: Вы ведете переговоры с важным клиентом, поэтому у вас нет лет, чтобы закрыть сделку. И затем у вас нет лет, чтобы реализовать будущее. Так что все должно быть сделано в условиях относительной экстренности каждый раз, просто потому что это на самом деле больше, чем обычное соглашение для закрытия продажи. Все делается почти по дизайну в спешке. Но когда что-то становится шрамом, а когда что-то становится хорошей функцией? Ведь все эти программы должны развиваться, меняться, работать для своих клиентов. Что отличает одно от другого? Как вы знаете, что то, над чем вы работаете, не станет шрамом?
Жоанн Верморель: Вопрос в том, сколько это будет стоить в терминах обслуживания? Каждая строка кода, которая существует в вашем большом корпоративном программном обеспечении, - это то, что вам придется поддерживать. Одна вещь, которую люди не всегда осознают, даже профессионалы в области программного обеспечения, - это то, что программное обеспечение похоже на сложный механизм, где каждая часть должна каким-то образом взаимодействовать со всеми остальными частями. У вас есть проблема квадратичной сложности.
Что это значит? Это означает, что если у меня есть десять частей, у меня в основном есть около 100 потенциальных взаимодействий, знаете ли, 10 х 10. Если у меня есть тысяча частей, и они все взаимодействуют, то у меня есть 1 000 х 1 000 взаимодействий. Каждое потенциальное взаимодействие - это рецепт для всевозможных проблем: проблем безопасности, ошибок, сбоев, неправильных результатов или просто массовых замедлений в программном обеспечении.
Когда вы добавляете больше частей, вы увеличиваете количество потенциальных взаимодействий между частями в вашем программном обеспечении, и оно увеличивается намного быстрее, чем количество частей. И когда я говорю о частях, вы можете подумать о функциях, возможностях, экранах, вариантах данных или записях.
Если вы очень внимательны к архитектуре вашего программного обеспечения, вы можете сохранить количество взаимодействий между вашими функциями под контролем. Если вы удваиваете количество функций в вашем программном обеспечении, вы не хотите умножать количество взаимодействий на 4, потому что это означает, что когда вы удваиваете количество функций, вы фактически учетверяете количество обслуживания, которое вам нужно будет выполнить.
Но это очень сложно. Когда вы спешите, когда вы удваиваете количество функций, вы фактически умножаете на 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 Sharp, SQL или что-либо еще, - это то, что вам нужно поддерживать так долго, как существует эта строка кода. Если вы удаляете это, это означает, что во время вашей следующей интеграции или миграции людям не придется задавать вопрос о том, как мы перенесем эту вещь на следующую версию системы или на следующую систему вообще.
И это то, о чем должны задуматься руководители цепочки поставок. При покупке программного обеспечения они должны придерживаться принципа экономии - если вам это действительно не нужно, лучше не иметь эту часть системы. Это будет только обузой. Очень важно постоянно обращать внимание на технологическую массу решения, которое вы приобретаете и используете.
Эта технологическая масса не бесплатна. Если у вас больше экранов, вам нужно больше людей, чтобы обучить их. Если вы можете удалить несколько экранов, это означает меньше обучения, меньше ошибок, меньше конфликтов с ИТ и так далее. Речь идет о управлении сложностью ИТ, но сложность заключается в том, что обычно ИТ не имеет представления об этом, потому что у них нет доступа к бизнес-ценности. Они не могут различать между функциями, которые действительно необходимы, и функциями, которые совершенно необходимы. Они не могут перевести таблицы, поля, экраны или возможности в евро или доллары. Это то, что могут делать только люди в цепочке поставок или маркетинге, если вы рассматриваете другую систему. Вот почему ИТ нуждается в поддержке этих людей, принимающих решения в компании, чтобы обеспечить приоритетность и изменения в упрощении системы.
Кирен Чандлер: Итак, чтобы подвести итоги, вы упомянули, что если я - руководитель цепочки поставок, который хочет инвестировать в новое программное обеспечение для своей компании, кажется, что мне не следует просить слишком много настройки, потому что это вызывает проблемы. Так что мне следует искать?
Жоанн Верморель: Да, просить настройку или специальные функции - это как рецепт для создания проблем. Если ваш поставщик программного обеспечения не имел достаточно проблем, вы только создаете новые, которые только ухудшат ситуацию. Поэтому действительно не стоит этого делать. Если вы действительно можете попросить настройку, просто как тест, потому что если поставщик согласно вступает в обсуждение с вами о настройке, это означает, что у поставщика нет надежности. Это означает, что поставщик делает это со всеми остальными клиентами, что означает, что даже если продукт сегодня хорош, через пять лет он станет кошмаром.
Во-первых, если вы просите настройку, хорошо бы ожидать, что ваш запрос будет отклонен. Если нет, то это проблема.
Кирен Чандлер: Одна из вещей, о которой люди должны просить, - это специальные функции, верно? Я имею в виду, если есть что-то, о чем стоит просить, это может быть доступ к главному техническому директору или менеджеру продукта со стороны поставщика. Включите это в контракт, возможно? Например, хотите встречаться с этим человеком два часа раз в месяц. Почему?
Жоанн Верморель: Если вы договариваетесь о прямом доступе к людям, которые разрабатывают дорожную карту поставщика, вы можете просто представить свои изменения. Вам не нужно навязывать им свое решение; просто представьте свою проблему. Потому что, будучи инженерами, что они делают, когда им представляют проблему? Они начинают работать над решением. Если у вас есть регулярная встреча, где вы представляете свои проблемы, вам не нужно договариваться о каких-либо конкретных функциях в контракте. Через пару лет в продукте начнут появляться функции, которые кажутся подходящими для вашей проблемы.
Кирен Чандлер: Можете ли вы объяснить это немного подробнее?
Жоанн Верморель: Если вы посчитаете, сколько встреч может провести главный технический директор программной компании с клиентами в течение месяца? Допустим, у него есть максимум 20. Если у вас есть одна встреча в месяц, вы получаете примерно пять процентов умственной пропускной способности главного технического директора, который определяет технологическое развитие поставщика, с которым вы работаете. Это означает, что вашим проблемам уделяется значительное внимание.
Кирен Чандлер: Итак, каково ваше предложение?
Жоанн Верморель: Мое предложение, если вы хотите поступить умно, - это приблизиться к людям, которые контролируют дорожную карту. Это умнее, чем спешить договариваться о неработающих функциях, которые вы, скорее всего, откажетесь использовать через шесть месяцев, потому что ваше решение было плохим или ваша проблема изменилась. Также другой совет - избегать программного обеспечения, которое делает слишком много. Вы хотите думать о программном обеспечении, которое делает одну вещь и делает ее хорошо, а не о программном обеспечении с обширными возможностями, которое в конечном итоге делает все плохо.
Кирен Чандлер: Можете ли вы подробнее объяснить этот момент?
Жоанн Верморель: Улучшать узконаправленное программное обеспечение проще, чем улучшать гигантский фреймворк, который делает все. Каждый раз, когда вы собираетесь что-то настроить, думайте о квадратичном количестве взаимодействий. Если у вас есть тысяча функций и вы добавляете одну, вам нужно подумать о всех взаимодействиях с уже существующими тысячей функций. Таким образом, если вы вводите одну функцию, вы рассматриваете все 1000 взаимодействий. Однако, если у вас есть только десять функций и вы добавляете одиннадцатую, вам нужно рассмотреть только десять взаимодействий. Так что снова сосредоточьтесь на чем-то, что является легким и четко сфокусированным на конкретной проблеме, которую вы пытаетесь решить.
Кирен Чандлер: Отлично! Боюсь, что нам придется закончить на сегодня, но я думаю, что есть несколько генеральных директоров, которые не особо будут вам благодарны, вероятно, сейчас они получат еще несколько телефонных звонков. Ну, это все на этой неделе. Мы вернемся на следующей неделе с новой серией. До тех пор, будьте осторожны.
Жоанн Верморель: Спасибо.
