Forwarded from Средненький продакт | Антон Тарасов
Давно не было про ощущения вне моно-найма, а опросы говорят, что вам это интересно!
Победа конца прошлого года — перестал оценивать свое решение о выходе из моно-найма только деньгами. Почти год я старался зарабатывать сильно больше, чем в корпорации, вот прямо почти любой ценой, и это было единственной метрикой успеха. Сейчас же покататься на лыжах в понедельник — не менее важная штука, чем объём выручки. Сегодня, например, мы начали утро на катке всей семьёй. Короче, я заадоптил окончательно, что дело не только в деньгах. И не столько.
Отсутствие избытка больше не повод для тревоги:
• На ипотеку, аренду квартиры и базовые потребности семьи заработал — класс.
• Долгосрочные проекты двигаются — вообще отлично, значит не стою на месте.
• Есть время жить — супер, я за этим и шёл.
• Кратно меньше стресса — это офигеть какое достижение, дороже денег, потому что в гробу нет карманов.
Это не означает, что пропали амбиции и живу по течению. Как будто даже наоборот! Перестал истерить и начал смотреть дальше вперёд. Если первый год я воспринимал как майлстоун и задачей было продержаться и быть в своих глазах красавчиком, то теперь пришло осознание, что впереди охренеть какой марафон, и я в самом начале пути. У подножия холма своей истории. А если повезёт — у подножия горы.
И вот тут появилась внутренняя целостность и радость от жизни. Почувствовал счастье от достаточности и устойчивости. Прошлый год был истеричной погоней за финансовыми результатами. Этот год будет про выстраивание длительных историй. Может даже планировать научусь, кто знает.
Жить в состоянии "продержаться" очень ресурсоёмкая история. Раньше думал, что иначе и не бывает, а сейчас как понял. И вам желаю это на своём опыте прожить и понять. А если уже — вы красачик или может быть красавица!
Победа конца прошлого года — перестал оценивать свое решение о выходе из моно-найма только деньгами. Почти год я старался зарабатывать сильно больше, чем в корпорации, вот прямо почти любой ценой, и это было единственной метрикой успеха. Сейчас же покататься на лыжах в понедельник — не менее важная штука, чем объём выручки. Сегодня, например, мы начали утро на катке всей семьёй. Короче, я заадоптил окончательно, что дело не только в деньгах. И не столько.
Отсутствие избытка больше не повод для тревоги:
• На ипотеку, аренду квартиры и базовые потребности семьи заработал — класс.
• Долгосрочные проекты двигаются — вообще отлично, значит не стою на месте.
• Есть время жить — супер, я за этим и шёл.
• Кратно меньше стресса — это офигеть какое достижение, дороже денег, потому что в гробу нет карманов.
Это не означает, что пропали амбиции и живу по течению. Как будто даже наоборот! Перестал истерить и начал смотреть дальше вперёд. Если первый год я воспринимал как майлстоун и задачей было продержаться и быть в своих глазах красавчиком, то теперь пришло осознание, что впереди охренеть какой марафон, и я в самом начале пути. У подножия холма своей истории. А если повезёт — у подножия горы.
И вот тут появилась внутренняя целостность и радость от жизни. Почувствовал счастье от достаточности и устойчивости. Прошлый год был истеричной погоней за финансовыми результатами. Этот год будет про выстраивание длительных историй. Может даже планировать научусь, кто знает.
Жить в состоянии "продержаться" очень ресурсоёмкая история. Раньше думал, что иначе и не бывает, а сейчас как понял. И вам желаю это на своём опыте прожить и понять. А если уже — вы красачик или может быть красавица!
🔥36❤18❤🔥4👍3
Ваша разработка замедляется и это…
Нормально!
С каждым годом оценка задач/трудоемкость должны расти, селя-ви.
Почему так?
1.
закон Лемана, о котором я уже писал: энтропия всегда растет!
2.
Товарищ Кент Бек (чел, который придумал экстремальное программирование и в свое время участвовал в формулировке Agile Manifesto) расписал эту же теорию, но на современный лад.
Опциональность (это из экономической теории) - количество вариантов действий/шагов, которые у вас есть для следующего шага. Как пример, шахматы. У вас на старте 20 возможных ходов. После первого хода соперника, количество ваших опций может уменьшиться (если вы ходите вторым).
Фичи - количество фичей постоянно растет (ну это нормально, если ваш бизнес развивается). И вот получается, что каждая следующая фича делает ваш продукт лучше, но замедляет с каждым новым релизом. То есть уменьшает вашу опциональность (для простоты, условно, вы выбираете некий стек и теперь завязаны на него и каждая следующая фича только усиливает эту зависимость. ORACLE в свое время подсадил на себя 80% корпораций).
Возможно вы не чувствуете это сегодня, но точно ощутите на себе завтра
Что делать?
Кент предлагает использовать Tidy First- подход.
1.
Tidying first - означает, привести код в более чистое, структурированное состояние перед новой функциональностью,
2.
Ответить на вопросы:
Что мешает следующей фиче сейчас?
Что можно упорядочить, чтобы её сделать легче?
3.
Такая работа может временно снизить скорость видимого прогресса, но в долгой перспективе убыстряет весь процесс, потому что увеличивает опциональность.
То есть, отщипнуть немного сегодня, чтобы сохранить темп. Звучит как хорошая инвестиция!
Ну если короче, надо перед каждой фичей делать небольшой рефакторинг. Картиночку я вам тоже приложил.
А как у вас дела с управлением техдолгом?
🦄 - четко выстроенный процесс, каждый спринт инвестируем ресурсы
🔥 - нууу скорее вот прямо по жесткой необходимости раз в 3-12 месяцев
💊 - памагитеее! Живем с долгом еще от 2018 года, чисто как не тех долг, а ипотека
Нормально!
С каждым годом оценка задач/трудоемкость должны расти, селя-ви.
Почему так?
1.
закон Лемана, о котором я уже писал: энтропия всегда растет!
2.
Товарищ Кент Бек (чел, который придумал экстремальное программирование и в свое время участвовал в формулировке Agile Manifesto) расписал эту же теорию, но на современный лад.
Опциональность (это из экономической теории) - количество вариантов действий/шагов, которые у вас есть для следующего шага. Как пример, шахматы. У вас на старте 20 возможных ходов. После первого хода соперника, количество ваших опций может уменьшиться (если вы ходите вторым).
Фичи - количество фичей постоянно растет (ну это нормально, если ваш бизнес развивается). И вот получается, что каждая следующая фича делает ваш продукт лучше, но замедляет с каждым новым релизом. То есть уменьшает вашу опциональность (для простоты, условно, вы выбираете некий стек и теперь завязаны на него и каждая следующая фича только усиливает эту зависимость. ORACLE в свое время подсадил на себя 80% корпораций).
Возможно вы не чувствуете это сегодня, но точно ощутите на себе завтра
Что делать?
Кент предлагает использовать Tidy First- подход.
1.
Tidying first - означает, привести код в более чистое, структурированное состояние перед новой функциональностью,
2.
Ответить на вопросы:
Что мешает следующей фиче сейчас?
Что можно упорядочить, чтобы её сделать легче?
3.
Такая работа может временно снизить скорость видимого прогресса, но в долгой перспективе убыстряет весь процесс, потому что увеличивает опциональность.
То есть, отщипнуть немного сегодня, чтобы сохранить темп. Звучит как хорошая инвестиция!
Ну если короче, надо перед каждой фичей делать небольшой рефакторинг. Картиночку я вам тоже приложил.
А как у вас дела с управлением техдолгом?
🦄 - четко выстроенный процесс, каждый спринт инвестируем ресурсы
🔥 - нууу скорее вот прямо по жесткой необходимости раз в 3-12 месяцев
💊 - памагитеее! Живем с долгом еще от 2018 года, чисто как не тех долг, а ипотека
1💊44🔥25❤8🦄6👍1👎1🤡1
Леша Суринов (мой хороший знакомы и СТО SberID) выдал базу про то, какие виды СТО бывают.
И вот лучше не скажешь и я согласен на все 100%
И вот лучше не скажешь и я согласен на все 100%
❤6🔥4🤡1
Forwarded from Мысли вне кода | Суринов
За свою карьеру я видел принципиально два подхода к подбору человека на роль CTO.
🔧 CTO – самый сильный эксперт, он должен знать до мельчайших подробностей как работает его продукт, участвовать во всех встречах и согласовывать все решения.
Я сам вырос из такого CTO, столкнувшись со временем с целым рядом проблем:
⚠️ Сложные решения замыкаются на одном человеке, который с ростом компании становится бутылочным горлышком, а эффективное масштабирование становится невозможным
⚠️ Быть везде и всегда – верный путь к выгоранию и вероятному уходу, а болезнь или увольнение такого человека – сродни катастрофе (bus-фактор)
⚠️ Люди в такой команде растут в основном только технически – CTO принимает основные управленческие решения и единолично несет за них ответственность
⚠️ CTO зачастую не видит критичной необходимости нанимать людей сильнее себя и средний уровень экспертизы команды не растет
✅ У этого подхода, на мой взгляд, лишь одно преимущество – имея в одной голове все детали и нюансы небольшого продукта можно принимать отдельные технические решения заметно быстрее и точнее. Поэтому при всех описанных недостатках он вполне работает до определенного размера компании, и особенно – если CTO вырос вместе с ней.
🧩 CTO – архитектор окружения, инженер человеческих систем из сильных экспертов и процессов. Такой человек следует принципу: "Don't aim to be the smartest person in the room. Aim to be the one who builds the best room".
При грамотном выстраивании:
✅ Решения принимаются распределенно – людьми, которые фокусно и экспертно ищут наилучшие варианты, а вся система может масштабироваться
✅ Люди в такой среде активно растут, получая личный управленческий опыт и обмениваясь им
✅ При найме в команду экспертов сильнее CTO растет общая сила симбиоза знаний и опыта отдельных участников
✅ Команда автономна и может достаточное время успешно функционировать в его отсутствие
⚠️ Недостаток у этого подхода, на мой взгляд, лишь один – при распределенном принятии решений нелинейно растут издержки на коммуникации, что, впрочем, будто бы неизбежно происходит при значительном росте любой компании
🔧 CTO – самый сильный эксперт, он должен знать до мельчайших подробностей как работает его продукт, участвовать во всех встречах и согласовывать все решения.
Я сам вырос из такого CTO, столкнувшись со временем с целым рядом проблем:
⚠️ Сложные решения замыкаются на одном человеке, который с ростом компании становится бутылочным горлышком, а эффективное масштабирование становится невозможным
⚠️ Быть везде и всегда – верный путь к выгоранию и вероятному уходу, а болезнь или увольнение такого человека – сродни катастрофе (bus-фактор)
⚠️ Люди в такой команде растут в основном только технически – CTO принимает основные управленческие решения и единолично несет за них ответственность
⚠️ CTO зачастую не видит критичной необходимости нанимать людей сильнее себя и средний уровень экспертизы команды не растет
✅ У этого подхода, на мой взгляд, лишь одно преимущество – имея в одной голове все детали и нюансы небольшого продукта можно принимать отдельные технические решения заметно быстрее и точнее. Поэтому при всех описанных недостатках он вполне работает до определенного размера компании, и особенно – если CTO вырос вместе с ней.
🧩 CTO – архитектор окружения, инженер человеческих систем из сильных экспертов и процессов. Такой человек следует принципу: "Don't aim to be the smartest person in the room. Aim to be the one who builds the best room".
При грамотном выстраивании:
✅ Решения принимаются распределенно – людьми, которые фокусно и экспертно ищут наилучшие варианты, а вся система может масштабироваться
✅ Люди в такой среде активно растут, получая личный управленческий опыт и обмениваясь им
✅ При найме в команду экспертов сильнее CTO растет общая сила симбиоза знаний и опыта отдельных участников
✅ Команда автономна и может достаточное время успешно функционировать в его отсутствие
⚠️ Недостаток у этого подхода, на мой взгляд, лишь один – при распределенном принятии решений нелинейно растут издержки на коммуникации, что, впрочем, будто бы неизбежно происходит при значительном росте любой компании
🔥30👍9❤7🤡1💯1🤗1
This media is not supported in your browser
VIEW IN TELEGRAM
💯68❤19🤣18🦄6🤔1🤡1
Оооо
Тут вирусится история с «мой 2016», ловите!
Мне 24, я еще не седой, выгляжу как тощая шпала и огромный прыщ на лбу - вишенка на торте!
Это, кстати, меня сделали Тимлидом и начальник в своем кабинете фоткает для корпоративного портала!
А ты в 2016?
😎 - еще сдавал или готовился к ЕГЭ
🧑💻 - уже синьор помидор с 10+ лет опыта
❤️ - ток работать как раз начинаю, джун-мидл
Тут вирусится история с «мой 2016», ловите!
Мне 24, я еще не седой, выгляжу как тощая шпала и огромный прыщ на лбу - вишенка на торте!
Это, кстати, меня сделали Тимлидом и начальник в своем кабинете фоткает для корпоративного портала!
А ты в 2016?
😎 - еще сдавал или готовился к ЕГЭ
🧑💻 - уже синьор помидор с 10+ лет опыта
❤️ - ток работать как раз начинаю, джун-мидл
❤144👨💻82😎80😍4🌚4🤔2😁1
Илон Маск репостнул его исследование, а я позвал его на подкаст
Будущее и настоящее с исследователем из Стенфорда.
Ну что, я вам тут не просто так все писал и писал про:
1.
Как ребята из стенфорда оценили с помощью ML продуктивность разработки.
2.
А потом с помощью этой же модели выяснили, что 10% инженеров или 1.8 млн. в мире не работают (100 тыс.инеженеров в 600 компаниях были изучены).
3.
А потом про то, как и где лучше всего применить AI.
А писал и изучал я все это, потому что в воскресенье, то есть вчера - мы писали в офисе подкаст с тем самым Егором Денисовым-Бланшем.
Егор стал супер знаменит после того, как Илон Маск репостнул его твит и, в общем, дальше понеслась.
Что говорит Егор:
1.
Если вы еще не используете AI - бегите! Егор говорит, что если 6 месяцев назад он был не то, чтобы скептичен, а предлагал искать правильные места для использования, то теперь вам пора бежать.
2.
Все, кто считает, что продуктивность разработчика нельзя померить чаще всего оказываются самыми слабыми компаниями в части реальных результатов. При этом, и те, кто обвешали каждый чих метриками- не топ перформеры. Ключевая задача менеджмента найти правильный баланс.
3.
Каждые 6 месяцев AI будет забирать некий кусок вашей работы. И всем нам придется научиться с этим жить.
В целом, получилось очень круто! Прямо 2 часа невероятно плотного разговора.
Ребята забрали все это на монтаж! Так что ждем!
Stay tuned, как говорится!
Будущее и настоящее с исследователем из Стенфорда.
Ну что, я вам тут не просто так все писал и писал про:
1.
Как ребята из стенфорда оценили с помощью ML продуктивность разработки.
2.
А потом с помощью этой же модели выяснили, что 10% инженеров или 1.8 млн. в мире не работают (100 тыс.инеженеров в 600 компаниях были изучены).
3.
А потом про то, как и где лучше всего применить AI.
А писал и изучал я все это, потому что в воскресенье, то есть вчера - мы писали в офисе подкаст с тем самым Егором Денисовым-Бланшем.
Егор стал супер знаменит после того, как Илон Маск репостнул его твит и, в общем, дальше понеслась.
Что говорит Егор:
1.
Если вы еще не используете AI - бегите! Егор говорит, что если 6 месяцев назад он был не то, чтобы скептичен, а предлагал искать правильные места для использования, то теперь вам пора бежать.
2.
Все, кто считает, что продуктивность разработчика нельзя померить чаще всего оказываются самыми слабыми компаниями в части реальных результатов. При этом, и те, кто обвешали каждый чих метриками- не топ перформеры. Ключевая задача менеджмента найти правильный баланс.
3.
Каждые 6 месяцев AI будет забирать некий кусок вашей работы. И всем нам придется научиться с этим жить.
В целом, получилось очень круто! Прямо 2 часа невероятно плотного разговора.
Ребята забрали все это на монтаж! Так что ждем!
Stay tuned, как говорится!
1🔥44⚡17❤17👍2👎1🥱1
Спираль социализации решения
Не уверен, что это официальный термин.
Но явление максимально реальное.
Социализация решения - это когда ты публично «проносишь» идею через организацию: объясняешь, собираешь вопросы, закрываешь риски, добираешь поддержку.
И вот что я постоянно вижу: менеджеры проваливают социализацию не потому что идея слабая, а потому что они выбирают неправильный порядок.
Как обычно происходит:
1. придумал идею
2. сделал презентацию
3. вышел сразу на широкий круг
4. получил шквал вопросов / возражений / «а почему не так?»
сдулся, демотивировался, пошел «допиливать» в одиночку
Проблема тут простая:
ты приходишь “на всех” без прогрева и без опоры.
И аудитория делает свою работу, то есть начинает проверять решение на прочность.
Только проверка происходит публично, шумно и не в твою пользу.
Как надо:
Социализация - это спираль. Начинай с ближнего круга: тех, кто лоялен к тебе,
реально шарит в контексте,
сможет добить решение вопросами «по делу», а не политикой.
Прошел первый виток → поправил → получил поддержку.
Дальше расширяй круг: следующий виток стейкхолдеров, потом следующий.
И важный эффект: на каждом витке у тебя появляется “опора”. Ты уже не «один с презентацией», а «мы обсудили с X и Y, договорились вот так, спорные моменты закрыли».
Это резко меняет позицию в обсуждении и снижает уровень хаоса.
Вывод простой: не спешите “показать всем”. Выделите эти лишние 4–8 часов на прогрев и прогоны. Это выглядит профессионально, экономит нервы и, как правило, ускоряет согласование в итоге.
Че скажите, есть ли термин «спираль социализации»:
💯 - еще мой дед так говорил и термин точно есть
❤️ - поддержать бедолагу: сам придумал проблему, сам ее решил
🔥 - проблема есть, решение верное, термин не тот
Не уверен, что это официальный термин.
Но явление максимально реальное.
Социализация решения - это когда ты публично «проносишь» идею через организацию: объясняешь, собираешь вопросы, закрываешь риски, добираешь поддержку.
И вот что я постоянно вижу: менеджеры проваливают социализацию не потому что идея слабая, а потому что они выбирают неправильный порядок.
Как обычно происходит:
1. придумал идею
2. сделал презентацию
3. вышел сразу на широкий круг
4. получил шквал вопросов / возражений / «а почему не так?»
сдулся, демотивировался, пошел «допиливать» в одиночку
Проблема тут простая:
ты приходишь “на всех” без прогрева и без опоры.
И аудитория делает свою работу, то есть начинает проверять решение на прочность.
Только проверка происходит публично, шумно и не в твою пользу.
Как надо:
Социализация - это спираль. Начинай с ближнего круга: тех, кто лоялен к тебе,
реально шарит в контексте,
сможет добить решение вопросами «по делу», а не политикой.
Прошел первый виток → поправил → получил поддержку.
Дальше расширяй круг: следующий виток стейкхолдеров, потом следующий.
И важный эффект: на каждом витке у тебя появляется “опора”. Ты уже не «один с презентацией», а «мы обсудили с X и Y, договорились вот так, спорные моменты закрыли».
Это резко меняет позицию в обсуждении и снижает уровень хаоса.
Вывод простой: не спешите “показать всем”. Выделите эти лишние 4–8 часов на прогрев и прогоны. Это выглядит профессионально, экономит нервы и, как правило, ускоряет согласование в итоге.
Че скажите, есть ли термин «спираль социализации»:
💯 - еще мой дед так говорил и термин точно есть
❤️ - поддержать бедолагу: сам придумал проблему, сам ее решил
🔥 - проблема есть, решение верное, термин не тот
🔥83💯48❤30👍13🤝6
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Scrum кажется простым на схемах, но в реальной жизни всё сложнее: роли путаются, ответственность размывается, команда перестаёт быть самоуправляемой. Как избежать этого?
Приглашаем на открытый вебинар, где разберём, как устроена ролевая модель Scrum на практике. Узнаете:
✔️ Отличия проектного и продуктового подходов
✔️ Что действительно меняется при переходе на Scrum
✔️ Почему классические управленческие привычки здесь не работают
Вы чётко поймёте:
🔹 За что отвечает Scrum-мастер
🔹 Роль владельца продукта
🔹 Как формируется ответственность команды
🔹 Что объединяет все роли в единую систему
Эти знания помогут выстроить рабочие процессы без микроменеджмента и конфликтов..
📅 Открытый урок пройдёт 3 февраля в 20:00 МСК в преддверие старта курса «Agile Project Manager».
Зарегистрируйтесь, чтобы не пропустить: 👉https://otus.pw/qKOL/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Приглашаем на открытый вебинар, где разберём, как устроена ролевая модель Scrum на практике. Узнаете:
✔️ Отличия проектного и продуктового подходов
✔️ Что действительно меняется при переходе на Scrum
✔️ Почему классические управленческие привычки здесь не работают
Вы чётко поймёте:
🔹 За что отвечает Scrum-мастер
🔹 Роль владельца продукта
🔹 Как формируется ответственность команды
🔹 Что объединяет все роли в единую систему
Эти знания помогут выстроить рабочие процессы без микроменеджмента и конфликтов..
📅 Открытый урок пройдёт 3 февраля в 20:00 МСК в преддверие старта курса «Agile Project Manager».
Зарегистрируйтесь, чтобы не пропустить: 👉https://otus.pw/qKOL/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
🔥7❤6👍2
Сегодня необычный эксперимент.
Я хочу дать написать пост в мой канал - Володе Невзорову, который супер эксперт в System Design и даже ведет отдельный канал об этом.
Если вы помните, то я топлю за то, что менеджер должен шарить в технике. И вот Володя написал для вас пост о том, как решить одну из задач проектирования.
Я хочу дать написать пост в мой канал - Володе Невзорову, который супер эксперт в System Design и даже ведет отдельный канал об этом.
Если вы помните, то я топлю за то, что менеджер должен шарить в технике. И вот Володя написал для вас пост о том, как решить одну из задач проектирования.
🔥6❤4👍2
"Спроектируйте сервис заказа еды. Масштабируемый на весь мир, естественно."
Задачу из System Design
Но всё это будет потом. А сначала на сцену должен выйти он - Монолит. Почему?
1) спроектировать минимально работающую систему.
2) описать все нужные флоу - поиск ресторанов, показ меню, выбор блюд, заказ, ...
3) зафиксироваться с интервьюером об очередном пройденном этапе
В моей практике я видел сениорного кандидата, который сразу пошёл в сложную систему. И поплыл...
Нарисовал много сервисов. Но где-то стрелочки не доведены до конца. Не все флоу описаны...
В случае сервиса заказа такая архитектура сводится к микросервисной. Где каждый сервис воплощает какой-то из доменов:
• обслуживание заказа
• проведение оплаты
• доставка
• ...
• Мы хотим масштабировать наши сервисы независимо. По максимуму их развязать.
Поэтому давайте придумаем такую сущность как событие.
order_created, к примеру.• Пускай наш order service при создании пользователем заказа отправляет такое событие.
Куда? Не в какой-то определенный сервис. А в какое-то временное хранилище.
Вот бы выбрать такое, чтобы можно было с одной стороны легко класть. С другой читать. Настраивать время хранения.
• Kafka, твой выход! У нас появляется некое развязывающее ПО. Так называемое middleware.
Всё взаимодействие проходит через него.
• Поздравляю!
• Логика её использования проста - есть писатели, внутренние топики, потребители
• Активно используется в BigTech
• Отлично выполняет функцию перекладчика событий.
Наш
order_created попадает в целевой топик. Откуда эти события вычитывают потребители. В первую очередь payment service. Ещё, возможно, аналитический.Благо функционал consumer groups нам в этом помогает.
1) Мы не пошли в частую ошибку новичка -
сразу масштабироваться закидывая интервьюера всеми мыслимыми и немыслимыми терминами2) Последовали принципу Monolith first
3) Расшили его по сервисам
4) Ввели EDA, события, развязывающий компонент - Kafka
5) Всё это привело нас к более легкому масштабированию
"А что с кубернетиз, деплоями, шардированием?", - оказывается до этого может даже не дойти
Автор - Невзоров Владимир. Телеграмм канал - @system_design_world
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥38👍12❤9👌4🤯1💯1
This media is not supported in your browser
VIEW IN TELEGRAM
#пятничное
Ну че, было такое?
🔥 - обожаю наблюдать за такими разборками. У меня глаза даже еще больше навыкате бывают
😎 - сам пару раз участвовал
❤️ - хм…никогда не встречал
Ну че, было такое?
🔥 - обожаю наблюдать за такими разборками. У меня глаза даже еще больше навыкате бывают
😎 - сам пару раз участвовал
❤️ - хм…никогда не встречал
🔥53😎25😁13❤10🤣2👍1🤔1
От хаоса к офферу
В поиске оффера чаще всего не хватает не мотивации, а понятных ориентиров: как понять, готов ли я к работе, чего от меня ждут на собеседовании и в каком направлении развиваться дальше.
karpovꓸcourses подготовили бесплатный гайд по собеседованиям, где шаг за шагом разобрали весь процесс найма аналитика: этапы собеседований, как выглядит хороший отклик, что проверяют на HR-скрининге, чего ждут на техническом интервью и как презентовать свой опыт.
И гайд — «Путь аналитика данных: от Junior к Senior» — это подробное описание грейдов, типичных задач, навыков и зон ответственности, чтобы было понятно, где вы сейчас находитесь и куда двигаться дальше.
Переходите по ссылке и забирайте оба гайда в боте бесплатно: https://clc.to/erid_2W5zFGnCDLU
Реклама. ООО "КАРПОВ КУРСЫ". ИНН 7811764627. erid: 2W5zFGnCDLU
В поиске оффера чаще всего не хватает не мотивации, а понятных ориентиров: как понять, готов ли я к работе, чего от меня ждут на собеседовании и в каком направлении развиваться дальше.
karpovꓸcourses подготовили бесплатный гайд по собеседованиям, где шаг за шагом разобрали весь процесс найма аналитика: этапы собеседований, как выглядит хороший отклик, что проверяют на HR-скрининге, чего ждут на техническом интервью и как презентовать свой опыт.
И гайд — «Путь аналитика данных: от Junior к Senior» — это подробное описание грейдов, типичных задач, навыков и зон ответственности, чтобы было понятно, где вы сейчас находитесь и куда двигаться дальше.
Переходите по ссылке и забирайте оба гайда в боте бесплатно: https://clc.to/erid_2W5zFGnCDLU
Реклама. ООО "КАРПОВ КУРСЫ". ИНН 7811764627. erid: 2W5zFGnCDLU
❤8👍5🔥2👎1🤔1
This media is not supported in your browser
VIEW IN TELEGRAM
Все, что нужно знать обо мне как о папе дочки!!
🔥 - если у тебя с твоим ребенком также
❤️ - чисто поддержать нас
🦄 - если у тебя дети ведут себя самым послушным образом
🔥 - если у тебя с твоим ребенком также
❤️ - чисто поддержать нас
🦄 - если у тебя дети ведут себя самым послушным образом
🔥38❤30🦄6🤣4🤔1
Media is too big
VIEW IN TELEGRAM
Команды, платформы и сложные проекты
Меня тут некоторое время назад Серёжа Зинкевич - это СЕО К2 Cloud пригласил на подкаст!
🎥Смотреть, если что можно прямо тут.
Прислал вопросы и темы для обсуждения. Я глянул - ну топчик. Сумеем заглянуть во все закоулки души и карьеры.
О чем поразгоняли:
1.
Ошибки, ошибки и еще раз ошибки.
Конечно, с моей любимой притчей:
2.
Где бы я ни был, не могу ни сказать про платформы и про них поговорили.
3.
Не забыли и похоливарить и за классический конфликт «быстро» vs «качественно»
4.
Ну и вишенка на торте: как понять, что пора команду отпустить.
Меня тут некоторое время назад Серёжа Зинкевич - это СЕО К2 Cloud пригласил на подкаст!
🎥Смотреть, если что можно прямо тут.
Прислал вопросы и темы для обсуждения. Я глянул - ну топчик. Сумеем заглянуть во все закоулки души и карьеры.
О чем поразгоняли:
1.
Ошибки, ошибки и еще раз ошибки.
Конечно, с моей любимой притчей:
Однажды самолёт президента стоял в аэропорту на регламентном обслуживании.
Работа шла по чек-листу, всё как всегда.
Один из механиков - опытный, спокойный, без нареканий - забыл закрутить одну гайку.
Мелочь. Почти незаметную.
Перед вылетом проблему заметили во время финальной проверки.
Разобрались. Нашли. Закрутили. Катастрофы не случилось.
Руководство вызвало этого механика.
Все ожидали увольнения. Сам он - тоже.
Но вместо этого ему сказали:
- С этого дня ты главный механик самолёта президента.
Он опешил:
- Почему? Я же ошибся.
Ему ответили:
- Потому что теперь ты единственный, кто точно никогда больше так не ошибётся.
Цена этой ошибки уже уплачена. Повторять её ты не будешь.
А нам нужен человек, который знает, что такое ответственность, а не тот, кто просто ещё не ошибался.
С тех пор этот самолёт обслуживал самый внимательный механик в стране.
2.
Где бы я ни был, не могу ни сказать про платформы и про них поговорили.
3.
Не забыли и похоливарить и за классический конфликт «быстро» vs «качественно»
4.
Ну и вишенка на торте: как понять, что пора команду отпустить.
🔥13❤10⚡3❤🔥1👍1