Design review

[Херовимчик]

Ну знаете, там где делают ревью не просто в PR/CL, а с митингами и матюками…
У кого есть опыт, и какие стратегии чтобы победить?

Проблема очень смешная. Давным-давно, нашла большое упущение, предложила решение. Все хорошо, VP в ладоши похлопал, потенциальные пользователи протянули руки «дай», данные с полей прекрасные, медали розданы, респект и уважуха от коллег получены. Но! Изменение до сих пор не сдано, потому что взрослые товарищи честно сказали (после пыток), «чего-то стремно. А может не надо?». Опасения не напрасные, изменения в основе-основ (память), и если что пойдёт не так, отлавливать это будет очень сложно и дорого.

Вообщем, я их понимаю, и переживания разлепляю. Поэтому пошла в атаку и забила с ним ревью в виде митинга. Внимание вопросы:
- как подготовиться (исторические данные и прогнозы на будущее собрала, тестовые данные есть, причина нафига надо - тоже). Стоит ли рисовать всякие диаграммки и прочую хрень?
- как убедить 4х Стаффов дать хоть какой-то фидбек? Молчат как рыбы, ни да, ни нет
- сколько нужно выпить для храбрости? (шутка)

Ну и общие советы, у нас такой формат вообще не в ходу. Лично никогда не присутствовала, но т.к. я организатор, то хочется продумать структуру заранее.
Пока план:
- найти удаленную машину, куда мы все дружно зайдём и сможем тыкать код лично (без этих дурацких «scroll up/down… to far, scroll back a bit).
- прям там же, всем дружно вести записи и идеи в блокнотике (и потом носом всех ткнуть в качестве follow up).
- подготовить все мыслимые спеки

[nyekimov]

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

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

Сын отцу программисту - папа, папа, а почему солнце встаёт сутра и заходит вечером?
Папа: каждый день так? Ты проверял?
Да, пап, каждый день!
Если работает, то нетрожь!

У нас в таких случаях начинаем с тех, кому больше колется. И я сам буду действовать без раздумий, если 100% уверен в исходе.
Блин ещё hardware походу да? В софт я бы обсудил пилотный подход, давайте по feature switch выпустим на группу по какому то признаку, например географическому. И если все ок; то постепенно наращивать переход. Если где то новые ошибки касаемые нововведения, то откат.

[Херовимчик]

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

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

Сын отцу программисту - папа, папа, а почему солнце встаёт сутра и заходит вечером?
Папа: каждый день так? Ты проверял?
Да, пап, каждый день!
Если работает, то нетрожь!

У нас в таких случаях начинаем с тех, кому больше колется. И я сам буду действовать без раздумий, если 100% уверен в исходе.
Блин ещё hardware походу да? В софт я бы обсудил пилотный подход, давайте по feature switch выпустим на группу по какому то признаку, например географическому. И если все ок; то постепенно наращивать переход. Если где то новые ошибки касаемые нововведения, то откат.

Не, не железо, прошивка (самое сердце выделения памяти). Проблема скаллабмлити, важна как для заказчика, так и для разработки (30% улучшения перфоманса на каждую итерацию, при топ конфиге цифры очень ощутимые).
Все сделано по уму, включать можно по одному, собственно так с полей (у заказчика) данные и собирали. Но мы все равно все дружно очкуем )))

(Вопрос не сдать любой ценной, вопрос грамотно все потыкать со всех сторон и свести риски к минимуму)

[Мальчик-Одуванчик]

(Вопрос не сдать любой ценной, вопрос грамотно все потыкать со всех сторон и свести риски к минимуму)

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

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

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

[Херовимчик]

(Вопрос не сдать любой ценной, вопрос грамотно все потыкать со всех сторон и свести риски к минимуму)

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

Одна строчка, тупо «выкл». Хуже того, предусмотрен откат к оригинальной имплементации при любой ошибке. По моим прикидкам, уже максимум через полгода нам будут выдавать люлюей за перфоманс официально.
Это одноразовая операция, один раз сделал и забыл, никакой поддержки не требуется

[Мальчик-Одуванчик]

Это одноразовая операция, один раз сделал и забыл, никакой поддержки не требуется

То есть другие устройства, системы сбора метрик этого даже не заметят?

[Helmsman]

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

Ну так через 5 месяцев и подать как proactive performance improvement.

[Мальчик-Одуванчик]

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

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

[BitterSean]

Это одноразовая операция, один раз сделал и забыл, никакой поддержки не требуется

Не перестаю вами восхищаться.

[Херовимчик]

Это одноразовая операция, один раз сделал и забыл, никакой поддержки не требуется

То есть другие устройства, системы сбора метрик этого даже не заметят?

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

Риски высокие, вещь нужная (все 4го согласны). Но они достали тянуть резину, сидеть ждать пока официально бить будут - не хочу. Ищу совета как устроить массовое избиение старших по званию…

(Неофициальную бету давно откатали уже)

[Херовимчик]

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

Ну так через 5 месяцев и подать как proactive performance improvement.

Это как раз сейчас оно proactive, а через 5 месяцев - build blocker, с вызовом на ковёр каждый день

[Мальчик-Одуванчик]

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

[Херовимчик]

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

Да, один из вариантов опять уговорить парочку PM-ов на пилот программу. Но тогда мне ещё нужен план как замочить моего менеджера, потому что это он в прошлый заход все прошлёпал на финальном этапе и не смог дожать этих 4м (меня выдернули на другой проект и он мамой клялся, что все сделает в лучшем виде!)

[Мальчик-Одуванчик]

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

[Lisa]

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

Ну так через 5 месяцев и подать как proactive performance improvement.

Это как раз сейчас оно proactive, а через 5 месяцев - build blocker, с вызовом на ковёр каждый день

Кого будут вызывать на ковёр? Они об этом знают?

[Мальчик-Одуванчик]

Но тогда мне ещё нужен план как замочить моего менеджера, потому что это он в прошлый заход все прошлёпал на финальном этапе и не смог дожать этих 4м (меня выдернули на другой проект и он мамой клялся, что все сделает в лучшем виде!)

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

[Херовимчик]

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

Этот вариант держу как совсем экстренный, скип жует попкорн и ждет когда сдамся и приду за помощью

Кого будут вызывать на ковёр? Они об этом знают?

Преимущественно меня, им только по касательной прилетит (можно ещё официальный фидбек на них дать и подпортить ревью слегка).

[Мальчик-Одуванчик]

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

Этот вариант держу как совсем экстренный, скип жует попкорн и ждет когда сдамся и приду за помощью

А запустить в прод эту высокорисковую версию точно в Ваших полномочиях?

[Херовимчик]

Но тогда мне ещё нужен план как замочить моего менеджера, потому что это он в прошлый заход все прошлёпал на финальном этапе и не смог дожать этих 4м (меня выдернули на другой проект и он мамой клялся, что все сделает в лучшем виде!)

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

На эту редиску-менеджера у меня уже 3 Тома доказательной базы есть. С ним вопрос почти закрыт. Но помощи конкретно от него вообще не будет, да и он ни разу не авторитет у этих товарищей. Я себе ставлю цель ещё месяц повоевать, и пускать в ход тяжёлую артиллерию - вышестоящее начальство (1 из 4 его direct report).

[nyekimov]

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

Согласен. Обоими руками за совет.

Суть в том, что вот представьте, что вы ( обращение к тс ) одна из стаф инженеров к которому пришёл кто то другой и просит дать добро на исправление. Хм, тут надо вникнуть, проверить, все ли было сделано, то есть провести свой анализ, а все ради чего? Ведь если проблем нет, то все основные плюшки пришедшему - проявил инициативу. Если же проблемы, то и тебе может прилететь - куда смотрел?! Назовёте их, а где гарантия, что потом вспомнят, кто назвал? Но в первую очередь, если у самого завал, то как раз таки и нужно вышестоящее руководство, чтобы перераспределить приоритеты и дать толчок.
Ну и конечно если просит вышестоящее руководство. То оно в курсе своих просьб. Я просто сам встречал и такие ситуации, когда шёл навстречу, вкладывал личное время, нужно же и по своим таскам успеть, а тут раз и человек потом технично молчит о чужом вкладе. А некоторые прикиньте, потом ещё жаловались, что их тормозили! А если приоритет высокий, то ко мне это сверху придёт как убедительная просьба, я ещё сразу поторгуюсь о том, что мне за это будет, а там можно и вникать в проблему.
Ну а когда сразу 4 убедить надо, то вообще засада, каждый полагает, что кто то другой из оставшихся троих вникнет и замолвит слово, тогда и на него можно будет переложить ответственность за решение.

[Херовимчик]

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

Этот вариант держу как совсем экстренный, скип жует попкорн и ждет когда сдамся и приду за помощью

А запустить в прод эту высокорисковую версию точно в Ваших полномочиях?

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

[Мальчик-Одуванчик]

Мне еще не совсем понятно "и если что пойдёт не так, отлавливать это будет очень сложно и дорого"
В чем риск, если есть возможность откатиться?

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

[Херовимчик]

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

Согласен. Обоими руками за совет.

Суть в том, что вот представьте, что вы ( обращение к тс ) одна из стаф инженеров к которому пришёл кто то другой и просит дать добро на исправление. Хм, тут надо вникнуть, проверить, все ли было сделано, то есть провести свой анализ, а все ради чего? Ведь если проблем нет, то все основные плюшки пришедшему - проявил инициативу. Если же проблемы, то и тебе может прилететь - куда смотрел?! Назовёте их, а где гарантия, что потом вспомнят, кто назвал? Но в первую очередь, если у самого завал, то как раз таки и нужно вышестоящее руководство, чтобы перераспределить приоритеты и дать толчок.
Ну и конечно если просит вышестоящее руководство. То оно в курсе своих просьб. Я просто сам встречал и такие ситуации, когда шёл навстречу, вкладывал личное время, нужно же и по своим таскам успеть, а тут раз и человек потом технично молчит о чужом вкладе. А некоторые прикиньте, потом ещё жаловались, что их тормозили! А если приоритет высокий, то ко мне это сверху придёт как убедительная просьба, я ещё сразу поторгуюсь о том, что мне за это будет, а там можно и вникать в проблему.
Ну а когда сразу 4 убедить надо, то вообще засада, каждый полагает, что кто то другой из оставшихся троих вникнет и замолвит слово, тогда и на него можно будет переложить ответственность за решение.

Я их полностью понимаю! Мне уже даже промо за это дали, а им - тратить кучу времени, да ещё и риски что проглядели косяк какой.
Но если я на них натравлю их начальство, то они тоже меня сильно за это любить не будут!

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

[Мальчик-Одуванчик]

А запустить в прод эту высокорисковую версию точно в Ваших полномочиях?

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

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

[Херовимчик]

Мне еще не совсем понятно "и если что пойдёт не так, отлавливать это будет очень сложно и дорого"
В чем риск, если есть возможность откатиться?

Потому что это память. Такие баги обычно из разряда «появляется только если почесать пяткой за правым ухом во-время полнолуния». Отвалиться может как у непосредственного пользователя этого изменения, так и у совершенно левых потребителей памяти (получит неправильный тип памяти при вызове malloc), и пойди потом пойми почему какой-то совершенно левый драйвер вдруг стал работать в 2 раза медленнее. Причём случиться это может только на 1001 вызов, или потому что включили логгер.