Как-то один замечательный человек спросил:
Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?
Есть два совершенно разных уровня:
👉 1. Технические SLA 👈
Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:
- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном
Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.
👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈
Это вообще другой пласт. И тут люди хотят магии:
- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу
Но это не про технику. Это про сервис.
Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.
А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!
А теперь о том, что реально можно померить.
Если хочешь именно технические метрики:
- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет
Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!
Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.
У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.
⚠️ Важная мысль ⚠️
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.
Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:
- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?
Это уже не про Kafka, а про продуктовое управление и лидерство.
Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически.😳
Всё остальное — коммуникация. И договорённости.
Если непонятно, как это построить — велкам на обучение руководству и тимлидству. Потому что никакие красивые метрики тебя от этих разговоров не спасут.
А какие критерии удовлетворенности работы Кафкой вы бы взяли? Уже вторую итерацию сомневаюсь, что хорошие выбрал.
Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?
Есть два совершенно разных уровня:
👉 1. Технические SLA 👈
Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:
- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном
Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.
👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈
Это вообще другой пласт. И тут люди хотят магии:
- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу
Но это не про технику. Это про сервис.
Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.
А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!
А теперь о том, что реально можно померить.
Если хочешь именно технические метрики:
- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет
Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!
Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.
У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.
Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:
- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?
Это уже не про Kafka, а про продуктовое управление и лидерство.
Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически.
Всё остальное — коммуникация. И договорённости.
Если непонятно, как это построить — велкам на обучение руководству и тимлидству. Потому что никакие красивые метрики тебя от этих разговоров не спасут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14 10👍2🤯1
Есть забавная штука, которая раз за разом возвращается к нам под разными соусами — типологии.
Спиральная динамика, Белбин, MBTI, DISC, соционика, ваша внутренняя самодельная табличка в Excel — неважно. Человек ужасно любит находить паттерны и втыкать людей в аккуратные коробочки. Потому что так проще. Так мозг экономит энергию.
Типичный первый вопрос при знакомстве с любой моделью: "А какой я?"
И это окей для саморазвития. Но если ты руководитель, особенно руководитель группы руководителей, то пора перестать крутить фонарик в глаза себе и начать светить вокруг.
Да, это очередной пост инсайтов, пришедших мне в процессе закрепления навыков руководителя отдела в Стратоплане.
Правильные вопросы могут звучать так:
"А какие люди вокруг меня?"
"Какие у меня тимлиды?", "А мой руководитель?", "А коллеги в соседнем отделе?"
Например, в управленческой команде с тобой:
– Оперативный "дожиматель", который доведёт любое дело до конца, но не любит мечтать.
– Вдохновенный "идейщик", который генерит сто концептов до обеда и забывает их к ужину.
– Консервативный скептик, который всех бесит своим "давайте подумаем", но спасает от катастроф.
Проектируя архитектуру — мы же не думаем об каждой детали, мы думаем о верхнеуровневых абстракциях. Так и проектируя систему взаимоотношений, команд, или пересматривая их — мы так же можем думать об абстракциях.
Типологии тут не истина в последней инстанции. Было бы ошибкой считать, что они отражают истину.
Карта — не территория. Но без карты ты и шагу не сделаешь в незнакомом лесу.
Архитектор, проектируя систему, не задумывается о конкретных байтах в памяти — он оперирует абстракциями. Так и ты: если у тебя десяток-другой человек в зоне влияния — придётся мыслить уровнями выше.
И да, выбор типологии — холиварный вопрос. Белбин? DISC? Своя классификация на "стратегов", "копателей" и "разрушителей спокойствия"? Да вообще пофиг. Работает — пользуйся: договорись, внедри, используй. Не работает — выбрось.
Главное — не забывай, что за любой абстракцией стоят люди. С их опытом, страхами, надеждами и тараканами. И твоя задача — не рассортировать их по коробкам, а построить с ними отношения, которые позволят всей системе работать.
Спиральная динамика, Белбин, MBTI, DISC, соционика, ваша внутренняя самодельная табличка в Excel — неважно. Человек ужасно любит находить паттерны и втыкать людей в аккуратные коробочки. Потому что так проще. Так мозг экономит энергию.
Типичный первый вопрос при знакомстве с любой моделью: "А какой я?"
И это окей для саморазвития. Но если ты руководитель, особенно руководитель группы руководителей, то пора перестать крутить фонарик в глаза себе и начать светить вокруг.
Да, это очередной пост инсайтов, пришедших мне в процессе закрепления навыков руководителя отдела в Стратоплане.
Правильные вопросы могут звучать так:
"А какие люди вокруг меня?"
"Какие у меня тимлиды?", "А мой руководитель?", "А коллеги в соседнем отделе?"
Например, в управленческой команде с тобой:
– Оперативный "дожиматель", который доведёт любое дело до конца, но не любит мечтать.
– Вдохновенный "идейщик", который генерит сто концептов до обеда и забывает их к ужину.
– Консервативный скептик, который всех бесит своим "давайте подумаем", но спасает от катастроф.
Проектируя архитектуру — мы же не думаем об каждой детали, мы думаем о верхнеуровневых абстракциях. Так и проектируя систему взаимоотношений, команд, или пересматривая их — мы так же можем думать об абстракциях.
Типологии тут не истина в последней инстанции. Было бы ошибкой считать, что они отражают истину.
Карта — не территория. Но без карты ты и шагу не сделаешь в незнакомом лесу.
Архитектор, проектируя систему, не задумывается о конкретных байтах в памяти — он оперирует абстракциями. Так и ты: если у тебя десяток-другой человек в зоне влияния — придётся мыслить уровнями выше.
И да, выбор типологии — холиварный вопрос. Белбин? DISC? Своя классификация на "стратегов", "копателей" и "разрушителей спокойствия"? Да вообще пофиг. Работает — пользуйся: договорись, внедри, используй. Не работает — выбрось.
Главное — не забывай, что за любой абстракцией стоят люди. С их опытом, страхами, надеждами и тараканами. И твоя задача — не рассортировать их по коробкам, а построить с ними отношения, которые позволят всей системе работать.
👍33🔥8🎉4🤔1 1
Вы никогда не просили, но у меня ещё есть литературный канал @neveraskedforthisstories, куда я публикую короткие фантастические зарисовки. Последняя вот получилась в жанре хоррор - это мне такие сны снятся после рабочего дня в айтишечке.
https://t.iss.one/neveraskedforthisstories/54 - а вот эта например очень зашла немногим читателям, что уже есть.
I've never asked for this, но иногда офигительные истории невозможно держать в себе. Делюсь с вами.
https://t.iss.one/neveraskedforthisstories/54 - а вот эта например очень зашла немногим читателям, что уже есть.
I've never asked for this, но иногда офигительные истории невозможно держать в себе. Делюсь с вами.
Telegram
Never asked for this stories
Бар в порту-19 вонял горелым спиртом и заплесневелыми историями. Арон, техник с Раха, пил в одиночестве, пока к нему не подсели двое пилотов — с виду потрёпанные, с виду свои.
— Ты не знаешь, что творится в Центре, да? — сказал один, приглушённо. — Людей…
— Ты не знаешь, что творится в Центре, да? — сказал один, приглушённо. — Людей…
🔥4
Есть такая фраза: "нельзя делегировать ответственность".
Начинающие тимлиды воспринимают это как "если мой разработчик не справляется — я должен взять клавиатуру и мышку и решить задачу сам"
НЕТ
Фраза некорректно сформулирована. Ответственность - это про "добиться результата", а не про "сделать". Исполнителем остаётся разработчик. Это буквально его работа.
Фраза должна звучать как "нельзя передать целиком ответственность и забыть про задачу".
Забыть — нельзя. Передать — нельзя, ты всё равно рядом стоишь со свечкой. Результат всё равно на тебе, ты смотришь и принимаешь решение норм или переделать.
Делегирование — это не "отдать" — это привлечь человека, чтобы он был обязан сделать свою часть.
Тот, кто считает, что "делегирование" — это "отдать и выкинуть из головы" — тролль, лжец, либо некомпетентен. Гоните его, насмехайтесь над ним!
Начинающие тимлиды воспринимают это как "если мой разработчик не справляется — я должен взять клавиатуру и мышку и решить задачу сам"
НЕТ
Фраза некорректно сформулирована. Ответственность - это про "добиться результата", а не про "сделать". Исполнителем остаётся разработчик. Это буквально его работа.
Фраза должна звучать как "нельзя передать целиком ответственность и забыть про задачу".
Забыть — нельзя. Передать — нельзя, ты всё равно рядом стоишь со свечкой. Результат всё равно на тебе, ты смотришь и принимаешь решение норм или переделать.
Делегирование — это не "отдать" — это привлечь человека, чтобы он был обязан сделать свою часть.
Тот, кто считает, что "делегирование" — это "отдать и выкинуть из головы" — тролль, лжец, либо некомпетентен. Гоните его, насмехайтесь над ним!
👍38
Миты можно было бы заменить письмом!
Да, можно было бы. А потом всё равно пришлось бы встретиться, чтобы узнать, почему письмо не прочитали.
Да, можно было бы. А потом всё равно пришлось бы встретиться, чтобы узнать, почему письмо не прочитали.
Что такое SLA платформенного сервиса? Чем он такой особенный?
https://habr.com/ru/companies/oleg-bunin/articles/913508/ — разбираю этот вопрос в длинной статье. Основные тезисы выделены для удобного чтения.
- Как SLA помогает сократить потери сам по себе? Помогает ли?
- Как использовать SLI для организации работы SRE?
- Чем "технологические платформы" отличаются от конечных продуктов с точки зрения метрик надёжности*
- Без каких вещей в культуре компании все эти приседания с числами яйца выеденного не стоят.
Читаем, лайкаем, комментируем.
https://habr.com/ru/companies/oleg-bunin/articles/913508/ — разбираю этот вопрос в длинной статье. Основные тезисы выделены для удобного чтения.
- Как SLA помогает сократить потери сам по себе? Помогает ли?
- Как использовать SLI для организации работы SRE?
- Чем "технологические платформы" отличаются от конечных продуктов с точки зрения метрик надёжности*
- Без каких вещей в культуре компании все эти приседания с числами яйца выеденного не стоят.
Читаем, лайкаем, комментируем.
Хабр
Как не потерять миллионы на SLA: архитектурный подход к управлению ожиданиями
Нарушение SLA — это условность, которую придумали поверх технических проблем. В IT-инфраструктуре любая техническая проблема быстро превращается в убытки, особенно если не умеешь правильно управлять...
👍4 4🔥1
👍15🔥2🤣1
Компания что-то меняет. Чуть ли не на стенах висят плакаты со словами "трансформация", "новая стратегия", "будущее уже рядом". Все бегают с презентациями, а у вас — ничего. Всё по-прежнему. Почему так?
Потому что вы по уши в операционке. И это нормально.
Стратегические изменения сначала происходят там, где и зародились — на уровне стратегии. В кабинетах, где рисуют стрелочки, KPI и новые оргструктуры.
До операционки они докатываются с задержкой. А иногда — не докатываются вовсе. Потому что пока вы держите на себе работу и процессы, ваша основная задача — не уронить то, что уже работает. И не сойти с ума.
Не обязательно видеть изменения, чтобы они были.
И не обязательно менять то, что работает, только потому что сверху пошли лозунги.
Дайте время.
Занимайтесь своей работой, без которой всё встанет.
У вас всё хорошо.
Потому что вы по уши в операционке. И это нормально.
Стратегические изменения сначала происходят там, где и зародились — на уровне стратегии. В кабинетах, где рисуют стрелочки, KPI и новые оргструктуры.
До операционки они докатываются с задержкой. А иногда — не докатываются вовсе. Потому что пока вы держите на себе работу и процессы, ваша основная задача — не уронить то, что уже работает. И не сойти с ума.
Не обязательно видеть изменения, чтобы они были.
И не обязательно менять то, что работает, только потому что сверху пошли лозунги.
Дайте время.
Занимайтесь своей работой, без которой всё встанет.
У вас всё хорошо.
🔥25👍10🤔2
Помните Прагматичный гайд по управлению знаниями?
https://pragmatic-km.guide/practices/README.html
Он до сих пор живёт, люди им пользуются, а мне даже "Преображение" за него дали.
https://km-alliance.ru/laureate2022
И вот я снова думаю.
А что если сделать нечто подобное, но про глубокую айтишечку?
Что-то про платформенные продукты, про эксплуатацию, про организационные подходы в крупном IT — не теоретическое бла-бла, а прям с кишочками, болью и практикой. Не знаю пока точно про что, но знаю, как сделать полезно.
Формат вижу наподобие платной подписки на бусти, где будет больше инсайдов, возможность влиять на контент и задавать вопросы. Запускать всё это начну не раньше следующего года, но хочу заранее понять — нужно ли это кому-то, кроме меня?
https://pragmatic-km.guide/practices/README.html
Он до сих пор живёт, люди им пользуются, а мне даже "Преображение" за него дали.
https://km-alliance.ru/laureate2022
И вот я снова думаю.
А что если сделать нечто подобное, но про глубокую айтишечку?
Что-то про платформенные продукты, про эксплуатацию, про организационные подходы в крупном IT — не теоретическое бла-бла, а прям с кишочками, болью и практикой. Не знаю пока точно про что, но знаю, как сделать полезно.
Формат вижу наподобие платной подписки на бусти, где будет больше инсайдов, возможность влиять на контент и задавать вопросы. Запускать всё это начну не раньше следующего года, но хочу заранее понять — нужно ли это кому-то, кроме меня?
👍9💩6 3
🗳 Опрос: а вы бы вписались в такой проект?
Anonymous Poll
9%
Shut up and take my money! — ты умеешь в полезное
5%
Да, очень интересно, хочу следить и поддерживать
34%
Посмотрю по содержанию, но идея норм
33%
Не моя тема, но успехов
18%
Зачем ты всё это написал, где мемы?
Про самое дорогое
Самое дорогое, что есть в обеспечении надёжности — это систематические тупые ошибки на банальном.
Переключали трафик — но не проверили, готов ли получатель его принять.
Сделали невинную правочку — забили на тесты, “ну там же одна строчка”.
Лезли в конфиг под нагрузкой — забыли про health checks.
Шли чинить что-то незнакомое — без плана, “по ходу разберёмся”, ага, особенно хорошо это работает в два часа ночи.
Обидно терять деньги. Но ещё обиднее — когда падаешь на грабли, о которые уже ломали ноги до тебя. Много раз. Со всеми постмортемами.
Чек-листы спасают.
Тупые, однообразные, регулярные чек-листы.
— Проверил ли ты, что переключение двустороннее?
— Прогнал ли тест даже на маленькую правку?
— Задокументировал ли порядок действий, если идёшь в неизвестность?
Они не нужны, пока не нужны.
А потом вдруг выясняется, что это единственное, что могло спасти.
Я накидал примеры, где чаще всего стреляет. Смотрите, где проблемы у вас. Где стыдно и команда выглядит недотёпами. Там, где привыкли считать, что "и так сойдёт".
Самое дорогое, что есть в обеспечении надёжности — это систематические тупые ошибки на банальном.
Переключали трафик — но не проверили, готов ли получатель его принять.
Сделали невинную правочку — забили на тесты, “ну там же одна строчка”.
Лезли в конфиг под нагрузкой — забыли про health checks.
Шли чинить что-то незнакомое — без плана, “по ходу разберёмся”, ага, особенно хорошо это работает в два часа ночи.
Обидно терять деньги. Но ещё обиднее — когда падаешь на грабли, о которые уже ломали ноги до тебя. Много раз. Со всеми постмортемами.
Чек-листы спасают.
Тупые, однообразные, регулярные чек-листы.
— Проверил ли ты, что переключение двустороннее?
— Прогнал ли тест даже на маленькую правку?
— Задокументировал ли порядок действий, если идёшь в неизвестность?
Они не нужны, пока не нужны.
А потом вдруг выясняется, что это единственное, что могло спасти.
Я накидал примеры, где чаще всего стреляет. Смотрите, где проблемы у вас. Где стыдно и команда выглядит недотёпами. Там, где привыкли считать, что "и так сойдёт".
👍30 9🔥3
Почти половина курса “Руководитель отдела” от Стратоплана позади. Решил зафиксировать впечатления, пока всё свежо. Объективно: будет и за что пожурить, и что похвалить.
Первое, что понял — многое упирается в преподавателя. Кирилла Линника я просто не смог слушать. Не потому что тема неинтересна, а потому что подача рассыпается на куски: слайдов мало, структура в них не отражена, вместо четкой линии повествования — случайные истории из жизни. Опыт у человека, без сомнений, есть, но я так и не смог связать рассказанное в цельную картину. К счастью, он вел не весь курс.
Второе — любовь к теме чувствуется или не чувствуется. На блоке про финансы в основной программе она, похоже, потерялась по дороге. Материал вроде нужный, но заходит как инструкция по эксплуатации кофемашины — формально верно, но душно. В итоге плотность полезного контента от темы к теме скачет. Может, это из-за того, что в одних областях я уже неплохо ориентируюсь, а в других — полный ноль.
Теперь про хорошее. Общая конструкция курса работает. Сначала я не понимал, зачем нас заставляют работать в группах и “взаимоопыляться”. Но после занятия по культуре, где мы вдруг увидели, что у нас есть командная идентичность, всё поехало. Начались нормальные обсуждения, появилось чувство, что мы учимся вместе, а не просто сидим на одних лекциях.
Материал в целом ставит мозги на место. Мне приходят не просто “знания ради знаний”, а живые инсайты, которые можно утащить в работу уже завтра. Особенно зашла тема с трекингом личных целей на обучение. Нам не дали спрятаться в общих формулировках вроде “хочу развиваться”, а заставили чётко сформулировать, что именно хочешь прокачать, и потом регулярно сверяться — двигаешься ты или топчешься на месте.
Вывод на данный момент: курс живой и полезный, но качество отдельных модулей неравномерное. И тут уж как повезёт — попадёшь на “своего” преподавателя или нет.
Первое, что понял — многое упирается в преподавателя. Кирилла Линника я просто не смог слушать. Не потому что тема неинтересна, а потому что подача рассыпается на куски: слайдов мало, структура в них не отражена, вместо четкой линии повествования — случайные истории из жизни. Опыт у человека, без сомнений, есть, но я так и не смог связать рассказанное в цельную картину. К счастью, он вел не весь курс.
Второе — любовь к теме чувствуется или не чувствуется. На блоке про финансы в основной программе она, похоже, потерялась по дороге. Материал вроде нужный, но заходит как инструкция по эксплуатации кофемашины — формально верно, но душно. В итоге плотность полезного контента от темы к теме скачет. Может, это из-за того, что в одних областях я уже неплохо ориентируюсь, а в других — полный ноль.
Теперь про хорошее. Общая конструкция курса работает. Сначала я не понимал, зачем нас заставляют работать в группах и “взаимоопыляться”. Но после занятия по культуре, где мы вдруг увидели, что у нас есть командная идентичность, всё поехало. Начались нормальные обсуждения, появилось чувство, что мы учимся вместе, а не просто сидим на одних лекциях.
Материал в целом ставит мозги на место. Мне приходят не просто “знания ради знаний”, а живые инсайты, которые можно утащить в работу уже завтра. Особенно зашла тема с трекингом личных целей на обучение. Нам не дали спрятаться в общих формулировках вроде “хочу развиваться”, а заставили чётко сформулировать, что именно хочешь прокачать, и потом регулярно сверяться — двигаешься ты или топчешься на месте.
Вывод на данный момент: курс живой и полезный, но качество отдельных модулей неравномерное. И тут уж как повезёт — попадёшь на “своего” преподавателя или нет.
🔥22👍15 8🤔1
Media is too big
VIEW IN TELEGRAM
На днях опубликуем интервью о создании стартапа в Сингапуре, замене людей роботами, как быстро прототипировать свои задумки и как с этим жить дальше
🔥11🤔1
Где лучше выкладывать видосы?
Final Results
32%
telegram — норм
12%
vk video
41%
youtube
3%
rutube
12%
MAX
Про перформанс-ревью и зарплатные сказки
Однажды я обнаружил, что некие талантливые люди превратили систему перфоманс ревью в инструмент отмазок. HR-служба сфокусировалась не на развитии людей, а на том, чтобы обосновать, почему денег не будет. Формально они дали два повода поднять зарплату: навыки и достижения.
- Навыки – это про прокачку по матрице компетенций. Которой, естественно, не было. Но даже если была бы – “ты же пришёл уже с этим стеком, так что какой рост?” Хочешь денег? Набирай себе чужой работы, может быть, когда-нибудь дадут подачку в 5%. Рост внутри грейда? Сомнительно, сначала добейся перехода на новый грейд.
- Результативность – это вообще песня. В начале года сотрудник сам должен сформулировать себе задачи на год. Конкретные, измеримые. И потом не просто выполнить, а перевыполнить. А если не получилось? Ну, значит, ты просто не старался.
А что, если за год всё изменилось, стратегию крутило три раза, ты не управляешь скоупом своих задач или сформулировал слишком амбициозную, невыполнимую цель? Твои проблемы. Не справился – твоя вина. Нет опции “сделал много”, “старался” — смотрим только на “выполнено — не выполнено”.
При этом несоответствие зарплаты рынку – не повод поднять зарплату. Риск ухода ключевого сотрудника, без которого всё развалится? Не повод поднять зарплату.
И вот тут вопрос: а что дальше? Компании, конечно, виднее. Иногда бизнесу реально важнее сэкономить, чем вкладываться в людей – потому что иначе не сойдётся экономика, деньги не берутся из воздуха. Но если планка удержания ставится ниже планки развития, то в какой-то момент останутся только те, кого и удерживать не надо. Слабые, которым норм, будут сидеть на попе ровно. А сильные – будут уходить.
Может, я просто всё слишком драматизирую? Или у вас были кейсы, где такая система реально работала?
Однажды я обнаружил, что некие талантливые люди превратили систему перфоманс ревью в инструмент отмазок. HR-служба сфокусировалась не на развитии людей, а на том, чтобы обосновать, почему денег не будет. Формально они дали два повода поднять зарплату: навыки и достижения.
- Навыки – это про прокачку по матрице компетенций. Которой, естественно, не было. Но даже если была бы – “ты же пришёл уже с этим стеком, так что какой рост?” Хочешь денег? Набирай себе чужой работы, может быть, когда-нибудь дадут подачку в 5%. Рост внутри грейда? Сомнительно, сначала добейся перехода на новый грейд.
- Результативность – это вообще песня. В начале года сотрудник сам должен сформулировать себе задачи на год. Конкретные, измеримые. И потом не просто выполнить, а перевыполнить. А если не получилось? Ну, значит, ты просто не старался.
А что, если за год всё изменилось, стратегию крутило три раза, ты не управляешь скоупом своих задач или сформулировал слишком амбициозную, невыполнимую цель? Твои проблемы. Не справился – твоя вина. Нет опции “сделал много”, “старался” — смотрим только на “выполнено — не выполнено”.
При этом несоответствие зарплаты рынку – не повод поднять зарплату. Риск ухода ключевого сотрудника, без которого всё развалится? Не повод поднять зарплату.
И вот тут вопрос: а что дальше? Компании, конечно, виднее. Иногда бизнесу реально важнее сэкономить, чем вкладываться в людей – потому что иначе не сойдётся экономика, деньги не берутся из воздуха. Но если планка удержания ставится ниже планки развития, то в какой-то момент останутся только те, кого и удерживать не надо. Слабые, которым норм, будут сидеть на попе ровно. А сильные – будут уходить.
Может, я просто всё слишком драматизирую? Или у вас были кейсы, где такая система реально работала?
👍36🔥9🤔5
На подкасте я сделал канальчик, где каждый день постят ободряющие фразы для истерзанных айтишных душ:
@gentle_architect
Подпишитесь, что ли, может и ваша жизнь станет чуточку светлее, и свершится добро❤️
@gentle_architect
Подпишитесь, что ли, может и ваша жизнь станет чуточку светлее, и свершится добро
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Конфликты
Слово, от которого у некоторых топов поджимается всё, что может поджиматься. А уж у линейных менеджеров и исполнителей — тем более. Кажется, что конфликт — это обязательно крики, токсичность, кто-то хлопает дверью, кто-то рыдает в туалете.
Но спор о том, какую либу выбрать — это конфликт.
Выбор, какую фичу делать в этом спринте, а какую — отправить в бэклог на кладбище идей — это тоже конфликт.
Просто не всегда личный. Иногда — просто профессиональный.
И тут вся магия в умении отделять одно от другого.
Если каждый раз воспринимать разногласия как личное оскорбление — недолго и выгореть. Или начать мстить. Или срываться на коллег.
(Если уже начали — добро пожаловать к психотерапевту. Это не стыдно, а очень полезно и развивающе)
Важно вот что:
- Нормальная, живая работа невозможна без конфликтов.
- Если конфликтов нет — либо у вас авторитаризм, либо сказочное изобилие ресурсов и времени, либо апатия и всем пофиг. Ни один из вариантов — это не про здоровое состояние дел в команде.
Не бойтесь, когда мнения сталкиваются.
Бойтесь, когда всем всё всегда и так ок.
Слово, от которого у некоторых топов поджимается всё, что может поджиматься. А уж у линейных менеджеров и исполнителей — тем более. Кажется, что конфликт — это обязательно крики, токсичность, кто-то хлопает дверью, кто-то рыдает в туалете.
Но спор о том, какую либу выбрать — это конфликт.
Выбор, какую фичу делать в этом спринте, а какую — отправить в бэклог на кладбище идей — это тоже конфликт.
Просто не всегда личный. Иногда — просто профессиональный.
И тут вся магия в умении отделять одно от другого.
Если каждый раз воспринимать разногласия как личное оскорбление — недолго и выгореть. Или начать мстить. Или срываться на коллег.
(Если уже начали — добро пожаловать к психотерапевту. Это не стыдно, а очень полезно и развивающе)
Важно вот что:
- Нормальная, живая работа невозможна без конфликтов.
- Если конфликтов нет — либо у вас авторитаризм, либо сказочное изобилие ресурсов и времени, либо апатия и всем пофиг. Ни один из вариантов — это не про здоровое состояние дел в команде.
Не бойтесь, когда мнения сталкиваются.
Бойтесь, когда всем всё всегда и так ок.
👍25🔥4
Мне тут на курсе руководитель отдела у стратоплана открыли глаза на тупые опросы от HR-ов про "как вы относитесь к нашей компании". Оказывается, тупил я :)
Попробую вам объяснить.
Смотрите, не секрет, что когда люди работают из-под палки, в курилке только и разговоров, о том как всё задолбало (и это не энергичные разговоры "щас всё порешаю", а выжженные, в край демотивированные разговоры вида "убейте меня пожалуйста, я не хочу идти обратно") — это отразится на результатах. Если настроение никакое — у этого, конечно, есть не-HR-ные причины. Кто-то — дятел, где-то — хрень в процессах, что-то пошло не так, как ожидали. Но красота в глазах смотрящего, трудности можно воспринимать и как вызов, если на это есть силы, как повод что-то изменить к лучшему.
Но это невозможно, когда все выгорели и ищут на кого спихнуть ответственность.
И все эти проблемы видно, когда ты в операционке, общаешься с людьми. Но всё искусство заключается в том, чтобы построить систему с индикаторами, которые будут загораться даже если ты занят другими проблемами. Потому что оперативки начинает не хватать, начиная с определённой стадии роста команды, и подходы перестраиваются. Да, становятся менее персональными и более обезличенными.
Чтобы управлять машиной не нужно мониторить каждую деталь, достаточно приборной панели. Чтобы мониторить вовлечённость команды (и узнать о том, что загорелся check engine и пора лезть под капот) — можно использовать опросник gallup q12.
На больших числах и в динамике — он достаточно неплох, чтобы им можно было пользоваться как лампочкой.
Простите, HR-ы, я был не прав, вы не все бесполезны,только те, кто врёт и крутится ужом . Спасибо адекватным людям за работу!
Попробую вам объяснить.
Смотрите, не секрет, что когда люди работают из-под палки, в курилке только и разговоров, о том как всё задолбало (и это не энергичные разговоры "щас всё порешаю", а выжженные, в край демотивированные разговоры вида "убейте меня пожалуйста, я не хочу идти обратно") — это отразится на результатах. Если настроение никакое — у этого, конечно, есть не-HR-ные причины. Кто-то — дятел, где-то — хрень в процессах, что-то пошло не так, как ожидали. Но красота в глазах смотрящего, трудности можно воспринимать и как вызов, если на это есть силы, как повод что-то изменить к лучшему.
Но это невозможно, когда все выгорели и ищут на кого спихнуть ответственность.
И все эти проблемы видно, когда ты в операционке, общаешься с людьми. Но всё искусство заключается в том, чтобы построить систему с индикаторами, которые будут загораться даже если ты занят другими проблемами. Потому что оперативки начинает не хватать, начиная с определённой стадии роста команды, и подходы перестраиваются. Да, становятся менее персональными и более обезличенными.
Чтобы управлять машиной не нужно мониторить каждую деталь, достаточно приборной панели. Чтобы мониторить вовлечённость команды (и узнать о том, что загорелся check engine и пора лезть под капот) — можно использовать опросник gallup q12.
На больших числах и в динамике — он достаточно неплох, чтобы им можно было пользоваться как лампочкой.
Простите, HR-ы, я был не прав, вы не все бесполезны,
👍32🔥14💩5