Технический долг — как кредит, ч.1
Техдолг — техническое несовершенство системы, порождённое в момент разработки.
Словосочетание Технический Долг — удобная метафора, чтобы объяснить не-технарям причину замедления поставки ценности.
Давайте попробуем развить эту метафору, чтобы лучше понять причины и следствия, какие виды техдолга бывают и можно ли не порождать техдолг. Пост получился объемным, поэтому для удобства читателя я разбил его на две части.
🏦 Кредит: заёмщик не копит деньги, а берет их у банка. И сразу тратит их на какие-то блага, здесь и сейчас. А далее долгое время регулярно отдает часть своего дохода банку за пользование деньгами. Заёмщик накопил бы нужную сумму быстрее, чем погасит кредит. Он вынужден отказывать себе в других благах. Но он уже пользуется первоначальными благами и платит за это свою цену. Поначалу платёж почти полностью уходит в переплату.
Разумный заёмщик будет гасить тело кредита частичными досрочными погашениями.
🏃♂️Техдолг: разработчики не тратят время на корректное техническое решение. Они поставляют ценность здесь и сейчас. У этого есть цена: замедление поставки ценности в будущем, пока техдолг не будет выплачен. Зачастую техдолг только копится. Со временем поставка ценности становится всё медленнее.
Разумный владелец продукта заинтересован в долгосрочном сохранении скорости поставки, поэтому готов инвестировать во внутреннее качество продукта.
Кредит может быть разумным и ответственным. Например, ипотека. Жить где-то надо, и ипотека может быть решением проблемы. Обычно люди осознанно входят в ипотеку. Они видят график платежей, понимают свой достаток и возможность платить вовремя и без просрочек.
А может быть неразумным или безответственным. Например, микрозайм с целью закрыть очередной платёж по другому микрозайму. Из такой ситуации сложно выйти, она засасывает и негативно влияет на качество жизни.
Мартин Фаулер разделяет техдолг на 4 квадранта, по степени осознанности и ответственности разработчиков, этот техдолг порождающих.
В следующем посте поговорим конкретно об этих видах техдолга, можно ли не порождать техдолг в принципе, и если да, то как.
Техдолг — техническое несовершенство системы, порождённое в момент разработки.
Словосочетание Технический Долг — удобная метафора, чтобы объяснить не-технарям причину замедления поставки ценности.
Давайте попробуем развить эту метафору, чтобы лучше понять причины и следствия, какие виды техдолга бывают и можно ли не порождать техдолг. Пост получился объемным, поэтому для удобства читателя я разбил его на две части.
🏦 Кредит: заёмщик не копит деньги, а берет их у банка. И сразу тратит их на какие-то блага, здесь и сейчас. А далее долгое время регулярно отдает часть своего дохода банку за пользование деньгами. Заёмщик накопил бы нужную сумму быстрее, чем погасит кредит. Он вынужден отказывать себе в других благах. Но он уже пользуется первоначальными благами и платит за это свою цену. Поначалу платёж почти полностью уходит в переплату.
Разумный заёмщик будет гасить тело кредита частичными досрочными погашениями.
🏃♂️Техдолг: разработчики не тратят время на корректное техническое решение. Они поставляют ценность здесь и сейчас. У этого есть цена: замедление поставки ценности в будущем, пока техдолг не будет выплачен. Зачастую техдолг только копится. Со временем поставка ценности становится всё медленнее.
Разумный владелец продукта заинтересован в долгосрочном сохранении скорости поставки, поэтому готов инвестировать во внутреннее качество продукта.
Кредит может быть разумным и ответственным. Например, ипотека. Жить где-то надо, и ипотека может быть решением проблемы. Обычно люди осознанно входят в ипотеку. Они видят график платежей, понимают свой достаток и возможность платить вовремя и без просрочек.
А может быть неразумным или безответственным. Например, микрозайм с целью закрыть очередной платёж по другому микрозайму. Из такой ситуации сложно выйти, она засасывает и негативно влияет на качество жизни.
Мартин Фаулер разделяет техдолг на 4 квадранта, по степени осознанности и ответственности разработчиков, этот техдолг порождающих.
В следующем посте поговорим конкретно об этих видах техдолга, можно ли не порождать техдолг в принципе, и если да, то как.
❤1
Технический долг — как кредит, ч.2
Этот пост - продолжение предыдущего. По мотивам статьи Мартина Фаулера
С ростом финансовой грамотности человек начинает осознавать разницу между микрозаймом, потребительским кредитом и ипотекой. Чуть позже он начинает разбираться в инвестировании и может принимать взвешенное решение: купить в ипотеку или арендовать и копить.
Можно провести аналогию опыта и ответственности с разработкой и техдолгом:
1️⃣ «Какие такие слои архитектуры?» — Первый микрозайм;
2️⃣ «У нас нет времени на проработку архитектуры» — Когда нет денег на очередной платёж по микрозайму и человек берет для этого еще один микрозайм;
3️⃣ «Мы должны релизить сейчас и отвечать за последствия» — Кредит с адекватным процентом и понятным графиком платежей. Осознанный ответственный долг;
4️⃣ «Теперь мы знаем, как это следовало бы реализовать» — Если бы я знал о грядущих локдауне и удалёнке, то купил бы дом, а не студию в центре. В частном доме больше места, удобнее организовать рабочее пространство и есть свой двор. Спрос на частные дома сильно вырос, а с ним и цены.
Если разработчик находится в среде, где от него требуют наиболее быстрой и дешевой поставки ценности пользователю, то он с большой вероятностью будет порождать техдолг. В этом нет вины разработчика, это системная проблема рабочей среды.
Среду формируют отношение руководства и инструменты. Среди этих инструментов — Definition of Done. С помощью DoD мы избавляемся от первых двух вариантов безответственного техдолга.
Третий вариант возможен только по просьбе владельца продукта, для быстрой проверки сырой гипотезы, или срочного удовлетворения текущей потребности рынка.
От четвертого варианта техдолга не защищены лучшие команды. © M. Fowler
Я призываю создавать такую среду и инструменты, чтобы системно не допускать первых трёх вариантов техдолга.
У нас и так есть риск породить техдолг, даже если будем ответственно и осознаннно подходить к проработке архитектуры.
Этот пост - продолжение предыдущего. По мотивам статьи Мартина Фаулера
С ростом финансовой грамотности человек начинает осознавать разницу между микрозаймом, потребительским кредитом и ипотекой. Чуть позже он начинает разбираться в инвестировании и может принимать взвешенное решение: купить в ипотеку или арендовать и копить.
Можно провести аналогию опыта и ответственности с разработкой и техдолгом:
1️⃣ «Какие такие слои архитектуры?» — Первый микрозайм;
2️⃣ «У нас нет времени на проработку архитектуры» — Когда нет денег на очередной платёж по микрозайму и человек берет для этого еще один микрозайм;
3️⃣ «Мы должны релизить сейчас и отвечать за последствия» — Кредит с адекватным процентом и понятным графиком платежей. Осознанный ответственный долг;
4️⃣ «Теперь мы знаем, как это следовало бы реализовать» — Если бы я знал о грядущих локдауне и удалёнке, то купил бы дом, а не студию в центре. В частном доме больше места, удобнее организовать рабочее пространство и есть свой двор. Спрос на частные дома сильно вырос, а с ним и цены.
Если разработчик находится в среде, где от него требуют наиболее быстрой и дешевой поставки ценности пользователю, то он с большой вероятностью будет порождать техдолг. В этом нет вины разработчика, это системная проблема рабочей среды.
Среду формируют отношение руководства и инструменты. Среди этих инструментов — Definition of Done. С помощью DoD мы избавляемся от первых двух вариантов безответственного техдолга.
Третий вариант возможен только по просьбе владельца продукта, для быстрой проверки сырой гипотезы, или срочного удовлетворения текущей потребности рынка.
От четвертого варианта техдолга не защищены лучшие команды. © M. Fowler
Я призываю создавать такую среду и инструменты, чтобы системно не допускать первых трёх вариантов техдолга.
У нас и так есть риск породить техдолг, даже если будем ответственно и осознаннно подходить к проработке архитектуры.
Open Space Technology - инструмент для проведения мероприятий с большим числом участников.
В группе размером больше чем 6 участников обычно общаются два-три наиболее активных. При этом другие не имеют возможности высказать свое мнение.
Если не все выскажутся, это может привести к трём проблемам:
1️⃣ — Упустят какие-то важные аспекты;
2️⃣ — Примут менее качественное решение;
3️⃣ — Тот, кто не смог высказаться, может почувствовать себя ненужным.
Open Space — фреймворк мероприятия, который решает эти проблемы в любом масштабе, вплоть до тысячи участников.
Он даёт возможность каждому внести свой вклад и рассмотреть тему со всех возможных сторон.
Основная концепция Open Space - выделять аспекты общей темы и отделять обсуждение аспекта в отдельную комнату, куда придут все желающие поговорить именно об этом.
Предлагаю попробовать на практике на нашем митапе 1 апреля после работы.
Регистрация на Timepad
В посты на канале я стараюсь закладывать пространство для мыслей и обсуждений. Например, серия постов про зоны ответственности разработчика.
1 апреля в 19:00 соберемся в зуме, чтобы потрындеть как раз про зоны ответственности разработчика.
Вместо докладов будет свободное общение в формате Open Space.
Единственное отличие от классического Open Space - мы не будем принимать решения.
Каждое мнение правильное, нет цели принять какое-то одно за единственно верное.
Цели:
— собрать вместе разрабов из разных компаний;
— получить удовлетворение от дискуссии;
— завязать новые знакомства;
— узнать, какие есть варианты границ зон ответствености разработчиков, какие у них особенности и как они влияют на продукт и самого разработчика.
Регистрация на Timepad
Увидимся! 🙂
В группе размером больше чем 6 участников обычно общаются два-три наиболее активных. При этом другие не имеют возможности высказать свое мнение.
Если не все выскажутся, это может привести к трём проблемам:
1️⃣ — Упустят какие-то важные аспекты;
2️⃣ — Примут менее качественное решение;
3️⃣ — Тот, кто не смог высказаться, может почувствовать себя ненужным.
Open Space — фреймворк мероприятия, который решает эти проблемы в любом масштабе, вплоть до тысячи участников.
Он даёт возможность каждому внести свой вклад и рассмотреть тему со всех возможных сторон.
Основная концепция Open Space - выделять аспекты общей темы и отделять обсуждение аспекта в отдельную комнату, куда придут все желающие поговорить именно об этом.
Предлагаю попробовать на практике на нашем митапе 1 апреля после работы.
Регистрация на Timepad
В посты на канале я стараюсь закладывать пространство для мыслей и обсуждений. Например, серия постов про зоны ответственности разработчика.
1 апреля в 19:00 соберемся в зуме, чтобы потрындеть как раз про зоны ответственности разработчика.
Вместо докладов будет свободное общение в формате Open Space.
Единственное отличие от классического Open Space - мы не будем принимать решения.
Каждое мнение правильное, нет цели принять какое-то одно за единственно верное.
Цели:
— собрать вместе разрабов из разных компаний;
— получить удовлетворение от дискуссии;
— завязать новые знакомства;
— узнать, какие есть варианты границ зон ответствености разработчиков, какие у них особенности и как они влияют на продукт и самого разработчика.
Регистрация на Timepad
Увидимся! 🙂
qiwi-events.timepad.ru
Онлайн OpenSpace Meetup: Зоны ответственности разработчика / События на TimePad.ru
Живое общение - источник вдохновения
Раньше мы виделись с коллегами в офисе и общались с айтишниками из других компаний на митапах и конференциях. Из этого общения мы черпали вдохновение, узнавали о трендах и процессах в айтишном мире. Такое взаимное опыление было в привычном порядке вещей, и оно сильно влияло на развитие индустрии.
Год удалёнки нас изменил. Мы смогли адаптироваться к сидению по домам, но все силы ушли на эту адаптацию. Мы меньше общаемся с коллегами из других компаний, взаимного опыления не происходит. Максимум - пойти послушать вебинар. После вебинара - сессия Q&A. И это всё. Формат обычно разделяет спикера и слушателей и не подразумевает общения между участниками.
Потихоньку мы начинаем это осознавать и выползать из своих нор.
За последний месяц я попал на несколько мероприятий, где формат располагал участников общаться друг с другом. И это был восторг. Я понял, чего мне не хватало весь год: живого общения с людьми из индустрии.
Говорю «живое», имею ввиду интересную дискуссию в зуме с включенными камерами. Включенная камера - обязательный аттрибут живого общения. Камера помогает входить в эмоциональный контакт с собеседником и лучше понимать друг друга.
Рекомендую найти в себе силы, чтобы вырваться из привычной рутины удалёнки и начать участвовать в сообществе. Вам есть, что сказать, а у других людей есть интересное для вас!
Ходите на митапы, где можно не просто смотреть доклад, а общаться с другими участниками.
Такие мероприятия проводят ребята из Podlodka Crew и TechnicalExcellence. Благодаря им я и понял ценность живого общения.
Такой митап вчера провели мы.
Дать пространство и время для общения и собрать живых людей может каждый!
Спасибо всем, кто помогал в организации и огромное спасибо всем тем, кто вечер четверга посвятил живому общению с коллегами из других компаний.
Вы развиваете айтишное сообщество!
Раньше мы виделись с коллегами в офисе и общались с айтишниками из других компаний на митапах и конференциях. Из этого общения мы черпали вдохновение, узнавали о трендах и процессах в айтишном мире. Такое взаимное опыление было в привычном порядке вещей, и оно сильно влияло на развитие индустрии.
Год удалёнки нас изменил. Мы смогли адаптироваться к сидению по домам, но все силы ушли на эту адаптацию. Мы меньше общаемся с коллегами из других компаний, взаимного опыления не происходит. Максимум - пойти послушать вебинар. После вебинара - сессия Q&A. И это всё. Формат обычно разделяет спикера и слушателей и не подразумевает общения между участниками.
Потихоньку мы начинаем это осознавать и выползать из своих нор.
За последний месяц я попал на несколько мероприятий, где формат располагал участников общаться друг с другом. И это был восторг. Я понял, чего мне не хватало весь год: живого общения с людьми из индустрии.
Говорю «живое», имею ввиду интересную дискуссию в зуме с включенными камерами. Включенная камера - обязательный аттрибут живого общения. Камера помогает входить в эмоциональный контакт с собеседником и лучше понимать друг друга.
Рекомендую найти в себе силы, чтобы вырваться из привычной рутины удалёнки и начать участвовать в сообществе. Вам есть, что сказать, а у других людей есть интересное для вас!
Ходите на митапы, где можно не просто смотреть доклад, а общаться с другими участниками.
Такие мероприятия проводят ребята из Podlodka Crew и TechnicalExcellence. Благодаря им я и понял ценность живого общения.
Такой митап вчера провели мы.
Дать пространство и время для общения и собрать живых людей может каждый!
Спасибо всем, кто помогал в организации и огромное спасибо всем тем, кто вечер четверга посвятил живому общению с коллегами из других компаний.
Вы развиваете айтишное сообщество!
Как совмещать Бизнесовые фичи и Развитие инженерки
Вот мы зафиксировали нижний порог уровня качества выпускаемых фич с помощью Definition of Done.
Не факт, что этот нижний порог — высокий. Скорее всего, тут и там в процессах разработки есть несовершенство и техдолг. Это несовершенство нас тормозит и делает продукт менее качественным.
Например, мы не могли включить в DoD пункт про Unit тесты, пока не было однозначных договоренностей в виде Unit Tests Best Practices. Без них этот пункт не принёс бы ценности: его было бы легко нарушить, или отмазаться, написав один незначительный тест.
Отсутствие Best Practices дает свободу вкусовщине, что может привести к срачам на ревью и разножопице в реализации компонентов. При совместном владении кодом это негативно влияет на Time2Market и на стабильность и поддериживаемость систем в целом.
Как бы так сделать, чтобы команда могла вынырнуть из потока бизнесовых фич, подтянуть инженерные практики и процессы, доработать инструменты для самих разработчиков, улучшить CI/CD, расплатиться с техдолгом?
При чем не однократно, типа субботника, а сделать это непрерывным процессом.
У нас такая проблема была и для её решения мы собрали непрерывный процесс развития разработки.
Раньше я писал про Dual Track Development, когда задачи прорабатываются меньшими циклами разной длины параллельно запилу конкретной фичи в спринте.
С учётом процесса развития разработки у нас получается Tripple Track Development:
1️⃣ — Проработка задач из бэклога
2️⃣ — Разработка фичи в спринте
3️⃣ — Развитие инженерных практик и процессов
В следующем посте подробно опишу этот третий трек и какие результаты он приносит.
Вот мы зафиксировали нижний порог уровня качества выпускаемых фич с помощью Definition of Done.
Не факт, что этот нижний порог — высокий. Скорее всего, тут и там в процессах разработки есть несовершенство и техдолг. Это несовершенство нас тормозит и делает продукт менее качественным.
Например, мы не могли включить в DoD пункт про Unit тесты, пока не было однозначных договоренностей в виде Unit Tests Best Practices. Без них этот пункт не принёс бы ценности: его было бы легко нарушить, или отмазаться, написав один незначительный тест.
Отсутствие Best Practices дает свободу вкусовщине, что может привести к срачам на ревью и разножопице в реализации компонентов. При совместном владении кодом это негативно влияет на Time2Market и на стабильность и поддериживаемость систем в целом.
Как бы так сделать, чтобы команда могла вынырнуть из потока бизнесовых фич, подтянуть инженерные практики и процессы, доработать инструменты для самих разработчиков, улучшить CI/CD, расплатиться с техдолгом?
При чем не однократно, типа субботника, а сделать это непрерывным процессом.
У нас такая проблема была и для её решения мы собрали непрерывный процесс развития разработки.
Раньше я писал про Dual Track Development, когда задачи прорабатываются меньшими циклами разной длины параллельно запилу конкретной фичи в спринте.
С учётом процесса развития разработки у нас получается Tripple Track Development:
1️⃣ — Проработка задач из бэклога
2️⃣ — Разработка фичи в спринте
3️⃣ — Развитие инженерных практик и процессов
В следующем посте подробно опишу этот третий трек и какие результаты он приносит.
Engineering Improvements Track
Мы перешли от конфликта бизнеса и разработки к взаимовыгодному сотрудничеству. Один-два часа в неделю каждый разработчик может посвятить развитию инженерных практик и процессов. Бизнес довольно легко соглашается на один-два часа в неделю. А мы построили такой процесс, который приносит профит даже при минимальных затратах времени.
Наш третий трек базируется на Scrum:
📌 Продукт — Инженерные практики и процессы;
📌 Бэклог продукта — Задачи, направленные на устранение техдолга и улучшение инженерных практик;
📌 Владелец продукта — Сообщество разработчиков, которые приоритезируют бэклог и решают, какие задачи самые важные;
📌 Проработка задач из бэклога (PBR) — Рабочая группа описывает задачу: в чем проблема, как часто возникает, какие риски несёт, если не решать, и какая ценность для бизнеса. Очень важно объяснить бизнесу ценность от этой работы. Чаще всего ценность в более быстром выпуске фич (T2M) и более стабильных системах (внутреннее качество);
📌 Планирование итерации — Один час на первой неделе;
📌 Три Команды разработки — каждую итерацию для трёх задач набираются рабочие группы из разных продуктовых команд;
📌 Фиксированная длина итераций — 8 недель, что эквивалентно 4 бизнесовых спринта из Delivery Track.
Итерации долгие, но мы тратим всего один-два часа в неделю.
При этом раз в 4 бизнесовых спринта прогнозируемо появляется три значимых улучшения инженерных практик и процессов. Обычно мы договариваемся о стандартах типа Best Practice, чтобы не плодить велосипеды. Реже — разрабатываем конкретные улучшения инфраструктуры и инструментов для разработчиков.
Примеры результатов работы по этому треку:
— Тесты в CI Pipeline;
— Повышение стабильности при использовании Kafka;
— Best Practice документирования архитектуры;
— Best Practice по Unit тестам;
— Best Practice по Интеграционным тестам;
— Best Practice по разработке и деплою миграций БД микросервисов;
— стандартизация code style;
— SQL-Linter для Oracle PL/SQL;
— автоматизация разворачивания новой БД для микросервиса;
— Проработали требования и план разработки системы бизнес-мониторинга;
и еще с десяток улучшений, которые сложно описать без погружения в контекст.
Мы собирали этот процесс несколько лет и продолжаем менять. Этот процесс не идеален, но видно что он приносит свои плоды. Сообщество разработчиков из разных команд вместе договариваются о стандартах и лучших практиках, разрабатывают и внедряют инструменты для разработки, ci/cd, мониторинга.
В этот процесс не очень хорошо вписываются конкретные прикладные задачи "накодить". Чтобы их тоже делать в рамках этого процесса, мы думаем, как этот процесс изменить. Возможно, нужна именно dev2dev команда, которая занималась бы конкретно инструментами для разработчиков. Но пока довольны тем что имеем.
А у вас есть непрерывный процесс улучшения инженерки? Пишите в комментах.
Мы перешли от конфликта бизнеса и разработки к взаимовыгодному сотрудничеству. Один-два часа в неделю каждый разработчик может посвятить развитию инженерных практик и процессов. Бизнес довольно легко соглашается на один-два часа в неделю. А мы построили такой процесс, который приносит профит даже при минимальных затратах времени.
Наш третий трек базируется на Scrum:
📌 Продукт — Инженерные практики и процессы;
📌 Бэклог продукта — Задачи, направленные на устранение техдолга и улучшение инженерных практик;
📌 Владелец продукта — Сообщество разработчиков, которые приоритезируют бэклог и решают, какие задачи самые важные;
📌 Проработка задач из бэклога (PBR) — Рабочая группа описывает задачу: в чем проблема, как часто возникает, какие риски несёт, если не решать, и какая ценность для бизнеса. Очень важно объяснить бизнесу ценность от этой работы. Чаще всего ценность в более быстром выпуске фич (T2M) и более стабильных системах (внутреннее качество);
📌 Планирование итерации — Один час на первой неделе;
📌 Три Команды разработки — каждую итерацию для трёх задач набираются рабочие группы из разных продуктовых команд;
📌 Фиксированная длина итераций — 8 недель, что эквивалентно 4 бизнесовых спринта из Delivery Track.
Итерации долгие, но мы тратим всего один-два часа в неделю.
При этом раз в 4 бизнесовых спринта прогнозируемо появляется три значимых улучшения инженерных практик и процессов. Обычно мы договариваемся о стандартах типа Best Practice, чтобы не плодить велосипеды. Реже — разрабатываем конкретные улучшения инфраструктуры и инструментов для разработчиков.
Примеры результатов работы по этому треку:
— Тесты в CI Pipeline;
— Повышение стабильности при использовании Kafka;
— Best Practice документирования архитектуры;
— Best Practice по Unit тестам;
— Best Practice по Интеграционным тестам;
— Best Practice по разработке и деплою миграций БД микросервисов;
— стандартизация code style;
— SQL-Linter для Oracle PL/SQL;
— автоматизация разворачивания новой БД для микросервиса;
— Проработали требования и план разработки системы бизнес-мониторинга;
и еще с десяток улучшений, которые сложно описать без погружения в контекст.
Мы собирали этот процесс несколько лет и продолжаем менять. Этот процесс не идеален, но видно что он приносит свои плоды. Сообщество разработчиков из разных команд вместе договариваются о стандартах и лучших практиках, разрабатывают и внедряют инструменты для разработки, ci/cd, мониторинга.
В этот процесс не очень хорошо вписываются конкретные прикладные задачи "накодить". Чтобы их тоже делать в рамках этого процесса, мы думаем, как этот процесс изменить. Возможно, нужна именно dev2dev команда, которая занималась бы конкретно инструментами для разработчиков. Но пока довольны тем что имеем.
А у вас есть непрерывный процесс улучшения инженерки? Пишите в комментах.
Пирамида Мониторинга
Представьте, что ночью вам звонит разгневанный начальник, которого разбудил его начальник, которого … , который узнал от пользователей, что прод упал.
Этого можно избежать, если продукт хорошо покрыт мониторингом.
Сначала введем термин «Пирамида Мониторинга».
Аналогично Пирамиде Тестирования, предлагаю разделить мониторинг на слои по степени детализации.
Посмотрим на эту пирамиду снизу вверх:
📌 Базовый слой — Мониторинг инфраструктурных юнитов.
Сеть, железо, базы данных, виртуалки, кластерное взаимодействие. Пинги между хостами, температура процессоров, ресурсы на виртуалках. Сюда же можно отнести взаимодействие компонентов распределенных систем, например отставание реплик баз данных. По этим метрикам всегда понятно, что чинить.
📌 Средний слой — Мониторинг интеграции приложений и инфраструктуры.
Liveness probes, метрики частоты успешных и ошибочных клиентских запросов, тайминги выполнения этих запросов.
Из этих метрик уже не всегда бывает понятно, что чинить. Например, если начинаются задержки в доставке SMS-подтверждений, можно переключить на другой шлюз. Но если возрастает время обработки пользовательских запросов, нужно смотреть в низлежащие компоненты: другие сервисы, базы данных. Возможно, пришло время оптимизировать хранилище и SQL запросы.
📌 Самый верхний слой — Мониторинг бизнес-метрик.
Работоспособность пользовательских сценариев и критериев приемки фич.
Покрыть все возможные технические и интеграционные метрики мониторингом невозможно. Спасает бизнес-мониторинг, максимально широко покрывающий продукт. Просевшая конверсия по платежам не дает понимания, как чинить. Но срабатывание мониторинга даст информацию о том, какой пользовательский сценарий сломался и команда разработчиков может подключиться к починке.
📌 Самый-самый верхний слой — Клиент, у которого не работает.
Тут без комментариев 🙈 В идеале, этот слой мониторинга не должен быть задействован.
Обычно системные администраторы заботятся о мониторинге инфраструктуры, а разработчики — о мониторинге приложений.
Часто бывает, что продукт обделён бизнес-мониторингом. Иногда он заботит менеджеров, но чаще всего о его потенциальном существовании не знают или на него просто забивают.
Заботьтесь о мониторинге, и он позаботится о вас 😉
Представьте, что ночью вам звонит разгневанный начальник, которого разбудил его начальник, которого … , который узнал от пользователей, что прод упал.
Этого можно избежать, если продукт хорошо покрыт мониторингом.
Сначала введем термин «Пирамида Мониторинга».
Аналогично Пирамиде Тестирования, предлагаю разделить мониторинг на слои по степени детализации.
Посмотрим на эту пирамиду снизу вверх:
📌 Базовый слой — Мониторинг инфраструктурных юнитов.
Сеть, железо, базы данных, виртуалки, кластерное взаимодействие. Пинги между хостами, температура процессоров, ресурсы на виртуалках. Сюда же можно отнести взаимодействие компонентов распределенных систем, например отставание реплик баз данных. По этим метрикам всегда понятно, что чинить.
📌 Средний слой — Мониторинг интеграции приложений и инфраструктуры.
Liveness probes, метрики частоты успешных и ошибочных клиентских запросов, тайминги выполнения этих запросов.
Из этих метрик уже не всегда бывает понятно, что чинить. Например, если начинаются задержки в доставке SMS-подтверждений, можно переключить на другой шлюз. Но если возрастает время обработки пользовательских запросов, нужно смотреть в низлежащие компоненты: другие сервисы, базы данных. Возможно, пришло время оптимизировать хранилище и SQL запросы.
📌 Самый верхний слой — Мониторинг бизнес-метрик.
Работоспособность пользовательских сценариев и критериев приемки фич.
Покрыть все возможные технические и интеграционные метрики мониторингом невозможно. Спасает бизнес-мониторинг, максимально широко покрывающий продукт. Просевшая конверсия по платежам не дает понимания, как чинить. Но срабатывание мониторинга даст информацию о том, какой пользовательский сценарий сломался и команда разработчиков может подключиться к починке.
📌 Самый-самый верхний слой — Клиент, у которого не работает.
Тут без комментариев 🙈 В идеале, этот слой мониторинга не должен быть задействован.
Обычно системные администраторы заботятся о мониторинге инфраструктуры, а разработчики — о мониторинге приложений.
Часто бывает, что продукт обделён бизнес-мониторингом. Иногда он заботит менеджеров, но чаще всего о его потенциальном существовании не знают или на него просто забивают.
Заботьтесь о мониторинге, и он позаботится о вас 😉
Привет!
В этот четверг вечером встретимся в оффлайне на QIWI Server Party 6.0.
Открываю митап своей любимой темой, сами знаете какой 🙂
Порассуждаем об отличиях бэкенд-программиста и продуктового разработчика.
Обсудим сразу много полезных штук: продуктовую разработку и developer experience, спринты и инженерные практики, PlantUML и архитектуру платёжного шлюза.
А ещё немного похоливарим — стоит ли просить кандидатов писать код на собеседовании? Поговорим в формате круглого стола.
22 апреля, 18:00, Москва, ЗИЛ, Loft Hall №4.
Вход бесплатный, нужно только зарегистрироваться.
Программа митапа и регистрация.
А если не получается приехать, можно подключиться к прямой трансляции на YouTube.
В этот четверг вечером встретимся в оффлайне на QIWI Server Party 6.0.
Открываю митап своей любимой темой, сами знаете какой 🙂
Порассуждаем об отличиях бэкенд-программиста и продуктового разработчика.
Обсудим сразу много полезных штук: продуктовую разработку и developer experience, спринты и инженерные практики, PlantUML и архитектуру платёжного шлюза.
А ещё немного похоливарим — стоит ли просить кандидатов писать код на собеседовании? Поговорим в формате круглого стола.
22 апреля, 18:00, Москва, ЗИЛ, Loft Hall №4.
Вход бесплатный, нужно только зарегистрироваться.
Программа митапа и регистрация.
А если не получается приехать, можно подключиться к прямой трансляции на YouTube.
Совместное владение кодом
Это когда любой разработчик из любой команды может внести изменения в любой программный компонент. Когда писал пост, с удивлением узнал, что эта практика относится к экстремальному программированию 🙂
Такой подход дает продукту гибкость и сокращает Time-to-Market для фич. Номинально каждый разработчик несет ответственность за весь исходный код. Но в этом есть опасность.
Collective code ownership, — коллективное хозяйство. По-другому — «Колхоз». Для кого-то это слово с явно негативным оттенком, пахнет навозом и потными людьми.
Почему оттенок негативный? Проблема в среде.
Общее - значит ничье. Не свое, не жалко.
Так рождаются костыли, код замусоривается и начинает пахнуть. Проблема не в том, что программисты плохие. Проблема в том, что среда вокруг поощряет «пятилетку в три года» и «быстро-быстро, срочно в прод еще вчера». Зачастую в такой среде программисты увольняются раньше, чем сталкиваются с последствиями своих технических решений.
Чтобы выжить и преуспеть, продукт должен быть здоровым и не должен деградировать по скорости внесения изменений. А для этого все компоненты должны быть здоровы.
Мы можем создать среду, поощряющую внутреннее качество системы и её компонентов.
Среда тесно связана с рабочими процессами и регулярными активностями.
Раньше я писал про непрерывный процесс развития инженерки
Еще одна из таких активностей — Архитектурное ревью спринта.
Получилось много буков, пост про Архревью выпущу в понедельник.
А как вы поддерживаете внутреннее качество?
Поделитесь экспертизой в комментах
Это когда любой разработчик из любой команды может внести изменения в любой программный компонент. Когда писал пост, с удивлением узнал, что эта практика относится к экстремальному программированию 🙂
Такой подход дает продукту гибкость и сокращает Time-to-Market для фич. Номинально каждый разработчик несет ответственность за весь исходный код. Но в этом есть опасность.
Collective code ownership, — коллективное хозяйство. По-другому — «Колхоз». Для кого-то это слово с явно негативным оттенком, пахнет навозом и потными людьми.
Почему оттенок негативный? Проблема в среде.
Общее - значит ничье. Не свое, не жалко.
Так рождаются костыли, код замусоривается и начинает пахнуть. Проблема не в том, что программисты плохие. Проблема в том, что среда вокруг поощряет «пятилетку в три года» и «быстро-быстро, срочно в прод еще вчера». Зачастую в такой среде программисты увольняются раньше, чем сталкиваются с последствиями своих технических решений.
Чтобы выжить и преуспеть, продукт должен быть здоровым и не должен деградировать по скорости внесения изменений. А для этого все компоненты должны быть здоровы.
Мы можем создать среду, поощряющую внутреннее качество системы и её компонентов.
Среда тесно связана с рабочими процессами и регулярными активностями.
Раньше я писал про непрерывный процесс развития инженерки
Еще одна из таких активностей — Архитектурное ревью спринта.
Получилось много буков, пост про Архревью выпущу в понедельник.
А как вы поддерживаете внутреннее качество?
Поделитесь экспертизой в комментах
Архитектурное ревью спринта
По аналогии со Scrum-событием ревью спринта, только между разработчиками и про архитектуру.
Архревью — одна из активностей, поддерживающих качественное совместное владение кодом, когда в продукте много команд и на этапе проектирования физически не могут участвовать все.
На встрече каждая команда презентует значимые архитектурные изменения за спринт. Если архитектурных изменений нет, можно пропустить или поделиться чем-то другим полезным. На рассказ 10-15 минут, потом 5 минут на уточняющие вопросы и обратную связь.
Профиты архревью:
📌 — Синхронизация и обмен знаниями
Это отличный способ набраться опыта в архитектурном мышлении. Одна команда за один спринт проектирует одно архитектурное решение, а с помощью архревью можно узнать о четырех-восьми архитектурных изменениях в продукте. Кроме того, разработчики узнают, кто чем занимался и к кому за какой инфой можно идти.
📌— Персистентное описание архитектуры продукта
Для визуализации архитектурного изменения хорошо помогают диаграммы и схемы. Разрабы приносят их на архревью, и они же остаются в качестве документации в Confluence.
📌— Обратная связь для повышения квалификации разработчиков
Так же как ревью спринта дает обратную связь по инкременту, архревью дает обратную связь по архитектуре.
Опытные разработчики могут рассказать, какие еще варианты реализации можно было рассмотреть.
📌— Выявление рисков, связанных с архитектурными решениями
В идеале, этого не должно происходить. Для этого все нужные эксперты должны участвовать в изначальном проектировании при подготовке задачи к спринту по Definition Of Ready. Но все мы люди и можем ошибаться.
Архревью — еще один инструмент, чтобы ошибки не причиняли урон.
Важно понимать, что эта работа уже сделана. Переделывать или отменять её — равноценно остановке спринта, и для этого должен быть выявлен очень критичный риск.
Для четырех команд архревью займёт один час. Одна маленькая встреча в спинт, но большая польза для внутреннего качества продукта и развития разработчиков.
Если у вас нет регулярной встречи, где разработчики обмениваются опытом, — попробуйте! От этого точно будет польза для продукта и для самих разработчиков.
Если у вас есть что-то подобное, напишите о своем опыте в комментах. Всегда интересно узнать о процессах в разных компаниях и попробовать применить хорошие практики у себя.
По аналогии со Scrum-событием ревью спринта, только между разработчиками и про архитектуру.
Архревью — одна из активностей, поддерживающих качественное совместное владение кодом, когда в продукте много команд и на этапе проектирования физически не могут участвовать все.
На встрече каждая команда презентует значимые архитектурные изменения за спринт. Если архитектурных изменений нет, можно пропустить или поделиться чем-то другим полезным. На рассказ 10-15 минут, потом 5 минут на уточняющие вопросы и обратную связь.
Профиты архревью:
📌 — Синхронизация и обмен знаниями
Это отличный способ набраться опыта в архитектурном мышлении. Одна команда за один спринт проектирует одно архитектурное решение, а с помощью архревью можно узнать о четырех-восьми архитектурных изменениях в продукте. Кроме того, разработчики узнают, кто чем занимался и к кому за какой инфой можно идти.
📌— Персистентное описание архитектуры продукта
Для визуализации архитектурного изменения хорошо помогают диаграммы и схемы. Разрабы приносят их на архревью, и они же остаются в качестве документации в Confluence.
📌— Обратная связь для повышения квалификации разработчиков
Так же как ревью спринта дает обратную связь по инкременту, архревью дает обратную связь по архитектуре.
Опытные разработчики могут рассказать, какие еще варианты реализации можно было рассмотреть.
📌— Выявление рисков, связанных с архитектурными решениями
В идеале, этого не должно происходить. Для этого все нужные эксперты должны участвовать в изначальном проектировании при подготовке задачи к спринту по Definition Of Ready. Но все мы люди и можем ошибаться.
Архревью — еще один инструмент, чтобы ошибки не причиняли урон.
Важно понимать, что эта работа уже сделана. Переделывать или отменять её — равноценно остановке спринта, и для этого должен быть выявлен очень критичный риск.
Для четырех команд архревью займёт один час. Одна маленькая встреча в спинт, но большая польза для внутреннего качества продукта и развития разработчиков.
Если у вас нет регулярной встречи, где разработчики обмениваются опытом, — попробуйте! От этого точно будет польза для продукта и для самих разработчиков.
Если у вас есть что-то подобное, напишите о своем опыте в комментах. Всегда интересно узнать о процессах в разных компаниях и попробовать применить хорошие практики у себя.
Contract First
Чтобы запилить стандартную фичу команде разработчиков нужно внести изменения в разные компоненты. Компонентами могут быть Бэкенд и фронты, несколько микросервисов или даже сущности в коде одного приложения. Казалось бы, накодить компоненты и интегрировать их друг с другом.
Подвох кроется как раз в интеграции. При стыковке может вскрыться необходимость дополнительной работы, на которую не закладывались при планировании. Если сшивать всю работу в конце, после того как написан основной код, есть риск поехать по срокам и начать костылить, чтобы успеть.
Типичная проблема: допустим, с бэка на фронт забыли отдать одно поле для отображения пользователю. Очень легко (но не бесплатно) пофиксить эту проблему, если это поле есть во внутренней структуре данных. Достаточно пробросить его в API.
Сложнее и дольше, если для этого поля нужно делать еще бизнес-логику, запрос в БД или взаимодействие с другими компонентами. Дополнительно встает вопрос архитектуры и нагрузки.
Было бы здорово позаботиться об архитектуре и нагрузоустойчивости на этапе проектирования и декомпозиции фичи. Проработка контракта — один и способов подумать о потоках данных фичи. Поэтому мы включили пункт «Проработан драфт контракта» в Definition Of Ready (for sprint). Это просто шпаргалка, о чем еще можно подумать при проработке задачи.
Бывает, что даже совместно и заранее спроектированное апи оказывается не совсем подходящим. В такой ситуации спасает ранняя интеграция компонентов на заглушках. Очень просто сразу после проектирования апи запилить mock-заглушку. И в эту заглушку сразу интегрируются все компоненты.
Во-первых, это тоже помогает выявить неизвестности как можно раньше. Быстрый фидбек — ключ к успеху.
Во-вторых, это развязывает руки для паралельной разработки. Можно не ждать реализации бизнес-логики на бэке, сверстать фронт и получить обратную связь от дизайнера и QA. При этом быть уверенным, что после реализации бизнес-логики интеграция не изменится.
Благодаря Contract First подходу мы ускорили Time2Market и пришли к таким Contract-First Best Practices:
1️⃣ — Проектируем контракт при декомпозиции фичи, чтобы подумать обо всех данных фичи и спроектировать архитектуру;
2️⃣ — В проектировании участвуют эксперты во всех компонентах, чтобы интеграция была удобной для всех;
3️⃣ — При начале разработки фичи сразу выкатываем mock-заглушки контрактов, чтобы интеграция была как можно более ранней;
4️⃣ — Описываем контракт в виде кода в общей shared-библиотеке, чтобы переиспользовать её на серверной и клиентской стороне.
5️⃣ — Бонус, документация апи готова еще до того как фича разработана.
Для визуализации нарисовал наглядную картинку, которая показывает как именно подход Contract First экономит время при разработке.
Чтобы запилить стандартную фичу команде разработчиков нужно внести изменения в разные компоненты. Компонентами могут быть Бэкенд и фронты, несколько микросервисов или даже сущности в коде одного приложения. Казалось бы, накодить компоненты и интегрировать их друг с другом.
Подвох кроется как раз в интеграции. При стыковке может вскрыться необходимость дополнительной работы, на которую не закладывались при планировании. Если сшивать всю работу в конце, после того как написан основной код, есть риск поехать по срокам и начать костылить, чтобы успеть.
Типичная проблема: допустим, с бэка на фронт забыли отдать одно поле для отображения пользователю. Очень легко (но не бесплатно) пофиксить эту проблему, если это поле есть во внутренней структуре данных. Достаточно пробросить его в API.
Сложнее и дольше, если для этого поля нужно делать еще бизнес-логику, запрос в БД или взаимодействие с другими компонентами. Дополнительно встает вопрос архитектуры и нагрузки.
Было бы здорово позаботиться об архитектуре и нагрузоустойчивости на этапе проектирования и декомпозиции фичи. Проработка контракта — один и способов подумать о потоках данных фичи. Поэтому мы включили пункт «Проработан драфт контракта» в Definition Of Ready (for sprint). Это просто шпаргалка, о чем еще можно подумать при проработке задачи.
Бывает, что даже совместно и заранее спроектированное апи оказывается не совсем подходящим. В такой ситуации спасает ранняя интеграция компонентов на заглушках. Очень просто сразу после проектирования апи запилить mock-заглушку. И в эту заглушку сразу интегрируются все компоненты.
Во-первых, это тоже помогает выявить неизвестности как можно раньше. Быстрый фидбек — ключ к успеху.
Во-вторых, это развязывает руки для паралельной разработки. Можно не ждать реализации бизнес-логики на бэке, сверстать фронт и получить обратную связь от дизайнера и QA. При этом быть уверенным, что после реализации бизнес-логики интеграция не изменится.
Благодаря Contract First подходу мы ускорили Time2Market и пришли к таким Contract-First Best Practices:
1️⃣ — Проектируем контракт при декомпозиции фичи, чтобы подумать обо всех данных фичи и спроектировать архитектуру;
2️⃣ — В проектировании участвуют эксперты во всех компонентах, чтобы интеграция была удобной для всех;
3️⃣ — При начале разработки фичи сразу выкатываем mock-заглушки контрактов, чтобы интеграция была как можно более ранней;
4️⃣ — Описываем контракт в виде кода в общей shared-библиотеке, чтобы переиспользовать её на серверной и клиентской стороне.
5️⃣ — Бонус, документация апи готова еще до того как фича разработана.
Для визуализации нарисовал наглядную картинку, которая показывает как именно подход Contract First экономит время при разработке.
❤2
Должен ли сотрудник просить повышение зарплаты
За последние пару недель в разговорах с друзьями и коллегами несколько раз заходила тема "как просить повышение зарплаты" и я понял, что проблемы схожие, а тема более широкая. Обычно HR и руководители говорят, что оцениваются не качества сотрудника, а его работа. Но многие воспринимают зарплату близко к оценке личных качеств и справедливости отношения как к персоне. Поэтому тема еще и тонкая.
Disclaimer: Пост — рассуждение на тему грейдов и мотивации, а не пошаговая инструкция для сотрудника по «истребованию» повышения.
Начнем с вопроса «почему».
Самый распространенный вариант — потому что в текущей ситуации сотрудник полагает, что может получать больше. Кто-то говорит «заслуживает большего» или «считает себя недооцененным». Просить повышения — его путь к справедливости. То есть, с точки зрения сотрудника присутствует некая несправедливость. Дополнительная проблема в субъективности и неуверенности в этой несправедливости. А субъективность и неуверенность исходят из рассинхронизации с руководителем, когда нет прозрачного регулярного процесса пересмотра зп.
Это задает контекст. Есть несправедливость, и сотрудник вынужден просить руководителя её разрешить. В таком контексте довольно сложно общаться в конструктивной позиции «на равных». В таком контексте позиция сотрудника по умолчанию — «снизу», а руководителя — «сверху». Это как будто даже закрепилось в названии ролей сотрудник и руководитель. Хотя если задуматься, то в айти «рынок кандидата», сотрудники более независимы, и руководители заинтересованы в удержании. Но природа человеческого мышления одинакова в любой сфере: просящий — снизу.
Мысль о такой встрече демотивирует сотрудников. Проблема как раз в «позиции снизу». Это заведомо проигрышная позиция, в которой сложно вести конструктивный диалог. Ситуацию усугубляет субъективность обеих сторон.
Если руководитель не согласен с аргументами или процесс и показатели компании не позволяют поднять зп, сотрудник получает тройную дозу демотивации: сначала подготовиться к встрече, потом выстрадать саму встречу, и в конце получить отказ.
В описанной ситуации я вижу несколько проблем:
1️⃣ — сотрудник субъективно чувствует несправедливость;
2️⃣ — сотрудник тратит мыслетопливо на весь этот процесс;
3️⃣ — сотрудник попадает в позицию «снизу»;
4️⃣ — сотрудник и руководитель субъективны на самой встрече, она может пройти неконструктивно.
Эти проблемы можно решить системно, имея в компании регулярный прозрачный процесс и объективные метрики.
Опять получился лонгрид. В следующем посте будет про процесс, с примерами и ссылками.
За последние пару недель в разговорах с друзьями и коллегами несколько раз заходила тема "как просить повышение зарплаты" и я понял, что проблемы схожие, а тема более широкая. Обычно HR и руководители говорят, что оцениваются не качества сотрудника, а его работа. Но многие воспринимают зарплату близко к оценке личных качеств и справедливости отношения как к персоне. Поэтому тема еще и тонкая.
Disclaimer: Пост — рассуждение на тему грейдов и мотивации, а не пошаговая инструкция для сотрудника по «истребованию» повышения.
Начнем с вопроса «почему».
Самый распространенный вариант — потому что в текущей ситуации сотрудник полагает, что может получать больше. Кто-то говорит «заслуживает большего» или «считает себя недооцененным». Просить повышения — его путь к справедливости. То есть, с точки зрения сотрудника присутствует некая несправедливость. Дополнительная проблема в субъективности и неуверенности в этой несправедливости. А субъективность и неуверенность исходят из рассинхронизации с руководителем, когда нет прозрачного регулярного процесса пересмотра зп.
Это задает контекст. Есть несправедливость, и сотрудник вынужден просить руководителя её разрешить. В таком контексте довольно сложно общаться в конструктивной позиции «на равных». В таком контексте позиция сотрудника по умолчанию — «снизу», а руководителя — «сверху». Это как будто даже закрепилось в названии ролей сотрудник и руководитель. Хотя если задуматься, то в айти «рынок кандидата», сотрудники более независимы, и руководители заинтересованы в удержании. Но природа человеческого мышления одинакова в любой сфере: просящий — снизу.
Мысль о такой встрече демотивирует сотрудников. Проблема как раз в «позиции снизу». Это заведомо проигрышная позиция, в которой сложно вести конструктивный диалог. Ситуацию усугубляет субъективность обеих сторон.
Если руководитель не согласен с аргументами или процесс и показатели компании не позволяют поднять зп, сотрудник получает тройную дозу демотивации: сначала подготовиться к встрече, потом выстрадать саму встречу, и в конце получить отказ.
В описанной ситуации я вижу несколько проблем:
1️⃣ — сотрудник субъективно чувствует несправедливость;
2️⃣ — сотрудник тратит мыслетопливо на весь этот процесс;
3️⃣ — сотрудник попадает в позицию «снизу»;
4️⃣ — сотрудник и руководитель субъективны на самой встрече, она может пройти неконструктивно.
Эти проблемы можно решить системно, имея в компании регулярный прозрачный процесс и объективные метрики.
Опять получился лонгрид. В следующем посте будет про процесс, с примерами и ссылками.
Настал день, когда @product_developer рекомендуют в большом канале о продуктах 🙂
Когда начал вести канал, обратился за обратной связью и советом к Владимиру Меркушеву, который давно ведет канал про продукты. Тогда Владимир помог сориентироваться в направлении развития канала и контента. А еще он подписался, чтобы через какое-то время решить, может ли он рекомендовать мой канал своим подписчикам.
Спасибо Владимиру за обратную связь и эту рекомендацию!
https://www.tg-me.com/vladimir_merkushev/1086
Когда начал вести канал, обратился за обратной связью и советом к Владимиру Меркушеву, который давно ведет канал про продукты. Тогда Владимир помог сориентироваться в направлении развития канала и контента. А еще он подписался, чтобы через какое-то время решить, может ли он рекомендовать мой канал своим подписчикам.
Спасибо Владимиру за обратную связь и эту рекомендацию!
https://www.tg-me.com/vladimir_merkushev/1086
Telegram
Продукторий Владимира Меркушева
Помните, у меня была рубрика с рекомендациями небольших, но интересных каналов о продуктах и маркетинге? Я продолжаю вести специальный списочек и сегодня готов пригласить вас попробовать 3 новых канала.
@Inwebua — канал моих давних знакомых из Netpeak Group…
@Inwebua — канал моих давних знакомых из Netpeak Group…
Performance Review
Это регулярный процесс синхронизации компании с сотрудником. Чтобы он не задавался вопросом «как просить повышение зарплаты», а точно понимал: какие от него ожидания, как он им соответствует и когда таки будет повышение.
Исходим от задачи: синхронизироваться с сотрудником по ожиданиям и его соответствию + закрыть базовую потребность в справедливом вознаграждении.
В идеале, при этом процессе сотрудник своевременно получает прибавку по мере развития. Для этого должен быть способ однозначно сделать вывод о его текущем уровне навыков и степени вклада в продукт.
Навыки
Например, это может быть общий для продукта список навыков. Для каждого навыка прописаны примеры наблюдаемого проявления на уровнях Junior, Middle, Senior. По каждому навыку можно однозначно понять, проявляет ли его сотрудник и если да, то на каком уровне.
Эта матрица за каждого сотрудника заполняется им самим, его коллегами и его руководителем.
Эта матрица — способ обеспечить справедливость между сотрудниками.
Она же — способ ретроспективно оценить развитие сотрудника, достаточно посмотреть в значения квартал назад.
Performance
Степень вклада в продукт — максимально непонятная зона. Попытка формализовать процесс измерения вклада может привести к введению KPI на строчки кода. После такого от Performance review отказались ABBYY и Microsoft. Все успешные примеры Performance Review подразумевают индивидуальный подход к каждому сотруднику.
Регулярность
Смотрите, выше про матрицу компетенций я говорю «квартал назад». Этот процесс должен быть регулярным. Только так мы снимем с сотрудника необходимость следить за справедливостью своего вознаграждения. Тут важно не переборщить с частотой, потому что растёт оверхед такого процесса для компании.
Прозрачность
А еще этот процесс должен быть максимально прозрачным для всех в компании. А еще круче — для всех в индустрии. Для меня идеал прозрачности - Open Source. Посмотрите, как круто чуваки из Avito описали свои процессы на гитхабе:
Описания грейдов — про компетенции и soft skills для каждого грейда.
Мне как стороннему наблюдателю было бы интересно почитать еще про уровни hard skills и примеры наблюдаемого поведения для компетенций.
Процесс Performance Review — про процесс, определяющий продвижение по грейдам и по зарплате.
Вообще, рекомендую статью Егора Толстого на хабре. Топ прозрачности процесса и куча пользы для комьюнити. Внизу статьи еще ссылки на источники.
Итог:
Процесс в первую очередь должен быть регулярным, прозрачным. Эти два фактора обеспечить проще всего, и они уже решают большую часть проблемы.
Труднее сделать процесс объективно измеряющим и навыки и вклад. Все примеры процессов, которые я находил, — включали большую долю субъективизма оценивающего.
Хорошее свойство процесса — учитывать этот субъективизм и гарантировать справедливую оценку.
Как всегда, велком в комменты. Если вы знаете, где еще почитать про Performance Review, и особенно если такой опыт есть у вас, напишите в комментарии. Приветствуется в том числе рассказ о том, как не зашло 🙂
Это регулярный процесс синхронизации компании с сотрудником. Чтобы он не задавался вопросом «как просить повышение зарплаты», а точно понимал: какие от него ожидания, как он им соответствует и когда таки будет повышение.
Исходим от задачи: синхронизироваться с сотрудником по ожиданиям и его соответствию + закрыть базовую потребность в справедливом вознаграждении.
В идеале, при этом процессе сотрудник своевременно получает прибавку по мере развития. Для этого должен быть способ однозначно сделать вывод о его текущем уровне навыков и степени вклада в продукт.
Навыки
Например, это может быть общий для продукта список навыков. Для каждого навыка прописаны примеры наблюдаемого проявления на уровнях Junior, Middle, Senior. По каждому навыку можно однозначно понять, проявляет ли его сотрудник и если да, то на каком уровне.
Эта матрица за каждого сотрудника заполняется им самим, его коллегами и его руководителем.
Эта матрица — способ обеспечить справедливость между сотрудниками.
Она же — способ ретроспективно оценить развитие сотрудника, достаточно посмотреть в значения квартал назад.
Performance
Степень вклада в продукт — максимально непонятная зона. Попытка формализовать процесс измерения вклада может привести к введению KPI на строчки кода. После такого от Performance review отказались ABBYY и Microsoft. Все успешные примеры Performance Review подразумевают индивидуальный подход к каждому сотруднику.
Регулярность
Смотрите, выше про матрицу компетенций я говорю «квартал назад». Этот процесс должен быть регулярным. Только так мы снимем с сотрудника необходимость следить за справедливостью своего вознаграждения. Тут важно не переборщить с частотой, потому что растёт оверхед такого процесса для компании.
Прозрачность
А еще этот процесс должен быть максимально прозрачным для всех в компании. А еще круче — для всех в индустрии. Для меня идеал прозрачности - Open Source. Посмотрите, как круто чуваки из Avito описали свои процессы на гитхабе:
Описания грейдов — про компетенции и soft skills для каждого грейда.
Мне как стороннему наблюдателю было бы интересно почитать еще про уровни hard skills и примеры наблюдаемого поведения для компетенций.
Процесс Performance Review — про процесс, определяющий продвижение по грейдам и по зарплате.
Вообще, рекомендую статью Егора Толстого на хабре. Топ прозрачности процесса и куча пользы для комьюнити. Внизу статьи еще ссылки на источники.
Итог:
Процесс в первую очередь должен быть регулярным, прозрачным. Эти два фактора обеспечить проще всего, и они уже решают большую часть проблемы.
Труднее сделать процесс объективно измеряющим и навыки и вклад. Все примеры процессов, которые я находил, — включали большую долю субъективизма оценивающего.
Хорошее свойство процесса — учитывать этот субъективизм и гарантировать справедливую оценку.
Как всегда, велком в комменты. Если вы знаете, где еще почитать про Performance Review, и особенно если такой опыт есть у вас, напишите в комментарии. Приветствуется в том числе рассказ о том, как не зашло 🙂
👍2
Commitment — обязательство?
Среди ценностей Scrum есть Commitment.
Буквально переводится как обязательство.
Есть опасность в буквальном переводе Commitment to Sprint Goal, когда в компании в целом и среде вокруг команды есть культура достигаторства и «отвечания за базар».
Я долгое время трактовал это именно как обязательство по достижению цели спринта в объеме, запланированном в первый день спринта. Когда мы не успевали, я испытывал тревогу и чувство вины. Потом я кое-что понял и жить стало легче. Хочу этим поделиться.
Смотрите, Контринтуитивное утверждение:
Если у команды жесткое обязательство на достижение цели спринта и негативныве последствия в противном случае, то это негативно влияет на time2market и качество.
Объясню, почему так:
1️⃣ — Если нереальная цель уже в спринте и надо «кровь из носу» успеть, то качество пострадает уже сейчас, а time-2-market в будущем. Чтобы успеть, разработчикам придется породить техдолг. Слово долг здесь очень уместно: по сути, они берут время в долг у себя (или других разрабов) из будущего. Разработчикам в будущем придется тратить еще больше времени на борьбу с техдолгом.
2️⃣ — Если стоит выбор, сколько работы взять в спринт, то разработчики будут осторожничать, закладывать больше запаса на риски. Time-2-market страдает уже на этапе планирования работы.
Отмотаем немного назад. Scrum был придуман для работы в условиях неизвестности и постоянных изменений. Кажется, жесткая фиксация цели спринта и полное её достижение в таких условиях — скорее чудо, чем норма.
Заглянем в Scrum Guide. А точнее, в историю изменений.
Смотрите, в 2011 году первым пунктом слово «обязанность» заменили на «прогноз».:
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
Вот статья на scrum.org об этой замене.
Смотрим актуальный гайд, конкретное место: Commitment: Sprint Goal.
Смотрим официальный перевод 2020г, а там вообще приверженность.
Из контекста скрамгайда я трактую Commitment не как обязательство, а как стремление. Как в идиоме Commitment to Excellence, стремление к совершенству.
Ценность Commitment — не про жесткое обязательство сделать цель спринта.
Эта ценность — про стремление к совершенству, стремление делать работу качественно (по Definition of Done), работать в команде, быть сфокусированными на цели спринта, учиться, рефлексировать, адаптироваться, искать пути для улучшения, быть проактивными, и делать всё что в наших силах для улучшения продукта.
Среди ценностей Scrum есть Commitment.
Буквально переводится как обязательство.
Есть опасность в буквальном переводе Commitment to Sprint Goal, когда в компании в целом и среде вокруг команды есть культура достигаторства и «отвечания за базар».
Я долгое время трактовал это именно как обязательство по достижению цели спринта в объеме, запланированном в первый день спринта. Когда мы не успевали, я испытывал тревогу и чувство вины. Потом я кое-что понял и жить стало легче. Хочу этим поделиться.
Смотрите, Контринтуитивное утверждение:
Если у команды жесткое обязательство на достижение цели спринта и негативныве последствия в противном случае, то это негативно влияет на time2market и качество.
Объясню, почему так:
1️⃣ — Если нереальная цель уже в спринте и надо «кровь из носу» успеть, то качество пострадает уже сейчас, а time-2-market в будущем. Чтобы успеть, разработчикам придется породить техдолг. Слово долг здесь очень уместно: по сути, они берут время в долг у себя (или других разрабов) из будущего. Разработчикам в будущем придется тратить еще больше времени на борьбу с техдолгом.
2️⃣ — Если стоит выбор, сколько работы взять в спринт, то разработчики будут осторожничать, закладывать больше запаса на риски. Time-2-market страдает уже на этапе планирования работы.
Отмотаем немного назад. Scrum был придуман для работы в условиях неизвестности и постоянных изменений. Кажется, жесткая фиксация цели спринта и полное её достижение в таких условиях — скорее чудо, чем норма.
Заглянем в Scrum Guide. А точнее, в историю изменений.
Смотрите, в 2011 году первым пунктом слово «обязанность» заменили на «прогноз».:
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
Вот статья на scrum.org об этой замене.
Смотрим актуальный гайд, конкретное место: Commitment: Sprint Goal.
Смотрим официальный перевод 2020г, а там вообще приверженность.
Из контекста скрамгайда я трактую Commitment не как обязательство, а как стремление. Как в идиоме Commitment to Excellence, стремление к совершенству.
Ценность Commitment — не про жесткое обязательство сделать цель спринта.
Эта ценность — про стремление к совершенству, стремление делать работу качественно (по Definition of Done), работать в команде, быть сфокусированными на цели спринта, учиться, рефлексировать, адаптироваться, искать пути для улучшения, быть проактивными, и делать всё что в наших силах для улучшения продукта.
Привет!
Раньше я постил анонсы нескольких наших мероприятий. А вчера ко мне обратились с просьбой попромить митап, о котором я не слышал раньше. Я ответил, что должен посмотреть и решить, могу ли рекомендовать его своей аудитории. Пост вы таки читаете 🙂
Ребята делают митапы каждые две недели чуть больше девяти месяцев. Это круто, такая движуха — сильный вклад в комьюнити, и польза для всех нас. Поэтому я поддерживаю всеми руками и ногами.
Затрагивают разные темы из разработки и менеджмента, и многие у меня откликнулись.
На ближайшем митапе 10 июня в 17:00 будет две темы:
1️⃣ Функциональные языки для бизнес-разработки
Прямо в этом спринте мы правим один там залегасившийся компонент на Scala. Хочу посмотреть, какие грабли нас еще ждут впереди.
2️⃣ Проектирование расширяемых приложений: плагинная архитектура
Вообще заявлен C#, но у меня есть флешбеки с микрофронтендами. Хочу посмотреть, насколько концепции пересекаются.
Короче, мне стало интересно, поэтому смело рекомендую. Мероприятие бесплатное и мне ессно никто не платил.
Ссылка на оригинальный анонс:
https://www.tg-me.com/neattalks/33
Раньше я постил анонсы нескольких наших мероприятий. А вчера ко мне обратились с просьбой попромить митап, о котором я не слышал раньше. Я ответил, что должен посмотреть и решить, могу ли рекомендовать его своей аудитории. Пост вы таки читаете 🙂
Ребята делают митапы каждые две недели чуть больше девяти месяцев. Это круто, такая движуха — сильный вклад в комьюнити, и польза для всех нас. Поэтому я поддерживаю всеми руками и ногами.
Затрагивают разные темы из разработки и менеджмента, и многие у меня откликнулись.
На ближайшем митапе 10 июня в 17:00 будет две темы:
1️⃣ Функциональные языки для бизнес-разработки
Прямо в этом спринте мы правим один там залегасившийся компонент на Scala. Хочу посмотреть, какие грабли нас еще ждут впереди.
2️⃣ Проектирование расширяемых приложений: плагинная архитектура
Вообще заявлен C#, но у меня есть флешбеки с микрофронтендами. Хочу посмотреть, насколько концепции пересекаются.
Короче, мне стало интересно, поэтому смело рекомендую. Мероприятие бесплатное и мне ессно никто не платил.
Ссылка на оригинальный анонс:
https://www.tg-me.com/neattalks/33
Telegram
Neat Talks
Привет! ✋
🎤 В четверг 10 июня в 17:00 по МСК пройдет Neat Talks 17, на котором мы поговорим о функциональных языках и о плагинной архитектуре.
⏰ 17:00 - Функциональные языки для бизнес-разработки (50 минут)
👨💻 Неволин Роман @nevoroman, Developer Relations…
🎤 В четверг 10 июня в 17:00 по МСК пройдет Neat Talks 17, на котором мы поговорим о функциональных языках и о плагинной архитектуре.
⏰ 17:00 - Функциональные языки для бизнес-разработки (50 минут)
👨💻 Неволин Роман @nevoroman, Developer Relations…
Definition Of Ready
На прошлый пост Commitment — обязательство? один близкий друг мне возразил: если разработчики не будут брать на себя обязательств, то будут из спринта в спринт ехать задачи. Справедливая точка зрения, позволю себе раскрутить эту мысль.
Можно даже предположить, что я хочу снять ответственность с разработчиков за цель спринта. Но оглядываясь назад, проваленные спринты были не из-за того что мы были безответственны и пинали баклуши.
Если план спринта нарушался, это происходило из-за неучтённой при планировании работы.
📌 Например, неучтённый компонент. Оказывалось, что в него тоже нужно было внести изменения, пройти ревью и зарелизить.
📌 Или выяснялся кейс, не описанный в критериях приемки. Это нужно было срочно решать, согласовывать со стейкхолдерами, и тоже кодить.
📌 В худшем случае появлялась необходимость работы внешних подразделений. Врываться в чей-то рабочий режим с горящей задницей — не лучшая стратегия для долгосрочных продуктивных отношений.
На самом деле, обо всем этом можно было подумать заранее. Давайте примем, что мы люди, а память у людей работает неидеально. Нереально помнить все аспекты, о которых нужно подумать. В какой-то момент мы подумали, о чем стоит вспомнить при проработке задачи.
Тогда мы составили чек-лист Definition Of Ready (for sprint).
Теперь при проработке задачи у нас есть возможность вспомнить о согласованиях, пропиливании доступов, обеспечению метрик для постоценки. Пункты про список компонентов, проработку архитектуры и наброски контрактов помогают нам погрузиться в будущую реализацию, учесть возможные нюансы, построить верхнеуровневый план, понять влезает ли в спринт и декомпозировать при необходимости.
DoR — шпаргалка, но не барьер. DoR не запрещает брать в спринт непроработанную задачу. Если есть уникальная возможность на рынке, которую нужно быстро удовлетворить, то прорабатывать задачу можно уже в спринте. Но DoR — инструмент, помогающий прогнозируемо достигать цели. Это способ подстелить соломку себе-из-будущего.
Если наш спринт поехал, на ретроспективе мы стараемся осознать причину, и добавить пункт в DoR. Сегодня как раз пятница, у кого-то конец спринта и ретроспектива 🙂
Если у вас нет Definition of Ready, предлагаю добавить в минимальном виде, буквально несколько пунктов. Дальше итеративно вы сможете его дополнять. Так начали мы, и это помогло в достижении целей спринтов. Может помочь и вам.
На прошлый пост Commitment — обязательство? один близкий друг мне возразил: если разработчики не будут брать на себя обязательств, то будут из спринта в спринт ехать задачи. Справедливая точка зрения, позволю себе раскрутить эту мысль.
Можно даже предположить, что я хочу снять ответственность с разработчиков за цель спринта. Но оглядываясь назад, проваленные спринты были не из-за того что мы были безответственны и пинали баклуши.
Если план спринта нарушался, это происходило из-за неучтённой при планировании работы.
📌 Например, неучтённый компонент. Оказывалось, что в него тоже нужно было внести изменения, пройти ревью и зарелизить.
📌 Или выяснялся кейс, не описанный в критериях приемки. Это нужно было срочно решать, согласовывать со стейкхолдерами, и тоже кодить.
📌 В худшем случае появлялась необходимость работы внешних подразделений. Врываться в чей-то рабочий режим с горящей задницей — не лучшая стратегия для долгосрочных продуктивных отношений.
На самом деле, обо всем этом можно было подумать заранее. Давайте примем, что мы люди, а память у людей работает неидеально. Нереально помнить все аспекты, о которых нужно подумать. В какой-то момент мы подумали, о чем стоит вспомнить при проработке задачи.
Тогда мы составили чек-лист Definition Of Ready (for sprint).
Теперь при проработке задачи у нас есть возможность вспомнить о согласованиях, пропиливании доступов, обеспечению метрик для постоценки. Пункты про список компонентов, проработку архитектуры и наброски контрактов помогают нам погрузиться в будущую реализацию, учесть возможные нюансы, построить верхнеуровневый план, понять влезает ли в спринт и декомпозировать при необходимости.
DoR — шпаргалка, но не барьер. DoR не запрещает брать в спринт непроработанную задачу. Если есть уникальная возможность на рынке, которую нужно быстро удовлетворить, то прорабатывать задачу можно уже в спринте. Но DoR — инструмент, помогающий прогнозируемо достигать цели. Это способ подстелить соломку себе-из-будущего.
Если наш спринт поехал, на ретроспективе мы стараемся осознать причину, и добавить пункт в DoR. Сегодня как раз пятница, у кого-то конец спринта и ретроспектива 🙂
Если у вас нет Definition of Ready, предлагаю добавить в минимальном виде, буквально несколько пунктов. Дальше итеративно вы сможете его дополнять. Так начали мы, и это помогло в достижении целей спринтов. Может помочь и вам.
Используете Definition Of Ready (for sprint)?
Anonymous Poll
36%
Да
49%
Еще нет, но задумался
12%
Нет, не понимаю ценности
4%
Свой вариант в комментарии
Деньги vs Мотивация
Лет 6 назад один начальник вдохновил меня фразой «лучшее резюме — мешок денег, заработанный своим ремеслом». На вопрос мотивации тогда я бы сказал, что хожу на работу работать работу за деньги, и че тут разговаривать о какой-то там мотивации. Добавьте денег — будет мотивация.
Даже тогда это было бы неправдой. Сейчас я пишу пост о том, что деньги — откровенно хреновый мотиватор делать что-то и точно не мотиватор становиться лучше. Но деньги — базовая потребность, после удовлетворения которой может начать развиваться настоящая мотивация. Больше шансов полюбить свое дело и развиваться в нём, если сосредоточиться на работе и людях вокруг, а не на деньгах.
Условно, мотивацию можно поделить на внешнюю и внутреннюю. Они друг друга вытесняют.
Внешняя — подкрепление желаемого поведения снаружи
Хороший пример — позитивная обратная связь коллег и руководства.
Нормальный пример — небольшая регулярная прибавка к ЗП как признание развития.
Плохой пример — навалить человеку котлету денег в стремлении удержать его в компании. Это разворошит его сознание, породит либо синдром замозванца и страх завышенных ожиданий, либо нарциссические мысли, и на 100% отвлечет от работы. Человек останется в компании, но есть большой риск что от него теперь будет больше вреда.
Внутренняя — самоподкрепление
В любое живое существо заложены механизмы самоподкрепления.
Каждый день вы можете видеть на улицах бегающих людей. Есть куча беговых сообществ, забеги в крупных городах собирают десятки тысяч участников. Это целый параллельный беговой мир. Если вы бегаете сами, то понимаете к чему веду. Приведу цитату Строфилова:
Некоторые бегуны испытывают эйфорию, похожую на действие LSD, к другим приходит вдохновение, и они начинают писать стихи и книги, третьи находят смысл жизни.
Наш организм сам поощряет такое поведение. И это самая сильная мотивация. Поэтому так много людей бегают регулярно. Нет никакой «силы воли», которую надо напрячь чтобы сбросить лишние килограммы. Есть просто кайф от процесса.
Давайте попробуем переложить это на работу. На чистой силе воли можно работать работу и без мотивации. Но сколько так может продолжаться? А если найти то, что в самой работе заставляет ваш мозг выделять дофамин?
Мы можем осознанно выбрать: кайфовать или механически делать работу. Думать о деньгах или думать о том, что вдохновляет.
Мы проводим на работе большую часть жизни. Эта жизнь может быть полной беспокойств, а может быть счастливой. Мы можем этим управлять.
Пост на тему денег и мотивации мы договорились написать совместно с Анастасией Калашниковой, ведущей канала Psy в IT. Она сказала, что напишет (внезапно) о важности денег в мотивации. Её пост тут: https://www.tg-me.com/psyvit/423
Лет 6 назад один начальник вдохновил меня фразой «лучшее резюме — мешок денег, заработанный своим ремеслом». На вопрос мотивации тогда я бы сказал, что хожу на работу работать работу за деньги, и че тут разговаривать о какой-то там мотивации. Добавьте денег — будет мотивация.
Даже тогда это было бы неправдой. Сейчас я пишу пост о том, что деньги — откровенно хреновый мотиватор делать что-то и точно не мотиватор становиться лучше. Но деньги — базовая потребность, после удовлетворения которой может начать развиваться настоящая мотивация. Больше шансов полюбить свое дело и развиваться в нём, если сосредоточиться на работе и людях вокруг, а не на деньгах.
Условно, мотивацию можно поделить на внешнюю и внутреннюю. Они друг друга вытесняют.
Внешняя — подкрепление желаемого поведения снаружи
Хороший пример — позитивная обратная связь коллег и руководства.
Нормальный пример — небольшая регулярная прибавка к ЗП как признание развития.
Плохой пример — навалить человеку котлету денег в стремлении удержать его в компании. Это разворошит его сознание, породит либо синдром замозванца и страх завышенных ожиданий, либо нарциссические мысли, и на 100% отвлечет от работы. Человек останется в компании, но есть большой риск что от него теперь будет больше вреда.
Внутренняя — самоподкрепление
В любое живое существо заложены механизмы самоподкрепления.
Каждый день вы можете видеть на улицах бегающих людей. Есть куча беговых сообществ, забеги в крупных городах собирают десятки тысяч участников. Это целый параллельный беговой мир. Если вы бегаете сами, то понимаете к чему веду. Приведу цитату Строфилова:
Некоторые бегуны испытывают эйфорию, похожую на действие LSD, к другим приходит вдохновение, и они начинают писать стихи и книги, третьи находят смысл жизни.
Наш организм сам поощряет такое поведение. И это самая сильная мотивация. Поэтому так много людей бегают регулярно. Нет никакой «силы воли», которую надо напрячь чтобы сбросить лишние килограммы. Есть просто кайф от процесса.
Давайте попробуем переложить это на работу. На чистой силе воли можно работать работу и без мотивации. Но сколько так может продолжаться? А если найти то, что в самой работе заставляет ваш мозг выделять дофамин?
Мы можем осознанно выбрать: кайфовать или механически делать работу. Думать о деньгах или думать о том, что вдохновляет.
Мы проводим на работе большую часть жизни. Эта жизнь может быть полной беспокойств, а может быть счастливой. Мы можем этим управлять.
Пост на тему денег и мотивации мы договорились написать совместно с Анастасией Калашниковой, ведущей канала Psy в IT. Она сказала, что напишет (внезапно) о важности денег в мотивации. Её пост тут: https://www.tg-me.com/psyvit/423
Telegram
Psy в IT
У нас тут на выходных прошёл интенсив для выпускников. Одна из тем встречи - мотивация команды. Тема важная и нужная, хотя зачастую воспринимается очень поверхностно. Особенно это касается мотивации на деньги, заработок.
Очень часто руководитель из обращения…
Очень часто руководитель из обращения…
Продуктовый подход к найму
Так получилось, что сам я собеседовал в команду последний раз года три назад. И на три года забыл об этом. Недавно мне предложили включиться в процесс найма в компанию. Прошел обучение, сходил несколько раз как наблюдатель, потом собеседовал сам. Признаюсь, первые разы были волнительными. Объективно оценить человека за короткое время сложно, а цена ошибки высока.
Иногда слышал, как коллеги ходят по собеседованиям. Для меня тогда это выглядело как «поход налево». Явной политики партии на эту тему не было. А где нет договоренностей — там возникают субъективные додумки и недопонимание между людьми.
И только когда включился в процесс найма в компанию понял, что и здесь возможен продуктовый подход.
Выход с исследованием на рынок — один из продуктовых методов. Который к тому же помогает снять волнение на самом интервью.
Оттолкнемся от того, что наш клиент — кандидат. Разработчик, который пришел к нам на интервью. Для многих это стресс, который надо пройти ради будущего блага. Тут всё сводится к тому, чтобы дать кандидату лучший клиентский опыт, чем конкуренты. Короче, надо понять, как сделать клиенту хорошо. При этом важно самим понять, что кандидат нам подходит.
Побывав с обеих сторон собеседований, для себя я определил такие критерии хорошего процесса:
📌 — Кандидат раскрывает свои сильные стороны.
Бывает, что с кандидата «сбивают ценник», находя его слабости. Со стороны это может выглядеть как самоутверждение интервьюера. Если тратить время на закапывание в слабые стороны, можно не найти ни одной сильной. Нащупав пробел, лучше перейти к другой области, чтобы кандидат раскрылся.
📌 — Кандидату комфортно.
Интервью — не допрос с пристрастием, а общение профессионалов. Топовый скилл интервьюера — сохранять позицию «на равных». Для этого помогает изначальная позиция «с кандидатом всё ок».
📌 — Интервьюеров несколько.
Чтобы оценка была более объективной и не зависела от настроения или самочувствия одного.
📌 — Есть шпаргалка для интервьюеров.
Чтобы не придумывать на ходу, о чем еще спросить.
📌 — Есть профиль с навыками и компетенциями.
Чтобы понимать, что проверять.
📌 — Не принимать решение на самом интервью.
Если интервьюер решил, что кандидат не подходит, это отражается на мимике, жестах, поведении, вопросах. Кандидат это считывает. После этого почти нет шанса, что кандидат сможет раскрыть свои сильные стороны. Хотя это было бы возможно, если бы решение не было принято.
📌 — Работа оправдывает собеседования.
Чтобы новоиспеченный сотрудник не испытал разочарования от скучности реальных задач, после прохождения очень сложного собеседования.
…
Есть большие компании с мощным HR-брендом. Они притягивают на вход огромный поток кандидатов. Чтобы этот поток переварить, они выстраивают общий процесс найма с пайплайном отсева. Прежде чем кандидат дойдёт до команды, он пройдёт через общие секции по языку, алгоритмам, архитектуре. Тогда команде остается только оценить, подходит ли кандидат по ментальности.
Когда выстроен такой пайплайн, и в него на вход поступает огромное количество кандидатов, очень сложно учесть индивидуальность кандидатов. Некоторым это удается, за это респект.
Большинству компаний нужно принять решение об оффере за одно интервью. Иначе это сделают другие и кандидат уйдёт. Поэтому мы стараемся принять решение за одно полутора-двухчасовое интервью. На нем в основном мы стараемся узнать о кандидате. А чтобы кандидат мог сделать осознанный выбор, мы готовы час рассказывать о компании уже после оффера.
Так получилось, что сам я собеседовал в команду последний раз года три назад. И на три года забыл об этом. Недавно мне предложили включиться в процесс найма в компанию. Прошел обучение, сходил несколько раз как наблюдатель, потом собеседовал сам. Признаюсь, первые разы были волнительными. Объективно оценить человека за короткое время сложно, а цена ошибки высока.
Иногда слышал, как коллеги ходят по собеседованиям. Для меня тогда это выглядело как «поход налево». Явной политики партии на эту тему не было. А где нет договоренностей — там возникают субъективные додумки и недопонимание между людьми.
И только когда включился в процесс найма в компанию понял, что и здесь возможен продуктовый подход.
Выход с исследованием на рынок — один из продуктовых методов. Который к тому же помогает снять волнение на самом интервью.
Оттолкнемся от того, что наш клиент — кандидат. Разработчик, который пришел к нам на интервью. Для многих это стресс, который надо пройти ради будущего блага. Тут всё сводится к тому, чтобы дать кандидату лучший клиентский опыт, чем конкуренты. Короче, надо понять, как сделать клиенту хорошо. При этом важно самим понять, что кандидат нам подходит.
Побывав с обеих сторон собеседований, для себя я определил такие критерии хорошего процесса:
📌 — Кандидат раскрывает свои сильные стороны.
Бывает, что с кандидата «сбивают ценник», находя его слабости. Со стороны это может выглядеть как самоутверждение интервьюера. Если тратить время на закапывание в слабые стороны, можно не найти ни одной сильной. Нащупав пробел, лучше перейти к другой области, чтобы кандидат раскрылся.
📌 — Кандидату комфортно.
Интервью — не допрос с пристрастием, а общение профессионалов. Топовый скилл интервьюера — сохранять позицию «на равных». Для этого помогает изначальная позиция «с кандидатом всё ок».
📌 — Интервьюеров несколько.
Чтобы оценка была более объективной и не зависела от настроения или самочувствия одного.
📌 — Есть шпаргалка для интервьюеров.
Чтобы не придумывать на ходу, о чем еще спросить.
📌 — Есть профиль с навыками и компетенциями.
Чтобы понимать, что проверять.
📌 — Не принимать решение на самом интервью.
Если интервьюер решил, что кандидат не подходит, это отражается на мимике, жестах, поведении, вопросах. Кандидат это считывает. После этого почти нет шанса, что кандидат сможет раскрыть свои сильные стороны. Хотя это было бы возможно, если бы решение не было принято.
📌 — Работа оправдывает собеседования.
Чтобы новоиспеченный сотрудник не испытал разочарования от скучности реальных задач, после прохождения очень сложного собеседования.
…
Есть большие компании с мощным HR-брендом. Они притягивают на вход огромный поток кандидатов. Чтобы этот поток переварить, они выстраивают общий процесс найма с пайплайном отсева. Прежде чем кандидат дойдёт до команды, он пройдёт через общие секции по языку, алгоритмам, архитектуре. Тогда команде остается только оценить, подходит ли кандидат по ментальности.
Когда выстроен такой пайплайн, и в него на вход поступает огромное количество кандидатов, очень сложно учесть индивидуальность кандидатов. Некоторым это удается, за это респект.
Большинству компаний нужно принять решение об оффере за одно интервью. Иначе это сделают другие и кандидат уйдёт. Поэтому мы стараемся принять решение за одно полутора-двухчасовое интервью. На нем в основном мы стараемся узнать о кандидате. А чтобы кандидат мог сделать осознанный выбор, мы готовы час рассказывать о компании уже после оффера.