Здравствуйте, Codealot, Вы писали:
C>Коллега, тебе надо всё же определиться — либо надеть трусы, либо снять крестик.

C>То есть, либо менеджер не разбирается в технической стороне вопроса, и в таком случае он делегирует технические обязанности кому-то более знающему и в микроменеджмент не лезет.
Всё ещё остаётся непонятным, что считается "технической стороной вопроса".

C>Он передает девменеджеру/архитектору/тимлиду/главному-по-бараку/кому-там-еще пожелания заказчика, и в ответ получает примерный расклад по задачам, которые нужно выполнить. Если есть разные варианты реализации — значит, по нескольким вариантам. Которые он распределяет в соответствии со сроками или откладывает на потом, если сроки жмут, а задача не особо важная.
Да, примерно так и есть.
C>Если менеджер не понимает, важна ли задача — он спрашивает про это у того, кто знает.
Вот здесь под тем, кто знает — кто подразумевается?

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

C>Либо же он считает себя самым умным по всем вопросам и лезет решать технические вопросы сам, но в таком случае, если выбор оказался плохим — виноват только он сам. И его блеяние о том, что кто-то ему что-то недостаточно хорошо объяснил — всего лишь оправдание своей некомпетентности.
Менеджер не считает себя самым умным, но ответственность несёт именно он. Если проект будет провален потому, что кодеры занимались рефакторингом вместо того, чтобы приносить пользу, то менеджера трахнут. А кодеров просто переведут на другой проект — они же не делали ничего плохого; им утвердили задачу рефакторить, они и рефакторили.
Поэтому таки да, хороший менеджер всегда спрашивает

C>Ну и наконец, ты подменил предмет спора. Я писал не о таких случаях, когда кто-то с кем-то не договорился о том, какой рефакторинг надо делать. А о таких, когда рефакторинг не делается вообще в принципе.
Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".
Во-вторых, любые "рефакторинг не делается никогда" состоят из отдельных "нет, вот этот рефакторинг мы делать не будем". У каждого из которых могут быть причины.
В-третьих, нет ничего плохого в том, что рефакторинг не делается вообще никогда в принципе. У рефакторинга самостоятельной ценности нету. Если из-за этого отказа рефакторить страдают какие-то наблюдаемые характеристики — то это одна история, а если нет — то совсем другая.
Да, я могу себе представить тупого менеджера, который сначала принимает решение выбрать из двух способов решения задачи более дешёвый и грязный, типа "завайте сейчас захачим, а порефакторим в следующем релизе", а в следующем релизе отказывается рефакторить, т.к. мало ли что там обсуждалось ранее. Ну, как бы даже этот менеджер рано или поздно упрётся в то, что дальнейшие "полезные" изменения стоят всё больше и больше, и будет вынужден одобрить рефакторинг.
А если нет — то, значит, и рефакторинг в данном проекте вовсе не так полезен, как кажется на первый взгляд.

C>То есть твой менеджер всё же знает, чем отличается линукс от винды и чем чреват тот или иной выбор.
В каком смысле "знает"? С тем же успехом можно обсуждать переход с бензина на газ или с 95 на дизель. С точки зрения управленческой науки — ровно то же самое. Заказчику нужно, чтоб работало на газу, мы поставляем движки на бензине.
Всё, что нужно знать — это что нельзя заправлять газом бензиновый движок, и стоимости переоборудования в ту или иную сторону.
"Чреватость" в данном случае — это выполнение либо невыполнение требований заказчика.

C>Он не требует, чтобы ему за 5 минут все в деталях объяснили, а когда он не может понять — не устраивает истерику, что ему недостаточно хорошо объяснили.
C>Правильно?
Эмм, истерику-то устраивать вообще плохая идея. Но у меня из десятков знакомых менеджеров разных уровней (от линейных до вице-президентов и президентов компаний) истеричек было полтора штуки.
А вот тренировать персонал так, чтобы они могли объяснить свою мысль за пять минут — идея хорошая.
Обычно, если обе стороны диалога достаточно компетентны, то даже если менеджеру сначала приходится очень подолгу получать ответы на свои вопросы, то постепенно происходит притирка.
Менеджер уже знает, что линукс с виндой совместим ограниченно, и что рефакторинг суть реорганизация кода без изменения функциональных требований с целью изменения нефункциональных; разработчики привыкают, что надо всегда быть готовым выражать свою идею в терминах наблюдаемых характеристик. И не встают стобом при вопросах "на что это повлияет", "что изменится, если мы это сделаем не сейчас, а через полгода", и "сколько времени вам на это нужно".

C>Такими вопросами должны заниматься кодеры от сеньора и выше, менеджера такие вопросы волновать вообще не должны. Микроменеджмент.
Какими вопросами? Какую библиотеку выбрать для генерации PDF? Под какие браузеры тестировать веб-приложение? Использовать ли в проекте хранимые процедуры? Откуда брать картинки для шаблонов?
Распределение ролей в компании или команде может быть разным. Но вообще такие вещи должны быть как минимум согласованы с менеджером.

Без этого бывают интересные последствия, которые потом сильно влияют на успех компании. Я лично наблюдал много интересных историй на эту тему, и даже не все из них под NDA.
Кодер, который разбирается во всех аспектах разработки, от юридических и эстетических до финансовых и литературных — штука хорошая, но в природе почти не встречается.
Проще нанять менеджера, который будет заниматься всеми вопросами взаимодействия, а кодер будет заниматься своим делом — писать код.

Здравствуйте, Codealot, Вы писали:
C>Коллега, тебе надо всё же определиться — либо надеть трусы, либо снять крестик.

C>То есть, либо менеджер не разбирается в технической стороне вопроса, и в таком случае он делегирует технические обязанности кому-то более знающему и в микроменеджмент не лезет.
Всё ещё остаётся непонятным, что считается "технической стороной вопроса".

C>Он передает девменеджеру/архитектору/тимлиду/главному-по-бараку/кому-там-еще пожелания заказчика, и в ответ получает примерный расклад по задачам, которые нужно выполнить. Если есть разные варианты реализации — значит, по нескольким вариантам. Которые он распределяет в соответствии со сроками или откладывает на потом, если сроки жмут, а задача не особо важная.
Да, примерно так и есть.
C>Если менеджер не понимает, важна ли задача — он спрашивает про это у того, кто знает.
Вот здесь под тем, кто знает — кто подразумевается?

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

C>Либо же он считает себя самым умным по всем вопросам и лезет решать технические вопросы сам, но в таком случае, если выбор оказался плохим — виноват только он сам. И его блеяние о том, что кто-то ему что-то недостаточно хорошо объяснил — всего лишь оправдание своей некомпетентности.
Менеджер не считает себя самым умным, но ответственность несёт именно он. Если проект будет провален потому, что кодеры занимались рефакторингом вместо того, чтобы приносить пользу, то менеджера трахнут. А кодеров просто переведут на другой проект — они же не делали ничего плохого; им утвердили задачу рефакторить, они и рефакторили.
Поэтому таки да, хороший менеджер всегда спрашивает у технических специалистов про последствия тех или иных решений. Но берёт ответственность за решения на себя.

C>Ну и наконец, ты подменил предмет спора. Я писал не о таких случаях, когда кто-то с кем-то не договорился о том, какой рефакторинг надо делать. А о таких, когда рефакторинг не делается вообще в принципе.
Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".
Во-вторых, любые "рефакторинг не делается никогда" состоят из отдельных "нет, вот этот рефакторинг мы делать не будем". У каждого из которых могут быть причины.
В-третьих, нет ничего плохого в том, что рефакторинг не делается вообще никогда в принципе. У рефакторинга самостоятельной ценности нету. Если из-за этого отказа рефакторить страдают какие-то наблюдаемые характеристики — то это одна история, а если нет — то совсем другая.
Да, я могу себе представить тупого менеджера, который сначала принимает решение выбрать из двух способов решения задачи более дешёвый и грязный, типа "завайте сейчас захачим, а порефакторим в следующем релизе", а в следующем релизе отказывается рефакторить, т.к. мало ли что там обсуждалось ранее. Ну, как бы даже этот менеджер рано или поздно упрётся в то, что дальнейшие "полезные" изменения стоят всё больше и больше, и будет вынужден одобрить рефакторинг.
А если нет — то, значит, и рефакторинг в данном проекте вовсе не так полезен, как кажется на первый взгляд.

C>То есть твой менеджер всё же знает, чем отличается линукс от винды и чем чреват тот или иной выбор.
В каком смысле "знает"? С тем же успехом можно обсуждать переход с бензина на газ или с 95 на дизель. С точки зрения управленческой науки — ровно то же самое. Заказчику нужно, чтоб работало на газу, мы поставляем движки на бензине.
Всё, что нужно знать — это что нельзя заправлять газом бензиновый движок, и стоимости переоборудования в ту или иную сторону.
"Чреватость" в данном случае — это выполнение либо невыполнение требований заказчика.

C>Он не требует, чтобы ему за 5 минут все в деталях объяснили, а когда он не может понять — не устраивает истерику, что ему недостаточно хорошо объяснили.
C>Правильно?
Эмм, истерику-то устраивать вообще плохая идея. Но у меня из десятков знакомых менеджеров разных уровней (от линейных до вице-президентов и президентов компаний) истеричек было полтора штуки.
А вот тренировать персонал так, чтобы они могли объяснить свою мысль за пять минут — идея хорошая.
Обычно, если обе стороны диалога достаточно компетентны, то даже если менеджеру сначала приходится очень подолгу получать ответы на свои вопросы, то постепенно происходит притирка.
Менеджер уже знает, что линукс с виндой совместим ограниченно, и что рефакторинг суть реорганизация кода без изменения функциональных требований с целью изменения нефункциональных; разработчики привыкают, что надо всегда быть готовым выражать свою идею в терминах наблюдаемых характеристик. И не встают стобом при вопросах "на что это повлияет", "что изменится, если мы это сделаем не сейчас, а через полгода", и "сколько времени вам на это нужно".

C>Такими вопросами должны заниматься кодеры от сеньора и выше, менеджера такие вопросы волновать вообще не должны. Микроменеджмент.
Какими вопросами? Какую библиотеку выбрать для генерации PDF? Под какие браузеры тестировать веб-приложение? Использовать ли в проекте хранимые процедуры? Откуда брать картинки для шаблонов?
Распределение ролей в компании или команде может быть разным. Но вообще такие вещи должны быть как минимум согласованы с менеджером.

Без этого бывают интересные последствия, которые потом сильно влияют на успех компании. Я лично наблюдал много интересных историй на эту тему, и даже не все из них под NDA.
Кодер, который разбирается во всех аспектах разработки, от юридических и эстетических до финансовых и литературных — штука хорошая, но в природе почти не встречается.
Проще нанять менеджера, который будет заниматься всеми вопросами взаимодействия, а кодер будет заниматься своим делом — писать код.