мы на дискуссии, тут круто

Спасибо ИТМО, лично Тане за возможность выступить перед такой активной и интересующейся аудиторией.
было чуть суматошно и капельку кустарно, но зато душевно.
спасибо новым подписчикам, надеюсь, вам тут понравится.
доклад мне понравился, я рассказал что хотел и по отзыву аудитории — вы получили что хотели. если что не поняли — читайте презентацию, смотрите запись или просто задавайте вопросы.
на Мерж будет чуточку иначе, но для закрепления информации — полезно послушать.
Дима вот два раза послушает))

в своей работе мы расследуем инциденты с помощью RCA — root cause analysis — поиска коренной причины.
конечно, не обязательно его применять только для инцидентов и проблем, можно пользоваться для определения текущего или целевого поведения сервиса и его архитектуры.

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

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

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

так же, можно пользоваться причинно-следственной диаграммой Исикавы, в которой от основной проблемы мы строим ответвления причин и следствий

плюс, перечислю несколько других способов (баззворды для гугла): FMEA, FTA, диаграмма Парето, диаграмма рассеяния

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

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

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

вау, многабукаф

комьюнити, давайте помогать! у кого есть вакансии стажеров или джунов инженеров devops?

на конференции в ИТМО ко мне подошел парень и попросил помощи.

мы причесали резюме и я разослал его любимым рекрутерам. пока пусто, поэтому прошу вашей помощи.
по запросу, в ЛС скину резюме.

с меня крыса 🐀

ага, значит так:

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

то что у меня получилось, очень близко по духу к devops методологии, поэтому пощу их сюда.

Капибара – самый большой грызун.
А мы — знаем очень многое в нашей компании. Мы хотим всех научить тому, что умеем сами. Мы не хищники и не ищем жертв. Но если кто-то стал бревном – мы его покусаем!

Капибара – добрая
Мы должны быть и будем прежде всего добрыми к своим коллегам и самим себе. Мы хотим понять проблему и решить ее.

Клан
У капибары есть клан, а у нас – есть кора. Мы вместе, а значит – друг за друга горой. Мы всегда придем на помощь друг другу и подскажем ответ даже на самый глупый вопрос. Глуп тот, кто не задал вопроса.
Каждый капи готов помочь соседнему клану как своему.

Плодовитость и готовность жить
Капибары обычно держат по 5-8 малышей в клане. При этом, каждый новый малыш в минимальные сроки может встать на ноги и сделать первые шаги. Значит, мы учим новичков максимально эффективно и главная цель – сделать их самостоятельными.

Дрессировка и обучение
В домашних условиях, капибары очень хорошо обучаются. Мы учим и обучаемся сами, непрерывно и с удовольствием. Если хочешь что-то изучить – просто попроси. А если хочешь обучить – сделай это немедленно. Обо всех новых знаниях рассказывай всем вокруг!

Домик для других
Капибары не против, чтобы птички и мелкие грызуны оставались для передышки на их теле. А это значит, что мы гостеприимны и всегда готовы помочь, приютить, рассказать как что делать любому входящему в нашу зону. 

Прячемся от хищников
Не смотря на свою медлительность, капи очень хорошо прячутся, потому что отлично изучили территрию и пользуются всеми преимуществами среды. Значит, что мы хорошо знаем окружающие нас вещи, архитектуры и хорошо в них разбираемся. 
Если у капи отнимают еду – капи не расстроится. У нее всегда есть запас, а еще она хорошо умеет спрятать еду от хищников и воришек. Да и вообще капибара не расстроится: она дружелюбна и поделилась едой.

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

Дружелюбные болтушки
Капибары очень дружелюбны и болтливы. Это не значит, что слова должны быть пустыми и лишь бы занять время. Но мы всегда должны быть готовы развернуто ответить и хорошо описать необходимую информацию.

Любим покушать
Капибары прожорливы и кушают по 3-4 кг сена в день. А мы берем много задач, но не допускаем состояния "мне плохо от еды". При этом, мы разборчивы и абы что в работу не берем – просим правильно оформлять задачи, писать критерии приемки и сами оцениваем задачи перед работой. Мы не хотим быть толстыми, а значит – не хотим перегрузиться задачами. Оцениваем свою производительность объективно.

Любознательность
Капибара – любопытная, постоянно учится и движется. Если на одной и той же территории ей стало скучно – она найдет новый ландшафт для жизни и творчества, освоит его и улучшит. Да и новые друзья – это круто!

про карго-культ

ко мне вчера подошли и спросили "что делать, если у нас карго-культ?"
мой ответ был прост "не делать так, а сделать как нужно вам".

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

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

в такую компанию зовут активатора изменений (человека, который зафасилитирует и поможет сделать правильно), но за что браться — ему не понятно.

я предлагаю экспансивный путь — начать с малого, взять один отдел, на который меньше всего смотрят и который готов к изменениям и сделать там всё правильно, поставить процесс, поставить цели, описать ценности и начать жить правильно. по мере создания ценности и кристаллизации результата — продолжать распространять, при этом доводя до руководителя что "вот оно как должно работать, сравните!"

дальше — переходить от количества к качеству. как только количество групп с правильным подходом, ясными целями и понятными принципами станет весомым или результативным — можно сказать "давайте-ка признаем, что наш подход работает?" и распространить его на всех. на этом этапе понадобится много фасилитаторов и enabling teams. то есть команд, которые помогут и включат процессы и подходы в правильную сторону.

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

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

меняй компанию, или меняй компанию.

кто из вас ждал запись доклада из Салехарда (yamal.dev) — вот он!
лучше поздно, чем никогда!
там же, на канале есть и остальные видео с конференции, посмотрите их, они интересные!

работа с возражениями

тоже "вопрос из зала")
если в вашей команде постоянно возникают вопросы из разряда "зачем это?" "почему мы?" "неужели это того стоит?" и прочие вещи из разряда основополагающих — вам нужно озаботиться следующим.

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

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

движемся дальше, ценности обозначили, но нужны цели.
цели у команды тоже обязательно должны быть свои и важно — цели могут меняться с течением времени (гораздо чаще, чем ценности). цели — это наши опорные точки, маяки, на которые мы движемся и достигаем их через результаты. цели хорошо обозначать глобально для отдела, локально для группы и супер-локально для отрезков времени (ИПР/квартал/спринт). цели нужно достигать и все силы прикладывать, чтобы цели становились результатом. если цели постоянно не достигаются — надо понять почему и поработать над этим. либо ставить более адекватные и достижимые цели ("встать с дивана и сделать две задачи")

а еще, если у вас прямо обозначены цели — их можно использовать как рычаг воздействия на входящие вам задачи — мол "это не помогает нам достичь цели". но не нужно злоупотреблять и всегда стоит оценить конечный результат от выполненных задач. очевидно, не все задачи ведут к цели, и это нормально: таких задач может быть даже много, но не должно быть столько, чтобы блокировать команду в достижении целей. и индивидуальные цели не должны блокироваться целями команды. ух сложно!

возражения обычно возникают, когда не понятно что это принесет и куда это приведет. под "это" можно понимать что угодно) задачи, практики, подходы, решения.

надеюсь, хоть как-то понятно)

видос со Стачки!
https://www.youtube.com/watch?v=cK3baRL2eH8
кто там хотел про обучение узнать? вот оно!

https://www.youtube.com/watch?v=NEdpIwlcyos

отличное интервью крутой Насти с офигенным Антоном. рад, что работал с ними и вообще хотелось бы, чтобы у Антона все получилось.
спасибо!

и снова "ко мне пришли с вопросом")

вопрос: нужен ли спринт-ревью?

ответ: да, нужен (но есть нюанс, как водится)

что такое спринт-ревью? почему-то сталкиваюсь часто с тем, что путают или даже объединяют его с ретро. или считают что это необязательная процедура и бойкотируют. мол "мне рассказывать нечего, я это все на дейли рассказывал" или даже "я слушать вас не буду, мне всё понятно". так вот — спринт-ревью — это церемония, часть процесса скрама, в которой происходит демонстрация и описание того, что было сделано за спринт (читай — инкремента)

на самом деле, эта практика очень полезна для самого исполнителя и вдвойне полезна для команды.

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

при этом, очевидно, рассказы должны быть емкими и цельными, без лишней воды, в идеале — с демонстрацией кода/результата, можно даже с презентацией (ppt) и слайдами.

нужно ли на спринт-ревью закрывать спринт? конечно, иначе как мы демонстрируем инкремент, когда задачи еще в работе? после закрытия спринта — можно смотреть на графики велосити/бёрндауна и анализировать поток. потом — спринт-ревью.

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

ну а ретро должен (должно? вообще — должна, это же ретроспектива или встреча) проводиться после всех спринт-ревью и закрытий спринтов. чтобы на ретро идти и обсуждать уже процессные вещи, передавать друг другу спасибо и с чистой головой уходить в заслуженные выходные.