Егор, привет. Внезапно наткнулся на твою статью, и она как откликнулась моей болью, может что-то посоветуешь. Привет от бывшего длинноволосого Артура)
Есть продукт, довольно большая CRM, в которой много разных направлений живут со своими воронками, отчетами и прочими радостями, частично или полностью пересекаясь. Изначальная документация кривая и больше техническая, не хватает как раз понимания, что на что влияет, как следствие версии при выходе часто ломают что-то старое. Собрать тест-кейсы для регресса так же тяжело, так как тестеры в продукте всегда свежие, и посадить их за описание - это по сути на месяц садить их учить, что мы делаем, и черкз 2 месяца все по новой (оргдизайн управления проектный, люди бегают, никто не в продукте). С чего и через кого лучше начать описание всего, что есть с взаимосвязями между фичами и структурными блоками?
Похожую схему делали с кластером редиса, в принципе не могу сказать, что в чем-то концептуальные отличия, так же сваренный синхронизатор, структура БД для хранения, и индексы. Коллеги просто не стали описывать типовые процедуры прогрева редиса в первый раз, перезапись в случае сбоев из БД и так далее. Персистентность нужна для того, чтобы не приходилось кэш обнулять и перезаписывать, это довольно затратная по ресурсам операция, типа "а давай-ка 100500 записей удалим, а то есть подозр, что какие-то из них битые, и запишем заново" - и хренак, на 4-6 часов у тебя инстанс вылетает из пула, перезаписывается, и так все по очереди (мы же не дурачки, да, в одном кеше все хранить, нужен кластерок). И тут тоже свои песни возникают, типа "а если за время синхронизации еще записей появилось? А если изменилось что-то в бд? - то есть еще возникает некая промежуточная шина, в которую на время обновления пишутся события обновления, чтобы потом после полной перезаписи их раздать, и так по каждому инстансу кеша. Короч, решение скажем так сложнее, чем тцт описано, но у ребят явно не было цели описать все, скорее "а как заманить к ним в команду клиента, которому это надо".
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
Но ты же при этом понимаешь, что ВЕРОЯТНОСТЬ, что человек окажется завтра на войне/взломан/убит/закрыт великим файрволом в подворотне ниже в условной Голландии, чем в РФ? А жизнь - это череда вероятностей, и работа по митигации рисков бизнеса - это ключевая задача СБ/ИБ. Рынок вне РФ чуть более конкурентен со стороны работодателя, и поэтому они могут выбирать. Это у себя на стуле ты хороший. А он видит 70 стульев, где все хорошие, и ему проще выбрать тот стул, который хорош со всех сторон)
слушай, мы с моей прошлой командой прям друзья. Вместе тусим, ходим по барам, ходим в гости друг к другу, играем на гиатрке, снова пьем, говорим о чем угодно и так далее. Вы почему-то ограничиваетесь работой как работой - делать таски и получать зп. Это тоже важно и нужно, но чьерт побьери, я могу делать таски и получать зп и все, а могу делать таски, получать зп и круто проводить время в компании друзей. Это никак не мешает мне делать свою работу. Никто не мешает мне шутить и смеяться, даже если полный треш вокруг. Потому что с грустным хлебалом я уже работал, больше не хочу. И поверь, если ты сам открыт к людям, то и люди к тебе открыты. Если ты понимаешь, что у условного Сани вечером др, ты никогда в жизни не запланируешь на него какой-то левый кранч. Если ты знаешь, что Юльке в 6 надо быть в садике, ты будешь планировать спринты и ее загрузку с учетом этого знания, а не "я чет там напланировал, а команда опять меня подвела".
И если у пацанов и чик проблемы на работе или вне ее - мы их реально перетрем, что на ретро, что в баре, так как мы бро, а бро слушает своего бро, ферштейн? И проблема решится, потому что если бро в соло не может, мы ему поможем на том или ином уровне. Я вот продакт, и мог прийти и попросить к линейным рукам бабок тому или иному сотруднику, потому что его уже заманало, а морально не умеет просить. А мне черт возьми не жалко, мне жалко, если я хорошего человека и сотрудника из команды потеряю. Если он будет ходить унылым и не хотеть делать свою работу (а че мы потом в баре обсудим?!) Если есть тела, которые не влились, то можно ж вместе их подкалывать?
Так что я тут с ТСом согласен от и до - нормально общаешься - быстрее летит. А когда сидишь в своей конуре в одного 24/7, то и пропускаешь как весь движ, так и всю помощь.
У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
боюсь, это неправда. Тендер - это тендер по условиям. То, что в результате тендера компания должна сделать согласно ТЗ/требований - это как отче наш. Но есть еще требования с коэффициентами, типа компания имеет аналогичные проекты такой же компетенции, сколько у компании сотрудников по профилю, что есть из сертификатов и так далее - в общем, это так же параметры честного тендера, не только цена. И итог - это кэф*цену, то есть приведенная цена контракта
был аналогичный опыт, только я тот самый менеджер продукта, который ставит ограничения сверху. Нет в этом ничего особо сложного, ты оцениваешь как-то сверху, сколько тебе нужно времени на разобраться, это время явно укладывается в спринт (если ты хочешь несколько месяцев разбираться, то сорян, задача уже, очевидно, не нужна вообще). После старта задача уточняется, и уже можно ее разбивать на более конкретные вещи.
Да и в целом планирование же нужно не чтобы кого-то поставить раком в рамки, а чтобы спланировать загрузку и прогнозировать результат этой загрузки, команда же не сама по себе ради своего интереса живет, такие вот дела, что за это кто-то платит, а кто платит, тот и заказывает музыку. А если хочется просто в свободного ученого поиграть - то это уже не про работу, а про любопытство, и то на это в рабочее время принято выделять время, но в целом - это нерабочая активность. Если потрогать технологию занимает больше месяца, то надо уже не ее изучать внутренними силами, а привлекать кого-то, кто за месяц сделает, это эффективней как-тл для проекта. Для человека, который хотел потрогать - нет, но для команды и проекта - однозначно
Боюсь, тут есть некоторые знания, которые вы не учитываете, которые открывают глаза именно на 90 дней. У вас есть учетка. Вы ей пользуетесь, у нее есть некоторые права. Есть Любка, при вашем увольнении она должна деактивировать учетку, но она этого не делает. Итого за 90 дней в случае утечки вашей учетки вовне можно походить по сервисам, найти доступы куда попало, влезть в систему. Учетки не утекают моментально, но утекают, и как следствие, важно, чтобы время, сколько с этой учеткой будут работать всякие буки, было минимально, но при этом не совсем напрягать пользователя, то есть не каждую неделю, не каждый месяц, а все же раз в 3 мес.
Если вы думаете, что я описываю какой-то редкий кейс, то нифига подобного. Это 95 процентов всех взломов инфры - изнутри, зашел-вышел, делов на 5 минут (с). А потери компании будут огромные, вон, СДЭКовские бд и бэкапы зашифровали, как думаете, как? А легко, зашли с учетки, положили вирусню, распространили по системе. У нас в орге ломают сеть как? Учетки утекли, попали в защищенный сегмент сети, пробуют положить базы. Инфра не спит ночами, отбивается, думаете, оно им надо?))) Так что лучше смириться с 90 днями, чем с потерями (иногда в миллиард рублей и больше) просто по вине утекшей учетки, которая не обрубится сама
Егор, привет. Внезапно наткнулся на твою статью, и она как откликнулась моей болью, может что-то посоветуешь. Привет от бывшего длинноволосого Артура)
Есть продукт, довольно большая CRM, в которой много разных направлений живут со своими воронками, отчетами и прочими радостями, частично или полностью пересекаясь. Изначальная документация кривая и больше техническая, не хватает как раз понимания, что на что влияет, как следствие версии при выходе часто ломают что-то старое. Собрать тест-кейсы для регресса так же тяжело, так как тестеры в продукте всегда свежие, и посадить их за описание - это по сути на месяц садить их учить, что мы делаем, и черкз 2 месяца все по новой (оргдизайн управления проектный, люди бегают, никто не в продукте). С чего и через кого лучше начать описание всего, что есть с взаимосвязями между фичами и структурными блоками?
Похожую схему делали с кластером редиса, в принципе не могу сказать, что в чем-то концептуальные отличия, так же сваренный синхронизатор, структура БД для хранения, и индексы. Коллеги просто не стали описывать типовые процедуры прогрева редиса в первый раз, перезапись в случае сбоев из БД и так далее. Персистентность нужна для того, чтобы не приходилось кэш обнулять и перезаписывать, это довольно затратная по ресурсам операция, типа "а давай-ка 100500 записей удалим, а то есть подозр, что какие-то из них битые, и запишем заново" - и хренак, на 4-6 часов у тебя инстанс вылетает из пула, перезаписывается, и так все по очереди (мы же не дурачки, да, в одном кеше все хранить, нужен кластерок). И тут тоже свои песни возникают, типа "а если за время синхронизации еще записей появилось? А если изменилось что-то в бд? - то есть еще возникает некая промежуточная шина, в которую на время обновления пишутся события обновления, чтобы потом после полной перезаписи их раздать, и так по каждому инстансу кеша. Короч, решение скажем так сложнее, чем тцт описано, но у ребят явно не было цели описать все, скорее "а как заманить к ним в команду клиента, которому это надо".
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
Но ты же при этом понимаешь, что ВЕРОЯТНОСТЬ, что человек окажется завтра на войне/взломан/убит/закрыт великим файрволом в подворотне ниже в условной Голландии, чем в РФ? А жизнь - это череда вероятностей, и работа по митигации рисков бизнеса - это ключевая задача СБ/ИБ. Рынок вне РФ чуть более конкурентен со стороны работодателя, и поэтому они могут выбирать. Это у себя на стуле ты хороший. А он видит 70 стульев, где все хорошие, и ему проще выбрать тот стул, который хорош со всех сторон)
слушай, мы с моей прошлой командой прям друзья. Вместе тусим, ходим по барам, ходим в гости друг к другу, играем на гиатрке, снова пьем, говорим о чем угодно и так далее. Вы почему-то ограничиваетесь работой как работой - делать таски и получать зп. Это тоже важно и нужно, но чьерт побьери, я могу делать таски и получать зп и все, а могу делать таски, получать зп и круто проводить время в компании друзей. Это никак не мешает мне делать свою работу. Никто не мешает мне шутить и смеяться, даже если полный треш вокруг. Потому что с грустным хлебалом я уже работал, больше не хочу. И поверь, если ты сам открыт к людям, то и люди к тебе открыты. Если ты понимаешь, что у условного Сани вечером др, ты никогда в жизни не запланируешь на него какой-то левый кранч. Если ты знаешь, что Юльке в 6 надо быть в садике, ты будешь планировать спринты и ее загрузку с учетом этого знания, а не "я чет там напланировал, а команда опять меня подвела".
И если у пацанов и чик проблемы на работе или вне ее - мы их реально перетрем, что на ретро, что в баре, так как мы бро, а бро слушает своего бро, ферштейн? И проблема решится, потому что если бро в соло не может, мы ему поможем на том или ином уровне. Я вот продакт, и мог прийти и попросить к линейным рукам бабок тому или иному сотруднику, потому что его уже заманало, а морально не умеет просить. А мне черт возьми не жалко, мне жалко, если я хорошего человека и сотрудника из команды потеряю. Если он будет ходить унылым и не хотеть делать свою работу (а че мы потом в баре обсудим?!) Если есть тела, которые не влились, то можно ж вместе их подкалывать?
Так что я тут с ТСом согласен от и до - нормально общаешься - быстрее летит. А когда сидишь в своей конуре в одного 24/7, то и пропускаешь как весь движ, так и всю помощь.
У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
боюсь, это неправда. Тендер - это тендер по условиям. То, что в результате тендера компания должна сделать согласно ТЗ/требований - это как отче наш. Но есть еще требования с коэффициентами, типа компания имеет аналогичные проекты такой же компетенции, сколько у компании сотрудников по профилю, что есть из сертификатов и так далее - в общем, это так же параметры честного тендера, не только цена. И итог - это кэф*цену, то есть приведенная цена контракта
был аналогичный опыт, только я тот самый менеджер продукта, который ставит ограничения сверху. Нет в этом ничего особо сложного, ты оцениваешь как-то сверху, сколько тебе нужно времени на разобраться, это время явно укладывается в спринт (если ты хочешь несколько месяцев разбираться, то сорян, задача уже, очевидно, не нужна вообще). После старта задача уточняется, и уже можно ее разбивать на более конкретные вещи.
Да и в целом планирование же нужно не чтобы кого-то поставить
ракомв рамки, а чтобы спланировать загрузку и прогнозировать результат этой загрузки, команда же не сама по себе ради своего интереса живет, такие вот дела, что за это кто-то платит, а кто платит, тот и заказывает музыку. А если хочется просто в свободного ученого поиграть - то это уже не про работу, а про любопытство, и то на это в рабочее время принято выделять время, но в целом - это нерабочая активность. Если потрогать технологию занимает больше месяца, то надо уже не ее изучать внутренними силами, а привлекать кого-то, кто за месяц сделает, это эффективней как-тл для проекта. Для человека, который хотел потрогать - нет, но для команды и проекта - однозначноБоюсь, тут есть некоторые знания, которые вы не учитываете, которые открывают глаза именно на 90 дней. У вас есть учетка. Вы ей пользуетесь, у нее есть некоторые права. Есть Любка, при вашем увольнении она должна деактивировать учетку, но она этого не делает. Итого за 90 дней в случае утечки вашей учетки вовне можно походить по сервисам, найти доступы куда попало, влезть в систему. Учетки не утекают моментально, но утекают, и как следствие, важно, чтобы время, сколько с этой учеткой будут работать всякие буки, было минимально, но при этом не совсем напрягать пользователя, то есть не каждую неделю, не каждый месяц, а все же раз в 3 мес.
Если вы думаете, что я описываю какой-то редкий кейс, то нифига подобного. Это 95 процентов всех взломов инфры - изнутри, зашел-вышел, делов на 5 минут (с). А потери компании будут огромные, вон, СДЭКовские бд и бэкапы зашифровали, как думаете, как? А легко, зашли с учетки, положили вирусню, распространили по системе. У нас в орге ломают сеть как? Учетки утекли, попали в защищенный сегмент сети, пробуют положить базы. Инфра не спит ночами, отбивается, думаете, оно им надо?))) Так что лучше смириться с 90 днями, чем с потерями (иногда в миллиард рублей и больше) просто по вине утекшей учетки, которая не обрубится сама