Как вести себя с руководителем, который считает, что более сложное решение всегда является лучшим?

Я думаю, что самая большая проблема здесь в том, что это «всегда» так, как это делается. По какой-то причине аналитик чувствует необходимость развивать навыки каждого. В этом нет ничего плохого.

Избегайте вникать в то, что является лучшим решением. Вы уже привели аргумент простого решения, но вы проигрываете. Вместо этого попросите, чтобы вам разрешили придумать некоторые из ваших собственных решений в рамках учебного процесса. Я уверен, что он помнит, как это расстраивает, когда тебе не разрешают экспериментировать и придумывать собственные проекты. Если вы не доведете его до определенного уровня производства, вы никогда не узнаете, действительно ли это работает и легко ли его поддерживать.

Другая часть вашего обучающего аргумента состоит в том, чтобы узнать, когда и где применять более сложное решение. Конечно, вам нужно научиться кодировать более сложное решение, чтобы сравнивать и сопоставлять его с более простым.

Возможно, он на самом деле не заботится о том, чтобы все учились, а просто продвигает свои способности с помощью сложных дизайнов. Если это так, будет трудно спорить с кем-то со скрытыми мотивами, особенно когда у него больше полномочий.

Вы должны ясно объяснить ему, почему вы хотите поступать так, как хотите. Как у менеджера, у него будут разные цели в отношении того, что доставляется клиенту (будь то внутренние или внешние), с такими факторами, как ремонтопригодность, ограничения технической архитектуры, которые являются лишь двумя из многих. Вам нужно понять, каковы его приоритеты, и если вы полны решимости продать ему свой подход, вам нужно убедиться, что он соответствует этим приоритетам.

Если вы пытаетесь продать свой подход просто как «немного облегчающий разработку», то любой достойный менеджер будет сопротивляться этому.

Стандарты кодирования существуют по какой-то причине, и иногда этап разработки немного более болезненный, чем кажется, просто потому, что его правильное заблаговременное выполнение делает все с этого момента намного проще.

Напомните ему о положительных сторонах принципа KISS.

Более простые подходы часто предполагают более короткие периоды обучения, более быструю реализацию и более успешные циклы обслуживания.

Если более простое решение не дает этих преимуществ, выберите более сложное решение.

Я бы очень хотел знать, что он на самом деле говорит.

Часто существует простое решение проблемы, которое работает в большинстве случаев, но не всегда. И решение, которое является более сложным и работает все время. По моему опыту, более сложное решение оказывается проще, потому что будут обнаружены дыры в более простом решении, требующие исправления, которые делают его более сложным, но все же неправильным, требующим все большего и большего количества исправлений, и вы можете видеть, к чему это идет. (Говорят: у каждой проблемы есть решение, простое, очевидное и неправильное).

С другой стороны, у вас может быть начальник, который просто немного глуповат — очень часто самое простое решение на самом деле самое лучшее.

А бывает и так, что проблему можно решить простым хаком, который очень скоро укусит вас в спину.

Хорошенько подумайте, какой именно.

Спросите своего менеджера, будет ли он помогать вам с оперативной работой и дежурить позже? Если нет, то скажите ему, что вам неудобно поддерживать систему, которую он предложил, и что он должен знать об этом и взять на себя ответственность за увеличение оперативной работы.

Является ли его роль менеджером/архитектором или просто менеджером? Если это просто менеджер (а это значит, что он не будет помогать вам с работой оператора), то он должен быть там, чтобы управлять сотрудниками и распределять задачи, а не проектировать систему. Это то, для чего вы находитесь.