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

I>>Нет, не любые. Менеджер, даже пиэм, может быть плохим по самым разным причинам. Например, пить водку вместо работы.

C>Ни одного такого не встречал. А любителей микроменеджмента — очень много, с самым разным бэкграундом.

Как интересно, сначала ты выдал "Любые плохие пиэмы". Теперь не любые а только многие. Эдак ты дойдешь до конкретных вместо многих

I>>Очевидно — нет. Есть общая зона ответствености, пересечение. И это не код.

C>А что, уже научились создавать программы без написания кода?

Похоже, ты не представляешь себе менеджера что в код не смотрит

Вот пример, самый свежий, девелопер создаёт тикет:
"во фремворк надо добавить агент вот такойто с такими то значениями"
мотивация
"это надо, потому что все консумеры должны делать такое а тут неудобно и непонятно"
Чудесно, да? Надо, потому что нада

В этом описании business value отсутствует в принципе. Менеджеру ничего не ясно, вообще ничего.

Вот смотри, мой вариант, в единицах business value

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

Фикс фремворка не требуется, консумеры настраивают свои агенты сами, см доку по настройкам

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

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

В код смотреть не надо.

> В нашей индустрии, нет кода — нет никакого business value. Точка.

business value это фичи, производительность, надежность, секурити, 'time-to-market' т.е. всё, что непосредственно приносит деньги.

Соответсвенно, Не надо показывать код фичи, достаточно её правильно идентифицировать. Вместо "вот код фичи, которая барахлит" достаточно написать
"typeahead морозит инстансы, последствия — от деградации производительности вплоть до отказа инстанца"
причина — "лавина запросов, т.к. нет никакого back pressure".
Менеджеру понятна первая строчка. Последнюю ему понимать уже необязательно и в код лезть тем более.

И совершенно точно лучше не станет, если тикеты будут вида "перенести конфигурацию http agent оттуда сюда" или "передать парамент keepAlive фремворку".

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

I>>Нет, не любые. Менеджер, даже пиэм, может быть плохим по самым разным причинам. Например, пить водку вместо работы.

C>Ни одного такого не встречал. А любителей микроменеджмента — очень много, с самым разным бэкграундом.

Как интересно, сначала ты выдал "Любые плохие пиэмы". Теперь не любые а только многие. Эдак ты дойдешь до конкретных вместо многих

I>>Очевидно — нет. Есть общая зона ответствености, пересечение. И это не код.

C>А что, уже научились создавать программы без написания кода?

Похоже, ты не представляешь себе менеджера что в код не смотрит

Вот пример, самый свежий, девелопер создаёт тикет:
"во фремворк надо добавить агент вот такойто с такими то значениями"
мотивация
"это надо, потому что все консумеры должны делать такое а тут неудобно и непонятно"
Чудесно, да? Надо, потому что нада

В этом описании business value отсутствует в принципе. Менеджеру ничего не ясно, вообще ничего.

Вот смотри, мой вариант, в единицах business value

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

Фикс фремворка не требуется, консумеры настраивают свои агенты сами, см доку по настройкам

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

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

В код смотреть не надо.

> В нашей индустрии, нет кода — нет никакого business value. Точка.

business value это фичи, производительность, надежность, секурити, 'time-to-market' т.е. всё, что непосредственно приносит деньги.

Соответсвенно, Не надо показывать код фичи, достаточно её правильно идентифицировать. Вместо "вот код фичи, которая барахлит" достаточно написать
"typeahead морозит инстансы, последствия — от деградации производительности вплоть до отказа инстанца"
причина — "лавина запросов, т.к. нет никакого back pressure".
Менеджеру понятна первая строчка. Последнюю ему понимать уже необязательно и в код лезть тем более.

И совершенно точно лучше не станет, если тикеты будут вида "перенести конфигурацию http agent оттуда сюда" или "передать параметр keepAlive фремворку", "refactor the smelly code" + ссылка место в коде в репозитрии