собеседования
одной из любимых частей моей работы всегда были собеседования (нет, я не про хопанье, гусары!)
да, они отнимают много времени и в периоды активного найма, в моем и без того плотном графике, выкроить время хотя бы на два в неделю сложно. а приходилось по 3-5 человек собеседовать
при этом я проводил и классические технички, и топ-грейдинги и комбо для лидов.
но самое интересное что в каждом интервью я нахожу что-то новое и никогда не чувствую рутинности действия. разные люди, разные настроения, разные повороты
а ещё, наверное, я повидал столько разных инженеров и менеджеров, что могу, при должном усилии, как-то их классифицировать (но пока не хочу)
кстати, зачастую собеседование воспринимается как «мы проверяем кандидата», а ведь это игра в обе калитки и собеседуемый может (и должен!) задавать вопросы. всегда удивляет (и обычно ставит крест) собеседник, говорящий «у меня нет вопросов»
одной из любимых частей моей работы всегда были собеседования (нет, я не про хопанье, гусары!)
да, они отнимают много времени и в периоды активного найма, в моем и без того плотном графике, выкроить время хотя бы на два в неделю сложно. а приходилось по 3-5 человек собеседовать
при этом я проводил и классические технички, и топ-грейдинги и комбо для лидов.
но самое интересное что в каждом интервью я нахожу что-то новое и никогда не чувствую рутинности действия. разные люди, разные настроения, разные повороты
а ещё, наверное, я повидал столько разных инженеров и менеджеров, что могу, при должном усилии, как-то их классифицировать (но пока не хочу)
кстати, зачастую собеседование воспринимается как «мы проверяем кандидата», а ведь это игра в обе калитки и собеседуемый может (и должен!) задавать вопросы. всегда удивляет (и обычно ставит крест) собеседник, говорящий «у меня нет вопросов»
❤13👍6
небось соскучились по докладам от меня?
как и говорил раньше — я в ПК bigtechnight, отбирал в трек ламоды самые крутые доклады от крутых спикеров. пять крутых докладов от шести (!!) спикеров ждут вас (и нас) в офисе ламоды и (потом) в записи.
но мало того, один из докладов — конечно от меня. однако, подождите, там будет два спикера — со мной будет Юля (а у Юли нефиговый такой бэкграунд в бигтехах) и мы поговорим о том как You Build It You Run It существует и как мы в этом всём варимся.
мало? тогда давайте еще анонс — я на хард-треке ламоды на bigtechnight еще и ведущий!
продано? тогда го! Lamoda Tech
как и говорил раньше — я в ПК bigtechnight, отбирал в трек ламоды самые крутые доклады от крутых спикеров. пять крутых докладов от шести (!!) спикеров ждут вас (и нас) в офисе ламоды и (потом) в записи.
но мало того, один из докладов — конечно от меня. однако, подождите, там будет два спикера — со мной будет Юля (а у Юли нефиговый такой бэкграунд в бигтехах) и мы поговорим о том как You Build It You Run It существует и как мы в этом всём варимся.
мало? тогда давайте еще анонс — я на хард-треке ламоды на bigtechnight еще и ведущий!
продано? тогда го! Lamoda Tech
Telegram
Lamoda Tech
Ночь, когда виден весь прод. Начните ее с Lamoda
12 сентября мы проводим big tech night — «Ночь музеев» в мире IT. Ее придумали в Яндексе, а соорганизаторами стали Сбер, X5, Т-Банк и Lamoda.
Готовы первыми увидеть, как, где и кем создаются технологии для…
12 сентября мы проводим big tech night — «Ночь музеев» в мире IT. Ее придумали в Яндексе, а соорганизаторами стали Сбер, X5, Т-Банк и Lamoda.
Готовы первыми увидеть, как, где и кем создаются технологии для…
🔥12❤🔥1🎉1
итерации и фазы
вроде уже говорилось, но повторю.
хочется сразу взять и сделать. с первого раза идеально, как задумал и по лучшим лекалам и соблюдая все практики. но не получается.
да и не должно получаться. тут эджайл как нельзя кстати. делайте, просто делайте, потом доделывайте. не бросайте. работайте с техдолгом.
разделите проект на стадии или фазы. не пресловутое "давайте слона есть по кусочкам" (кто вообще ест слонов?!), но именно "я сделаю МВП или ПоК и потом уже пойму куда ведет дальше нас"
если твой ПоК занимает больше спринта времени — упрощай.
если твой МВП сразу работает как надо — выкатывай и отдавай в эксплуатацию.
а если нужны доработки — сразу пиши задачи в бэклог. отдавай техдолг. заложи на это время и ресурс.
но делай, делай и получай результат, улучшай, делай еще лучше, но не парься, если не получилось сразу идеально и целиком.
вроде уже говорилось, но повторю.
хочется сразу взять и сделать. с первого раза идеально, как задумал и по лучшим лекалам и соблюдая все практики. но не получается.
да и не должно получаться. тут эджайл как нельзя кстати. делайте, просто делайте, потом доделывайте. не бросайте. работайте с техдолгом.
разделите проект на стадии или фазы. не пресловутое "давайте слона есть по кусочкам" (кто вообще ест слонов?!), но именно "я сделаю МВП или ПоК и потом уже пойму куда ведет дальше нас"
если твой ПоК занимает больше спринта времени — упрощай.
если твой МВП сразу работает как надо — выкатывай и отдавай в эксплуатацию.
а если нужны доработки — сразу пиши задачи в бэклог. отдавай техдолг. заложи на это время и ресурс.
но делай, делай и получай результат, улучшай, делай еще лучше, но не парься, если не получилось сразу идеально и целиком.
👍8❤7
Forwarded from anton egorushkov
f_12_09_Егорушков_Антон_BigTechNight_designed_final.pdf
4.6 MB
👍16🔥6
This media is not supported in the widget
VIEW IN TELEGRAM
🔥17❤🔥10😱5
https://events.yandex.ru/events/bigtechnight/records ищите тут материалы с BTN!
Forwarded from Инженер и Менеджер
Как_добиваться_успехов_на_переговорах.pdf
5.2 MB
У меня есть для вас подарок. Он поможет вам побеждать в переговорах.
Ведь когда устраиваешься на работу — переговоры о зарплате. Хочешь больше людей — переговоры о найме и ресурсах.
Крис Восс 27 лет проводил переговоры в ФБР, в том числе — с похитителями и настоящими террористами. Его методы спасали жизни. Теперь он учит этому бизнес.
Мой подарок — выжимка из его книги "Никаких компромиссов". В выжимке: система ведения переговоров, набор инструментов, конкретных приемов и критериев успеха. Если у вас есть время, купите и прочитайте книгу целиком. Если нет, мой гайд на 6 страниц поможет начать использовать методику. Без воды.
Бесплатно. Без email, регистрации и СМС. Просто заберите и используйте на следующей встрече.
Единственная просьба. Если гайд реально поможет — перешлите этот пост другу, коллеге или в чат. Ваши репосты это главный двигатель моего канала и главная моя мотивация продолжать.
Надеюсь, подарок вам понравится. Приятного чтения!
P.S. Если примените хотя бы одну технику на следующей неделе и она сработает — напишите в комментариях. Мне важна обратная связь.
Ведь когда устраиваешься на работу — переговоры о зарплате. Хочешь больше людей — переговоры о найме и ресурсах.
Крис Восс 27 лет проводил переговоры в ФБР, в том числе — с похитителями и настоящими террористами. Его методы спасали жизни. Теперь он учит этому бизнес.
Мой подарок — выжимка из его книги "Никаких компромиссов". В выжимке: система ведения переговоров, набор инструментов, конкретных приемов и критериев успеха. Если у вас есть время, купите и прочитайте книгу целиком. Если нет, мой гайд на 6 страниц поможет начать использовать методику. Без воды.
Бесплатно. Без email, регистрации и СМС. Просто заберите и используйте на следующей встрече.
Единственная просьба. Если гайд реально поможет — перешлите этот пост другу, коллеге или в чат. Ваши репосты это главный двигатель моего канала и главная моя мотивация продолжать.
Надеюсь, подарок вам понравится. Приятного чтения!
P.S. Если примените хотя бы одну технику на следующей неделе и она сработает — напишите в комментариях. Мне важна обратная связь.
Forwarded from The ExtremeCode Times
Кто нибудь расскажет мне как в бигтехах уживаются следующие взаимоисключающие параграфы?
1. Проблемы с софтом.
> Вечная бесконечная сборка-пересборка. Добрая половина времени разработки уходит на сборку.
> Отсутствие возможности запуска некоторых приложений вне прода во время разработки,
> Лапшекод в котором невозможно разобраться
> Проблемы с процессами, работяги гонят друг на друга и пытаются перекинуть свою работу на других
2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.
Почему сильные кадры делают слабо?
1. Проблемы с софтом.
> Вечная бесконечная сборка-пересборка. Добрая половина времени разработки уходит на сборку.
> Отсутствие возможности запуска некоторых приложений вне прода во время разработки,
> Лапшекод в котором невозможно разобраться
> Проблемы с процессами, работяги гонят друг на друга и пытаются перекинуть свою работу на других
2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.
Почему сильные кадры делают слабо?
ретро
важно: ретро это вам не спринт-ревью и звать туда абы кого не стоит. там должна быть только команда. только мы, кому есть что обсудить. над чем по рефлексировать.
на ретро можно хвастаться, ругаться, благодарить. но все должно быть подкреплено фактами.
рекомендую вообще использовать конструкцию с фактами. то есть: не «Вася опять сделал лажу», а «Василий не успел разобраться в задаче и сделал её неверно, задачу не приняли». или не «Вася красава!», но «Вася смог сделать 5 задач за спринт».
то есть, к этой самой конструкции можно применить действие. часто на ретро возникают обсуждения и задачи процессной части.
очевидно, что для «плохих» карточек действия обязательны, а для хороших? тоже! но можно их делать в формате: «чтобы все делали так же хорошо, нам нужно» или «улучшить постановку задач и перед взятием в работу проверять что все в команде понимают требования».
ретро может превращаться в нытинг. а фасилитатору нужно иметь силу воли и строгость модерации, чтобы все стало продуктивным.
задачи с ретро берутся в работу с высоким приоритетом.
важно: ретро это вам не спринт-ревью и звать туда абы кого не стоит. там должна быть только команда. только мы, кому есть что обсудить. над чем по рефлексировать.
на ретро можно хвастаться, ругаться, благодарить. но все должно быть подкреплено фактами.
рекомендую вообще использовать конструкцию с фактами. то есть: не «Вася опять сделал лажу», а «Василий не успел разобраться в задаче и сделал её неверно, задачу не приняли». или не «Вася красава!», но «Вася смог сделать 5 задач за спринт».
то есть, к этой самой конструкции можно применить действие. часто на ретро возникают обсуждения и задачи процессной части.
очевидно, что для «плохих» карточек действия обязательны, а для хороших? тоже! но можно их делать в формате: «чтобы все делали так же хорошо, нам нужно» или «улучшить постановку задач и перед взятием в работу проверять что все в команде понимают требования».
ретро может превращаться в нытинг. а фасилитатору нужно иметь силу воли и строгость модерации, чтобы все стало продуктивным.
задачи с ретро берутся в работу с высоким приоритетом.
не делай всё сам
для менеджера свойственно проводить все встречи самому. это зовется "лидировать".
но ведь нет, есть такое понятие "фасилитация". я долго держал его в негативной коннотации, но потом понял — помощь и сопровождение — вот что нужно вкладывать в фасилитацию.
а фасилитировать может кто угодно, не обязательно менеджер. а значит — вести встречи, следить за исполнением процесса и помогать — тоже!
это не освобождает менеджера от его обязанностей, но помогает каждому в команде быть частью процесса и ускорять, улучшать и пропускать это всё через себя.
и да, конечно, вся команда — это единое фасилитирующее. и менеджер или лид — лицо, принимающее решение и ответственность.
но если менеджер будет делать всё сам и завернет всё на себя — ему не стоит переходить дорогу не поглядев по сторонам.
для менеджера свойственно проводить все встречи самому. это зовется "лидировать".
но ведь нет, есть такое понятие "фасилитация". я долго держал его в негативной коннотации, но потом понял — помощь и сопровождение — вот что нужно вкладывать в фасилитацию.
а фасилитировать может кто угодно, не обязательно менеджер. а значит — вести встречи, следить за исполнением процесса и помогать — тоже!
это не освобождает менеджера от его обязанностей, но помогает каждому в команде быть частью процесса и ускорять, улучшать и пропускать это всё через себя.
и да, конечно, вся команда — это единое фасилитирующее. и менеджер или лид — лицо, принимающее решение и ответственность.
но если менеджер будет делать всё сам и завернет всё на себя — ему не стоит переходить дорогу не поглядев по сторонам.
😁4
Forwarded from Enabling.team Insights
InfoQ Trends DevOps and Cloud 2025
В октябре 2025 года сообщество InfoQ выпустило отчёт DevOps and Cloud Trends, в котором представлены ключевые тенденции в области DevOps и облачных технологий.
Из интересных технологий отметим: Platform engineering teams, DevEx Frameworks, MCP-based ops tooling, AI agents in cloud engineering, Industry-aggregated incident analysis, Team Topologies, Measuring performance, DORA metrics и др.
Подробнее про ключевые тренды из отчета читайте в нашем обзоре.
В октябре 2025 года сообщество InfoQ выпустило отчёт DevOps and Cloud Trends, в котором представлены ключевые тенденции в области DevOps и облачных технологий.
Из интересных технологий отметим: Platform engineering teams, DevEx Frameworks, MCP-based ops tooling, AI agents in cloud engineering, Industry-aggregated incident analysis, Team Topologies, Measuring performance, DORA metrics и др.
Подробнее про ключевые тренды из отчета читайте в нашем обзоре.
Forwarded from Кулешов разгоняет IT | AI
Инфекция CTO. Или парадокс накрутчиков в российском IT менеджменте.
Заметили, как каждый второй в IT за последние пару лет начал описывать свою должность как C-level?
И всё бы ничего — можно было бы просто посмеяться со стороны, если бы это не стало напоминать тот самый фильтр «опыта от трёх лет», который железобетонно перекрыл дорогу новичкам в российское IT.
Теперь, чтобы манагеру просто попасть на некоторые мероприятия или выступить там, нужно стать волком и прикрутить к себе громкий титул, желательно с буквой C. Причём никого не волнует, ты CTO Google Cloud или CTO стартапа из трёх человек, основанного твоим другом вчера. И все это делают.
Но это ещё цветочки. С поиском работы началось то же самое. Ни результативность, ни достижения, ни проекты, ни твои навыки никого не интересуют. Отфильтруют тебя только по двум вещам: сколько у тебя штатных единиц в подчинении и насколько громко сияет буква «С» в твоём титуле. Причем, это одновременно стреляет и по компаниям, которые теперь вынуждены плодить псевдо-С-level вакансии, чтобы люди соглашались у них работать.
А дальше — пока слабохарактерные кодеры, не умеющие врать, честно проходят миллионы алгоритмических интервью и системных дизайнов, чтобы работать за копейки, просто нужно успешно сказать про «700 тысяч человек в подчинении», добавить, какой ты великий CTO/CDO/CIO/CPO, и получить работу очередного «CTO» в следующей компании.
При этом в реальности, когда мы говорим о Top Management Team (TMT) или Senior Leaders — то это группа руководителей, влияющих на организацию целиком. Сюда входят CEO, CFO, CTO, CIO, CMO и другие «chief»-роли. Это те, кто определяют стратегию и направление развития компании в целом.
Так что если ты — тимлид команды из трёх человек и не отчитываешься генеральному директору или совету директоров, то пожалуйста, прекрати позориться, выдумывать себе C-level титулы и притворяться большим боссом.
Нет, ты не C-level. Эти роли в компании — единичный товар. Не бывает так, чтобы у тебя в конторе была сотня таких же бедолаг на букву «С».
Открой трудовую, посмотри, что там написано. Вразумительно и с чувством прочти это вслух, можешь даже не читать название своей компании, чтобы не разрушить картинку Волка с Уолл-стрит у себя в голове. А потом, напиши это у себя в подписи под именем. Спасибо.
PS возможно, таким честным постом обижу многих своих товарищей и знакомых. Но этим лишь докажу свою правоту. Поэтому воспринимайте это как мягкий укол, чтобы сделать нашу общую с вами индустрию лучше. Обнимаю! Всегда ваш, "завистливый не-CTO-но-мог-бы-быть" Кулешов.
Заметили, как каждый второй в IT за последние пару лет начал описывать свою должность как C-level?
И всё бы ничего — можно было бы просто посмеяться со стороны, если бы это не стало напоминать тот самый фильтр «опыта от трёх лет», который железобетонно перекрыл дорогу новичкам в российское IT.
Теперь, чтобы манагеру просто попасть на некоторые мероприятия или выступить там, нужно стать волком и прикрутить к себе громкий титул, желательно с буквой C. Причём никого не волнует, ты CTO Google Cloud или CTO стартапа из трёх человек, основанного твоим другом вчера. И все это делают.
Но это ещё цветочки. С поиском работы началось то же самое. Ни результативность, ни достижения, ни проекты, ни твои навыки никого не интересуют. Отфильтруют тебя только по двум вещам: сколько у тебя штатных единиц в подчинении и насколько громко сияет буква «С» в твоём титуле. Причем, это одновременно стреляет и по компаниям, которые теперь вынуждены плодить псевдо-С-level вакансии, чтобы люди соглашались у них работать.
А дальше — пока слабохарактерные кодеры, не умеющие врать, честно проходят миллионы алгоритмических интервью и системных дизайнов, чтобы работать за копейки, просто нужно успешно сказать про «700 тысяч человек в подчинении», добавить, какой ты великий CTO/CDO/CIO/CPO, и получить работу очередного «CTO» в следующей компании.
При этом в реальности, когда мы говорим о Top Management Team (TMT) или Senior Leaders — то это группа руководителей, влияющих на организацию целиком. Сюда входят CEO, CFO, CTO, CIO, CMO и другие «chief»-роли. Это те, кто определяют стратегию и направление развития компании в целом.
Так что если ты — тимлид команды из трёх человек и не отчитываешься генеральному директору или совету директоров, то пожалуйста, прекрати позориться, выдумывать себе C-level титулы и притворяться большим боссом.
Нет, ты не C-level. Эти роли в компании — единичный товар. Не бывает так, чтобы у тебя в конторе была сотня таких же бедолаг на букву «С».
Открой трудовую, посмотри, что там написано. Вразумительно и с чувством прочти это вслух, можешь даже не читать название своей компании, чтобы не разрушить картинку Волка с Уолл-стрит у себя в голове. А потом, напиши это у себя в подписи под именем. Спасибо.
PS возможно, таким честным постом обижу многих своих товарищей и знакомых. Но этим лишь докажу свою правоту. Поэтому воспринимайте это как мягкий укол, чтобы сделать нашу общую с вами индустрию лучше. Обнимаю! Всегда ваш, "завистливый не-CTO-но-мог-бы-быть" Кулешов.
👍11❤5💯5👏2
ограничения
https://theengineeringmanager.substack.com/p/the-beauty-of-constraints
нам нужны ограничения. нужно понимать, когда сказать "нет" или отсечь часть ненужного.
нет, это не про приоритизацию, но идет рядом с ней.
RICE/ICE это сортировка (охват, влияние, уверенность в оценке и трудозатраты), а вот отсечение нужно делать через ограничения: скоупа, ресурсов, времени. ведь всегда именно их и не хватает!
например: режем скоуп до конкретно того, что нужно для работы, без рюшечек и свистоперделок. четко определяем критерий успеха, определяем то, что будет по-умолчанию четко и ясно. не раздуваем команду и инфраструктуру под проект (даже если можем). ставим дедлайны, для которых придется постараться (но не овертаймить) и постоянно демонстрируешь результат в рамках интервалов (спринтов или других удобных обеим сторонам отрезков).
как это делать на практике:
- спросить "эти требования можно усечь?" и "кто задал эти требования?"
- исключить все шаги, которые не приводят к поломке результата. если сломалось — вернись
- тюнь (подкручивай) только то, что реально нужно, то что у тебя останется. а не всё, что видишь по пути
- сокращай (уменьшай) цикл обучения: попробовали, измерили, осознали, поправили, снова пробуем
- автоматизируй уже когда понял что всё оставшееся нужно автоматизировать (чтобы не тратить силы на ненужное)
- задай вопрос "что я могу сделать, чтобы уложиться в половину времени/ресурсов на проект?"
ну и, разумеется, постоянно спрашивай "можно ли это сделать проще/дешевле/быстрее/меньшим ресурсом?"
да, это не универсальное решение и его не нужно применять всегда, но оно очень отрезвляет и помогает вернуться в реальность.
не заливай ресурсами, деньгами и инфраструктурой то, что можно сделать хорошо и без этого.
https://theengineeringmanager.substack.com/p/the-beauty-of-constraints
нам нужны ограничения. нужно понимать, когда сказать "нет" или отсечь часть ненужного.
нет, это не про приоритизацию, но идет рядом с ней.
RICE/ICE это сортировка (охват, влияние, уверенность в оценке и трудозатраты), а вот отсечение нужно делать через ограничения: скоупа, ресурсов, времени. ведь всегда именно их и не хватает!
например: режем скоуп до конкретно того, что нужно для работы, без рюшечек и свистоперделок. четко определяем критерий успеха, определяем то, что будет по-умолчанию четко и ясно. не раздуваем команду и инфраструктуру под проект (даже если можем). ставим дедлайны, для которых придется постараться (но не овертаймить) и постоянно демонстрируешь результат в рамках интервалов (спринтов или других удобных обеим сторонам отрезков).
как это делать на практике:
- спросить "эти требования можно усечь?" и "кто задал эти требования?"
- исключить все шаги, которые не приводят к поломке результата. если сломалось — вернись
- тюнь (подкручивай) только то, что реально нужно, то что у тебя останется. а не всё, что видишь по пути
- сокращай (уменьшай) цикл обучения: попробовали, измерили, осознали, поправили, снова пробуем
- автоматизируй уже когда понял что всё оставшееся нужно автоматизировать (чтобы не тратить силы на ненужное)
- задай вопрос "что я могу сделать, чтобы уложиться в половину времени/ресурсов на проект?"
ну и, разумеется, постоянно спрашивай "можно ли это сделать проще/дешевле/быстрее/меньшим ресурсом?"
да, это не универсальное решение и его не нужно применять всегда, но оно очень отрезвляет и помогает вернуться в реальность.
не заливай ресурсами, деньгами и инфраструктурой то, что можно сделать хорошо и без этого.
Substack
The beauty of constraints
Having less choice often creates more opportunity.
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Почему ретроспективы не работают
Многие ретроспективы дисфункциональны. Вместо того, чтобы служить механизмом continuous improvement, они помогают команде отпустить чувство вины по поводу проблем, которые не чинятся. Так получается, потому что стандартный исход ретроспективы – записать все проблемы в трекер, и либо вообще больше к ним не возвращаться, либо немного поисследовать, и только потом забить.
При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:
👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.
Многие ретроспективы дисфункциональны. Вместо того, чтобы служить механизмом continuous improvement, они помогают команде отпустить чувство вины по поводу проблем, которые не чинятся. Так получается, потому что стандартный исход ретроспективы – записать все проблемы в трекер, и либо вообще больше к ним не возвращаться, либо немного поисследовать, и только потом забить.
При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:
👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.
Lucas F. Costa
Why your retrospectives don't work and how to fix them
Hot takes and cold truths on software, startups, and the lies we tell ourselves.
❤4
люди
где бы я ни работал, чем бы ни занимался, даже когда был сисадмином и думал что серверная мой дом и патч-панели — мои друзья — я общался с людьми. я знакомился, помогал, решал их проблемы и задачи.
эти люди менялись, менялся и я, менялись работы и шло время.
людей становилось все больше, но всегда оставались определенные люди, с которыми в любой момент можно снова поработать, встретиться, помочь им или которые помогут тебе.
это не какой-то круг, не какие-то рукопожатия. это люди.
оборачивать это все в нетворкинг, и тем более, учиться этому на курсах — это какой-то другой мир.
даже не потому что времени жалко, а потому что такие контакты будут просто ещё одной визиткой в пачке других.
душа? может и душа.
вот сегодня встретился с Севой. работали с ним уже 4 года назад, а людьми остались до сих пор.
где бы я ни работал, чем бы ни занимался, даже когда был сисадмином и думал что серверная мой дом и патч-панели — мои друзья — я общался с людьми. я знакомился, помогал, решал их проблемы и задачи.
эти люди менялись, менялся и я, менялись работы и шло время.
людей становилось все больше, но всегда оставались определенные люди, с которыми в любой момент можно снова поработать, встретиться, помочь им или которые помогут тебе.
это не какой-то круг, не какие-то рукопожатия. это люди.
оборачивать это все в нетворкинг, и тем более, учиться этому на курсах — это какой-то другой мир.
даже не потому что времени жалко, а потому что такие контакты будут просто ещё одной визиткой в пачке других.
душа? может и душа.
вот сегодня встретился с Севой. работали с ним уже 4 года назад, а людьми остались до сих пор.
❤25👍14💯8
притащили чудесное (конечно, я же там участвовал)
хочу прокомментировать то, что увидел и что происходит в головах общества.
однако, сразу осекусь: я и с devops раньше борцунствовал, но если всем ок сисадминам платить большие зарплаты, не получая практик — то кто я такой, чтобы с этим бороться?(я сыч, я всю спикерскую деятельность на это положил и буду продолжать)
Кто отвечает за надёжность?
тут я хочу ответить просто и коротко: YBIYRI. а в ответах даже нет "разработчик сервиса"))) это как?)
то что SRE это молодая роль — в первую очередь заслуга размытия понимания роли как таковой. devops и SRE это вообще синонимы. в проде что-то полетело — зовите опсов (а это кто? SRE или devops? а может вообще sysops?), а если у вас облачная инфраструктура и managed сервисы? кого звать?
и как следствие — компаниям нужен универсал, понимающий код и подтиряющий сопельки + тот, кто напишет пайп и закрутит все гайки безопасности. да, это SRE)
про вкатунов и "я за три года до сеньора" — не буду.
девятки после запятой и девятки до запятой — это задача не SRE, а CTO.
дальше в отчете идет статистика по количеству SRE на компанию. и тут я не могу не вспомнить вопрос с собеседований "сколько должно быть инженеров на разработчика?" или правильнее сказать "сколько разработчиков у одного инженера?".
мое правило: коэффициент 0,1 — 10% должен быть инженерный состав, всё что ниже — будет отзываться так или иначе. хотя, правильнее было бы построить кривую зависимости. ну и отдать должное разным организационным подходам и практикам. чем лучше — тем проще и спокойнее инженеру и коэффициент можно уменьшить)
самое забавное что я слышал про SRE — что это девопс с дежуркой) но дежурка есть у всех и отчет это подтверждает. помимо дежурки, конечно, есть и инцидент и проблем-менеджмент (о них мы еще точно поговорим и не раз). но в отчете мне бросилось в глаза что упор на автоматизацию рутины делают... сисдамины! да-да! тогда как платформенных инженеров заставляют участвовать в он-коллах) что происходит с рынком?
пункты про сложность отстаивания своего мнения я спишу на плохие процессы, которые не позволяют каждому открыто и прозрачно влиять на инженерные и архитектурные решения (опять же, процессная проблема)
разумеется, более половины (хаха, статистика, 51%) не разделяют SRE и devops. да и зачем? ведь это всё просто фильтр, на деле люди одинаковые и работают одинаково? о, нет) о, нет! это не так. и ведь дальше раскрывается почему:
- операционка
- разрыв контекста
- нет денег на разделение
догадаетесь, что тут будет ключом к успеху?
и что меня расстроило больше всего в этом отчете — так это то6 что лишь в 2,5% случаев за инциденты и дежурства по сервису отвечает сама разработка (первичное реагирование). и, как следствие — лишь у полвины описаны инструкции и ранбуки по инцидентам.
но ладно, радует что об этом говорят и смотрят на ситуацию с разных сторон.
что ж, добро пожаловать в эру, когда мы (я) будем рассказывать и про CRE. пристегивайтесь, будет душно.
хочу прокомментировать то, что увидел и что происходит в головах общества.
однако, сразу осекусь: я и с devops раньше борцунствовал, но если всем ок сисадминам платить большие зарплаты, не получая практик — то кто я такой, чтобы с этим бороться?
Кто отвечает за надёжность?
тут я хочу ответить просто и коротко: YBIYRI. а в ответах даже нет "разработчик сервиса"))) это как?)
то что SRE это молодая роль — в первую очередь заслуга размытия понимания роли как таковой. devops и SRE это вообще синонимы. в проде что-то полетело — зовите опсов (а это кто? SRE или devops? а может вообще sysops?), а если у вас облачная инфраструктура и managed сервисы? кого звать?
и как следствие — компаниям нужен универсал, понимающий код и подтиряющий сопельки + тот, кто напишет пайп и закрутит все гайки безопасности. да, это SRE)
про вкатунов и "я за три года до сеньора" — не буду.
девятки после запятой и девятки до запятой — это задача не SRE, а CTO.
дальше в отчете идет статистика по количеству SRE на компанию. и тут я не могу не вспомнить вопрос с собеседований "сколько должно быть инженеров на разработчика?" или правильнее сказать "сколько разработчиков у одного инженера?".
мое правило: коэффициент 0,1 — 10% должен быть инженерный состав, всё что ниже — будет отзываться так или иначе. хотя, правильнее было бы построить кривую зависимости. ну и отдать должное разным организационным подходам и практикам. чем лучше — тем проще и спокойнее инженеру и коэффициент можно уменьшить)
самое забавное что я слышал про SRE — что это девопс с дежуркой) но дежурка есть у всех и отчет это подтверждает. помимо дежурки, конечно, есть и инцидент и проблем-менеджмент (о них мы еще точно поговорим и не раз). но в отчете мне бросилось в глаза что упор на автоматизацию рутины делают... сисдамины! да-да! тогда как платформенных инженеров заставляют участвовать в он-коллах) что происходит с рынком?
пункты про сложность отстаивания своего мнения я спишу на плохие процессы, которые не позволяют каждому открыто и прозрачно влиять на инженерные и архитектурные решения (опять же, процессная проблема)
разумеется, более половины (хаха, статистика, 51%) не разделяют SRE и devops. да и зачем? ведь это всё просто фильтр, на деле люди одинаковые и работают одинаково? о, нет) о, нет! это не так. и ведь дальше раскрывается почему:
- операционка
- разрыв контекста
- нет денег на разделение
догадаетесь, что тут будет ключом к успеху?
и что меня расстроило больше всего в этом отчете — так это то6 что лишь в 2,5% случаев за инциденты и дежурства по сервису отвечает сама разработка (первичное реагирование). и, как следствие — лишь у полвины описаны инструкции и ранбуки по инцидентам.
но ладно, радует что об этом говорят и смотрят на ситуацию с разных сторон.
что ж, добро пожаловать в эру, когда мы (я) будем рассказывать и про CRE. пристегивайтесь, будет душно.