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

S>Всё ещё остаётся непонятным, что считается "технической стороной вопроса".

Странный вопрос.

S>Вот здесь под тем, кто знает — кто подразумевается?

Менеджер сам решает, у кого он хочет спросить. Это его работа

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

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

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

Это хороший менеджер, который встречается почти так же редко, как белый слон. А типичный менеджер — обвинит во всем программистов, которые ему "недостаточно хорошо ему объяснили" (С) и заставит работать сверхурочно.

S>Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".

Непонятно только тому, кто его вообще не читал. Я с самого начала написал о случаях, когда рефакторинг не делается вообще.

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

И это — типичнейшая картина, глядя на обычный распространенный софт.

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

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

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

Гениально. Это именно то, что я недавно и писал.

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

S>Всё ещё остаётся непонятным, что считается "технической стороной вопроса".

Странный вопрос.

S>Вот здесь под тем, кто знает — кто подразумевается?

Менеджер сам решает, у кого он хочет спросить. Это его работа

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

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

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

Это хороший менеджер, который встречается почти так же редко, как белый слон. А типичный менеджер — обвинит во всем программистов, которые "недостаточно хорошо ему объяснили" (С) и заставит работать сверхурочно.

S>Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".

Непонятно только тому, кто его вообще не читал. Я с самого начала написал о случаях, когда рефакторинг не делается вообще.

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

И это — типичнейшая картина, глядя на обычный распространенный софт.

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

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

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

Гениально. Это именно то, что я недавно и писал.