Зачем растить джунов
День итак всегда забит, а тут еще люди приходят с вопросами, хотят узнавать больше и развиваться. Стоит ли им помогать? Давайте разберем некоторые "за".
#чеклист #тимлиду
День итак всегда забит, а тут еще люди приходят с вопросами, хотят узнавать больше и развиваться. Стоит ли им помогать? Давайте разберем некоторые "за".
#чеклист #тимлиду
Идеальный код и продакшен
На связи Максим, сегодня хочу поговорить на тему идеального кода на продакшене, когда это важно и можно ли без этого обойтись. Начну с начала. Мое мнение относительно этого вопроса менялось по ходу роста моих навыков и смены должностей. Когда я только начинал разработчиком, мне нужно было делать кучу задач под разные проекты и платформы, которые были нужны на недолгий срок. Я опробовал много языков и платформ, особо в качество упирать естественно не было возможностей, да и понимания, где оно, это качество, не было.
Начав разрабатывать долгоживующие проекты, я понял, что очень важно писать их удобно для сопровождения и отладки. А частые правки от бизнеса приучили, что без тестов делать большие смены курса проекта или большой рефакторинг себе дороже.
С ростом сложности проектов я начал больше внимания уделять внимание архитектуре проекта. Отказоустойчивость компонентов, гарантированная доставка событий, корректная работа под пиковыми нагрузками и т.д. Структура проекта, или проектов, стала такой, что рефакторить куски стало не очень сложной задачей, а перерабатывать архитектуру всегда долго и больно.
Став СТО, я пришел к выводу, что в повседневной работе нужно всегда отстаивать сроки на разработку качественной фичи (обязательна правильная архитектура и наличие тестов), компромис в коде можно согласовать, если после запуска фичи сразу берется рефакторинг. Но, как правило, любой компромис останется вашим вечным техническим долгом.
Как же быть с проектами, которые нужно просто попробовать или фичами, с которыми нужно лишь протестировать взлетят они или нет? Если вы встраиваете фичу в большой проект, где поверх вашей фичи уже будут писаться другие, то тут без вариантов, качество должно соблюдаться на каждой фиче. Если это проект на попробовать, то у вас два варианта: пишите так, чтобы можно было отрефакторить в случае успеха или пишете с нуля, если выяснили, что проект взлетит. Это надо четко понимать, я видел много проектов, стартовавших как попробовать и потом развивающихся поверх этого кода многие годы. Работать с этим мягко говоря сложно, предсказуемость работы отсутствует. Поэтому если вы понимаете, что времени на исправление не будет, делайте хорошо сразу, если время будет, то я выбираю вариант с рефакторингом (при условии, что проект делается с запасом по нагрузке х2 и будет без огрехов выполнять заказанный функционал).
На связи Максим, сегодня хочу поговорить на тему идеального кода на продакшене, когда это важно и можно ли без этого обойтись. Начну с начала. Мое мнение относительно этого вопроса менялось по ходу роста моих навыков и смены должностей. Когда я только начинал разработчиком, мне нужно было делать кучу задач под разные проекты и платформы, которые были нужны на недолгий срок. Я опробовал много языков и платформ, особо в качество упирать естественно не было возможностей, да и понимания, где оно, это качество, не было.
Начав разрабатывать долгоживующие проекты, я понял, что очень важно писать их удобно для сопровождения и отладки. А частые правки от бизнеса приучили, что без тестов делать большие смены курса проекта или большой рефакторинг себе дороже.
С ростом сложности проектов я начал больше внимания уделять внимание архитектуре проекта. Отказоустойчивость компонентов, гарантированная доставка событий, корректная работа под пиковыми нагрузками и т.д. Структура проекта, или проектов, стала такой, что рефакторить куски стало не очень сложной задачей, а перерабатывать архитектуру всегда долго и больно.
Став СТО, я пришел к выводу, что в повседневной работе нужно всегда отстаивать сроки на разработку качественной фичи (обязательна правильная архитектура и наличие тестов), компромис в коде можно согласовать, если после запуска фичи сразу берется рефакторинг. Но, как правило, любой компромис останется вашим вечным техническим долгом.
Как же быть с проектами, которые нужно просто попробовать или фичами, с которыми нужно лишь протестировать взлетят они или нет? Если вы встраиваете фичу в большой проект, где поверх вашей фичи уже будут писаться другие, то тут без вариантов, качество должно соблюдаться на каждой фиче. Если это проект на попробовать, то у вас два варианта: пишите так, чтобы можно было отрефакторить в случае успеха или пишете с нуля, если выяснили, что проект взлетит. Это надо четко понимать, я видел много проектов, стартовавших как попробовать и потом развивающихся поверх этого кода многие годы. Работать с этим мягко говоря сложно, предсказуемость работы отсутствует. Поэтому если вы понимаете, что времени на исправление не будет, делайте хорошо сразу, если время будет, то я выбираю вариант с рефакторингом (при условии, что проект делается с запасом по нагрузке х2 и будет без огрехов выполнять заказанный функционал).
Как плохие владельцы продукта обманывают команду
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Уволить после отпуска
На днях мне скинули заметку о Генри Форде с вопросом, что я вообще о таком думаю? Сама история:
Однажды Генри Форд собрал руководителей всех отделов свой компании и отправил их в двухнедельный круиз. После возвращения один ждало повышение, а других увольнение. Форд основывался на работе отделов в отсутствие руководителя. Если работа шла хорошо и без руководителя, значит он сумел все хорошо организовать, а если нет, значит отдел без своего руководителя работать не может и это его вина.
Можно ли такую практику применять
Если ответить коротко, то это вполне распространенная и применяемая практика, которая показывает готовность команды к работе без руководителя.
А теперь немного поподробнее, почему это вообще важно? Потому что руководитель - это человек, который должен выстроить процесс, сделать работу своих людей понятной, четкой и, по возможности, комфортной для достижения максимальной производительности. Поэтому, если при уходе в отпуск руководителя работа встает, очевидно, что отдел работает не самым эффективным образом. То есть о выстраивании эффективной работы руководитель задумывался слабо или вообще не думал.
Это работает не только для руководителей
Такие проверки устраивать нужно обязательно, более того не только руководители, но и исполнители, бывают незаменимы, о чем многие с удивлением узнают после увольнения людей, после которого весь процесс останавливается. Поэтому нужно всегда смотреть может ли каждый из ваших сотрудников уйти в отпуск так, чтобы это не повлияло на процесс (конечно это влияет на скорость, банально в команде нет одного человека, но команда должна понимать что делать с задачами и нештатными ситуациями).
Обязательно протестируйте себя. Уйдите в отпуск и будьте недоступны или слабо доступны. Это может подсветить много слабых моментов. Конечно в обычной ситуации перед уходом в отпуск нужно передать дела своим сотрудникам, рассказать о потенциальных проблемах, где и как им нужно вас подменить. Помимо этого можете попробовать посмотреть, как процесс работает без вас, просто став недоступным по определенным вопросам на несколько дней (например, в целом по процессу ведения уже взятых в работу задач с любыми проблемами на пути работы).
Когда так делать нельзя
Также хотел уточнить ситуации, когда такой подход нельзя применять:
- если руководитель только назначен и не успел вникнуть в дела или перестроить процесс под свое видение;
- если стоит задача перестройки или реорганизации команды/отдела;
- если происходит быстрый рост команды/отдела. Новые люди и новые проекты, это всегда точки некоторого хаоса и притирки. Просто нужно оговаривать какие-то примерные сроки и шаги по стабилизации и следить как идет процесс;
- запуск новых проектов.
Я не знаю, кто первый начал практиковать способ с отпусками и где он впервые был описан, но это хороший способ проверить, что руководитель выстроил работу, а сотрудники шарят знания и могут подменять друг друга.
Максим Шаламов
#тимлиду
На днях мне скинули заметку о Генри Форде с вопросом, что я вообще о таком думаю? Сама история:
Однажды Генри Форд собрал руководителей всех отделов свой компании и отправил их в двухнедельный круиз. После возвращения один ждало повышение, а других увольнение. Форд основывался на работе отделов в отсутствие руководителя. Если работа шла хорошо и без руководителя, значит он сумел все хорошо организовать, а если нет, значит отдел без своего руководителя работать не может и это его вина.
Можно ли такую практику применять
Если ответить коротко, то это вполне распространенная и применяемая практика, которая показывает готовность команды к работе без руководителя.
А теперь немного поподробнее, почему это вообще важно? Потому что руководитель - это человек, который должен выстроить процесс, сделать работу своих людей понятной, четкой и, по возможности, комфортной для достижения максимальной производительности. Поэтому, если при уходе в отпуск руководителя работа встает, очевидно, что отдел работает не самым эффективным образом. То есть о выстраивании эффективной работы руководитель задумывался слабо или вообще не думал.
Это работает не только для руководителей
Такие проверки устраивать нужно обязательно, более того не только руководители, но и исполнители, бывают незаменимы, о чем многие с удивлением узнают после увольнения людей, после которого весь процесс останавливается. Поэтому нужно всегда смотреть может ли каждый из ваших сотрудников уйти в отпуск так, чтобы это не повлияло на процесс (конечно это влияет на скорость, банально в команде нет одного человека, но команда должна понимать что делать с задачами и нештатными ситуациями).
Обязательно протестируйте себя. Уйдите в отпуск и будьте недоступны или слабо доступны. Это может подсветить много слабых моментов. Конечно в обычной ситуации перед уходом в отпуск нужно передать дела своим сотрудникам, рассказать о потенциальных проблемах, где и как им нужно вас подменить. Помимо этого можете попробовать посмотреть, как процесс работает без вас, просто став недоступным по определенным вопросам на несколько дней (например, в целом по процессу ведения уже взятых в работу задач с любыми проблемами на пути работы).
Когда так делать нельзя
Также хотел уточнить ситуации, когда такой подход нельзя применять:
- если руководитель только назначен и не успел вникнуть в дела или перестроить процесс под свое видение;
- если стоит задача перестройки или реорганизации команды/отдела;
- если происходит быстрый рост команды/отдела. Новые люди и новые проекты, это всегда точки некоторого хаоса и притирки. Просто нужно оговаривать какие-то примерные сроки и шаги по стабилизации и следить как идет процесс;
- запуск новых проектов.
Я не знаю, кто первый начал практиковать способ с отпусками и где он впервые был описан, но это хороший способ проверить, что руководитель выстроил работу, а сотрудники шарят знания и могут подменять друг друга.
Максим Шаламов
#тимлиду
Большинство не знает этого секрета в подаче обратной связи
Умение давать обратную связь другим людям вообще встретить довольно сложно. Но я бы хотел остановиться на одном аспекте, а именно: ваша реакция на презентацию чего-либо от ваших коллег (друзей и кого угодно в целом). На этой, казалось бы мелочи, вырастают и конфликты, и демотивация, и отсутствие контакта и взаимопонимания в команде.
Как это обычно выглядит: человек или команда делают продукт/концепт/прототип/фичу/т.д., вкладываются в это, прикладывают все усилия, презентуют результат… Ну и слышат сходу что-то вроде: “да, но хотелось бы побольше, побыстрее, покрасивее”. И тут на самом деле даже люди привычные к такому будут не сильно в восторге, а у людей, близко к сердцу принимающих свою работу, будет гореть так, что огнетушитель не поможет. Причем, мало кто осознает во время или после таких презентаций, что все негативные эмоции и конфликт произошли из-за этой маленькой мелочи - критики со старта.
Обычно вы не знаете через какие проблемы проходят люди, какие там внешние и внутренние проблемы мешали, да и просто это не лучшая стратегия. Обязательно поблагодарите людей, хотя бы за то, что они старались и показали вам результат своих усилий. Стартуйте обсуждение с того, что вам не понравилось не в форме осуждения, а в форме вопроса. Например: “чем обусловлен выбор этого решения?” или “рассматривали ли вы такие подходы?” и т.д. На самом деле, из таких мелочей в итоге и складывается конструктивная или не особо работа. Не нужно врать людям и не говорить свое мнение. Просто уважайте чужой труд и выбирайте правильную форму подачи. В конце концов, если выяснится, что смягчающих факторов нет и все реально плохо, то тогда и можно переходить к ультимативной критике. До этого используйте более тактичный подход. Это сэкономит вам время и нервы.
Максим Шаламов
Умение давать обратную связь другим людям вообще встретить довольно сложно. Но я бы хотел остановиться на одном аспекте, а именно: ваша реакция на презентацию чего-либо от ваших коллег (друзей и кого угодно в целом). На этой, казалось бы мелочи, вырастают и конфликты, и демотивация, и отсутствие контакта и взаимопонимания в команде.
Как это обычно выглядит: человек или команда делают продукт/концепт/прототип/фичу/т.д., вкладываются в это, прикладывают все усилия, презентуют результат… Ну и слышат сходу что-то вроде: “да, но хотелось бы побольше, побыстрее, покрасивее”. И тут на самом деле даже люди привычные к такому будут не сильно в восторге, а у людей, близко к сердцу принимающих свою работу, будет гореть так, что огнетушитель не поможет. Причем, мало кто осознает во время или после таких презентаций, что все негативные эмоции и конфликт произошли из-за этой маленькой мелочи - критики со старта.
Обычно вы не знаете через какие проблемы проходят люди, какие там внешние и внутренние проблемы мешали, да и просто это не лучшая стратегия. Обязательно поблагодарите людей, хотя бы за то, что они старались и показали вам результат своих усилий. Стартуйте обсуждение с того, что вам не понравилось не в форме осуждения, а в форме вопроса. Например: “чем обусловлен выбор этого решения?” или “рассматривали ли вы такие подходы?” и т.д. На самом деле, из таких мелочей в итоге и складывается конструктивная или не особо работа. Не нужно врать людям и не говорить свое мнение. Просто уважайте чужой труд и выбирайте правильную форму подачи. В конце концов, если выяснится, что смягчающих факторов нет и все реально плохо, то тогда и можно переходить к ультимативной критике. До этого используйте более тактичный подход. Это сэкономит вам время и нервы.
Максим Шаламов
Вопросы, которые важно задавать любой компании на собеседовании. Часть первая "Цели"
От года к году мое понимание того, что и зачем спрашивать у потенциального работодателя меняется. Сейчас я хочу поделиться своим текущим набором вопросов. Конечно много вопросов пойдут от специфики компании и от того, как будет происходить общение. Но есть минимальный общий набор. Это особенно важно, когда вам предлагают руководить и отвечать за какие-то направления.
Первым сейчас для меня идет блок вопросов о целях. Без целей у компании не будет направления, а у людей не будет вокруг чего объединяться. Имея опыт работы в компания без конкретных целей, сейчас я сразу заканчиваю общение в случае, если мне не могут сформулировать цели компании и вытекающие из этого личные цели. Можно выделить следующие вопросы.
Каковы цели компании?
Верхнеуровневые цели, сформулированные руководством. Для достижения этих целей собственно и должны работать все сотрудники компании. Глядя на эти цели уже можно сложить представление о том подойдет вам компания или нет.
Каковы цели вашего проекта/департамента/…?
Поскольку каждый из нас работает в рамках какого-то проекта/департамента/ваша орг. структура, то нужно понять какие цели будут стоять у вашего подразделения и как вы влияете на цели компании. Из этого можно понять насколько важна ваша работа для компании и будет ли ваше подразделение в числе первых получать дополнительные ресурсы или нет. На этом этапе вы уже должны верхнеуровнево понимать, на что ваша работа влияет и степень ее важности. Если тут особого интереса не возникает, то я бы советовал поискать еще.
Каковы будут ваши личные цели и как они соотносятся с глобальными целями? Как понимать степень успеха вашей работы?
На этом этапе нужно понять есть ли четкое понимание вашего места в компании, того, что от вас ожидают и как будут оценивать. Чем более абстрактно на этом этапе отвечают, тем больше неприятных сюрпризов будет ждать в дальнейшей работе. Если вас вдохновляет то, чем занимается компания и то, как вы можете поучаствовать в ее работе, то в этом месте вы должны четко обговорить свои обязанности и цели. Чем четче вы зафиксируете и детальнее проговорите все детали, тем вам же будет проще в дальнейшем.
Какие решения принимаете лично вы на этой позиции?
Важный вопрос для понимания того, какие функции вам реально будут делегированы. На этом этапе может оказаться, что вам будет либо недостаточно инструментов для исполнения обязанностей, либо на вас пытаются переложить слишком много. В любом случае это хороший пункт, чтобы выровняться по ожиданиям и либо пойти на уступки, либо нет. В случае если вы произведете хорошее впечатление, чаще всего вам пойдут навстречу.
На этом пока все. Обязательно следите за обновления, на следующей неделе будет вторая часть с вопросами, которые помогут определить сложится ли ваше счастливое будущее в потенциальной компании. А пока сохраняйте этот пост, делитесь с друзьями и помните о нем на ближайшем собеседовании.
Максим Шаламов
От года к году мое понимание того, что и зачем спрашивать у потенциального работодателя меняется. Сейчас я хочу поделиться своим текущим набором вопросов. Конечно много вопросов пойдут от специфики компании и от того, как будет происходить общение. Но есть минимальный общий набор. Это особенно важно, когда вам предлагают руководить и отвечать за какие-то направления.
Первым сейчас для меня идет блок вопросов о целях. Без целей у компании не будет направления, а у людей не будет вокруг чего объединяться. Имея опыт работы в компания без конкретных целей, сейчас я сразу заканчиваю общение в случае, если мне не могут сформулировать цели компании и вытекающие из этого личные цели. Можно выделить следующие вопросы.
Каковы цели компании?
Верхнеуровневые цели, сформулированные руководством. Для достижения этих целей собственно и должны работать все сотрудники компании. Глядя на эти цели уже можно сложить представление о том подойдет вам компания или нет.
Каковы цели вашего проекта/департамента/…?
Поскольку каждый из нас работает в рамках какого-то проекта/департамента/ваша орг. структура, то нужно понять какие цели будут стоять у вашего подразделения и как вы влияете на цели компании. Из этого можно понять насколько важна ваша работа для компании и будет ли ваше подразделение в числе первых получать дополнительные ресурсы или нет. На этом этапе вы уже должны верхнеуровнево понимать, на что ваша работа влияет и степень ее важности. Если тут особого интереса не возникает, то я бы советовал поискать еще.
Каковы будут ваши личные цели и как они соотносятся с глобальными целями? Как понимать степень успеха вашей работы?
На этом этапе нужно понять есть ли четкое понимание вашего места в компании, того, что от вас ожидают и как будут оценивать. Чем более абстрактно на этом этапе отвечают, тем больше неприятных сюрпризов будет ждать в дальнейшей работе. Если вас вдохновляет то, чем занимается компания и то, как вы можете поучаствовать в ее работе, то в этом месте вы должны четко обговорить свои обязанности и цели. Чем четче вы зафиксируете и детальнее проговорите все детали, тем вам же будет проще в дальнейшем.
Какие решения принимаете лично вы на этой позиции?
Важный вопрос для понимания того, какие функции вам реально будут делегированы. На этом этапе может оказаться, что вам будет либо недостаточно инструментов для исполнения обязанностей, либо на вас пытаются переложить слишком много. В любом случае это хороший пункт, чтобы выровняться по ожиданиям и либо пойти на уступки, либо нет. В случае если вы произведете хорошее впечатление, чаще всего вам пойдут навстречу.
На этом пока все. Обязательно следите за обновления, на следующей неделе будет вторая часть с вопросами, которые помогут определить сложится ли ваше счастливое будущее в потенциальной компании. А пока сохраняйте этот пост, делитесь с друзьями и помните о нем на ближайшем собеседовании.
Максим Шаламов
Больше вопросов, которые важно задавать любой компании на собеседовании. Часть вторая
Дальше очень важно понять чем живет ваша потенциальная компания.
Кто клиенты вашей компании и/или вашего проекта?
К этому моменту чаще всего вы уже что-то знаете о проектах компании, но важно в деталях понимать кто и зачем пользуется продуктами компании.
Кто заказчик?
Очень важно знать, кто будет ставить задачи на разработку проектов. Как это работает и как принимаются решения. Очень важно понять для себя, что вас устраивают процессы и вы понимаете кто и по какому принципу принимает решения о развитии продукта. Периодически я прошу короткие встречи для знакомства, отказов обычно нет.
Какова структура компании? Кто и за что отвечает верхнеуровнево?
Это вопрос чисто из моего списка, знаю, что на это мало кто смотрит. Однако по структуре компании часто можно увидеть потенциальные проблемы в принятии решений и взаимодействиях для себя.
Как работает система мотивации сотрудников в компании?
Важный вопрос как для сотрудника так и для руководителя. Как руководителю вам важно понимать, помогает ли компания вам в мотивации и удержании сотрудников или нет, это хороший дополнительный показатель по компании.
Что случилось с предшественником?
Если вы разработчик, то ответ обычно очевиден: компания растет и развивается необходимость в людях растет, хотя и при поиске разработчиков бывают интересные истории. С руководящими позициями все не так очевидно. Если выделение новой структурной единицы понятно (хотя я обычно спрашиваю почему нет желающих из своих), то вот причину увольнения предшественника интересно узнать (конечно это мнение компании, но его тоже важно услышать). На этом этапе могут всплыть подводные камни или неочевидные важные для компании моменты, о которые и споткнулся предшественник или почему собственные сотрудники не стремятся на эту позицию.
Вот вопросы, которые я задаю не зависимо от компании, уже несколько лет. Они помогают мне неплохо оценить важные для меня детали о компании. Добавляйте в сохраненные, делитесь с коллегами, попробуйте лично, возможно какие-то вопросы войдут в ваш обязательный список.
Максим Шаламов
Дальше очень важно понять чем живет ваша потенциальная компания.
Кто клиенты вашей компании и/или вашего проекта?
К этому моменту чаще всего вы уже что-то знаете о проектах компании, но важно в деталях понимать кто и зачем пользуется продуктами компании.
Кто заказчик?
Очень важно знать, кто будет ставить задачи на разработку проектов. Как это работает и как принимаются решения. Очень важно понять для себя, что вас устраивают процессы и вы понимаете кто и по какому принципу принимает решения о развитии продукта. Периодически я прошу короткие встречи для знакомства, отказов обычно нет.
Какова структура компании? Кто и за что отвечает верхнеуровнево?
Это вопрос чисто из моего списка, знаю, что на это мало кто смотрит. Однако по структуре компании часто можно увидеть потенциальные проблемы в принятии решений и взаимодействиях для себя.
Как работает система мотивации сотрудников в компании?
Важный вопрос как для сотрудника так и для руководителя. Как руководителю вам важно понимать, помогает ли компания вам в мотивации и удержании сотрудников или нет, это хороший дополнительный показатель по компании.
Что случилось с предшественником?
Если вы разработчик, то ответ обычно очевиден: компания растет и развивается необходимость в людях растет, хотя и при поиске разработчиков бывают интересные истории. С руководящими позициями все не так очевидно. Если выделение новой структурной единицы понятно (хотя я обычно спрашиваю почему нет желающих из своих), то вот причину увольнения предшественника интересно узнать (конечно это мнение компании, но его тоже важно услышать). На этом этапе могут всплыть подводные камни или неочевидные важные для компании моменты, о которые и споткнулся предшественник или почему собственные сотрудники не стремятся на эту позицию.
Вот вопросы, которые я задаю не зависимо от компании, уже несколько лет. Они помогают мне неплохо оценить важные для меня детали о компании. Добавляйте в сохраненные, делитесь с коллегами, попробуйте лично, возможно какие-то вопросы войдут в ваш обязательный список.
Максим Шаламов
Как склонить коллег к вашему решению без конфликта
Хотел бы сегодня еще раз затронуть тему переговоров и убеждения своих собеседников во время встречи. Как часто выглядит диалог двух сторон, не согласных друг с другом: люди погружены в свою идею и переживания, наотрез отказываются даже вникнуть в слова оппонента, и главное, все больше и больше распаляются, что ведет к вбросу неосторожных фраз и часто к открытым конфликтам.
Я видел такое так часто, что даже не пытался вести подсчет. Будучи в начале своего карьерного пути я сам бывало вел себя точно также. Но, со временем, понимаешь, что твоя цель не спор и не унижение оппонента, твоя главная и единственная цель - убедить в своей правоте и продать свою идею. Более того, когда речь идет о долгосрочных взаимоотношениях на работе (да и не только), то победа любой ценой вам в принципе мало подходит. Такие победы создают крайне специфическую репутацию и отбивают желание у людей взаимодействовать с вами в будущем.
Заранее проработайте свою позицию
Что ж, я поделюсь тем как я это делаю и результаты меня вполне устраивают. Первое, вы обязательно готовитесь и четко прорабатываете свою позицию и аргументацию к ней. Очень важно найти слабые стороны, чтобы иметь возможность конструктивно общаться об этом. Все слабости нужно проработать в контексте того, что польза от вашего предложения сильно существеннее, чем минусы (минусы есть везде, если вы не видите ни одного, значит вы мало обдумывали свою идею).
Изучите позицию оппонента
Второе, обязательно постарайтесь понять и изучить позицию оппонентов. Обычно какие-то общие вещи известны заранее. Вы также должны найти не только минусы, но и плюсы чужой позиции. Обязательно нужно проработать идею так, будто она ваша. Если в процессе такого обдумывания вы поймете, что идея и правда лучше вашей, то сами объявите об этом, похвалите коллег и согласитесь с их мнением.
Анализируйте собеседников
Ну и главное, на встрече вы должны быть погружены не в себя и свою идею, а в анализ своих оппонентов. Мало кто в обычной рабочей встрече сильно заморачивается над работой над мимикой и голосом, поэтому вы многое сможете увидеть и услышать. Нужно чувствовать смену настроений, чтобы вовремя уйти от ненужного конфликта или, наоборот, начать активнее наседать, если увидите сомнения в сторону вашей идеи. В активных обсуждениях можно не успевать за всем следить, поэтому привлекайте на встречи своих сторонников, которые будут больше говорить, пока вы анализируете собеседников и ищите пути для лучшего развития ситуации. Никогда не фокусируйтесь только на себе, чувствуйте своих собеседников и пользуйтесь их реакциями.
Конечно пандемия и удаленка не всегда дают нам доступ к камере, чтобы видеть лицо собеседника. Однако и это не проблема: голос может сказать вам достаточно, особенно с учетом, что с выключенной камерой человек чувствует себя более раскованно и легче может выдать себя интонацией.
Итого, готовьтесь ко встречам, анализируйте мнение оппонентов и главное следите и используйте реакции собеседников. Тогда вы удивитесь насколько проще пойдут ваши переговоры на любые темы.
Максим Шаламов
Хотел бы сегодня еще раз затронуть тему переговоров и убеждения своих собеседников во время встречи. Как часто выглядит диалог двух сторон, не согласных друг с другом: люди погружены в свою идею и переживания, наотрез отказываются даже вникнуть в слова оппонента, и главное, все больше и больше распаляются, что ведет к вбросу неосторожных фраз и часто к открытым конфликтам.
Я видел такое так часто, что даже не пытался вести подсчет. Будучи в начале своего карьерного пути я сам бывало вел себя точно также. Но, со временем, понимаешь, что твоя цель не спор и не унижение оппонента, твоя главная и единственная цель - убедить в своей правоте и продать свою идею. Более того, когда речь идет о долгосрочных взаимоотношениях на работе (да и не только), то победа любой ценой вам в принципе мало подходит. Такие победы создают крайне специфическую репутацию и отбивают желание у людей взаимодействовать с вами в будущем.
Заранее проработайте свою позицию
Что ж, я поделюсь тем как я это делаю и результаты меня вполне устраивают. Первое, вы обязательно готовитесь и четко прорабатываете свою позицию и аргументацию к ней. Очень важно найти слабые стороны, чтобы иметь возможность конструктивно общаться об этом. Все слабости нужно проработать в контексте того, что польза от вашего предложения сильно существеннее, чем минусы (минусы есть везде, если вы не видите ни одного, значит вы мало обдумывали свою идею).
Изучите позицию оппонента
Второе, обязательно постарайтесь понять и изучить позицию оппонентов. Обычно какие-то общие вещи известны заранее. Вы также должны найти не только минусы, но и плюсы чужой позиции. Обязательно нужно проработать идею так, будто она ваша. Если в процессе такого обдумывания вы поймете, что идея и правда лучше вашей, то сами объявите об этом, похвалите коллег и согласитесь с их мнением.
Анализируйте собеседников
Ну и главное, на встрече вы должны быть погружены не в себя и свою идею, а в анализ своих оппонентов. Мало кто в обычной рабочей встрече сильно заморачивается над работой над мимикой и голосом, поэтому вы многое сможете увидеть и услышать. Нужно чувствовать смену настроений, чтобы вовремя уйти от ненужного конфликта или, наоборот, начать активнее наседать, если увидите сомнения в сторону вашей идеи. В активных обсуждениях можно не успевать за всем следить, поэтому привлекайте на встречи своих сторонников, которые будут больше говорить, пока вы анализируете собеседников и ищите пути для лучшего развития ситуации. Никогда не фокусируйтесь только на себе, чувствуйте своих собеседников и пользуйтесь их реакциями.
Конечно пандемия и удаленка не всегда дают нам доступ к камере, чтобы видеть лицо собеседника. Однако и это не проблема: голос может сказать вам достаточно, особенно с учетом, что с выключенной камерой человек чувствует себя более раскованно и легче может выдать себя интонацией.
Итого, готовьтесь ко встречам, анализируйте мнение оппонентов и главное следите и используйте реакции собеседников. Тогда вы удивитесь насколько проще пойдут ваши переговоры на любые темы.
Максим Шаламов
Что делать, если нет сил решать проблемы сотрудников
Что делать когда эмпатия на нуле, а помочь людям и/или сотрудникам надо? Эта ситуация чаще всего происходит на фоне большого перегруза, когда заваливает работой и нештатными ситуациями. В итоге, люди обычно становятся очень нервными и обидчивыми, а также очень бесчувственными по отношению к другим. Очевидным решением будет взять перерыв и отдохнуть. После чего все вернуться в норму. Но проблемы у людей происходят не по расписанию и часто в такие моменты вам нужно будет продолжать решать проблемы своих подчиненных.
Какие могут быть последствия?
Если есть понимание, что отдохнуть и перезагрузится получиться в течении ближайших 2-3 дня, лучше все такое общение переносить на потом и со свежей головой вникнуть в проблемы. Если ситуация затяжная, или нет понимания сроков окончания, то бегать от сотрудников плохая идея. Самая простая ситуация может раздуться до глобальной проблемы, либо люди потеряют желание делиться с вами проблемами и пытаться что-то улучшить. В итоге, демотивация и потеря желания работать - не лучший вариант.
Что делать?
Как же найти эмоции для восприятия проблем человека? Мой ответ: никак. Лично я всегда формулирую для себя критерии и ориентиры, по которым я принимаю решение. Это помогает и в этой ситуации, и в ситуации, когда эмоции захлестывают.
Поэтому мой сценарий такой:
⁃ слушаем человека;
⁃ записываем все тезисы;
⁃ задаем уточняющие вопросы;
⁃ вспоминаем свои приоритеты и установки;
⁃ берем небольшую паузу на формирование ответа (потому что в таких условиях лучше с листа не выдавать информацию).
Пример
Например, у вашего сотрудника есть потребность получить что-то: новую технику / обучение и т.д., согласование застопорилось, требует усилий по согласованию со сторонними подразделениями и отнимет у вас кучу сил. Вы понимаете, что это критично и сильно демотивирует человека в случае отказа. Вы забываете о своей усталости и смотрите в приоритеты. В них мы видим, что важно поддерживать эффективную и позитивную работу команды. Добавляем задачу себе в список дел и думаем как ее решить. Если задача не из ваших приоритетов, то откладываем ее до появления времени.
Вывод
По-другому у меня не получалось в таких ситуациях взяться за такие задачи, потому что, в моменты опустошения, проблемы других людей не кажутся такими страшными. Но помните, что, не зависимо от вашего состояния, людям в равной степени нужно внимание к их проблемам.
Максим Шаламов
#тимлиду
Что делать когда эмпатия на нуле, а помочь людям и/или сотрудникам надо? Эта ситуация чаще всего происходит на фоне большого перегруза, когда заваливает работой и нештатными ситуациями. В итоге, люди обычно становятся очень нервными и обидчивыми, а также очень бесчувственными по отношению к другим. Очевидным решением будет взять перерыв и отдохнуть. После чего все вернуться в норму. Но проблемы у людей происходят не по расписанию и часто в такие моменты вам нужно будет продолжать решать проблемы своих подчиненных.
Какие могут быть последствия?
Если есть понимание, что отдохнуть и перезагрузится получиться в течении ближайших 2-3 дня, лучше все такое общение переносить на потом и со свежей головой вникнуть в проблемы. Если ситуация затяжная, или нет понимания сроков окончания, то бегать от сотрудников плохая идея. Самая простая ситуация может раздуться до глобальной проблемы, либо люди потеряют желание делиться с вами проблемами и пытаться что-то улучшить. В итоге, демотивация и потеря желания работать - не лучший вариант.
Что делать?
Как же найти эмоции для восприятия проблем человека? Мой ответ: никак. Лично я всегда формулирую для себя критерии и ориентиры, по которым я принимаю решение. Это помогает и в этой ситуации, и в ситуации, когда эмоции захлестывают.
Поэтому мой сценарий такой:
⁃ слушаем человека;
⁃ записываем все тезисы;
⁃ задаем уточняющие вопросы;
⁃ вспоминаем свои приоритеты и установки;
⁃ берем небольшую паузу на формирование ответа (потому что в таких условиях лучше с листа не выдавать информацию).
Пример
Например, у вашего сотрудника есть потребность получить что-то: новую технику / обучение и т.д., согласование застопорилось, требует усилий по согласованию со сторонними подразделениями и отнимет у вас кучу сил. Вы понимаете, что это критично и сильно демотивирует человека в случае отказа. Вы забываете о своей усталости и смотрите в приоритеты. В них мы видим, что важно поддерживать эффективную и позитивную работу команды. Добавляем задачу себе в список дел и думаем как ее решить. Если задача не из ваших приоритетов, то откладываем ее до появления времени.
Вывод
По-другому у меня не получалось в таких ситуациях взяться за такие задачи, потому что, в моменты опустошения, проблемы других людей не кажутся такими страшными. Но помните, что, не зависимо от вашего состояния, людям в равной степени нужно внимание к их проблемам.
Максим Шаламов
#тимлиду
Ты можешь не все
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает