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

C>Ничего подобного я и не писал. Речь шла о базовом понимании того, что происходит в коде.
Что это за зверь "базовое понимание"? Что именно должен понимать менеджер, чтобы успешно управлять проектом?
Ну, вот я к примеру, знаю определение термина "рефакторинг". Кстати, ваше понимание, судя по комментам в других ветках, от него отличается.
Это не означает, что я просто буду разрешать разработчикам списывать произвольные объёмы работ на слово "рефакторинг", потому что "я обязан понимать ценность рефакторинга самостоятельно".
Нет уж, это разработчик обязан быть готов мне рассказать, что за рефакторинг он хочет провести, почему именно сейчас, и для чего нам это полезно.
Должна быть простая и понятная логическая цепочка — например, мы хотим избавиться от завязанности на библиотеку X, потому что у неё перестали выходить новые версии.
Сама замена библиотеки — дело тяжкое, в этот релиз может не влезть. Но мы можем потратить немножко времени в этом релизе для того, чтобы выделить взаимодействие с этой библиотекой в отдельный компонент, что позволит нам легко её заменить в следующем релизе.

C>И очень важное следствие, которое вытекает из этого пункта. В дальнейшем, его задача — не лезть в принятые ими технические решения. Потому что они разбираются в этих вопросах лучше.
Конечно же он будет лезть в принятые технические решения. Потому что он должен оценивать последствия этих решений не только для кодинга, но и много для чего ещё. Например, для мейнтенанса, для саппорта, для внедрения.
Какой-нибудь банальный переезд с .Net FW на .Net Core — стоит ли его делать? Джуны в столовой могут глотки сорвать, споря про "за" и "против".
Увы — только менеджер в курсе, обрадуются ли клиенты возможности переехать с винды на линукс или нет.
И запросто может оказаться так, что "техническое" решение, которое было супер-актуальным вчера, сегодня внезапно уже не нужно и даже вредно. Например, потому что проспект, который собирался заплатить $7500000 инсталляцию и кровь из носу требовал всё только на линуксе, вдруг поговорил со своим CIO и тот ему сказал, что поднять одну машинку с виндой — дело плёвое, тем более это можно сделать в Azure. И они лучше так и сделают, потому что это означает лонч в мае, а не "потом когда мы выпустим новую версию".

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

Девелопера может оскорблять то, как реализована в приложении выгрузка .csv — он-то знает способ лучше!
А вот менеджер может увидеть, что реализация — good enough, и не надо там ничего оптимизировать. Клиентов устраивает 30 секунд ждать файл вместо трёх.
Зато вот добавить в начало .csv строчку с "sep=," — это отличная фича, потому что теперь эти CSV будут корректно открываться экселем в Испании и России. Мы на это выделим часы, и даже упомянем это в релиз нотах и в презентации для channel, потому что интернационализация прекрасно согласуется с целями компании, заданными на 2020 год.

C>Твое дальнейшее словесное извержение просто скипаю по причине его бессмысленности.
Ну, как известно, [i]понимание/i] передать невозможно — только информацию. Осознать, как на самом деле обстоят дела, вам придётся самостоятельно. Ещё одна хорошая новость — это возможно.
Лет пятнадцать тому назад я примерно так же относился к менеджерам. К счастью, опыт помогает развиваться. Один из самых замечательных менеджеров, которых я встречал за мою карьеру, имел гуманитарное образование (юрист) и код не мог читать даже со словарём.
При этом техническое образование и глубокое знание кода никак не мешало одному из моих бывших коллег быть просто хреновейшим менеджером, после ухода которого все вздохнули с облегчением.

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

C>Ничего подобного я и не писал. Речь шла о базовом понимании того, что происходит в коде.
Что это за зверь "базовое понимание"? Что именно должен понимать менеджер, чтобы успешно управлять проектом?
Ну, вот я к примеру, знаю определение термина "рефакторинг". Кстати, ваше понимание, судя по комментам в других ветках, от него отличается.
Это не означает, что я просто буду разрешать разработчикам списывать произвольные объёмы работ на слово "рефакторинг", потому что "я обязан понимать ценность рефакторинга самостоятельно".
Нет уж, это разработчик обязан быть готов мне рассказать, что за рефакторинг он хочет провести, почему именно сейчас, и для чего нам это полезно.
Должна быть простая и понятная логическая цепочка — например, мы хотим избавиться от завязанности на библиотеку X, потому что у неё перестали выходить новые версии.
Сама замена библиотеки — дело тяжкое, в этот релиз может не влезть. Но мы можем потратить немножко времени в этом релизе для того, чтобы выделить взаимодействие с этой библиотекой в отдельный компонент, что позволит нам легко её заменить в следующем релизе.

C>И очень важное следствие, которое вытекает из этого пункта. В дальнейшем, его задача — не лезть в принятые ими технические решения. Потому что они разбираются в этих вопросах лучше.
Конечно же он будет лезть в принятые технические решения. Потому что он должен оценивать последствия этих решений не только для кодинга, но и много для чего ещё. Например, для мейнтенанса, для саппорта, для внедрения.
Какой-нибудь банальный переезд с .Net FW на .Net Core — стоит ли его делать? Джуны в столовой могут глотки сорвать, споря про "за" и "против".
Увы — только менеджер в курсе, обрадуются ли клиенты возможности переехать с винды на линукс или нет.
И запросто может оказаться так, что "техническое" решение, которое было супер-актуальным вчера, сегодня внезапно уже не нужно и даже вредно. Например, потому что проспект, который собирался заплатить $7500000 инсталляцию и кровь из носу требовал всё только на линуксе, вдруг поговорил со своим CIO и тот ему сказал, что поднять одну машинку с виндой — дело плёвое, тем более это можно сделать в Azure. И они лучше так и сделают, потому что это означает лонч в мае, а не "потом когда мы выпустим новую версию".

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

Девелопера может оскорблять то, как реализована в приложении выгрузка .csv — он-то знает способ лучше!
А вот менеджер может увидеть, что реализация — good enough, и не надо там ничего оптимизировать. Клиентов устраивает 30 секунд ждать файл вместо трёх.
Зато вот добавить в начало .csv строчку с "sep=," — это отличная фича, потому что теперь эти CSV будут корректно открываться экселем в Испании и России. Мы на это выделим часы, и даже упомянем это в релиз нотах и в презентации для channel, потому что интернационализация прекрасно согласуется с целями компании, заданными на 2020 год.

C>Твое дальнейшее словесное извержение просто скипаю по причине его бессмысленности.
Ну, как известно, понимание передать невозможно — только информацию. Осознать, как на самом деле обстоят дела, вам придётся самостоятельно. Ещё одна хорошая новость — это возможно.
Лет пятнадцать тому назад я примерно так же относился к менеджерам. К счастью, опыт помогает развиваться. Один из самых замечательных менеджеров, которых я встречал за мою карьеру, имел гуманитарное образование (юрист) и код не мог читать даже со словарём.
При этом техническое образование и глубокое знание кода никак не мешало одному из моих бывших коллег быть просто хреновейшим менеджером, после ухода которого все вздохнули с облегчением.