Как сделать встречи полезными?
В прошлом посте мы обсудили вред бесполезных встреч. Теперь давайте разберемся, как сделать встречи эффективными.
1️⃣ Уберите лишнее
Чтобы встречи были вам полезны, ходите только на полезные встречи. Отклоняйте ненужные или бесполезные для вас встречи.
Если сомневаетесь, спросите себя: на что конкретно вы меняете 30-60 минут своей жизни? Чтобы просто посидеть кустиком, потому что позвали, или вы внесете значимый вклад во встречу?
2️⃣ Слушайте и говорите
Если вы просидели молча всю встречу или постоянно смотрели мемы в соседней вкладке, поздравляю: вы только что растранжирили свое время одним из самых странных способов.
Если вы молчите и вам неинтересно содержимое встречи, скорее всего, это бесполезная для вас встреча.
3️⃣ Записывайте
Я пользуюсь программой LogSeq, чего и вам советую. После каждой встречи у меня остается 5-10 поинтов исключительно для меня. Иногда я к ним обращаюсь, иногда — нет. Но пишу всегда.
Записи помогают мне сосредоточится, так что меня меньше тянет отвлекаться от того, что говорят люди на встрече.
4️⃣ Пишите агенду
Если я собираю новую встречу, я либо прикреплю агенду ко встрече, либо отправлю людям документ в мессенджер. Агенда помогает мне четче сформулировать мою цель для встречи и экономит время на введение.
5️⃣ Пишите план действий
В конце встречи определите, что каждый из участников сделает (или не сделает) по итогу встречи. Например, мы договорились, что Вася напишет архитектурное решение до среды. Обязательно должны быть конкретные действия. Если после встречи их нет, боюсь, встреча могла пройти впустую.
‼️ Итоги
Для меня каждая встреча — важное событие, по итогу которого я ожидаю каких-то изменений и действий. Неважно: это регулярный 1-1 или встреча по Event Storming'у, каждая встреча важна и нужна, а без нее будет хуже, чем с ней.
А как вы делаете ваши встречи эффективнее?
В прошлом посте мы обсудили вред бесполезных встреч. Теперь давайте разберемся, как сделать встречи эффективными.
1️⃣ Уберите лишнее
Чтобы встречи были вам полезны, ходите только на полезные встречи. Отклоняйте ненужные или бесполезные для вас встречи.
Если сомневаетесь, спросите себя: на что конкретно вы меняете 30-60 минут своей жизни? Чтобы просто посидеть кустиком, потому что позвали, или вы внесете значимый вклад во встречу?
2️⃣ Слушайте и говорите
Если вы просидели молча всю встречу или постоянно смотрели мемы в соседней вкладке, поздравляю: вы только что растранжирили свое время одним из самых странных способов.
Если вы молчите и вам неинтересно содержимое встречи, скорее всего, это бесполезная для вас встреча.
3️⃣ Записывайте
Я пользуюсь программой LogSeq, чего и вам советую. После каждой встречи у меня остается 5-10 поинтов исключительно для меня. Иногда я к ним обращаюсь, иногда — нет. Но пишу всегда.
Записи помогают мне сосредоточится, так что меня меньше тянет отвлекаться от того, что говорят люди на встрече.
4️⃣ Пишите агенду
Если я собираю новую встречу, я либо прикреплю агенду ко встрече, либо отправлю людям документ в мессенджер. Агенда помогает мне четче сформулировать мою цель для встречи и экономит время на введение.
5️⃣ Пишите план действий
В конце встречи определите, что каждый из участников сделает (или не сделает) по итогу встречи. Например, мы договорились, что Вася напишет архитектурное решение до среды. Обязательно должны быть конкретные действия. Если после встречи их нет, боюсь, встреча могла пройти впустую.
‼️ Итоги
Для меня каждая встреча — важное событие, по итогу которого я ожидаю каких-то изменений и действий. Неважно: это регулярный 1-1 или встреча по Event Storming'у, каждая встреча важна и нужна, а без нее будет хуже, чем с ней.
А как вы делаете ваши встречи эффективнее?
Чему нас могут научить автобусы
Бизнес всегда хочет, чтобы разработка поставляла фичи быстрее. И мы у себя в ИТ придумали процессы, скрам, CI/CD — кучу всего придумали, если честно.
Но сегодня я дам вам самый простой рецепт, как повысить ощущение скорости разработки для бизнеса. И помогут нам в этом... Автобусы!
🚍 Как психология помогла сэкономить миллионы долларов
Во всех городах всех стран мира есть проблема: пассажиры расстраиваются, если слишком долго ждут свой автобус. Можно добавить новые автобусы на линию и решить проблему, но новые автобусы стоят много тысяч долларов.
Здесь важно помнить, какую проблему мы решаем. Корневая проблема — люди считают, что они слишком долго ждут автобуса. Добавление новых автобусов должно снизить их время ожидания, но это лишь один из методов решить проблему.
И тогда ученые подумали: как еще мы можем повлиять на время ожидания автобуса? В качестве эксперимента ученые установили на некоторых остановках дисплей, на которых отображалось время до прибытия следующего автобуса. Плюс у каждого пассажира начали спрашивать его ощущения, сколько минут он ждал своего автобуса.
Результаты удивили: пассажиры на остановках с дисплеем заявляли, что ждут автобуса примерно на 30% времени меньше, чем пассажиры на остановках без дисплея!
Еще раз: автобусов осталось ровно столько же. Ученые только добавили дисплей, на котором было видно, сколько еще осталось ждать. И это улучшило показатель на 30 процентов! Представьте, сколько автобусов нужно было бы вывести, чтобы достигнуть такого же результата? Сколько денег потратить — кошмар просто.
🚌 Автобусы помогают в ИТ
Думаю, вы уже догадались, куда я веду: контролируйте ожидания сроков своего заказчика. Не обещайте просто сделать задачу, озвучьте сроки и придерживайтесь их. А еще лучше: приведите в порядок вашу Джиру, чтобы бизнес сам мог видеть движение задач и знал, сколько ему еще ждать автобуса. В смысле, сколько еще ждать его фичи.
Я, кстати, до сих пор помню, как в Купере ко мне подошла менеджер и попросила просто говорить ей сроки. Она была согласна ждать задачу и месяц, и два — ей нужен был просто дедлайн, до которого задача гарантировано была бы сделана. Вместо этого, одна из моих команд просто говорила "сделаем" без ясных сроков. Так не надо.
Инструменты, которые могут вам помочь:
- Дорожная карта, на которой отмечены важные даты проекта или его релизы
- Текстовые апдейты раз в неделю (или чаще), как двигается проект и как мы попадаем в сроки
- Заполненная Джира, в которой виден статус проекта и его задач
Я в Циан использую все три, кстати.
Итак: прозрачные сроки сами по себе могут ускорить ощущение скорости разработки. Исследований в ИТ на эту тему пока не проводилось, поэтому скажите в комментариях, что думаете — бьется ли мой метод с вашим восприятием? Как вы сообщаете бизнесу сроки и контролируете его ощущения?
Бизнес всегда хочет, чтобы разработка поставляла фичи быстрее. И мы у себя в ИТ придумали процессы, скрам, CI/CD — кучу всего придумали, если честно.
Но сегодня я дам вам самый простой рецепт, как повысить ощущение скорости разработки для бизнеса. И помогут нам в этом... Автобусы!
🚍 Как психология помогла сэкономить миллионы долларов
Во всех городах всех стран мира есть проблема: пассажиры расстраиваются, если слишком долго ждут свой автобус. Можно добавить новые автобусы на линию и решить проблему, но новые автобусы стоят много тысяч долларов.
Здесь важно помнить, какую проблему мы решаем. Корневая проблема — люди считают, что они слишком долго ждут автобуса. Добавление новых автобусов должно снизить их время ожидания, но это лишь один из методов решить проблему.
И тогда ученые подумали: как еще мы можем повлиять на время ожидания автобуса? В качестве эксперимента ученые установили на некоторых остановках дисплей, на которых отображалось время до прибытия следующего автобуса. Плюс у каждого пассажира начали спрашивать его ощущения, сколько минут он ждал своего автобуса.
Результаты удивили: пассажиры на остановках с дисплеем заявляли, что ждут автобуса примерно на 30% времени меньше, чем пассажиры на остановках без дисплея!
Еще раз: автобусов осталось ровно столько же. Ученые только добавили дисплей, на котором было видно, сколько еще осталось ждать. И это улучшило показатель на 30 процентов! Представьте, сколько автобусов нужно было бы вывести, чтобы достигнуть такого же результата? Сколько денег потратить — кошмар просто.
🚌 Автобусы помогают в ИТ
Думаю, вы уже догадались, куда я веду: контролируйте ожидания сроков своего заказчика. Не обещайте просто сделать задачу, озвучьте сроки и придерживайтесь их. А еще лучше: приведите в порядок вашу Джиру, чтобы бизнес сам мог видеть движение задач и знал, сколько ему еще ждать автобуса. В смысле, сколько еще ждать его фичи.
Я, кстати, до сих пор помню, как в Купере ко мне подошла менеджер и попросила просто говорить ей сроки. Она была согласна ждать задачу и месяц, и два — ей нужен был просто дедлайн, до которого задача гарантировано была бы сделана. Вместо этого, одна из моих команд просто говорила "сделаем" без ясных сроков. Так не надо.
Инструменты, которые могут вам помочь:
- Дорожная карта, на которой отмечены важные даты проекта или его релизы
- Текстовые апдейты раз в неделю (или чаще), как двигается проект и как мы попадаем в сроки
- Заполненная Джира, в которой виден статус проекта и его задач
Я в Циан использую все три, кстати.
Итак: прозрачные сроки сами по себе могут ускорить ощущение скорости разработки. Исследований в ИТ на эту тему пока не проводилось, поэтому скажите в комментариях, что думаете — бьется ли мой метод с вашим восприятием? Как вы сообщаете бизнесу сроки и контролируете его ощущения?
Почему мы ВСЕГДА ошибаемся в сроках?
Ты когда-нибудь сталкивался с ситуацией, когда проект сорвал дедлайн, даже несмотря на все подстраховки? Это случается постоянно.
Люди не умеют точно оценивать задачи — об этом написаны сотни статей и книг. Но оценивать их все равно приходится. Причем не просто так, а так, чтобы реально укладываться в сроки.
И вот тут начинается самое интересное.
🚗 Почему даже простая оценка дороги до работы сложнее, чем кажется?
Возьмем простой пример.
Допустим, моя дорога до работы занимает 60 минут. Это если пробки средние и ничего не случилось.
Но если меня попросят дать оценку, я не скажу «60 минут». Почему? Потому что:
- Сильные пробки — +10 минут
- Перекрытие дорог — +10 минут
А если мне нужно назвать время, в которое я гарантированно уложусь? Тогда:
- Пробитое колесо — +20 минут
- Первый снег в Москве — +20 минут
В итоге выходит уже 120 минут — в два раза больше!
👨💻 Почему в IT-проектах происходит то же самое?
Когда мы оцениваем задачу в IT, мы тоже учитываем непредвиденные обстоятельства. Задача могла бы занять 4 дня? Добавляем подстраховку → получается 6 или 8 дней.
Почему так?
- Разработчик обжегся на прошлом проекте и теперь перестраховывается.
- Мы знаем, что форс-мажоры случаются.
- Мы хотим попасть в срок, а значит, лучше перебдеть, чем недобдеть.
В итоге, каждую задачу переоценивают → каждая подстраховка накапливается → проект вместо месяца занимает квартал.
Но проблема не только в этом.
🤦 Как мы сами разбазариваем время?
Подстраховка почти никогда не используется по назначению. Как она расходуется?
- Задача занимает ВСЕ время, что на нее выделено — если дали 3 дня, но справились за 2, оставшийся день потратим на «полировку».
- Синдром студента — раз у нас много времени, мы не торопимся. Мы знаем, что успеем, так что откладываем до последнего (как с курсовыми).
Получается парадокс: подстраховка должна помогать нам укладываться в сроки, но она же и создает задержки!
🧨 Почему проект ВСЕ РАВНО опаздывает?
Мы завышаем оценки → проект становится длиннее, чем нужно.
Подстраховка почти всегда используется (но не по назначению).
И когда рано или поздно одна из задач начинается опаздывать, подстраховка из других задач ей не поможет. Опоздание ОДНОЙ задачи тянет за собой ВСЕ следующие.
Как итог, что бы мы ни делали, сроки все равно срываются. Знакомая ситуация, да?
Я специально не буду давать решение в этом посте.
Мне интересно:
❓ Согласны ли вы с тем, что мы всегда завышаем оценки?
❓ Как у вас принято бороться с этой проблемой?
❓ Оцениваете ли вы задачи без подстраховки?
А в следующем посте расскажу, как предлагает решать этот вопрос Элияху Голдратт.
// Если пост был полезен, поделитесь им — так вы помогаете развитию канала. Спасибо!
Ты когда-нибудь сталкивался с ситуацией, когда проект сорвал дедлайн, даже несмотря на все подстраховки? Это случается постоянно.
Люди не умеют точно оценивать задачи — об этом написаны сотни статей и книг. Но оценивать их все равно приходится. Причем не просто так, а так, чтобы реально укладываться в сроки.
И вот тут начинается самое интересное.
🚗 Почему даже простая оценка дороги до работы сложнее, чем кажется?
Возьмем простой пример.
Допустим, моя дорога до работы занимает 60 минут. Это если пробки средние и ничего не случилось.
Но если меня попросят дать оценку, я не скажу «60 минут». Почему? Потому что:
- Сильные пробки — +10 минут
- Перекрытие дорог — +10 минут
А если мне нужно назвать время, в которое я гарантированно уложусь? Тогда:
- Пробитое колесо — +20 минут
- Первый снег в Москве — +20 минут
В итоге выходит уже 120 минут — в два раза больше!
👨💻 Почему в IT-проектах происходит то же самое?
Когда мы оцениваем задачу в IT, мы тоже учитываем непредвиденные обстоятельства. Задача могла бы занять 4 дня? Добавляем подстраховку → получается 6 или 8 дней.
Почему так?
- Разработчик обжегся на прошлом проекте и теперь перестраховывается.
- Мы знаем, что форс-мажоры случаются.
- Мы хотим попасть в срок, а значит, лучше перебдеть, чем недобдеть.
В итоге, каждую задачу переоценивают → каждая подстраховка накапливается → проект вместо месяца занимает квартал.
Но проблема не только в этом.
🤦 Как мы сами разбазариваем время?
Подстраховка почти никогда не используется по назначению. Как она расходуется?
- Задача занимает ВСЕ время, что на нее выделено — если дали 3 дня, но справились за 2, оставшийся день потратим на «полировку».
- Синдром студента — раз у нас много времени, мы не торопимся. Мы знаем, что успеем, так что откладываем до последнего (как с курсовыми).
Получается парадокс: подстраховка должна помогать нам укладываться в сроки, но она же и создает задержки!
🧨 Почему проект ВСЕ РАВНО опаздывает?
Мы завышаем оценки → проект становится длиннее, чем нужно.
Подстраховка почти всегда используется (но не по назначению).
И когда рано или поздно одна из задач начинается опаздывать, подстраховка из других задач ей не поможет. Опоздание ОДНОЙ задачи тянет за собой ВСЕ следующие.
Как итог, что бы мы ни делали, сроки все равно срываются. Знакомая ситуация, да?
Я специально не буду давать решение в этом посте.
Мне интересно:
❓ Согласны ли вы с тем, что мы всегда завышаем оценки?
❓ Как у вас принято бороться с этой проблемой?
❓ Оцениваете ли вы задачи без подстраховки?
А в следующем посте расскажу, как предлагает решать этот вопрос Элияху Голдратт.
// Если пост был полезен, поделитесь им — так вы помогаете развитию канала. Спасибо!
Как сделать так, чтобы разработчики не завышали оценку задач?
⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.
Так разработчики лучше понимают фичу, зачем мы ее пилим и как ее реализовать потом в коде сервиса. Задают вопросы по ходу discovery, следят за развитием мысли продакта и так далее.
Если же ваши разработчики получают требования откуда-то из черного ящика и в discovery не вовлекаются, они по-любому будут пытаться перестраховаться. Вы ведь просите их оценить что-то, что они видят в первый или второй раз в жизни.
⏳ Создайте буфер
Чтобы люди меньше пытались перестраховаться, заложите буфер на опоздания в конце квартала. Например, когда я планировал проекты, я всегда делал дату релиза ровно за один спринт до дедлайна. Таким образом, у нас всегда оставался спринт на то, чтобы порешать какие-то зависшие проблемы или нагнать отставание.
При этом в остальных, рабочих спринтах, я исключал перестраховку. Перестраховка уже заложена в конце квартала, нечего туда лезть внутри спринта.
🥊 Челленджите оценки
Это самый тяжелый, но в то же время самый простой способ. Легкий он потому что требует лишь одного вопроса, "а чо так долго?". Тяжелый — потому что его бывает непросто задавать.
Стесняться челленджить оценку — это критически плохо, потому что если оценка излишне высокая, вы просто потратите лишнее время зря. А могли бы потратить на другую задачу, на которую времени в итоге у вас может не хватить.
Но мне спрашивать было легко. Я — менеджер "от станка" и лет десять писал код каждый день. Поэтому когда я стал тимлидом, практически на любую оценку задачи я мог ответить, что сделал бы задачу в полтора-два раза быстрее.
Это — другая крайность, не делайте так. Потому что очень уж высок риск услышать в ответ на ваше "да я эту задачу за пару дней бы сделал" ответ "ну вот бери и делай тогда".
‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя
Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?
⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.
Так разработчики лучше понимают фичу, зачем мы ее пилим и как ее реализовать потом в коде сервиса. Задают вопросы по ходу discovery, следят за развитием мысли продакта и так далее.
Если же ваши разработчики получают требования откуда-то из черного ящика и в discovery не вовлекаются, они по-любому будут пытаться перестраховаться. Вы ведь просите их оценить что-то, что они видят в первый или второй раз в жизни.
⏳ Создайте буфер
Чтобы люди меньше пытались перестраховаться, заложите буфер на опоздания в конце квартала. Например, когда я планировал проекты, я всегда делал дату релиза ровно за один спринт до дедлайна. Таким образом, у нас всегда оставался спринт на то, чтобы порешать какие-то зависшие проблемы или нагнать отставание.
При этом в остальных, рабочих спринтах, я исключал перестраховку. Перестраховка уже заложена в конце квартала, нечего туда лезть внутри спринта.
🥊 Челленджите оценки
Это самый тяжелый, но в то же время самый простой способ. Легкий он потому что требует лишь одного вопроса, "а чо так долго?". Тяжелый — потому что его бывает непросто задавать.
Стесняться челленджить оценку — это критически плохо, потому что если оценка излишне высокая, вы просто потратите лишнее время зря. А могли бы потратить на другую задачу, на которую времени в итоге у вас может не хватить.
Но мне спрашивать было легко. Я — менеджер "от станка" и лет десять писал код каждый день. Поэтому когда я стал тимлидом, практически на любую оценку задачи я мог ответить, что сделал бы задачу в полтора-два раза быстрее.
Это — другая крайность, не делайте так. Потому что очень уж высок риск услышать в ответ на ваше "да я эту задачу за пару дней бы сделал" ответ "ну вот бери и делай тогда".
‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя
Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?
Эмпатия без требовательности — путь к плохому менеджменту
В книге "Радикальная прямота" увидел интересный фреймворк, решил, что должен с вами им поделиться. Сам фреймворк представлен на картинке выше: это график с двумя измерениями:
- Эмпатия (личный интерес) — насколько "по-человечески" вы относитесь к человеку, которому даете обратную связь, насколько вам важны его эмоции
- Требовательность (жесткие требования) — насколько четко вы выделяете, что хотите от человека и подсвечиваете его несоответствие требованиям
Отсюда вытекает четыре типа менеджмента. Разберем каждый тип на примере ситуации: ваш сотрудник завершил большую задачу, но результаты весьма средние. Есть сильные стороны, например, глубина проработки архитектуры. Есть слабые — не попал в сроки и проблемы с багами.
🕹 Манипулятивная неискренность (эмпатия — нет, требовательность — нет)
Если по-простому, вам феноменально безразличен и человек, и его эмоции, и требовать от него вы ничего не хотите.
В таком случае, вы похвалите человека за завершенную задачу, чтобы остаться в рамках социальной нормы. И все. Никакой обратной связи. Просто отмашка "норм, работай дальше".
С такими руководителями я не работал еще ни разу; и вам, если честно, не советовал бы. Даже нормального результата они вряд ли достигнут.
🤬 Оскорбительная агрессивность (эмпатия — нет, требовательность — да)
Такой руководитель укажет на абсолютно все слабые стороны результата в самой понятной и простой форме. Главное намерение — донести мысль до сотрудника, а не беспокоиться о чувствах человека.
Если вы спросите подчиненных оскорбительно-агрессивного руководителя, вам ответят, что он "выжимает" их досуха. Но результат обеспечивает; правда, ценой морального состояния коллектива.
🍨 Разрушительное сочувствие (эмпатия — да, требовательность — нет)
Этот тип укажет на все сильные стороны решения, но постарается как можно меньше и без подробностей говорить о слабых. Либо упомянет слабые стороны решения, но вскользь и в очень мягких формулировках.
К сожалению, шансов достичь результата у такого руководителя меньше, чем у оскорбительно-агрессивного. Причина проста: если вы явно не укажете человеку на его ошибки и не сделаете акцент, что такая ошибка — это плохо и надо ее исправить, то ошибки исправляться и не будут.
Из-за желания быть "экологичным" такой руководитель не позволяет расти и развиваться своим подчиненным. Наоборот, они убеждены, что выполняют свою работу великолепно, ведь лидер их всегда хвалит.
📏 Радикальная прямота (эмпатия — да, требовательность — да)
Такой руководитель постарается подобрать слова, чтобы сообщить человеку все как есть: подсветить и сильные, и слабые стороны его работы.
В отличие от оскорбительно-агрессивного, он подсветит слабые места с заботой о чувствах сотрудника.
В отличие от разрушительно-сочувственного, он укажет на точки роста без лишней словесной мишуры и сглаживания углов.
‼️ Вывод
Я стараюсь быть радикально откровенным и избегаю разрушительного сочувствия. Со временем радикальная прямота входит в привычку и уже не понимаешь, как можно по-другому. Сотрудники тоже привыкают и сами начинают использовать радикальную прямоту.
Главное — хорошо разобраться в проблеме и не спешить с выводами: радикальная прямота подразумевает акцент в том числе на слабых сторонах, поэтому нужно быть уверенным, что вы правильно выделили эти слабые стороны.
Но мне вот что интересно: если бы вы выбирали между руководителем типа "оскорбительная агрессия" и "разрушительное сочувствие", что бы вы выбрали?
В книге "Радикальная прямота" увидел интересный фреймворк, решил, что должен с вами им поделиться. Сам фреймворк представлен на картинке выше: это график с двумя измерениями:
- Эмпатия (личный интерес) — насколько "по-человечески" вы относитесь к человеку, которому даете обратную связь, насколько вам важны его эмоции
- Требовательность (жесткие требования) — насколько четко вы выделяете, что хотите от человека и подсвечиваете его несоответствие требованиям
Отсюда вытекает четыре типа менеджмента. Разберем каждый тип на примере ситуации: ваш сотрудник завершил большую задачу, но результаты весьма средние. Есть сильные стороны, например, глубина проработки архитектуры. Есть слабые — не попал в сроки и проблемы с багами.
🕹 Манипулятивная неискренность (эмпатия — нет, требовательность — нет)
Если по-простому, вам феноменально безразличен и человек, и его эмоции, и требовать от него вы ничего не хотите.
В таком случае, вы похвалите человека за завершенную задачу, чтобы остаться в рамках социальной нормы. И все. Никакой обратной связи. Просто отмашка "норм, работай дальше".
С такими руководителями я не работал еще ни разу; и вам, если честно, не советовал бы. Даже нормального результата они вряд ли достигнут.
Такой руководитель укажет на абсолютно все слабые стороны результата в самой понятной и простой форме. Главное намерение — донести мысль до сотрудника, а не беспокоиться о чувствах человека.
Если вы спросите подчиненных оскорбительно-агрессивного руководителя, вам ответят, что он "выжимает" их досуха. Но результат обеспечивает; правда, ценой морального состояния коллектива.
Этот тип укажет на все сильные стороны решения, но постарается как можно меньше и без подробностей говорить о слабых. Либо упомянет слабые стороны решения, но вскользь и в очень мягких формулировках.
К сожалению, шансов достичь результата у такого руководителя меньше, чем у оскорбительно-агрессивного. Причина проста: если вы явно не укажете человеку на его ошибки и не сделаете акцент, что такая ошибка — это плохо и надо ее исправить, то ошибки исправляться и не будут.
Из-за желания быть "экологичным" такой руководитель не позволяет расти и развиваться своим подчиненным. Наоборот, они убеждены, что выполняют свою работу великолепно, ведь лидер их всегда хвалит.
📏 Радикальная прямота (эмпатия — да, требовательность — да)
Такой руководитель постарается подобрать слова, чтобы сообщить человеку все как есть: подсветить и сильные, и слабые стороны его работы.
В отличие от оскорбительно-агрессивного, он подсветит слабые места с заботой о чувствах сотрудника.
В отличие от разрушительно-сочувственного, он укажет на точки роста без лишней словесной мишуры и сглаживания углов.
‼️ Вывод
Я стараюсь быть радикально откровенным и избегаю разрушительного сочувствия. Со временем радикальная прямота входит в привычку и уже не понимаешь, как можно по-другому. Сотрудники тоже привыкают и сами начинают использовать радикальную прямоту.
Главное — хорошо разобраться в проблеме и не спешить с выводами: радикальная прямота подразумевает акцент в том числе на слабых сторонах, поэтому нужно быть уверенным, что вы правильно выделили эти слабые стороны.
Но мне вот что интересно: если бы вы выбирали между руководителем типа "оскорбительная агрессия" и "разрушительное сочувствие", что бы вы выбрали?
Please open Telegram to view this post
VIEW IN TELEGRAM
Нет более верного способа испортить себе дела на работе, чем говорить "да" на каждую влетающую вам просьбу. Ну например:
- Можешь плиз посмотреть задачку быстренько? Там недолго, но мне прям очень надо, завтра релиз!
- Добавь пожалуйста в API вот эту ручку, мне для задачи не хватает, а взять ее могут только в следующем спринте, не могу ждать.
Ну и так далее. Знакомо? Соглашались? Тогда читайте дальше.
🦁 Зачем мы соглашаемся?
Очень просто: мы — социальные животные, и мы очень хотим быть в хороших отношениях с социумом вокруг нас. Это эволюционный механизм: люди, которые портили с социумом отношения, в большинстве своем не выжили и свои гены дальше не передали. Причин тому много: и саблезубые тигры, и различные виды мамонта.
Например, если неудачливый охотник-собиратель сломает себе на охоте ногу, его выживание целиком зависит от того, насколько к нему расположено племя. Если человек постоянно отказывался помочь коллегам по родо-племенному строю, вряд ли его будут подкармливать.
Поэтому наше подсознание говорим нам: соглашайся, сделай коллеге доброе дело, и тогда он сделает доброе дело тебе. Ситуация вин-вин! Тогда, в случае чего, с тобой поделятся мамонтом и ты не помрешь. Это называется "реципрокность" — наша склонность отвечать хорошим на хорошее.
⏳ А где здесь проблема?
Вот где: наше время в сутках жестко ограничено: 24 часа, из которых на работу желательно тратить часов 10-12 максимум. Многие скажут, что лучше даже поменьше. Время — невосполняемый ресурс, которым вы должны распоряжаться ответственно и инвестировать его только в важные и нужные дела.
Проблема в том, что каждое "да" отъедает кусок вашего рабочего времени. Плюс у вас есть свои рабочие задачи, в которые тоже нужно инвестировать время.
И самое главное: по ощущениям сказать "да" и согласится инвестировать время не стоит нам ни копейки времени! Ведь когда мы говорим да, мы не платим своим временем сразу. Мы выдаем сами себе кредит, который придется гасить чуть-чуть попозже, когда придет время реально выполнять работу.
Поэтому мы и говорим "да": в моменте нам это ничего не стоит, но дает ощущение, что социум нам если что подкинет кусок мамонта, если станет туго.
◀️ Обратный эффект
Рано или поздно человек, который на все говорит "да", влезает в долги: инвестирует больше времени, чем у него есть. А потом приходит время платить по этому кредиту, но выясняется, что платить нечем: мы помним, что время в сутках конечно.
Поэтому часть просьб либо отклоняется, либо делается тяп-ляп, по принципу "лишь бы отстали". Оба варианта очень плохи: человек рассчитывает на вас, строит свои планы исходя из того, что вы выполните его просьбу в срок. Вместо этого, он получает либо плохой результат, либо не получает его вообще.
В результате, вместо повышения социального одобрения и образа отзывчивого человека, мы получаем разочарованного коллегу, который вряд ли поделился бы с нами куском мамонта. Это и есть обратный эффект "да".
Самое интересное: если бы мы просто сказали "нет", эффект был бы гораздо позитивнее. Возможно, в моменте, коллега бы немного на нас подулся, но в целом — вряд ли вспомнил бы про этот отказ через пару дней. В конце-концов, отказы это просто часть нашей жизни и мы не заносим их в свою книгу обид. Правда же?
‼️ Что делать?
Не нужно отказывать всем во всех просьбах — тогда работа встанет во всей компании. Помогать коллегам важно и нужно, но внимательно рассчитывайте свою способность платить по тому кредиту, который создаст данное вами согласие. Тогда все получится как надо: вы и работе компании поможете, и вам не откажут в вашей просьбе спустя время.
А вы попадали в ситуации, где набрали слишком много кредитов на свое время? Поделитесь своей историей в комментариях! 🙂
- Можешь плиз посмотреть задачку быстренько? Там недолго, но мне прям очень надо, завтра релиз!
- Добавь пожалуйста в API вот эту ручку, мне для задачи не хватает, а взять ее могут только в следующем спринте, не могу ждать.
Ну и так далее. Знакомо? Соглашались? Тогда читайте дальше.
🦁 Зачем мы соглашаемся?
Очень просто: мы — социальные животные, и мы очень хотим быть в хороших отношениях с социумом вокруг нас. Это эволюционный механизм: люди, которые портили с социумом отношения, в большинстве своем не выжили и свои гены дальше не передали. Причин тому много: и саблезубые тигры, и различные виды мамонта.
Например, если неудачливый охотник-собиратель сломает себе на охоте ногу, его выживание целиком зависит от того, насколько к нему расположено племя. Если человек постоянно отказывался помочь коллегам по родо-племенному строю, вряд ли его будут подкармливать.
Поэтому наше подсознание говорим нам: соглашайся, сделай коллеге доброе дело, и тогда он сделает доброе дело тебе. Ситуация вин-вин! Тогда, в случае чего, с тобой поделятся мамонтом и ты не помрешь. Это называется "реципрокность" — наша склонность отвечать хорошим на хорошее.
⏳ А где здесь проблема?
Вот где: наше время в сутках жестко ограничено: 24 часа, из которых на работу желательно тратить часов 10-12 максимум. Многие скажут, что лучше даже поменьше. Время — невосполняемый ресурс, которым вы должны распоряжаться ответственно и инвестировать его только в важные и нужные дела.
Проблема в том, что каждое "да" отъедает кусок вашего рабочего времени. Плюс у вас есть свои рабочие задачи, в которые тоже нужно инвестировать время.
И самое главное: по ощущениям сказать "да" и согласится инвестировать время не стоит нам ни копейки времени! Ведь когда мы говорим да, мы не платим своим временем сразу. Мы выдаем сами себе кредит, который придется гасить чуть-чуть попозже, когда придет время реально выполнять работу.
Поэтому мы и говорим "да": в моменте нам это ничего не стоит, но дает ощущение, что социум нам если что подкинет кусок мамонта, если станет туго.
◀️ Обратный эффект
Рано или поздно человек, который на все говорит "да", влезает в долги: инвестирует больше времени, чем у него есть. А потом приходит время платить по этому кредиту, но выясняется, что платить нечем: мы помним, что время в сутках конечно.
Поэтому часть просьб либо отклоняется, либо делается тяп-ляп, по принципу "лишь бы отстали". Оба варианта очень плохи: человек рассчитывает на вас, строит свои планы исходя из того, что вы выполните его просьбу в срок. Вместо этого, он получает либо плохой результат, либо не получает его вообще.
В результате, вместо повышения социального одобрения и образа отзывчивого человека, мы получаем разочарованного коллегу, который вряд ли поделился бы с нами куском мамонта. Это и есть обратный эффект "да".
Самое интересное: если бы мы просто сказали "нет", эффект был бы гораздо позитивнее. Возможно, в моменте, коллега бы немного на нас подулся, но в целом — вряд ли вспомнил бы про этот отказ через пару дней. В конце-концов, отказы это просто часть нашей жизни и мы не заносим их в свою книгу обид. Правда же?
‼️ Что делать?
Не нужно отказывать всем во всех просьбах — тогда работа встанет во всей компании. Помогать коллегам важно и нужно, но внимательно рассчитывайте свою способность платить по тому кредиту, который создаст данное вами согласие. Тогда все получится как надо: вы и работе компании поможете, и вам не откажут в вашей просьбе спустя время.
А вы попадали в ситуации, где набрали слишком много кредитов на свое время? Поделитесь своей историей в комментариях! 🙂
Если у вас не взлетает Scrum, достаточно лишь...
Институт Исследования Scrum выпустил исследование, которое поможет вам внедрить Scrum, даже если команда сопротивляется.
Представляю вам Принципы Итеративных Постоянных Ежедневных Централизованных решений.
1️⃣ Давите авторитетом
Напоминайте команде, что решение о внедрении Скрам было принято на самом высоком уровне. Если кто-то против, пусть говорит со своим менеджером. Таким образом, вы избежите дискуссии и укрепите вертикаль власти в компании.
"Скрам — не мое решение, руководство так решило. Свои возражения ты можешь выразить руководителю."
2️⃣ Уберите ретроспективы
Ретроспективы скатываются в идеологические дебаты. Если инженеры не могут конструктивно спорить, но только атакуют идею Скрама, ваш единственный выход — заморозить практику ретроспектив. Пока инженеры не согласятся со Скрамом, вам придется отнять у них возможность пользоваться плюшками Скрама и устранять огрехи в нем.
"Ретроспектива — это бонус, а не стандарт. На данный момент я считаю, что команда не готова к ним."
3️⃣ Закрутите гайки
Безусловное следование практикам Скрама возможно лишь под вашим контролем. Без четкого следования практикам, прогресса не будет. Например, вы можете начать делать так:
- Проводите все Скрам-встречи самостоятельно, не доверяйте никому другому вести даже дейлики. Не подрывайте ваш авторитет.
- Усильте контроль с помощью инструментов: добавьте больше обязательных полей в Джиру, чтобы команда четко следовала процессам. Да, это скучно, но работа и не должна быть веселой.
- Детально проработайте Definition of Done: опишите все максиально подробно, превратите в чеклист и заставьте всех неукоснительно следовать ему.
Постоянство — ключ к успеху. Сама возможность сделать что-то не так вызовет мысль, что с идеями Скрам можно спорить. Избегайте подобных ситуаций.
4️⃣ Удерживайте контроль
Вы — владелец Скрам, и лишь ваши решения приведут команду в мир выполненных спринтов и качественной доставкой ценности. Например:
- Не допускайте дебатов. Избегайте споров с инженерами. Ваша коммуникация должна быть короткой и четкой, без возможности интерпретаций. Вы — командир, так что отдавайте приказы. А приказы не обсуждаются.
- Оставайтесь невозмутимым. Если что-то пошло не по плану или возникла очевидная проблема со Скрамом, удалитесь из беседы. "Простите, мне пора не следующую встречу" — отличная фраза, чтобы не потерять лицо перед инженерами.
5️⃣ Эскалируйте
Если возражения продолжают поступать, предложите эскалировать их вверх по цепочке. Помните про вертикаль власти в компании. Например:
- Предложите обратиться к HR или менеджменту. Четко коммуницируйте, что ваша работа состоит во внедрении решений, которые уже принял менеджмент. Вы внедряете лучшие стандарты индустрии, их приняли тысячи компаний по всему миру.
- Рассматривайте проблемы обезличенно. "Мы не говорим о чьем-то мнении, мы следуем общим, универсальным стандартам". Устраняйте личные мнения, принуждайте к следованию лучшим практикам.
‼️ Итоги
Предложенные выше решения могут показаться вам слишком суровыми. Это нормально. Иногда необходимо быть твердым, потому что Скрам может быть внедрен только тогда, когда вы следуете букве и духу Скрам гайда. Со временем инженеры привыкнут и даже начнут уважать ту дисциплину и следование правилам, которые вы внедрили.
А до тех пор, оставайтесь твердыми, непоколебимыми и не допускайте никаких дискуссий.
Что скажете — станете ли вы сторонником ПИПЕЦ (Принципы Итеративных Постоянных Ежедневных Централизованных) решений?
Оригинал статьи
Институт Исследования Scrum выпустил исследование, которое поможет вам внедрить Scrum, даже если команда сопротивляется.
Представляю вам Принципы Итеративных Постоянных Ежедневных Централизованных решений.
1️⃣ Давите авторитетом
Напоминайте команде, что решение о внедрении Скрам было принято на самом высоком уровне. Если кто-то против, пусть говорит со своим менеджером. Таким образом, вы избежите дискуссии и укрепите вертикаль власти в компании.
"Скрам — не мое решение, руководство так решило. Свои возражения ты можешь выразить руководителю."
2️⃣ Уберите ретроспективы
Ретроспективы скатываются в идеологические дебаты. Если инженеры не могут конструктивно спорить, но только атакуют идею Скрама, ваш единственный выход — заморозить практику ретроспектив. Пока инженеры не согласятся со Скрамом, вам придется отнять у них возможность пользоваться плюшками Скрама и устранять огрехи в нем.
"Ретроспектива — это бонус, а не стандарт. На данный момент я считаю, что команда не готова к ним."
3️⃣ Закрутите гайки
Безусловное следование практикам Скрама возможно лишь под вашим контролем. Без четкого следования практикам, прогресса не будет. Например, вы можете начать делать так:
- Проводите все Скрам-встречи самостоятельно, не доверяйте никому другому вести даже дейлики. Не подрывайте ваш авторитет.
- Усильте контроль с помощью инструментов: добавьте больше обязательных полей в Джиру, чтобы команда четко следовала процессам. Да, это скучно, но работа и не должна быть веселой.
- Детально проработайте Definition of Done: опишите все максиально подробно, превратите в чеклист и заставьте всех неукоснительно следовать ему.
Постоянство — ключ к успеху. Сама возможность сделать что-то не так вызовет мысль, что с идеями Скрам можно спорить. Избегайте подобных ситуаций.
4️⃣ Удерживайте контроль
Вы — владелец Скрам, и лишь ваши решения приведут команду в мир выполненных спринтов и качественной доставкой ценности. Например:
- Не допускайте дебатов. Избегайте споров с инженерами. Ваша коммуникация должна быть короткой и четкой, без возможности интерпретаций. Вы — командир, так что отдавайте приказы. А приказы не обсуждаются.
- Оставайтесь невозмутимым. Если что-то пошло не по плану или возникла очевидная проблема со Скрамом, удалитесь из беседы. "Простите, мне пора не следующую встречу" — отличная фраза, чтобы не потерять лицо перед инженерами.
5️⃣ Эскалируйте
Если возражения продолжают поступать, предложите эскалировать их вверх по цепочке. Помните про вертикаль власти в компании. Например:
- Предложите обратиться к HR или менеджменту. Четко коммуницируйте, что ваша работа состоит во внедрении решений, которые уже принял менеджмент. Вы внедряете лучшие стандарты индустрии, их приняли тысячи компаний по всему миру.
- Рассматривайте проблемы обезличенно. "Мы не говорим о чьем-то мнении, мы следуем общим, универсальным стандартам". Устраняйте личные мнения, принуждайте к следованию лучшим практикам.
‼️ Итоги
Предложенные выше решения могут показаться вам слишком суровыми. Это нормально. Иногда необходимо быть твердым, потому что Скрам может быть внедрен только тогда, когда вы следуете букве и духу Скрам гайда. Со временем инженеры привыкнут и даже начнут уважать ту дисциплину и следование правилам, которые вы внедрили.
А до тех пор, оставайтесь твердыми, непоколебимыми и не допускайте никаких дискуссий.
Что скажете — станете ли вы сторонником ПИПЕЦ (Принципы Итеративных Постоянных Ежедневных Централизованных) решений?
Оригинал статьи
У вас есть право на ошибку. И вы обязаны им пользоваться.
Понедельник — лучшее время, чтобы вспомнить: «Мы можем ошибаться». Даже не так — мы имеем право ошибаться! И мы будем ошибаться.
Но ведь ошибаться неприятно и даже больно? Правда. Рэй Далио писал: «Рост это боль плюс рефлексия», и по этой формуле ваш личный рост без совершения ошибок невозможен.
Венчурные инвесторы вообще считают, что если вы не совершаете ошибок в инвестировании, вы просто выбрали плохую стратегию. Ошибка — это не страшно, отсутствие ошибок это плохо. Потому что там, где нет ошибок, нет прогресса и роста.
Чем выше мы целимся, тем больше вероятность ошибки. Цельтесь высоко, но умно: не забывайте про диверсификацию рисков. Ставить все на красное это не стратегия, это азарт.
Понедельник — лучшее время, чтобы вспомнить: «Мы можем ошибаться». Даже не так — мы имеем право ошибаться! И мы будем ошибаться.
Но ведь ошибаться неприятно и даже больно? Правда. Рэй Далио писал: «Рост это боль плюс рефлексия», и по этой формуле ваш личный рост без совершения ошибок невозможен.
Венчурные инвесторы вообще считают, что если вы не совершаете ошибок в инвестировании, вы просто выбрали плохую стратегию. Ошибка — это не страшно, отсутствие ошибок это плохо. Потому что там, где нет ошибок, нет прогресса и роста.
Чем выше мы целимся, тем больше вероятность ошибки. Цельтесь высоко, но умно: не забывайте про диверсификацию рисков. Ставить все на красное это не стратегия, это азарт.
Президент США принял решение о депортации целых пяти языков программирования!
Проверьте, возможно, Трамп решил выслать из США и ваш любимый язык. Что тогда будете делать?
Поделитесь с коллегами — вдруг их любимый язык уже пересекает границу с Мексикой?
Проверьте, возможно, Трамп решил выслать из США и ваш любимый язык. Что тогда будете делать?
Поделитесь с коллегами — вдруг их любимый язык уже пересекает границу с Мексикой?
💥 Как подготовиться к эмоционально сложной встрече
(по мотивам статьи HBR)
Если ты руководишь людьми — рано или поздно окажешься на встрече, где эмоции будут кипеть: конфликт в команде, спор с продуктом, разговор об увольнении. И тут импровизация — плохой советчик. Вот три шага, которые работают.
---
🔸 1. Прокрути встречу в голове заранее
«Mental rehearsal» — это не фантазия, а часть подготовки лидера.
Задай себе вопросы:
— Что может быть сказано в эмоциональном тоне?
— Где человек может почувствовать себя атакованным? Помни: если человека атаковать, он будет защищаться.
— Какие слова могут триггернуть тебя самого?
Подготовь:
— Спокойные фразы для ответа на обвинения (“Я понимаю, что ты расстроен. Давай разберёмся вместе”)
— Альтернативные сценарии (“Если он начнёт всё отрицать — как я поведу диалог?”)
— Чёткие факты, а не только эмоции
Зачем? Ты не застигнут врасплох. Ты реагируешь осознанно, не на автомате. А это даёт уверенность и снижает градус.
«Самурай должен быть спокоен как в тихую погоду, так и в бурю» — Бусидо. Будь как самурай.
---
🔸 2. Определи, чего ты хочешь добиться
Не просто “провести встречу”, а прийти к результату.
Это САМОЕ главное. Когда ты начинаешь встречу, у тебя должно быть четкое понимание, что именно поменяется спустя пол-часа встречи: в тебе, в работе, в людях, в компании.
Перед тем как войти в переговорку или на встречу, задай себе вопросы:
— Какой конструктивный исход для всех сторон?
— Что важно для другого человека в этой ситуации?
— Что будет победой не только для тебя?
Например:
— Не “доказать, что он накосячил”, а “выяснить, как избежать этого в будущем”
— Не “объяснить, как мне тяжело”, а “получить поддержку и выстроить ожидания”.
Зачем? Цель держит фокус. Без неё эмоции уводят разговор в сторону, и вы выходите раздражёнными и без результата. Можно озвучить цель в самом начале беседы и убедиться, что все с ней согласны.
Pro-hint: если ситуация все-таки накалилась, четко сформулированная цель встрече поможет тебе вернуть ситуацию в конструктив. Если нет, то пользуйся советом Михалыча из Жмурок и «переноси стрелку на другой день».
---
🔸 3. Измени условия, если нужно
Иногда формат важнее содержания.
Проверь:
— Кто будет на встрече? Это безопасно для откровенного разговора?
— Где и как вы общаетесь? Можно ли выбрать спокойное место, без спешки?
— Формат помогает вам или мешает?
Если чувствуешь, что обычный формат «созвона на 30 минут» не подходит — измени его.
— Перенеси встречу на следующий день, чтобы дать себе и другим время. Я никогда не провожу пост-мортемы и подобные им встречи день-в-день, только в исключительных случаях делаю исключения.
— Сделай её тет-а-тет, если вопрос личный.
— Пригласи фасилитатора, если тема затрагивает всех. Если ты — прямой участник событий, полезно будет пригласить эмоционально невовлеченного человека. Например, твоего коллегу из соседнего отдела или функции.
Зачем? Ты не обязан принимать правила по умолчанию. Формат влияет на результат — используй это как инструмент в своем арсенале.
---
🧠 Главное: сложные разговоры можно готовить, как важные выступления. Эмоции не отменить, но ими можно управлять — особенно, если ты руководитель.
💬 А вы как готовитесь к «заряженным» встречам? Что работает лично у вас?
(по мотивам статьи HBR)
Если ты руководишь людьми — рано или поздно окажешься на встрече, где эмоции будут кипеть: конфликт в команде, спор с продуктом, разговор об увольнении. И тут импровизация — плохой советчик. Вот три шага, которые работают.
---
🔸 1. Прокрути встречу в голове заранее
«Mental rehearsal» — это не фантазия, а часть подготовки лидера.
Задай себе вопросы:
— Что может быть сказано в эмоциональном тоне?
— Где человек может почувствовать себя атакованным? Помни: если человека атаковать, он будет защищаться.
— Какие слова могут триггернуть тебя самого?
Подготовь:
— Спокойные фразы для ответа на обвинения (“Я понимаю, что ты расстроен. Давай разберёмся вместе”)
— Альтернативные сценарии (“Если он начнёт всё отрицать — как я поведу диалог?”)
— Чёткие факты, а не только эмоции
Зачем? Ты не застигнут врасплох. Ты реагируешь осознанно, не на автомате. А это даёт уверенность и снижает градус.
«Самурай должен быть спокоен как в тихую погоду, так и в бурю» — Бусидо. Будь как самурай.
---
🔸 2. Определи, чего ты хочешь добиться
Не просто “провести встречу”, а прийти к результату.
Это САМОЕ главное. Когда ты начинаешь встречу, у тебя должно быть четкое понимание, что именно поменяется спустя пол-часа встречи: в тебе, в работе, в людях, в компании.
Перед тем как войти в переговорку или на встречу, задай себе вопросы:
— Какой конструктивный исход для всех сторон?
— Что важно для другого человека в этой ситуации?
— Что будет победой не только для тебя?
Например:
— Не “доказать, что он накосячил”, а “выяснить, как избежать этого в будущем”
— Не “объяснить, как мне тяжело”, а “получить поддержку и выстроить ожидания”.
Зачем? Цель держит фокус. Без неё эмоции уводят разговор в сторону, и вы выходите раздражёнными и без результата. Можно озвучить цель в самом начале беседы и убедиться, что все с ней согласны.
Pro-hint: если ситуация все-таки накалилась, четко сформулированная цель встрече поможет тебе вернуть ситуацию в конструктив. Если нет, то пользуйся советом Михалыча из Жмурок и «переноси стрелку на другой день».
---
🔸 3. Измени условия, если нужно
Иногда формат важнее содержания.
Проверь:
— Кто будет на встрече? Это безопасно для откровенного разговора?
— Где и как вы общаетесь? Можно ли выбрать спокойное место, без спешки?
— Формат помогает вам или мешает?
Если чувствуешь, что обычный формат «созвона на 30 минут» не подходит — измени его.
— Перенеси встречу на следующий день, чтобы дать себе и другим время. Я никогда не провожу пост-мортемы и подобные им встречи день-в-день, только в исключительных случаях делаю исключения.
— Сделай её тет-а-тет, если вопрос личный.
— Пригласи фасилитатора, если тема затрагивает всех. Если ты — прямой участник событий, полезно будет пригласить эмоционально невовлеченного человека. Например, твоего коллегу из соседнего отдела или функции.
Зачем? Ты не обязан принимать правила по умолчанию. Формат влияет на результат — используй это как инструмент в своем арсенале.
---
🧠 Главное: сложные разговоры можно готовить, как важные выступления. Эмоции не отменить, но ими можно управлять — особенно, если ты руководитель.
💬 А вы как готовитесь к «заряженным» встречам? Что работает лично у вас?
Кажется, мы уже приплыли. Просто еще этого не заметили.
Раньше я посмеивался над людьми, которые кричали, мол "нейросети нас всех заменят!". А за последний месяц мне перестало быть смешно. Сейчас расскажу, почему.
💻 Нейронки для разработки
Месяц назад я начал использовать Cursor AI для своего сайд-проекта. Сначала просто как ко-пилот, а теперь пользуюсь им для написания целых файлов кода и тестов для него. Моя продуктивность возрасла в 3-4 раза. Откуда такая точность?
Дело в том, что по вечерам я пишу код с кальяном и точно знаю, сколько примерно я смогу написать за один кальян. Возможно, я запатентую новую метрику. Code per Hookah, или что-то типа.
А потом я соединил несколько нейронок с помощью AI агентов и охренел уже по-настоящему: одна нейронка искала мне исследования, вторая писала саммари, третья искала доп материалы, а четвертая сводила все воедино и отправляла мне в телегу.
Я бы убил на все это неделю. Нейронка справилась минут за 15.
❓ И тут вы скажете: «Олег, нейросеть никогда не заменит живого разработчика». Попробую угадать и ответить на ваши аргументы:
- Нейронка не понимает контекста задачи и бизнеса. Ну, некоторая часть разработчиков тоже не понимает, и ничего — работают. Но вообще, современные нейронки уже умеют уточнять требования и контекст.
- Нейронка не умеет мыслить нестандартно. Это правда, но кому какое дело? Подавляющее большинство задач и не требуют какого-то нестандартного мышления со стороны разработки.
- Ни в одну нейросеть не влезет крупный проект из-за ограничений самой нейросети. Согласен, но давайте честно: ни в одного живого человека такой проект тоже не влезет, никогда. А вот нейросети развиваются экспоненциально, так что рано или поздно смогут прожевать вообще любой проект.
- Нейросеть пишет слишком грязный код. Это тоже правда, но отчасти: хороший промпт дает неплохие результаты. Еще лучше результаты становятся, когда мы уменьшаем объем проекта. Чем меньше сервис, тем лучше нейросеть себя на нем показывает.
- Нейронка пишет код с ошибками, нужен человек для проверки. Нейронка может молотить 24/7, исправляя свои баги с помощью написанных собой же тестов. Участие человека будет необходимо, но скорее в режиме наблюдателя.
⚠️ Нас ждут перемены, которые не всем понравятся
Нейронки стартанули гораздо бодрее, чем любые другие инновации. Полтора века назад появление двигателей внутреннего сгорания изменило абсолютно все. Процесс растянулся на десятки лет: ДВС не захватили мир за ночь, зато теперь мы не можем представить без них мир.
Совет дам лишь один: не можешь победить — возглавь. Инвестируйте свое время, разбирайтесь в видах нейронок, их архитектуре, поколениях и новостях.
Раньше я посмеивался над людьми, которые кричали, мол "нейросети нас всех заменят!". А за последний месяц мне перестало быть смешно. Сейчас расскажу, почему.
💻 Нейронки для разработки
Месяц назад я начал использовать Cursor AI для своего сайд-проекта. Сначала просто как ко-пилот, а теперь пользуюсь им для написания целых файлов кода и тестов для него. Моя продуктивность возрасла в 3-4 раза. Откуда такая точность?
Дело в том, что по вечерам я пишу код с кальяном и точно знаю, сколько примерно я смогу написать за один кальян. Возможно, я запатентую новую метрику. Code per Hookah, или что-то типа.
А потом я соединил несколько нейронок с помощью AI агентов и охренел уже по-настоящему: одна нейронка искала мне исследования, вторая писала саммари, третья искала доп материалы, а четвертая сводила все воедино и отправляла мне в телегу.
Я бы убил на все это неделю. Нейронка справилась минут за 15.
❓ И тут вы скажете: «Олег, нейросеть никогда не заменит живого разработчика». Попробую угадать и ответить на ваши аргументы:
- Нейронка не понимает контекста задачи и бизнеса. Ну, некоторая часть разработчиков тоже не понимает, и ничего — работают. Но вообще, современные нейронки уже умеют уточнять требования и контекст.
- Нейронка не умеет мыслить нестандартно. Это правда, но кому какое дело? Подавляющее большинство задач и не требуют какого-то нестандартного мышления со стороны разработки.
- Ни в одну нейросеть не влезет крупный проект из-за ограничений самой нейросети. Согласен, но давайте честно: ни в одного живого человека такой проект тоже не влезет, никогда. А вот нейросети развиваются экспоненциально, так что рано или поздно смогут прожевать вообще любой проект.
- Нейросеть пишет слишком грязный код. Это тоже правда, но отчасти: хороший промпт дает неплохие результаты. Еще лучше результаты становятся, когда мы уменьшаем объем проекта. Чем меньше сервис, тем лучше нейросеть себя на нем показывает.
- Нейронка пишет код с ошибками, нужен человек для проверки. Нейронка может молотить 24/7, исправляя свои баги с помощью написанных собой же тестов. Участие человека будет необходимо, но скорее в режиме наблюдателя.
⚠️ Нас ждут перемены, которые не всем понравятся
Нейронки стартанули гораздо бодрее, чем любые другие инновации. Полтора века назад появление двигателей внутреннего сгорания изменило абсолютно все. Процесс растянулся на десятки лет: ДВС не захватили мир за ночь, зато теперь мы не можем представить без них мир.
Совет дам лишь один: не можешь победить — возглавь. Инвестируйте свое время, разбирайтесь в видах нейронок, их архитектуре, поколениях и новостях.
Перевод с корпоративного на русский
Я создаю стартап — это переводчик с корпоративного на русский. Вот первые результаты его работы. Что скажете, оплатили бы подписку?
// все совпадения с реальным миром сугубо случайны
Я создаю стартап — это переводчик с корпоративного на русский. Вот первые результаты его работы. Что скажете, оплатили бы подписку?
// все совпадения с реальным миром сугубо случайны