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

5er>Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
5er>Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

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

Здравствуйте, Аноним, Вы писали:

А>пара примеров ( ситуаций в жизни больше )

А>например если проект краткосрочный, одноразовый, поддержка не подразумевается, то говнокодом будет являться код который
А>1) пишется дольше обычного, вводятся лишние сущности/слои которые не пригодятся

А>если же проект например большой и долгосрочный, то говнокодом будет является код
А>1) плохо читаемый, плохо документированный
А>2) отсуствие архитектуры позволяющей осуществлять unit-тестирование
А>в общем который будет приводить к убыткам.

Хм. Я как-то рассуждал вслух о чем-то подобном — http://www.rsdn.ru/forum/flame.comp/4424831.flat.aspx

Автор: okman
Дата: 17.09.11

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

А>Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
А>Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
А>Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

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

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

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

Прям гомеопатия какая-то получается

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Рассмотрим ситуации :

А>1 менеджмет-код
А>2 менеджмент-говнокод
А>3 говноменджмент-код
А>4 говноменджмент-говнокод

А>ситуации 2 и 3 — это скорее исключение. При хорошем менеджменте говнокода быть не может, т.к. процесс должен предусматривать контроль качества кода.
А>При говноменджменте, код может получится только если попадется очень толерантный и талантливый разработчик, время жизни такого разработчика в организации стремится к нулю, как правило он увольняется и уходит.


А>остается устойчивых 2 ситуации 1 и 2.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?

А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

При иерархической системе производственных отношений, которая не изменилась еще со времен рабовладельцечкого века, все определяет менеджемент, так как просто может быть некому писать хороший код, так как действительно, а не на словах, квалифицированных программистов либо не возьмут на работу, либо уволят, так как они вступят в конфликт с менеджементом.
Далеко за примерами из жизни ходить не надо. Приведу самый свежий и многим известный пример. Не так давно Медведев проводил заседание правительства, на котором заявил, что провален заказ Министерства обороны. На этом заседании он заявил министрам: "Найдите виновных и их накажите. Иначе я вас сам накажу!"
Теперь другая ситуация. Как известно министр финансов Кудрин выступил с критикой проводимой финансовой политикой. Что с ним сделал Медведев? Уволил!
теперь вернемся к описанному выше заседанию. Итак, заказ Министерства обороны провален. Очевидно в министерствах были специалисты, которые говорили министру, что при таком подходе, заказ будет провален. Теперь что сделает министр? Кого он накажет? Он накажет именно теХ. которые критиковали его действия, заявляя, что заказ ббудет провален! Ведь не ему самому же уходить в отставку, не так ли? Они полностью зеркально повторят действия Медведева, который уволил Кудрина!
Значит специалисты, которые предупреждали, что заказ будет провален, будут уволены! А те, кто тихо сидел и не выступал,те останутся рабоать.
Все абсолютно тоже самое и в программировании, так как это -часть жизни с теми же самыми людьми и их психологией. Не сможет программист перепрыгнуть через голову вышестоящего, если только не найдется еще более вышестоящий, который заинтересован сам в свою очередь уволить этого менеджера проекта.
Поэтому серость всегда живуча, и более того в силу своей серости оона всегда объединяется в стае, так как это единственный способ им выжить, так как квалификацией они не обладают. А специалист — это всегда новатор, всегда человек, который имеет собственное мнение, а не мнение начальника. Поэтому он в первую очередь подвергается гонению.
Я как-то обратил внимание, что как начался кризис, и народ это обсуждалл, то многие заметили, что из организаций увольняют именно специалистов. А почему? Да потому что кто же будет увольнять своего родственника или, например, любовницу, или жену? Это же ударит по его личному семейному бюджету! Ведь жена никуда не денится, ей также надо материально помогать, если ее уволить. А значит, тем самым сокращается семейный бюджет!
дело в том, что в благополучные годы многие устраивают на теплые места своих родственников и знакомых. А специалистов набирают для выполнения основной работы. Но когда начинаются тяжелые времена, то каждый уже думает о своем личном кармане, и наплевать ему на других. Главное — это чтобы сейчас самому не остаться без работы. Ведь, согласитесь, вас лично никогда не волновало, если увольняют вашего коллегу, если только этот коллега не очень близкий вам человек.

Поэтому если плохой менеджемент, то трудно добиться, чтобы вцелом в проекте был хороший код. Понятно, что профессионал как писал качественный код, так и будет его писать. Но оон не в силах повлиять на других, так как оон для других — не начальник. Если начальник не говорит, что все плохо, значит все не плохо!

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

P>Я с большего согласен, и добавлю несколько соображений.

P>* Кроме менеджера есть ещё множество переменных окружения, ведущих к плохому коду. Представьте, что вы унаследовали сташный codebase.

Со страшным codebase, т.е. легаси-код, есть методы борьбы. Если менеджмент понимает это, проект можно реанимировать. Чем более убитый код, тем больше зависимость именно от менеджмента, а не программистов. Убитый код делает создает проблемы на ровном месте. Если менеджмент этого не понимает, то проблемы никогда не будут решены. То есть проект будет становиться все более дорогим.

P>* Хороший менеджмент — не гарантия хорошего кода. Представльте, что в условиях крайне ограниченного бюджета, с командой из джуниоров, менеджер ухитряется держать проект достаточно прибыльным, клиента достаточно довольным, и команде даже местами бонусы перепадают. Но при этом фигурирует ожидаемый говнокод. Был бы менеджер лучше, если б стал горой за качество кода, и потерял бы клиента и/или нанёс ущерб работодателю?

Как то странно рассматривать качество кода отдельно от бизнеса. Качественный код это не тот, который красиво выглядит. Качественный код это такой, который позволяет вводить фичи эффективно (стоимость/время) в краткосрочной, среднесрочной и долгосрочной перспективах.
Например если посрезать все углы( или накопипастить), то фичи появятся очень быстро. Зато через год придется
1 изыскать все места этих ускорений
2 пофиксить их
3 все смежные
4 реализровать фичу, периодически повторяя 1...3

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

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

Не бывает такого. Временные решения == говнокод. done-cbb == говнокод. Решение в лоб == говнокод. Промежуточные решения == говнокод. Решения под старый набор требований == говнокод. Очень тяжело после каждого фикса пересматривать весь проект в целом, потому этапы говнокода у хороших разработчиков чередуются с этапами очистки кода от мусора.

29.12.2011 23:20, minorlogic пишет:

> А>Мой вывод, основанный на печальном опыте, таков, что говноменеджер
> может сделать говнокод, имея даже команду самых лучших программистов.
>
> Лучшие програмисты не допустят навязывания безграмотных технических решений.
Они уволятся (или их уволят). В итоге останется говноменеджер с
говнопрогерами.

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

>> Хороший программист это тот кто выдаёт результат, а не отказывается от
>> результата под каким либо предлогом.
V>В любой сколь угодно малый срок?

А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями) результат. Один из результатов работы программиста это доведение до сведения руководителя о такой вот зависимости в самых разных формах.

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

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

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

IB>Говнокодерам часто дается шанс на исправление (время на переобучение). Воспользуется ли гавнокодер этим шансом трудно предсказать. Если не воспользуется, это отрицательно скажется на качестве продукта на выходе. Увольнять сотрудников при первом же подозрении в говнокоде нельзя, будет большая текучка со всеми вытекающими последствиями. Здесь нужно искать компромисс между строгостью критериев для увольнения и уровнем текучки.

Как я уже сказал, из вас никудышный программист и тем более никудышный менеджер, так как с интеллектом у вас явные проблемы!
На самом деле при хорошем управлении проект совершенно не зависит от того, что какой-то новый сотрудник не умеет писать код. Не в состоянии понять, почему? Я вам объясню!
Во-первых, всегда для новых сотрудников назначают ведущего, задача которого 1) постепенно ввести нового сотрудника в работу в проекте: 2) помогать при написании кода, если новому сотруднику дали самостоятельно реализовать часть проекта.
Но и этого мало!
При реализации задания есть этапы! Например, сначала пишется документ, в котором отражается, что будет сделано и как. Этот документ дается на ревью всем членам проекта. После написания кода снова происходит ревью! То есть новый сотрудник просто будет не в состоянии внести в проект плохой код, так как любое внесение кода в проект отслеживается на всех этапах!

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

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

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

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

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

M>>>Лучшие програмисты не допустят навязывания безграмотных технических решений.

I>>Это каким образом ? Приходит менеджер и говорит — фичу надо сделать завтра. Работы реально около месяца. Неужели самые лучшие программисты могут любую фичу в любой сколь угодно малый срок реализовать ?

M>Я смысла в посте не вижу никакого. А если придет менеджер и скажет что завтра надо долететь до луны? Какое это имеет отношение к моему посту ?

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

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

04.04.2012 9:58, igor-booch написал:

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

Все намного проще — хорошо делаешь только для себя. Это относится к любому виду деятельности, не только к программированию.

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

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

M>Лучшие програмисты не допустят навязывания безграмотных технических решений.

Это каким образом ? Приходит менеджер и говорит — фичу надо сделать завтра. Работы реально около месяца. Неужели самые лучшие программисты могут любую фичу в любой сколь угодно малый срок реализовать ?

29.02.2012 20:55, bkat пишет:

> Какие-то странные менеджеры, занимающиеся не своим делом.
Таких море. Вероятно у тебя просто еще малый опыт. Поработаешь побольше
насмотришься разных клоунов.

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

M>Здравствуйте, <Аноним>, Вы писали:

А>>В жизни мененеджеры не навязывают сортировку пузырьком.

M>Тут половину ветки жалуются что навязывают свои безграмотные технические решения. Я лишь пример придумываю

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

Говноменеджмент — это все же именно менеджмент, а не пузырек vs быстрая сортировка.

02.04.2012 21:35, igor-booch написал:

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

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

Существует ненулевая вероятность, что в Африке обитают летающие крокодилы

Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

Рассмотрим ситуации :

1 менеджмет-код
2 менеджмент-говнокод
3 говноменджмент-код
4 говноменджмент-говнокод

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


остается устойчивых 2 ситуации 1 и 2.

Вопрос возможно риторический, но все же.
Так что на ваш взгляд первичнее менеджмент или код ?

т.е.
получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

А>остается устойчивых 2 ситуации 1 и 2.

Очепятка, устойчивые 1 и 4.

Здравствуйте, Аноним, Вы писали:

А>...

Никто не даст точного определения, что же такое говнокод и говноменеджмент.

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

O>Здравствуйте, Аноним, Вы писали:

А>>...

O>Никто не даст точного определения, что же такое говнокод и говноменеджмент.

Если мое мнение то
определение факта наличия говнокода зависит от проекта, у кода могут быть такие свойства как "читаемость", "тестируемость", "гибкость" и т.д. у каждого свойства есть цена, все требует трудозатрат.

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


пара примеров ( ситуаций в жизни больше )

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

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


Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

Не помню уж кто сказал, что структура кода отражает структуру организации.
Склонен с этим мнением согласиться.

Первичны 2 персонажа: основатель компании и заказчик(и). Они, согласитесь, очень сильно влияют на то, имеет ли шанс развится говнокод/говноменеджмент и прочие занятные вещи.

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

O>Здравствуйте, Аноним, Вы писали:

А>>пара примеров ( ситуаций в жизни больше )

А>>например если проект краткосрочный, одноразовый, поддержка не подразумевается, то говнокодом будет являться код который
А>>1) пишется дольше обычного, вводятся лишние сущности/слои которые не пригодятся

А>>если же проект например большой и долгосрочный, то говнокодом будет является код
А>>1) плохо читаемый, плохо документированный
А>>2) отсуствие архитектуры позволяющей осуществлять unit-тестирование
А>>в общем который будет приводить к убыткам.

O>Хм. Я как-то рассуждал вслух о чем-то подобном — http://www.rsdn.ru/forum/flame.comp/4424831.flat.aspx

Автор: okman
Дата: 17.09.11

O>Суть в том, что код не может оцениваться изолированно, сам по себе, а должен рассматриваться в
O>контексте целей, которые преследует разработка.

А>>Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
А>>Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
А>>Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

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

Но есть и обратная сторона медали, если после того как кусок хлеба будет получен и нужно будет сопровождать проект, то конечные затраты из-за отсуствия нужных свойств кода могут вылиться в то что придется отдать 2 куска хлеба за то чтобы это поддерживать, если изначально условия такие , то лучше остаться с 0 куском хлеба и найти другой проект, чем потратить N лет и в конечном счете лишиться куска.
Тогда п2 будет хреновым менеджментом.

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?
А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

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

У меня в проекте было так, что говноменеджер на протяжении нескольких лет делал следующее:

1) так умудрялся давать задания и устанавливать сроки, чтобы ни одна задача не была сделана как следует, не второпях и не в виде "залепухи". Естественно, чем дальше, тем становилось хуже, так как проблемы и баги в коде только накапливались, но о причинах увеличения сроков на выполнение заданий говноменеджеру объяснять было, естественно, бесполезно;

2) тестирование говноменеджер необходимым не считал, то есть тестирования фактически не было. Естественно, в коде копились целые "системы" багов, компенсирующие друг друга, и при попытке фикса одного бага, часто при решении несвязанной задачи, программист неожиданно получал сразу несколько ужасных багов в разных местах;

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

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

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

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

нет, но и приёмка хреновая

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Рассмотрим ситуации :

А>1 менеджмет-код
А>2 менеджмент-говнокод
А>3 говноменджмент-код
А>4 говноменджмент-говнокод

А>ситуации 2 и 3 — это скорее исключение. При хорошем менеджменте говнокода быть не может, т.к. процесс должен предусматривать контроль качества кода.
А>При говноменджменте, код может получится только если попадется очень толерантный и талантливый разработчик, время жизни такого разработчика в организации стремится к нулю, как правило он увольняется и уходит.


А>остается устойчивых 2 ситуации 1 и 2.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?

А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

Доктор ТуамОсес: "Ты хоть сам-то понял, что написал? "

Здравствуйте, Аноним, Вы писали:
А>Рассмотрим ситуации :
А>1 менеджмет-код
А>4 говноменджмент-говнокод

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

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Рассмотрим ситуации :

А>1 менеджмет-код
А>2 менеджмент-говнокод
А>3 говноменджмент-код
А>4 говноменджмент-говнокод

А>ситуации 2 и 3 — это скорее исключение. При хорошем менеджменте говнокода быть не может, т.к. процесс должен предусматривать контроль качества кода.
А>При говноменджменте, код может получится только если попадется очень толерантный и талантливый разработчик, время жизни такого разработчика в организации стремится к нулю, как правило он увольняется и уходит.


А>остается устойчивых 2 ситуации 1 и 2.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?

А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

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

B>Люди — это то, что первично.
B>Хорошая архитектура не возникает из ничего.
B>Менеджмент запросто может поставить людей в такие условия,
B>что получить хорошую архитектуру будет практически невозжно.
B>Примеров тому полно.

Подтверждаю!

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

O>Никто не даст точного определения, что же такое говнокод и говноменеджмент.

Говноменеджер: "Почему опять нихрена не готово?!"
Говнокодер: "У меня работает!!!"
Говнотестер: уволен/не нанят, в целях сокращения расходов.

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

B>Здравствуйте, 5er, Вы писали:

5er>>Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
5er>>Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

B>Люди — это то, что первично.
B>Хорошая архитектура не возникает из ничего.
B>Менеджмент запросто может поставить людей в такие условия,
B>что получить хорошую архитектуру будет практически невозжно.
B>Примеров тому полно.

Ваш ответ подразумевает создание архитектуры. Т.е. начальный этап. Здесь важен конкретный человек или
группа людей с конкретным опытом и видением перспективы.
Я не об этом. Что дальше?

Приходилось наблюдать развитие проектов 10+ давности, которые
живут, развиваются и продаются до сих пор. Люди, которые начинали эти продукты уже
давно трудятся в других местах. Управления как такого нет, т.к. новый менеджмент меняется
каждые пару лет просто физически не успевая вникнуть во все нюансы.

Да, есть распределение задач, реализация новых фич и т.п. Но в целом фундамент остается
неизменным.

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

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

Здравствуйте, <Аноним>, Вы писали:

А>3) говноменеджер навязывал свои технические решения и любые рацпредложения программистов давил на корню. Сам говноменеджер, хоть и писал сайтики на асп-нете, в программировании — полный ламер, не знающий элементарных вещей.

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

Лучшие програмисты не допустят навязывания безграмотных технических решений.

B>Люди — это то, что первично.
B>Хорошая архитектура не возникает из ничего.
B>Менеджмент запросто может поставить людей в такие условия,
B>что получить хорошую архитектуру будет практически невозжно.
B>Примеров тому полно.

Я с большего согласен, и добавлю несколько соображений.

* Кроме менеджера есть ещё множество переменных окружения, ведущих к плохому коду. Представьте, что вы унаследовали сташный codebase.

* Хороший менеджмент — не гарантия хорошего кода. Представльте, что в условиях крайне ограниченного бюджета, с командой из джуниоров, менеджер ухитряется держать проект достаточно прибыльным, клиента достаточно довольным, и команде даже местами бонусы перепадают. Но при этом фигурирует ожидаемый говнокод. Был бы менеджер лучше, если б стал горой за качество кода, и потерял бы клиента и/или нанёс ущерб работодателю?

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

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

>> Лучшие програмисты не допустят навязывания безграмотных технических решений.
V>Они уволятся (или их уволят). В итоге останется говноменеджер с
V>говнопрогерами.

Хороший программист это тот кто выдаёт результат, а не отказывается от результата под каким либо предлогом.

09.01.2012 12:20, Ikemefula пишет:

> Хороший программист это тот кто выдаёт результат, а не отказывается от
> результата под каким либо предлогом.
В любой сколь угодно малый срок?

09.01.2012 12:48, Ikemefula пишет:

>> > Хороший программист это тот кто выдаёт результат, а не отказывается от
>> > результата под каким либо предлогом.
> V>В любой сколь угодно малый срок?
>
> А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями)
Я понадеялся, что ты сам понимаешь, что пишешь. И зря.

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

>> А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями)
V>Я понадеялся, что ты сам понимаешь, что пишешь. И зря.

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

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

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

Эдакий эльфы из страны чудес.

код и менеджмент связаны следующим образом:

1) Менеджер путем переговоров с заказчиком и программистами определяет сроки реализации, требования к проекту и к его развитию. Заказчик говорит какой срок он хочет, программисты говорят, какой срок они могут выдержать при данных требованиях. На этом этапе наговнять могут все, причем независимо друг от друга.

2) Хороший программист при данных требованиях и сроках, напишет хороший код, плохой программист, при таких же сроках и требованиях напишет плохой код. Здесь может быть нормальный менеджмент и говнокод.

3) Менеджмент предполагает архитектурное планирование, тестирование, code review, code metrics, continues integration, кадровую политику (увольнение, занимание, бонусы). Если это плохо устроено, то и хороший программист может выдать низкий результат. То есть здесь говноменеджмент => говнокод

Вывод: говноменеджмент приводит к говнокоду,
но говнокод может быть и при нормальном менеджменте.

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

А>>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.
M>Лучшие програмисты не допустят навязывания безграмотных технических решений.
Почему же? программисту может быть лень ругаться с менеджерами, он высказал свои соображения, его не полсушали — ну и ладно, дело хозяйское. ответственность на манагере все равно.

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

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

M>Лучшие програмисты не допустят навязывания безграмотных технических решений.

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

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

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


M>>Лучшие програмисты не допустят навязывания безграмотных технических решений.

L>Расскажи, как это делать, пожалуйста?
Делаешь хорошо и все.

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

L>>Расскажи, как это делать, пожалуйста?
M>Делаешь хорошо и все.

Т.е. не выполняешь распоряжения руководства?! Хороший совет, особенно, когда имеешь дело с менеджером со стороны заказчика.

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

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

L>>>Расскажи, как это делать, пожалуйста?
M>>Делаешь хорошо и все.

L>Т.е. не выполняешь распоряжения руководства?! Хороший совет, особенно, когда имеешь дело с менеджером со стороны заказчика.

Обычно так. И стараюсь максимально информировать руководство.

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

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

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

Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.

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

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

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

L>Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.

Всегда надо быть готовым сменить работу. Тогда не будет сложных ситуаций , тем более безвыходных.

Предлагаю определить для себя границу полномочий == ответственности и постараться максимально ясно донести это до руководства. Works for me

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

L>>Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.

M>Всегда надо быть готовым сменить работу. Тогда не будет сложных ситуаций , тем более безвыходных.

Ну, такой "секрет" и я знаю, это неинтересно.

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

IB>код и менеджмент связаны следующим образом:

IB>1) Менеджер путем переговоров с заказчиком и программистами определяет сроки реализации, требования к проекту и к его развитию. Заказчик говорит какой срок он хочет, программисты говорят, какой срок они могут выдержать при данных требованиях. На этом этапе наговнять могут все, причем независимо друг от друга.

IB>2) Хороший программист при данных требованиях и сроках, напишет хороший код, плохой программист, при таких же сроках и требованиях напишет плохой код. Здесь может быть нормальный менеджмент и говнокод.

IB>3) Менеджмент предполагает архитектурное планирование, тестирование, code review, code metrics, continues integration, кадровую политику (увольнение, занимание, бонусы). Если это плохо устроено, то и хороший программист может выдать низкий результат. То есть здесь говноменеджмент => говнокод

IB>Вывод: говноменеджмент приводит к говнокоду,
IB>но говнокод может быть и при нормальном менеджменте.


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

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

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

А>>>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.
M>>Лучшие програмисты не допустят навязывания безграмотных технических решений.
L>Почему же? программисту может быть лень ругаться с менеджерами, он высказал свои соображения, его не полсушали — ну и ладно, дело хозяйское. ответственность на манагере все равно.

Примеров масса может быть. Например написать тест который валится при неправильном решении и т.п.

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

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

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

M>>Лучшие програмисты не допустят навязывания безграмотных технических решений.

I>Это каким образом ? Приходит менеджер и говорит — фичу надо сделать завтра. Работы реально около месяца. Неужели самые лучшие программисты могут любую фичу в любой сколь угодно малый срок реализовать ?

Я смысла в посте не вижу никакого. А если придет менеджер и скажет что завтра надо долететь до луны? Какое это имеет отношение к моему посту ?

У вас не работает простейшая формальная логика. Ни вижу смысла в дальнейшем диалоге.

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

M>У вас не работает простейшая формальная логика. Ни вижу смысла в дальнейшем диалоге.

Не у нас, а у вас.

"Лучшие програмисты не допустят навязывания безграмотных технических решений."
Представь себе команду из лучших программистов. Менеджер хочет продавить очевидно безграмотное решение и программисты отказываются.
Менеджер пишет код сам, как умеет и проводит его в продакшн.
Код в продакшне ? Значит команда программистов не смогла "недопустить навязывания". Следовательно твоё высказывание ложно.

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

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

I>Представь себе команду из лучших программистов. Менеджер хочет продавить очевидно безграмотное решение и программисты отказываются.
I>Менеджер пишет код сам, как умеет и проводит его в продакшн.
I>Код в продакшне ? Значит команда программистов не смогла "недопустить навязывания". Следовательно твоё высказывание ложно.

Какие-то странные менеджеры, занимающиеся не своим делом.
В таких фирмах наверное и уборщицы принимают стратегические решения.
Ну просто по приколу

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

I>>Представь себе команду из лучших программистов. Менеджер хочет продавить очевидно безграмотное решение и программисты отказываются.
I>>Менеджер пишет код сам, как умеет и проводит его в продакшн.
I>>Код в продакшне ? Значит команда программистов не смогла "недопустить навязывания". Следовательно твоё высказывание ложно.

B>Какие-то странные менеджеры, занимающиеся не своим делом.

Лично не наблюдал такую ситуацию, рассказал со слов других. Речь о том, что менеджер может продавливать своё решение.

01.03.2012 13:08, Ikemefula пишет:

> Лично не наблюдал такую ситуацию, рассказал со слов других. Речь о том,
> что менеджер может продавливать своё решение.
Как бы написать так, чтобы и написать и начальников не обидеть.
В Минске я по пальцем одной руки могу пересчитать конторы, где менеджеры
более ни менее грамотные. Там, где ты работаешь к оным не относится.

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

V>Как бы написать так, чтобы и написать и начальников не обидеть.
V>В Минске я по пальцем одной руки могу пересчитать конторы, где менеджеры
V>более ни менее грамотные. Там, где ты работаешь к оным не относится.

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

01.03.2012 19:13, Ikemefula пишет:

> Это ты на основании чего заявляешь ? Если от балды, то вброс годный,
> только хотелось бы подробностей. Если на основании моего примера — он
> как раз про контору где я не работал.
А я так же как ты. Мимо проходил, в окно видел.

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

>> Это ты на основании чего заявляешь ? Если от балды, то вброс годный,
>> только хотелось бы подробностей. Если на основании моего примера — он
>> как раз про контору где я не работал.
V>А я так же как ты. Мимо проходил, в окно видел.

Я выделил

А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.
Павлик, ХВАТИТ!

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

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

DD>Все намного проще — хорошо делаешь только для себя. Это относится к любому виду деятельности, не только к программированию.

Когда шароварщик делает очередную шаровару — для кого он ее делает?

M>Лучшие програмисты не допустят навязывания безграмотных технических решений.

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

L>Почему же? программисту может быть лень ругаться с менеджерами, он высказал свои соображения, его не полсушали — ну и ладно, дело хозяйское. ответственность на манагере все равно.

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

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

M>>Лучшие програмисты не допустят навязывания безграмотных технических решений.

SD>Интересно, как?

Не делать туфту

B>Какие-то странные менеджеры, занимающиеся не своим делом.

Имя таким менеджерам — легион
Увы.

M>Не делать туфту

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

Пример.

Мульйон записей в оперативке которые надо отсортировать. Пишешь std::sort и тут появояется менагер и говорит что знает офигенную сортировку (далее расказывая сортировку пузырьком).

Ваши действия ?

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

SD> Иначе — раз сделано не так, как вы требуете — вы работать прекращаете, садитесь и плюете в потолок.

Один из вариантов. Почему бы не получать деньги за просто так ?

Кстати тупой менеджер это же находка !
На одной из последних работ, моя команда полгода разрабатывала T800 по еженедельным отчетам.

M>На одной из последних работ, моя команда полгода разрабатывала T800 по еженедельным отчетам.

Ах вот кто виноват в ядерной войне будущего!

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

M>Пример.

M>Мульйон записей в оперативке которые надо отсортировать. Пишешь std::sort и тут появояется менагер и говорит что знает офигенную сортировку (далее расказывая сортировку пузырьком).

M>Ваши действия ?

Просто проснусь.
В жизни мененеджеры не навязывают сортировку пузырьком.

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

Здравствуйте, <Аноним>, Вы писали:

А>В жизни мененеджеры не навязывают сортировку пузырьком.

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

Здравствуйте, Аноним, Вы писали:

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

Не надо недооценивать менеджеров. Многие из них вышли из программистов.

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

L>Здравствуйте, Аноним, Вы писали:

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

L>Не надо недооценивать менеджеров. Многие из них вышли из программистов.

"Не способны" надо читать как "не могут и/или нету времени".
Я имею ввиду именно менеджеров, которые все же должны управлять.
Aрхитект, для сравнения, — это такой же технарь, как и программист,
но с немного более широким взглядом на систему.
Пузырек архитекты тоже проталкивать не будут

L>Не надо недооценивать менеджеров. Многие из них вышли из программистов.

Да.
К сожалению

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

M>>>Лучшие програмисты не допустят навязывания безграмотных технических решений.

SD>>Интересно, как?

M>Не делать туфту

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

Итого, решение навязано, разгребать проблемы программистам, хотя они и не дали навязать решение

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

I>Это не решает проблемы. Манагер худо-бедно может и сам влить свой шедевр в репу или найдет того, не в состоянии отказать, или вообще найдет того кто даже задумыватся не будет о подобных мелочах.

I>Итого, решение навязано, разгребать проблемы программистам, хотя они и не дали навязать решение

Если называть синее красным, можно еще долго общаться на эту тему.

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

I>>Это не решает проблемы. Манагер худо-бедно может и сам влить свой шедевр в репу или найдет того, не в состоянии отказать, или вообще найдет того кто даже задумыватся не будет о подобных мелочах.

I>>Итого, решение навязано, разгребать проблемы программистам, хотя они и не дали навязать решение

M>Если называть синее красным, можно еще долго общаться на эту тему.

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

29.03.2012 1:01, Сыроежка написал:

> На самом деле при хорошем управлении проект *совершенно не зависит* от
> того, что какой-то новый сотрудник не умеет писать код.
Подтверждаю. Сам руководил проектом с толпой студентов на нем. И проект
до сих пор живет и здравствует.

Проведите мысленный эксперимент:

2 города, в каждом городе софтверная компания с менеджерами абсолютно одинакового высокого уровня. Этим компаниям заказали делать 2 абсолютно одинаковых проекта. Есть одно отличие: в первом городе высокая средняя квалификация программистов, в втором низкая.

Вы хотите сказать, что результаты у этих компаний будут одинаковыми?

У г-на есть одно удивительное свойство. С чем бы ты его не смешал, в любой пропорции, в итоге получится только г-но.
Дальше думайте сами.

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

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

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

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

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

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

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

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

L>>>Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.

M>>Всегда надо быть готовым сменить работу. Тогда не будет сложных ситуаций , тем более безвыходных.

L>Ну, такой "секрет" и я знаю, это неинтересно.

Я серебряными пулями не торгую

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

L>Здравствуйте, Аноним, Вы писали:

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

L>Не надо недооценивать менеджеров. Многие из них вышли из программистов.

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