Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой и влиятельный внутренний клиент (команда, департамент, whatever) и просит сделать такую фичу в платформе, которая действительно будет полезна и ценна для него. Однако проблема в том, что зачастую эта функция не нужна НИКОМУ из пользователей платформы, кроме него. Она будет использоваться эксклюзивно этим большим клиентом.
Сделали такую доработку один раз. Потом еще разок. И ведь нельзя сказать, что пользы нет - большой и важный клиент действительно решает свою задачу с помощью этих фич и в итоге больше зарабатывает или меньше тратит на уровне компании. А разве не для этого и существуют платформы в больших компаниях?! И отказать тоже непросто - отказ делать кастомные штуки может спровоцировать политический конфликт. Отношения с влиятельным клиентом могут стать натянутыми. Он может начать задумываться о разработке собственного решения, что ослабит позиции платформы в компании. И что делать менеджеру платформы в такой ситуации?
Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0.
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.
2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.
3. Подумать, есть ли такая мера обобщения предложенной фичи, в которой она будет полезна не только этому клиенту? Есть ли возможность сделать из кастомной идеи такой общий функционал, который даст ценность другим пользователям? Например, клиент хочет показывать в UI статус из какой-то кастомной системы, которая есть только у него. Обобщенный функционал мог бы выглядеть как возможность редактировать виджеты на странице, и одним из виджетов был бы виджет для статусов из той самой системы этого клиента. Таким образом ВСЕ пользователи получили бы возможность менять вид страницы под свои задачи с помощью виджетов, и важный клиент в их числе.
4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.
5. Приготовиться к давлению. Если важный клиент настойчив, то он может в каком-то виде начать давить на вас (в корпорациях это могут делать тонко). Кмк, тут важно сохранить фокус на будущем сотрудничестве и не допустить, чтобы этот конфликт стал деструктивным. Это непросто.
А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...