10% экономии на зп лучше считать от тех кого наняли. 10% ниже рынка * 200 закрытых вакансий * 200 000 руб = 4 млн в мес. за 3 мес эта экономия отобьет себя. а если добавить LTV в 1.5 года вычесть 3 мес на самоокупаемость этого собеса, то получится, что с каждых нанятых 200 в мес - они получают 15 мес * 4 млн = 60 млн экономии.
вроде сходится. старые (те, кто уже работают) - под этот расчет не подпадают.
Может быть суровый вердикт стоит пересмотреть? )))
Работодатель платит за приложение ваших компетенций и навыков (софт и хард) к созданию дополнительной ценности - писать код, тесты, пайплайны CI/CD, дебаг, улучшать обслуживаемость систем через логи, документацию, обучение коллег) - это на низком уровне, чем выше ваши навыки и ответственность в команде - компании, тем значительнее меняется понимание а какую ценность вы на самом деле создаете для бизнеса.
Откуда вы берете навыки - здесь несколько путей. Если вас берут с одного стека, а компания в другом - то тут взаимные обязательства - с них вас обучить, с вас обучиться. Если потребности команды в скилах меняются - а они на самом деле только растут - с ростом продукта, пользователей, сложности технологий. поэтому усидеть на стуле с текущим скилсетом невозможно. поэтому компания часто предлагает инструменты для повышения своей компетенции - оплата книг, обучений, внутренние митапы, менторство, 1:1 с тимлидом, с экспертом вашего комьюнити, где-то дают писать на хабр или в конфах выступать, где-то выделяет 10% времени на самообучение на работе по вашему ИПР, или дни для всей команды на эксперименты, или-или.
Ваша ответственность - понять свою стратегию развития, согласовать свой ИПР с тимлидом - чтобы и команде это было нужно, и вам интересно и полезно для карьеры. поэтому вы работаете и на настоящее и на будущее. здесь - только усилия с двух сторон - с вашей - это в том числе действия в нерабочее время. это может быть прохождение курса, купленного компанией, дома, или чтение проф литературы, или пет проекты, или-или. если нет возможности - то от этого будет тормозиться ваш карьерный трек, это к сожалению следствие - что количество переходит в качество, кто больше инвестирует в себя, тот быстрее растет. Компания может оказаться, что растет быстрее ваших навыков, или наоборот - вы. В одном случае - вы можете стать как герой в этой статье, в другом - повышение ответственности, сложности задачи и тд.
Идея здравая, боль была про QA + трудоустройство новичков в профессии и из нее появилась более общая идея.
Хочу предложить чуть более системный подход - адаптация под другие цели курсов - что кто-то идет проскиляться в 1-2-3, кому то нужно быстро погрузиться в основы новой профессии и новой роли, нового харда или софта.
идея - из Team Maturity - у Авито есть модель зрелости команд. тот же принцип.
Каждый курс берет 3-4-5 ключевых навыка из области Х (системный анализ, QA, PdM, CTO уже есть минимум два курса). и их качает - и говорит откуда и куда ведет, почему это важно. Junior QA и QA Automation это разные наборы навыков. Но их можно базово оцифровать. и у каждого курса - есть образ ЦА, есть акцентные вещи - и из них собирается внутри УТП, вот его было бы здорово вытащить.
для каждого курса брать выборку из 10 - 20 человек (разные соц. и иные группы) делать скрининг по выбранной области Х ДО и ПОСЛЕ - да, это будет частичный результат, но это будет честнее, и может быть полезно и самим авторам курсов и их edtech площадкам .
можно и в упрощенном виде - что курсы сами себя оценивают, а участники этих курсов могут записываться на скрининг сами и тогда оценка с двух сторон.
тогда на вашем сайте - если вы смотрите на себя как на независимую площадку - можно сказать я хочу курсы QA и мне важно 1-2-3 - какие курсы под это лучше заточены? именно это требуется от инженеров, когда они хотелки по курсам приносят руководителям - а руководителям-тимлидам и выше - необходимо обосновать почему в их компании для этих людей вот этот курс подходит, а этот не очень. и этот анализ бывает достаточно сложно делать. у меня бывало, что ресурса не было вглубь посмотреть на программы, поискать отзывы по 2-3 мес.
тут же не только про выстроенные процессы, бывает что процессы пока не ок, но там потрясающий эксперт и он-она дело говорит.
Ценность такая - в очень большом числе компаний, и я сам этим грешил через «отлаженный рабочий процесс» - такого даже близко нет в голове ни руководителей, ни сотрудников.
Статья действительно как вы написали - было бы здорово добавить кейсов ярко выраженных про негативные эффекты. Руководители, если сотрудники принесут им эту статью, - скажут, что у вас в отпуск включено "3 дня доп отпуска за ненормированный рабочий день" и с такой размытой формулировкой - кажется, что ... что-то не так, но что - непонятно.
Поэтому такие базовые статьи про культуру работы могут показывать, что может быть иначе. И, кстати, примеры внедрений, когда реально честно платят +30%, отгулы, двойная оплата - методы конкретные и примеры компаний где работает - открывает возможности для инициативы сотрудников. Руководители великолепно умеют играть в игры - денег нет, но вы держитесь.
Отличный подход! Внедрял аналогичные формулы для своих команд суппорта - дает и ПМ и самим инженерам прозрачность. Можете поделиться какие метрики вы поменяли внутри? Какие вызовы (ключевые ограничения) вы видите или эта схема уже дает стабильность и качество для клиента и понятный процесс масштабирования?
C точки зрения тимлида если это не важно, то где его личная мотивация - вот это вопрос. Это один из самых эффективных способов экономить деньги компании. 1. Люди занимаются тем и что интересно, и что необходимо для повышения эффективности команды. В вашем ИПР могут быть пункты - например изучение технологии, или практики, которые будут и вам в проф. рост и в то, что команде это даст буст. А личные 1:1 с руководителем - тимлидом, и еще было бы круто с руководителем по вашему направлению (SRE/back/front/qa/..) - как личный ментор. 2. дешевле всего чтобы вы росли внутри - повышения ЗП при хорошей вашей заинтересованности в росте чаще не догоняют вашего реального роста и профита для компании. 3. средний период работы в такой компании увеличивается. меньше денег на найм, обучение нового члена команды и тп. плюс в сложных доменах порог входа бывает 6-9 мес и это в вас будут вкладываться все это время. поэтому снова - дешевле всего дать вам поляну чтобы вы хотели приходить на работу, чтобы хотели и достигали технических вызовов внутри компании.
можно еще продолжить - это отлично работает в сцепке - называется культура компании. и в ней то, что Илья описал - поддерживается на разных уровнях через HR, через комьюнити-гильдии по срезам, через программы внутренние, митапы, и тд. это средним и крупным компаниям упрощает найм в долгую через HR бренд.
Планировать свое время так, чтобы оставалось время на развитие и на регулярный обзор поляны, особенно учитывая тот факт, что операционка, "неотложные" вопросы будут с момента вступления в должность и возможно даже до последнего дня работы в компании - будут съедать все доступное время. Говорить НЕТ, останавливаться и планировать.
Классный чек-лист! На практике, это требует а) человека, который глубоко в это погружен и по вашей статистике 3 из 100 знают глубоко, может еще 30 знают о том что это есть и из них 10 - что нужно туда копнуть когда возникнет такая задача (можно не знать глубоко - но уметь извлекать знания по необходимости - это самый дорогой навык имхо). б) достаточного масштаба задачи - уровня вкусно и точка - 1% экономии * 1млн использований - цена внедрения выше профита автоматизации.
На масштабе малых и средних компаний часто уже огромный профит, когда БП явно оцифрованы, выделены точки конфликтов, основные ограничения - и с ними уже можно работать. но есть сложности - что нет людей, говорящих на этом языке оптимизации БП( - на уровне руководителей, аналитиков - поэтому крайне сложно вообще сдвинуть паровоз в пользу прозрачной оцифровки БП - огромная победа (у меня лично) когда начальники отделов - в конфе делают список рутин, БП - и под каждую делают хотя бы выгрузку мозга, чтобы понимать матрицу компетенций, точки конфликтов, точки где бестолковые БП - исторические и тп.
а доходить до такой красоты - обычно нет ни экспертизы, ни времени. потому что если не сопровождаешь людей в том, чтобы итоговый артефакт - соответствовал цели - выявление всех БП, точек напряжения, бас-факторов, рисков - и чтобы его было дешево производить - люди закапываются и все разваливается.
Можете поделиться примерами, глядя на которые можно заземлить на практике это чек лист? в миро, например, взять БП понятный многими и на нем показать? на вашем стеке практик.
Моя жена выучила всех ключевых людей в команде, пока я был на созвонах - ей нравится до сих пор сидеть рядом на диване с ноутом и что-то свое делать. Забавно было, когда после одной из встреч в 2020 в конце - она такая - я (!) уже поняла что ты им донести хочешь).
Мы постоянно обсуждаем рабочие вопросы друг друга - бывает за обедом, бывает на прогулке, бывает специально просим помощи по конкретному вопросу. вопрос между делом - а кто по специальности ваш партнер - не лишен смысла))).
это работает - если есть функции кроссдоменные где каждый что-то понимает. жестко про архитектуру - она нет, а вот про управление, стратегию и тд - всегда за. не обязательно быть айтишником, чтобы можно было поэксплуатировать партнера).
пункт про NDA - важная часть ремоут культуры, а особенно - понятие хоум офиса - у меня тимлид за гладильной доской работал долго - как выстроить работу, чтобы домашние не мешали, было пространство - в наших реалиях скорее никак пока.
думаю, что скоро может быть так - либо компенсируют коворкинг рядом с домом, либо помогают обустроить хоум оффис, либо по старинке - в офис. но появится требование - чтобы рабочее пространство помогало - это реально надо обсуждать на 1:1, и планировать бюджет под это.
Спасибо, что поделился! Здорово, что практики здорового человека, которые можно масштабировать понятным образом на команды, распространяются благодаря тебе, Кириллу Ветчинкину, Саше Поломодову и еще многим другим!
Полностью поддерживаю. Прошел через множество кочек, когда действовал из позиции корпоративного подхода - ничего личного. Дошел до апогея - ничего личного по отношению уже ко мне, пришло много инсайтов. Теперь сложно смотреть на мир иначе чем через создание ценности в мире людям.
Браво! Первопричины изменения страт сессий - про красные компании и красных руководителей, про "рывок" за два дня на сырую (даже если готовиться всех данных не подготовишь, а еще часто толпа ТОПов просто делит зоны влияния и трепетно охраняет свои - здесь не до стратегии а как их элементарно сплотить) - полностью согласен, в работе аналогичные сессии часто делаются не только на уровне ТОПов, но и на более низких уровнях. И подход отлично масштабируется - оленя проще рассмотреть маленькими шагами и малой группой. в Agile такое давно практикуется, но часто много перестраховки - когда зовут всех на всякий случай. Из моей практики СТО - идеально, когда стратегию собираешь постепенно узкой группой, и затем представляешь широкой группе, получаешь обратную связь, корректируешь - ваш подход еще более систематизирован) и это супер гуд - буду рад, если расскажете подробнее. При сборке начальной стратегии - в паузах между встречами - у вас это встречи рабочей группы - идет работа каждого участника по своему направлению со своими командами - поэтому много слепых пятен закрывается в процессе и многие "да, но" уже закрыты - когда участники опробируют кусочки со своими экспертами, получают обратную связь, записывают и обрабатывают вопросы, эксперты уже в стратегии видят обработки указанных ими рисков - и меньше сопротивления, больше принятия и веры в нее.
по вашей формуле: (вероятность + потеривденьгах)/сложность самая рисковая задача стала вдруг неважной, лучше ICE
по ICE: вероятность*потеривденьгах*сложность где вероятность можно как 0.50 брать, чтобы итоговой цифрой не пугать причем вероятность 100% - надо брать и делать)
Спасибо, что делитесь применением ТОС! Особенно в IT).
Коллега @Sergey-Titkov верно подметил, что это может быть субоптимизация time-to-market. Но если это оставить чуть в стороне, и сказать, что ваша идея в этой конкретной реализации корректна, то к проблеме ускорения протаскивания техдолга можно тоже подойти системно).
Внизу ссылка на статью, в которой техдолг упаковывают в бизнес ценность. Как вариант - добить анализ потерь до начала цепочки, чтобы была полная карта потерь в time-to-market, упаковать в бизнес-ценность, посчитав на языке бизнеса value. Если это value нашли, идем дальше. Список таких доработок (там может быть еще пара actionitem'ов) упаковываем уже вместе с бэклогом - ценность описана на языке бизнеса же - ускорение поставки ценности на ХХ% с ХХ дней до УУ дней - и будете вы не писать патч на хрустальный сервис, а добиваться ускорения (патч писать придется тоже, но вы не остановитесь на том, что выпустили патч и вы молодцы - команда, взявшая фичу будет должна убедиться в общем ускорении и это в разы важнее выкатки патча - потому что вы еще должны будете переделать правила выкатки релиза и тд).
Если вы используете ICE/RICE/WSJF и тд, то тут же взвешиваете и она сама всплывает где надо. Если сложно менять общие подходы и в бэклоге она будет внизу - то ОК - бизнес решил что это здесь и сейчас не важно. Еще один элемент - управление рисками - если такая штука есть, то можно добавить это как риск и оценить его степень.
Еще момент. Даже в рамках архит.комитета оказалось, что это не так и важно раз за полгода не дошли - следовательно, ценность для разработчиков этого не так велика, им скорее болит распил очередного монолита или как легаси конвейер переделать на кафку). Поэтому разработка не лоббировала снизу эту доработку), там, где у них реально болит - они обязательно будут вспоминать и проталкивать в бэклог.
Итого: две гипотезы почему застряли). 1) до бизнеса не донесли реальную ценность и оценку сложности реализации 2) боль для разработки от этого мала, как следствие задачу положили не в "тот" бэклог).
Можно: вернуться в начало и оценить реальную пользу для бизнеса и тащить, упаковав в бизнес-фичу. Тогда и архит. проработка включится в работу в обычном режиме - не надо будет ждать архит.комитета. архит.комитет (или просто команда) по идее и так уже разложил боль до некоего решения, которое и надо тащить в бэклог.
файлы изменений очень удобно делать с помощью xslt — SlowCheetah просто великолепный инструмент, особенно в функции preview.
Подход с отдельным сервером конфигов достаточно спорный. этим он точно становится клоном consul.
12 factor app c ENV классная вещь, особенно с «наконец» сделанными нормальным управлением параметрами конфигурации Microsoft.Extensions.Configuration.
Я пока живу с критичными настройками в отдельном репозитории и обновлением при накатке с OctopusDeploy.
10% экономии на зп лучше считать от тех кого наняли.
10% ниже рынка * 200 закрытых вакансий * 200 000 руб = 4 млн в мес. за 3 мес эта экономия отобьет себя. а если добавить LTV в 1.5 года вычесть 3 мес на самоокупаемость этого собеса, то получится, что с каждых нанятых 200 в мес - они получают 15 мес * 4 млн = 60 млн экономии.
вроде сходится. старые (те, кто уже работают) - под этот расчет не подпадают.
Может быть суровый вердикт стоит пересмотреть? )))
Работодатель платит за приложение ваших компетенций и навыков (софт и хард) к созданию дополнительной ценности - писать код, тесты, пайплайны CI/CD, дебаг, улучшать обслуживаемость систем через логи, документацию, обучение коллег) - это на низком уровне, чем выше ваши навыки и ответственность в команде - компании, тем значительнее меняется понимание а какую ценность вы на самом деле создаете для бизнеса.
Откуда вы берете навыки - здесь несколько путей. Если вас берут с одного стека, а компания в другом - то тут взаимные обязательства - с них вас обучить, с вас обучиться. Если потребности команды в скилах меняются - а они на самом деле только растут - с ростом продукта, пользователей, сложности технологий. поэтому усидеть на стуле с текущим скилсетом невозможно. поэтому компания часто предлагает инструменты для повышения своей компетенции - оплата книг, обучений, внутренние митапы, менторство, 1:1 с тимлидом, с экспертом вашего комьюнити, где-то дают писать на хабр или в конфах выступать, где-то выделяет 10% времени на самообучение на работе по вашему ИПР, или дни для всей команды на эксперименты, или-или.
Ваша ответственность - понять свою стратегию развития, согласовать свой ИПР с тимлидом - чтобы и команде это было нужно, и вам интересно и полезно для карьеры. поэтому вы работаете и на настоящее и на будущее. здесь - только усилия с двух сторон - с вашей - это в том числе действия в нерабочее время. это может быть прохождение курса, купленного компанией, дома, или чтение проф литературы, или пет проекты, или-или. если нет возможности - то от этого будет тормозиться ваш карьерный трек, это к сожалению следствие - что количество переходит в качество, кто больше инвестирует в себя, тот быстрее растет. Компания может оказаться, что растет быстрее ваших навыков, или наоборот - вы. В одном случае - вы можете стать как герой в этой статье, в другом - повышение ответственности, сложности задачи и тд.
Идея здравая, боль была про QA + трудоустройство новичков в профессии и из нее появилась более общая идея.
Хочу предложить чуть более системный подход - адаптация под другие цели курсов - что кто-то идет проскиляться в 1-2-3, кому то нужно быстро погрузиться в основы новой профессии и новой роли, нового харда или софта.
идея - из Team Maturity - у Авито есть модель зрелости команд. тот же принцип.
Каждый курс берет 3-4-5 ключевых навыка из области Х (системный анализ, QA, PdM, CTO уже есть минимум два курса). и их качает - и говорит откуда и куда ведет, почему это важно. Junior QA и QA Automation это разные наборы навыков. Но их можно базово оцифровать.
и у каждого курса - есть образ ЦА, есть акцентные вещи - и из них собирается внутри УТП, вот его было бы здорово вытащить.
для каждого курса брать выборку из 10 - 20 человек (разные соц. и иные группы)
делать скрининг по выбранной области Х ДО и ПОСЛЕ - да, это будет частичный результат, но это будет честнее, и может быть полезно и самим авторам курсов и их edtech площадкам .
можно и в упрощенном виде - что курсы сами себя оценивают, а участники этих курсов могут записываться на скрининг сами и тогда оценка с двух сторон.
тогда на вашем сайте - если вы смотрите на себя как на независимую площадку - можно сказать я хочу курсы QA и мне важно 1-2-3 - какие курсы под это лучше заточены? именно это требуется от инженеров, когда они хотелки по курсам приносят руководителям - а руководителям-тимлидам и выше - необходимо обосновать почему в их компании для этих людей вот этот курс подходит, а этот не очень. и этот анализ бывает достаточно сложно делать. у меня бывало, что ресурса не было вглубь посмотреть на программы, поискать отзывы по 2-3 мес.
тут же не только про выстроенные процессы, бывает что процессы пока не ок, но там потрясающий эксперт и он-она дело говорит.
Ценность такая - в очень большом числе компаний, и я сам этим грешил через «отлаженный рабочий процесс» - такого даже близко нет в голове ни руководителей, ни сотрудников.
Статья действительно как вы написали - было бы здорово добавить кейсов ярко выраженных про негативные эффекты. Руководители, если сотрудники принесут им эту статью, - скажут, что у вас в отпуск включено "3 дня доп отпуска за ненормированный рабочий день" и с такой размытой формулировкой - кажется, что ... что-то не так, но что - непонятно.
Поэтому такие базовые статьи про культуру работы могут показывать, что может быть иначе.
И, кстати, примеры внедрений, когда реально честно платят +30%, отгулы, двойная оплата - методы конкретные и примеры компаний где работает - открывает возможности для инициативы сотрудников. Руководители великолепно умеют играть в игры - денег нет, но вы держитесь.
Отличный подход! Внедрял аналогичные формулы для своих команд суппорта - дает и ПМ и самим инженерам прозрачность. Можете поделиться какие метрики вы поменяли внутри?
Какие вызовы (ключевые ограничения) вы видите или эта схема уже дает стабильность и качество для клиента и понятный процесс масштабирования?
C точки зрения тимлида если это не важно, то где его личная мотивация - вот это вопрос.
Это один из самых эффективных способов экономить деньги компании.
1. Люди занимаются тем и что интересно, и что необходимо для повышения эффективности команды. В вашем ИПР могут быть пункты - например изучение технологии, или практики, которые будут и вам в проф. рост и в то, что команде это даст буст. А личные 1:1 с руководителем - тимлидом, и еще было бы круто с руководителем по вашему направлению (SRE/back/front/qa/..) - как личный ментор.
2. дешевле всего чтобы вы росли внутри - повышения ЗП при хорошей вашей заинтересованности в росте чаще не догоняют вашего реального роста и профита для компании.
3. средний период работы в такой компании увеличивается. меньше денег на найм, обучение нового члена команды и тп. плюс в сложных доменах порог входа бывает 6-9 мес и это в вас будут вкладываться все это время. поэтому снова - дешевле всего дать вам поляну чтобы вы хотели приходить на работу, чтобы хотели и достигали технических вызовов внутри компании.
можно еще продолжить - это отлично работает в сцепке - называется культура компании. и в ней то, что Илья описал - поддерживается на разных уровнях через HR, через комьюнити-гильдии по срезам, через программы внутренние, митапы, и тд. это средним и крупным компаниям упрощает найм в долгую через HR бренд.
Планировать свое время так, чтобы оставалось время на развитие и на регулярный обзор поляны, особенно учитывая тот факт, что операционка, "неотложные" вопросы будут с момента вступления в должность и возможно даже до последнего дня работы в компании - будут съедать все доступное время. Говорить НЕТ, останавливаться и планировать.
Классный чек-лист! На практике, это требует
а) человека, который глубоко в это погружен и по вашей статистике 3 из 100 знают глубоко, может еще 30 знают о том что это есть и из них 10 - что нужно туда копнуть когда возникнет такая задача (можно не знать глубоко - но уметь извлекать знания по необходимости - это самый дорогой навык имхо).
б) достаточного масштаба задачи - уровня вкусно и точка - 1% экономии * 1млн использований - цена внедрения выше профита автоматизации.
На масштабе малых и средних компаний часто уже огромный профит, когда БП явно оцифрованы, выделены точки конфликтов, основные ограничения - и с ними уже можно работать. но есть сложности - что нет людей, говорящих на этом языке оптимизации БП( - на уровне руководителей, аналитиков - поэтому крайне сложно вообще сдвинуть паровоз в пользу прозрачной оцифровки БП - огромная победа (у меня лично) когда начальники отделов - в конфе делают список рутин, БП - и под каждую делают хотя бы выгрузку мозга, чтобы понимать матрицу компетенций, точки конфликтов, точки где бестолковые БП - исторические и тп.
а доходить до такой красоты - обычно нет ни экспертизы, ни времени. потому что если не сопровождаешь людей в том, чтобы итоговый артефакт - соответствовал цели - выявление всех БП, точек напряжения, бас-факторов, рисков - и чтобы его было дешево производить - люди закапываются и все разваливается.
Можете поделиться примерами, глядя на которые можно заземлить на практике это чек лист?
в миро, например, взять БП понятный многими и на нем показать? на вашем стеке практик.
Ага, именно так.
Моя жена выучила всех ключевых людей в команде, пока я был на созвонах - ей нравится до сих пор сидеть рядом на диване с ноутом и что-то свое делать. Забавно было, когда после одной из встреч в 2020 в конце - она такая - я (!) уже поняла что ты им донести хочешь).
Мы постоянно обсуждаем рабочие вопросы друг друга - бывает за обедом, бывает на прогулке, бывает специально просим помощи по конкретному вопросу. вопрос между делом - а кто по специальности ваш партнер - не лишен смысла))).
это работает - если есть функции кроссдоменные где каждый что-то понимает. жестко про архитектуру - она нет, а вот про управление, стратегию и тд - всегда за. не обязательно быть айтишником, чтобы можно было поэксплуатировать партнера).
пункт про NDA - важная часть ремоут культуры, а особенно - понятие хоум офиса - у меня тимлид за гладильной доской работал долго - как выстроить работу, чтобы домашние не мешали, было пространство - в наших реалиях скорее никак пока.
думаю, что скоро может быть так - либо компенсируют коворкинг рядом с домом, либо помогают обустроить хоум оффис, либо по старинке - в офис. но появится требование - чтобы рабочее пространство помогало - это реально надо обсуждать на 1:1, и планировать бюджет под это.
Отличная подборка! Благодарю!
Потрясающе! Как папа и выпускник физмат школы - огромная благодарность!
Спасибо, что поделился! Здорово, что практики здорового человека, которые можно масштабировать понятным образом на команды, распространяются благодаря тебе, Кириллу Ветчинкину, Саше Поломодову и еще многим другим!
За Live Demo - отдельная благодарность!
Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
Полностью поддерживаю. Прошел через множество кочек, когда действовал из позиции корпоративного подхода - ничего личного. Дошел до апогея - ничего личного по отношению уже ко мне, пришло много инсайтов. Теперь сложно смотреть на мир иначе чем через создание ценности в мире людям.
Вы проделали фантастическую работу!
А вам точно нужны все эти пермишены?)
Сервис «Яндекс.Музыка» получит доступы:
Доступ к личным данным пользователя на сервисах Яндекса из мобильных приложений
Доступ к логину, имени и фамилии, полу
Доступ к адресу электронной почты
Доступ к дате рождения
Доступ к портрету пользователя
Изменение плейлистов
Чтение плейлистов
Каталог Яндекс.Музыки
Чат с саппортом Музыки
Доступ к общим данным пользовательских приложений
Хранение данных приложения
Доступ к профилям от социальных сетей, хранящихся на Яндексе
Привязка телефона
Привязка адресов электронной почты
Доступ к Яндекс.Диску для приложений
Просмотр списка устройств умного дома
Доступ к API Яндекс.Store для Android-разработчиков
Пульт для Yandex.IO-устройств
Браво! Первопричины изменения страт сессий - про красные компании и красных руководителей, про "рывок" за два дня на сырую (даже если готовиться всех данных не подготовишь, а еще часто толпа ТОПов просто делит зоны влияния и трепетно охраняет свои - здесь не до стратегии а как их элементарно сплотить) - полностью согласен, в работе аналогичные сессии часто делаются не только на уровне ТОПов, но и на более низких уровнях. И подход отлично масштабируется - оленя проще рассмотреть маленькими шагами и малой группой. в Agile такое давно практикуется, но часто много перестраховки - когда зовут всех на всякий случай. Из моей практики СТО - идеально, когда стратегию собираешь постепенно узкой группой, и затем представляешь широкой группе, получаешь обратную связь, корректируешь - ваш подход еще более систематизирован) и это супер гуд - буду рад, если расскажете подробнее. При сборке начальной стратегии - в паузах между встречами - у вас это встречи рабочей группы - идет работа каждого участника по своему направлению со своими командами - поэтому много слепых пятен закрывается в процессе и многие "да, но" уже закрыты - когда участники опробируют кусочки со своими экспертами, получают обратную связь, записывают и обрабатывают вопросы, эксперты уже в стратегии видят обработки указанных ими рисков - и меньше сопротивления, больше принятия и веры в нее.
по вашей формуле: (вероятность + потеривденьгах)/сложность
самая рисковая задача стала вдруг неважной, лучше ICE
по ICE: вероятность*потеривденьгах*сложность
где вероятность можно как 0.50 брать, чтобы итоговой цифрой не пугать
причем вероятность 100% - надо брать и делать)
Спасибо, что делитесь применением ТОС! Особенно в IT).
Коллега @Sergey-Titkov верно подметил, что это может быть субоптимизация time-to-market.
Но если это оставить чуть в стороне, и сказать, что ваша идея в этой конкретной реализации корректна, то к проблеме ускорения протаскивания техдолга можно тоже подойти системно).
Внизу ссылка на статью, в которой техдолг упаковывают в бизнес ценность.
Как вариант - добить анализ потерь до начала цепочки, чтобы была полная карта потерь в time-to-market, упаковать в бизнес-ценность, посчитав на языке бизнеса value. Если это value нашли, идем дальше.
Список таких доработок (там может быть еще пара actionitem'ов) упаковываем уже вместе с бэклогом - ценность описана на языке бизнеса же - ускорение поставки ценности на ХХ% с ХХ дней до УУ дней - и будете вы не писать патч на хрустальный сервис, а добиваться ускорения (патч писать придется тоже, но вы не остановитесь на том, что выпустили патч и вы молодцы - команда, взявшая фичу будет должна убедиться в общем ускорении и это в разы важнее выкатки патча - потому что вы еще должны будете переделать правила выкатки релиза и тд).
Если вы используете ICE/RICE/WSJF и тд, то тут же взвешиваете и она сама всплывает где надо. Если сложно менять общие подходы и в бэклоге она будет внизу - то ОК - бизнес решил что это здесь и сейчас не важно. Еще один элемент - управление рисками - если такая штука есть, то можно добавить это как риск и оценить его степень.
Еще момент. Даже в рамках архит.комитета оказалось, что это не так и важно раз за полгода не дошли - следовательно, ценность для разработчиков этого не так велика, им скорее болит распил очередного монолита или как легаси конвейер переделать на кафку). Поэтому разработка не лоббировала снизу эту доработку), там, где у них реально болит - они обязательно будут вспоминать и проталкивать в бэклог.
Итого: две гипотезы почему застряли).
1) до бизнеса не донесли реальную ценность и оценку сложности реализации
2) боль для разработки от этого мала, как следствие задачу положили не в "тот" бэклог).
Можно: вернуться в начало и оценить реальную пользу для бизнеса и тащить, упаковав в бизнес-фичу. Тогда и архит. проработка включится в работу в обычном режиме - не надо будет ждать архит.комитета. архит.комитет (или просто команда) по идее и так уже разложил боль до некоего решения, которое и надо тащить в бэклог.
Техдолг. Все говорят: «невозможно», а я говорю, что буду
https://habr.com/ru/company/oleg-bunin/blog/480636/
Подход с отдельным сервером конфигов достаточно спорный. этим он точно становится клоном consul.
12 factor app c ENV классная вещь, особенно с «наконец» сделанными нормальным управлением параметрами конфигурации Microsoft.Extensions.Configuration.
Я пока живу с критичными настройками в отдельном репозитории и обновлением при накатке с OctopusDeploy.