Я прочитал.

В целом, ПМ рассказывает заказчику какие плохие дэвы и всё

Из этого утверждения очевидно, что ПМ и заказчик — это разные субъекты.

Но вот второе утверждение это опровергает:

когда ПМ и даже тимлид (не так часто как ПМ) находятся на стороне заказчика,

Или сколько раз надо все перечитать, чтобы противоречие пропало?

А самый кайф — когда продукт для украинского рынка ;)

Если написано непонятно или противоречиво, то даже после десяти прочтений результат не изменится ;)

Ясность может появиться только после попыток переформулировать.

Значит, я в каком-то другом аутсорсе работаю тогда...

++

Похоже, что из-за разных проектов каждый выносит свой опыт.

Кому-то повезло быть на годных проектах и они не понимают деления на «аутсорс» и «продуктовые» с преклонением к последним.

А кто-то попал в «дно аутсорса», и после этого рассказывают всему миру про плохих ПМов и проблемах с заказчиком.

заказчик покупает дешевую рабочую силу и не ждет никакого качества

У меня для тебя плохие новости — тебе угараздило попасть на очень плохие проекты в аутсорсах.

Хотів би я глянути на «канонічний JSON», а тим більше REST ;)

Тогда у вас противоречие:

В целом, ПМ рассказывает заказчику какие плохие дэвы и всё

100500 случаев бывает, когда ПМ и даже тимлид (не так часто как ПМ) находятся на стороне заказчика, а девы в Украине.

Заказчику надо решение задач, аутсорсер обещает это сделать, уладив все вопросы «под капотом».

Пожаловаться заказчику на своих же девов — это расписаться в некомпетентности компании в целом.

Это как если бы вы пришли в магазин возвращать по гарантии сломанный девайс, а вас заставили выслушать истории про то, что сборщик на фабрике тогда выгорел, или был с бодуна или сбежал ;)

застосовувати стандартні рішення,

І багато вам довелося бачити реалізованих стандартних рішеннь в канонічному вигляді на живому проекті?

навєрно таке там у вас КРІ для зепки

Пан може запропонувати кращий KPI?

це формошльопство (говнокодінг звичайний)

Напевне, через «говно и палки» викликав асоціації з трохи іншою конотацією ;)

Мав на увазі, що горе-інженерам постійно щось заважає — то архітектура погана або «папірєднікі» наслідили, то вимоги не чіткі, то все дуже швидко змінюється, і т.д.

Справжній інженер має вирішувати проблеми бізнесу, а не створювати нові, про які не-інженери і не здогадувались.

коли уточнюєш питання тобі кажуть «тут питання задаю я» і

О, це ж чудово.

Після такої відповіді стає зрозуміло, що з такими «задаючими питання» тобі не подорозі.

Добре, що він себе проявив на співбесіді і тобі не довелося витрачати на них багато часу.

Культура съедает стратегию на завтрак ;)

В целом, ПМ рассказывает заказчику какие плохие дэвы и всё.

В аутсорсе это невозможно.

Потому что этот же ПМ, или его коллега, пару лет тому сами же
напаривали заказчику этих девов, как самых правильных и при этом за разумную цену.

На ох***нной архитектуре фичу любой дурак запилит ;)

Если бы все архитектуры были идеальны, бизнесу бы не было нужно сколько ИТшников.

Поэтому настоящее мастерство инженера — это как-раз «из говна и палок делать решения для бизнеса».
И чтобы в результате твоей работы количество говна не росло быстрее количества фич.
И высший пилотаж — это если получается систематически уменьшать показатель [сложность реализации]/[сложность функционала].

В таком виде оно действительно «токсично»:

«тут не то», «там не так»,

Это констатация фактов.

Если на месте ПМ не какой-нибудь дурачок, он и так догадывается, что там говно ;)

Проблема в том, что если лишний раз повторить «все плохо», не появиться понимание, что с этим делать.

Это менее токсично:

«давайте так не делать потому что потом будет то-то»

Но тут все та же проблема — не понятно, что делать.

Вы же знаете пресловутое «критикуя предлагай» :)

Поэтому не токсичная форма фидбека должна содержать альтернативу:
Давайте делать не так, а так, потому мы так сможем избежать _этого_ или улучшить _это_.

Але хто винний в цьому?

Ось підказка:

Я: Г*вно вопрос!

Кодер якраз так і відповідає. Як в тому анекдоті про «копати від забору до обіду».

Що робить «справжній інженер», перед тим, як братися за таску:
1) задасть декілька уточнюючих запитань, які сходу прийдуть в голову
2) якщо він не пам’ятає цей шматок коду системи, загляне в нього, у нього виникне ще декілька питань
3) обговорить з ПМом нові запитаня
4) подумає про те, як ця фіча буде викатуватись на прод, наприклад, чи не потрібна міграція?
5) подумає про те, як ця фіча буде тестуватися
6) згадає, чи немає зараз іншого тім-мембера, який робить щось схоже, або в тих же самих місцях системи і вам доветься «одночасно мержитися» перед релізом
6) і це все за умови, що інженер чітко розуміє «проблему», яку хоче вирішити ПМ. Якщо немає розуміння проблеми — то потрібно вставити пункт 0) «зрозуміти, чого зараз хоче добитися бізнес»

Після такого аналізу розкаже ПМу про «розклад»:
— скільки займе ресурсів реалізація «по правильному»
— як це можна зробити «швидко», у яких місцях через це будуть створені нові проблеми
— якщо пощастить, то запропонує варіант, коли це взагалі можна або варто не робити (зараз)

І тільки тоді вже візьметься за роботу ;)

Якщо комусь цікаво діліться своїми враженнями.

Враження — спантеличиння.

А ще викликає ряд запитаннь, зокрема:
Навіщо ви написали цей пост?

Про що та утиліта?

Чи ви знали, що в сучасних браузерах вже є вбудований spellcheck?

— Знаешь, как заинтриговать?
— Как?
— Завтра скажу.
©

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

Потому что джунам в самом, самом начале надо рассказывать про YAGNI.

Почти половина проблем в ИТ — из-за оверинжиниринга ;)

Потом про DRY. И что в случае конфликта между YAGNI и DRY приносить в жертву DRY.
И только потом все остальное.

я сча менторю пачку студиков-джунов и понимаю что дай им ваши объяснения

Ну то не давайте ;)

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

Проблемы, которые здесь затронуты — не для джунов.

Надо какое-то время посопровождать legacy-проект, желательно чей-то велосипед, чтобы прочувствовать «боль».

имхо лучше объяснить принципы

Не поверите, но на DOU писать статьи может каждый ;)