Задача у меня простая: есть огромный, жирный комок ... бд короче, мне нужно приделывать к ней разные интеграции, т.е. мне она нужна в плане users и записать-получить некоторые данные и то не всегда. До поры до времени было все хорошо, я делал так как мне удобно. Теперь начальство повесило на меня свои рекомендации как и что лучше делать. Все застопорилось, бд начала пускать свои метостазы и по моему коду, ни какие аргументы против не принимаются, всегда найдется отмазка почему по мнению начальства лучше делать именно так. У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

Здравствуйте, Qulac, Вы писали:

Q>Задача у меня простая: есть огромный, жирный комок ... бд короче, мне нужно приделывать к ней разные интеграции, т.е. мне она нужна в плане users и записать-получить некоторые данные и то не всегда. До поры до времени было все хорошо, я делал так как мне удобно. Теперь начальство повесило на меня свои рекомендации как и что лучше делать. Все застопорилось, бд начала пускать свои метостазы и по моему коду, ни какие аргументы против не принимаются, всегда найдется отмазка почему по мнению начальства лучше делать именно так. У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

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

Здравствуйте, Qulac, Вы писали:

Q>У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

Эмм, ты конечно извини, а почему ты считаешь, что проблема в начальстве?

Мне кажется, надо с начальством заканчивать технические холиварыи поговорить на языке бизнеса.
То есть выяснить, кому нужно навязанное тебе решение, для чего оно нужно (какую бизнес-потребность оно закрывает). Кого еще затронули эти изменения. Какие издержки привнесет это решение и какие выгоды. Ну и т.д.

А уже потом, имея информацию, можно дейстовать. Если такая необходимость все еще будет.

Здравствуйте, Gradiens, Вы писали:

G>Здравствуйте, Qulac, Вы писали:

Q>>У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

G>Эмм, ты конечно извини, а почему ты считаешь, что проблема в начальстве?

G>Мне кажется, надо с начальством заканчивать технические холиварыи поговорить на языке бизнеса.
G>То есть выяснить, кому нужно навязанное тебе решение, для чего оно нужно (какую бизнес-потребность оно закрывает). Кого еще затронули эти изменения. Какие издержки привнесет это решение и какие выгоды. Ну и т.д.

G>А уже потом, имея информацию, можно дейстовать. Если такая необходимость все еще будет.

К бизнесу это вообще не относится, есть просто антишаблон "золотой молоток" — когда для решения всех проблем используется один инструмент.

Здравствуйте, AmSpb, Вы писали:

AS>Здравствуйте, Qulac, Вы писали:

Q>>Задача у меня простая: есть огромный, жирный комок ... бд короче, мне нужно приделывать к ней разные интеграции, т.е. мне она нужна в плане users и записать-получить некоторые данные и то не всегда. До поры до времени было все хорошо, я делал так как мне удобно. Теперь начальство повесило на меня свои рекомендации как и что лучше делать. Все застопорилось, бд начала пускать свои метостазы и по моему коду, ни какие аргументы против не принимаются, всегда найдется отмазка почему по мнению начальства лучше делать именно так. У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

AS>ну раз начальству лучше знать, то пусть само и делает. ну или протоколируй хотелки начальства, свои возражения в переписке по почте, а потом когда система пойдет по **зде, покажи, что они сами этого хотели, пусть теперь кушают.

Эх, если было бы так просто, я бы не спрашивал.

Здравствуйте, AmSpb, Вы писали:

AS>ну раз начальству лучше знать, то пусть само и делает. ну или протоколируй хотелки начальства, свои возражения в переписке по почте, а потом когда система пойдет по **зде, покажи, что они сами этого хотели, пусть теперь кушают.
Он всё равно крайним останется.

Здравствуйте, Qulac, Вы писали:

Q> Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

"Смена работы" называется волшебная кнопка. Нажал, и у тебя опять всё нормально. Идея о том, что ты должен начальство заинтересовать в успехе проекта — абсурдна. Должно быть наоборот.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, AmSpb, Вы писали:

AS>>ну раз начальству лучше знать, то пусть само и делает. ну или протоколируй хотелки начальства, свои возражения в переписке по почте, а потом когда система пойдет по **зде, покажи, что они сами этого хотели, пусть теперь кушают.
K>Он всё равно крайним останется.

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

Здравствуйте, Qulac, Вы писали:


Q>К бизнесу это вообще не относится, есть просто антишаблон "золотой молоток" — когда для решения всех проблем используется один инструмент.

Так вот ты сам и пытаешься применить молоток
То есть спорить с технической точки зрения о правильности решений.
И тут молоток не работает, потому что решение — административное. Тут не надо доказывать что ты прав, тут надо выяснить истинную причину решения, которое начальство спускает сверху.
Надо понять, какой цели такое спускаемое решение служит. И кому оно выгодно. И вообще почему так получилось.
То есть взобраться на мета-уровень.

Иначе получается, ты для начальства работаешь в стиле "я художник, я так вижу". И начальство для тебя — аналогично.

Здравствуйте, Gradiens, Вы писали:

G>Здравствуйте, Qulac, Вы писали:


Q>>К бизнесу это вообще не относится, есть просто антишаблон "золотой молоток" — когда для решения всех проблем используется один инструмент.

G>Так вот ты сам и пытаешься применить молоток
G>То есть спорить с технической точки зрения о правильности решений.
G>И тут молоток не работает, потому что решение — административное. Тут не надо доказывать что ты прав, тут надо выяснить истинную причину решения, которое начальство спускает сверху.
G>Надо понять, какой цели такое спускаемое решение служит. И кому оно выгодно. И вообще почему так получилось.
G>То есть взобраться на мета-уровень.

G>Иначе получается, ты для начальства работаешь в стиле "я художник, я так вижу". И начальство для тебя — аналогично.

п 1. Начальство всегда право.
....

Здравствуйте, Qulac, Вы писали:

Q>Задача у меня простая: есть огромный, жирный комок ... бд короче, мне нужно приделывать к ней разные интеграции, т.е. мне она нужна в плане users и записать-получить некоторые данные и то не всегда. До поры до времени было все хорошо, я делал так как мне удобно. Теперь начальство повесило на меня свои рекомендации как и что лучше делать. Все застопорилось, бд начала пускать свои метостазы и по моему коду, ни какие аргументы против не принимаются, всегда найдется отмазка почему по мнению начальства лучше делать именно так. У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

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

Здравствуйте, AmSpb, Вы писали:

AS>потом когда система пойдет по **зде, покажи, что они сами этого хотели, пусть теперь кушают.

Не обязательно поможет. Правда в том, что даже если ты так будешь делать, при неадекватном начальстве оно всё равно не признает свои ошибки, и возложит всю вину на тебя. Начальство непогрешимо, а вот ты никудышный исполнитель.

Здравствуйте, Qulac, Вы писали:

Q>Задача у меня простая: есть огромный, жирный комок ... бд короче, мне нужно приделывать к ней разные интеграции, т.е. мне она нужна в плане users и записать-получить некоторые данные и то не всегда. До поры до времени было все хорошо, я делал так как мне удобно. Теперь начальство повесило на меня свои рекомендации как и что лучше делать. Все застопорилось, бд начала пускать свои метостазы и по моему коду, ни какие аргументы против не принимаются, всегда найдется отмазка почему по мнению начальства лучше делать именно так. У кого есть опыт общения с начальством, подскажите: Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?

пиши incident report, в котором конкретно описывай метастазы, их причины, способы их убрать, дай этот отчет почитать другому лиду (у вас же есть независимые от тебя технари?), поприте коллективным авторитетом. И да — обязательно используй понятные термины типа "технический долг", чтобы было понятнее, чем это чревато.

будучи полностью вне контекста, и не зная ваши порядки, поспекулирую насчет причин. У меня вот есть один очень умный, трудолюбивый и инициативный программер, который любит все последние технологии, методологии и радостно тащит их в проект. Как пример — притянул GraphQL, на замену обычному дедовскому REST API, на примитивный веб-сервис из 10 вызовов.

вообще продукт — элементарная программка на 5 экранов, которая читает данные из одного источника, анализирует их и выдает бесплатный отчет. Это даже не продукт, а маркетинговый инструмент; зато в таймшитах начинает мелькать "заменил GraphQL на Azure Service Bus". Это все круто, но бюджет на эту элементарную аппку давно уже превышен, а в коде разных обгорток, проксей и декларативных классов в разы больше чем самой логики.

и вот скоро мне прийдется так же само в приказном порядке говорить, что мы юзаем REST вместо GraphQL, что мы юзаем обычную реляционную базу вместо NoSQL, что не нужны одноразовые очереди в Service Bus для узкопрофильного продукта, рынок которого — 600 человек на всю страну.

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

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

Здравствуйте, Qulac, Вы писали:

Q>К бизнесу это вообще не относится,
Должно относиться в любом случае. Вы же там бизнесом занимаетесь.

Q>есть просто антишаблон "золотой молоток" — когда для решения всех проблем используется один инструмент.
Должны были быть причины, по которым было решено применить этот шаблон. Относящиеся к бизнесу причины.

Q>Может там у него какая ни будь "кнопка" есть, что бы нажал и стало опять нормально?
Кнопка называется "разговор с начальством".
Говоришь о том, что тебя беспокоит, почему, какие это может иметь последствия для выполнения твоих задач.
Начальство в ответ тебе скажет о своих причинах. Возможно, ты эти причины не поймешь, возможно начальство даже будет ошибаться.
Но начало диалогу будет положено и начальство узнает о твоих проблемах.

Как вариант предложишь своё решение проблем начальства. Либо скажешь — ОК ваши проблемы таким образом решаются, но как мне быть с моими задачами, они страдают и будут страдать из-за этого. Я, дескать, не могу придумать как не страдать. Поэтому либо дайте совет как поступить, либо давайте вместе подумаем, либо давайте учитывать эти страдания при постановке сроков выполнения задач.

P.S. "Технический долг" — это, конечно, красивые слова. Только неплохо бы выразить в цифрах этот самый технический долг.
P.P.S. Если начальство не согласится обсуждать и не захочет диалога — то либо готовься страдать, либо ищи новое место работы с более дружелюбным и общительным начальством.

Здравствуйте, Niemand, Вы писали:

N>Здравствуйте, Qulac, Вы писали:

N>будучи полностью вне контекста, и не зная ваши порядки, поспекулирую насчет причин. У меня вот есть один очень умный, трудолюбивый и инициативный программер, который любит все последние технологии, методологии и радостно тащит их в проект. Как пример — притянул GraphQL, на замену обычному дедовскому REST API, на примитивный веб-сервис из 10 вызовов.

N>вообще продукт — элементарная программка на 5 экранов, которая читает данные из одного источника, анализирует их и выдает бесплатный отчет. Это даже не продукт, а маркетинговый инструмент; зато в таймшитах начинает мелькать "заменил GraphQL на Azure Service Bus". Это все круто, но бюджет на эту элементарную аппку давно уже превышен, а в коде разных обгорток, проксей и декларативных классов в разы больше чем самой логики.

N>и вот скоро мне прийдется так же само в приказном порядке говорить, что мы юзаем REST вместо GraphQL, что мы юзаем обычную реляционную базу вместо NoSQL, что не нужны одноразовые очереди в Service Bus для узкопрофильного продукта, рынок которого — 600 человек на всю страну.

N>мораль: есть шанс, что начальство считает, что ты удовлетворяешь свою технологическую похоть за счет их бюджета, а проблема не так уж и серьезна. Исходя из этого и доноси свою тз.

N>если не выйдет и ты абсолютно будешь уверен, что начальство неадекваты — не мучай себя и найди другую работу. В конце концов именно начальство ответственно за успех продукта, а не ты.

Везет же людям: им сервисы можно писать. Мне бы одного-двух хватило бы и все уже было бы написано, про всякие там очереди даже речи не идет, причем один сервис все равно есть, но он для UI.

Здравствуйте, Qulac, Вы писали:

Q>Задача у меня простая: есть огромный, жирный комок
К сожалению, если ты не архитектор на проекте с правом принимать решения, то ты можешь либо саботировать и делать как считаешь нужным, но чтобы бизнес логика при этом не страдала, а потом ставить перед фактом, что всё работает и быстрее чем надо было, либо смягчать всё "демпферными абстракциями" для завода всего спагетти-кода по их фасад. Третий вариант, это вариант "успешного сениёра программиста на Node.js в 25 лет", а именно делать, что просят, а когда будет невмоготу работать из-за кривой архитектуры и кода просто обновить резюме и пойти найти новую работу.

N>пиши incident report, в котором конкретно описывай метастазы, их причины, способы их убрать, дай этот отчет почитать другому лиду (у вас же есть независимые от тебя технари?), поприте коллективным авторитетом. И да — обязательно используй понятные термины типа "технический долг", чтобы было понятнее, чем это чревато.

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

Здравствуйте, кубик, Вы писали:

N>>пиши incident report, в котором конкретно описывай метастазы, их причины, способы их убрать, дай этот отчет почитать другому лиду (у вас же есть независимые от тебя технари?), поприте коллективным авторитетом. И да — обязательно используй понятные термины типа "технический долг", чтобы было понятнее, чем это чревато.

К>Я думаю что у топик стартера усложняется работа, даже может быть и концепция правильная, просто ТС становится тяжелее. По любому причины инцидентов будут изза того что он где то недоглядел. А это вообще .. так себе аргумент.

Нет не правильно думаете. Мне реально предлагают штаны через голову надеть.

Здравствуйте, Qulac, Вы писали:

G>>Иначе получается, ты для начальства работаешь в стиле "я художник, я так вижу". И начальство для тебя — аналогично.

Q>п 1. Начальство всегда право.
Q>....
Q>

п.1 Цели бизнеса всегда правы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Qulac, Вы писали:

G>>>Иначе получается, ты для начальства работаешь в стиле "я художник, я так вижу". И начальство для тебя — аналогично.

Q>>п 1. Начальство всегда право.
Q>>....
Q>>

НС>п.1 Цели бизнеса всегда правы.

Это было бы так, если бы те кто начал заниматься бизнесом в 20 лет, к 45-50 годам загорали бы на палубе собственной яхты где ни будь в у побережья Испании(лень было лезть в гугл и искать хорошее побережье . На самом деле, подавляющая их часть ни добьется ни чего, ну в лучшем случае у них будет фирма: "чумодан без ручки".

НС>п.1 Цели бизнеса всегда правы.

Поэтому это следует читать так:

1. Начальник всегда прав.