Нужны ли руководителю технические знания?
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
Сегодня мы подготовили для вас инфографику о принципах набора людей для маленькой компании. Более развернутую информацию можно найти в статье.
#тимлиду #разработчику
#тимлиду #разработчику
Как я следовал своим же советам и что из этого вышло
Часто получаю вопросы, мол советовать легко, а сам то следуешь своим же советам? На самом деле все, что я пишу, я прогоняю через себя, оно опробовано в работе и дало те результаты, которые я описываю. Это не значит, что это идеальные советы или лучшие решения в конкретной ситуации, но это те вещи, которые работают в тех условиях, что я описываю. Хорошо или плохо - каждый может решить для себя. На эту тему могу рассказать историю о следовании своим же советам.
Увольнение с работы
Прошлый год, я думаю, для многих был сложным, и я не был исключением. Помимо мировых событий сошлось много чего в моей жизни и очередной тупик на работе был в их числе. Вопрос не столько про то, что нет должностей выше (это как раз не так важно для меня), сколько мои ожидания не накладывались на реальность. Попробовав разные варианты и доведя работу до логической точки, собственно как и всегда всем советую, я покинул ТАСС. Что я никому не советовал, дак это уходить в никуда, как сделал я. Уйти в никуда был обдуманный, сложный, но очень нужный шаг. Нужно было время, чтобы переосмыслить свои проблемы и подходы.
Момент выбора
Осмысления закончились в сентябре 2022 (многие наверное помнят, что это было не лучшее время для поиска работы). Вариантов, с учетом ситуации, было не так много, но они были. Основной вопрос был в том, выбрать ли аналогичное место со схожими условиями, но теми же ограничениями, или попробовать сыграть на перспективу. Я выбрал перспективу (что тоже обычно советую другим, конечно при соблюдении минимально необходимых для вас условий), хоть это и значило то, что нужно сделать небольшой шаг назад и снова проявлять себя для возвращения на ожидаемые позиции.
Стоило ли оно того?
В итоге, по прошествии полугода, я прошел через самый сложный релиз из всех, что у меня был (хотя каждый раз думаешь, ну куда уж хуже=)) ), работаю с людьми, с которыми хотел работать, работаю с бизнесом, который хочет результат, а не иллюзию контроля. Если говорить про всякие числовые показатели, люди, команды и т.д, то тут тоже произошел шаг вперед. Это не история про то, как все идеально и лучше быть не может. Нет, проблемы есть и их много, но сейчас есть возможности для их решения, что самое главное для меня, понятны зоны и возможности роста.
Что могу сказать в виде итога для вас:
- биться головой о потолок, который по не зависящим от вас причинам вы не сможете пробить, особого смысла не имеет. Ищете варианты под себя, возможности выбрать сейчас хватает. Люди и подходы в компаниях немного, но отличаются, этого вполне может вам хватить, чтобы получить то, что вы ищете.
- иногда важно взять время на обдумывание ситуации, своих проблем и ограничений. Если есть возможность между работами брать паузу, советую ей пользоваться. Не всегда получается, переходя с работы на работу, осмыслить накопившийся опыт и изменить свои подходы.
- если вы во что-то постоянно упираетесь, то причина, в том числе, кроется и в вас. Не важно, как много вы успели сделать и узнать, учиться и расти нужно всю жизнь.
- не страшно сделать шаг назад, если вы видите перспективу и понимаете ради чего это делаете. Отходя от моего опыта, есть немало биографий, где людям по тем или иным причинам приходилось делать шаг назад и это помогало им прийти к большему.
В остальном, верьте себе, прорабатывайте свои проблемы, двигайтесь вперед и все у вас получится.
Максим Шаламов
#советы
Часто получаю вопросы, мол советовать легко, а сам то следуешь своим же советам? На самом деле все, что я пишу, я прогоняю через себя, оно опробовано в работе и дало те результаты, которые я описываю. Это не значит, что это идеальные советы или лучшие решения в конкретной ситуации, но это те вещи, которые работают в тех условиях, что я описываю. Хорошо или плохо - каждый может решить для себя. На эту тему могу рассказать историю о следовании своим же советам.
Увольнение с работы
Прошлый год, я думаю, для многих был сложным, и я не был исключением. Помимо мировых событий сошлось много чего в моей жизни и очередной тупик на работе был в их числе. Вопрос не столько про то, что нет должностей выше (это как раз не так важно для меня), сколько мои ожидания не накладывались на реальность. Попробовав разные варианты и доведя работу до логической точки, собственно как и всегда всем советую, я покинул ТАСС. Что я никому не советовал, дак это уходить в никуда, как сделал я. Уйти в никуда был обдуманный, сложный, но очень нужный шаг. Нужно было время, чтобы переосмыслить свои проблемы и подходы.
Момент выбора
Осмысления закончились в сентябре 2022 (многие наверное помнят, что это было не лучшее время для поиска работы). Вариантов, с учетом ситуации, было не так много, но они были. Основной вопрос был в том, выбрать ли аналогичное место со схожими условиями, но теми же ограничениями, или попробовать сыграть на перспективу. Я выбрал перспективу (что тоже обычно советую другим, конечно при соблюдении минимально необходимых для вас условий), хоть это и значило то, что нужно сделать небольшой шаг назад и снова проявлять себя для возвращения на ожидаемые позиции.
Стоило ли оно того?
В итоге, по прошествии полугода, я прошел через самый сложный релиз из всех, что у меня был (хотя каждый раз думаешь, ну куда уж хуже=)) ), работаю с людьми, с которыми хотел работать, работаю с бизнесом, который хочет результат, а не иллюзию контроля. Если говорить про всякие числовые показатели, люди, команды и т.д, то тут тоже произошел шаг вперед. Это не история про то, как все идеально и лучше быть не может. Нет, проблемы есть и их много, но сейчас есть возможности для их решения, что самое главное для меня, понятны зоны и возможности роста.
Что могу сказать в виде итога для вас:
- биться головой о потолок, который по не зависящим от вас причинам вы не сможете пробить, особого смысла не имеет. Ищете варианты под себя, возможности выбрать сейчас хватает. Люди и подходы в компаниях немного, но отличаются, этого вполне может вам хватить, чтобы получить то, что вы ищете.
- иногда важно взять время на обдумывание ситуации, своих проблем и ограничений. Если есть возможность между работами брать паузу, советую ей пользоваться. Не всегда получается, переходя с работы на работу, осмыслить накопившийся опыт и изменить свои подходы.
- если вы во что-то постоянно упираетесь, то причина, в том числе, кроется и в вас. Не важно, как много вы успели сделать и узнать, учиться и расти нужно всю жизнь.
- не страшно сделать шаг назад, если вы видите перспективу и понимаете ради чего это делаете. Отходя от моего опыта, есть немало биографий, где людям по тем или иным причинам приходилось делать шаг назад и это помогало им прийти к большему.
В остальном, верьте себе, прорабатывайте свои проблемы, двигайтесь вперед и все у вас получится.
Максим Шаламов
#советы
Советы увольняющимся
Многие используют выходные дни, как возможность подготовиться к поиску новой работы. Но важно не только понравится на новом месте, но и правильно уйти с предыдущего. Мы собрали для вас 6 важных пунктов, которые нужно сделать перед увольнением, чтобы оставить о себе хорошее впечатление.
#советы #разработчику
Многие используют выходные дни, как возможность подготовиться к поиску новой работы. Но важно не только понравится на новом месте, но и правильно уйти с предыдущего. Мы собрали для вас 6 важных пунктов, которые нужно сделать перед увольнением, чтобы оставить о себе хорошее впечатление.
#советы #разработчику
Как выбрать коллег, увлеченных своим делом, на собеседовании
Я давно работаю в ИТ, собираю команды и собеседую людей. И есть один запрос, с которым я часто сталкиваюсь: как определить активного коллегу, человека знающего и умеющего, готового поделиться своими знаниями, с кем можно вместе достигать поставленных целей. Обычно все это сводится к понятию “человек, увлеченный своим делом” (профессионализм пока оставим за скобками, это вопрос отдельного поста). Проблемой поиска таких людей задаются, как команды, которые нанимают новых сотрудников, так и отдельные люди, которые ищут работу с коллективом, увлеченным своим делом.
В этих случаях, мы ищем людей, которые увлечены и мотивированы в рамках своей профессии или проекта. Соответственно, они могут делиться на два подтипа: люди, которым интересно развивать проект и делать все, для этого, и люди, которым в принципе интересно развиваться в рамках своей профессии, набираться новых навыков и умений на любых задачах и проектах.
Как определить таких людей на собеседовании?
Нащупать такое стремление в людях достаточно несложно даже на собеседовании. При этом, подход к определению увлеченных людей будет одинаковым и для собеседующего и для собеседуемого.
Интерес к проекту легко понять, начиная задавать уточняющие вопросы по этому проекту. Чем больше деталей и нюансов выдает вам собеседник, тем больше его увлеченность этим проектом. В идеале, попробовать сравнить проект с конкурентами, при таком обсуждении сразу будет понятно насколько человек ценит свой проект и как видит его на рынке относительно конкурентов.
С увлеченностью технической стороной работы, все тоже довольно просто. Либо обсуждая прошлые/текущие проекты, либо уже во время обсуждения технических задач, углубляйтесь в детали реализации, выбора технологий и т.д. Задавайте вопросы “как” и “почему”, делитесь своим видением. Если человеку интересны такие технические темы, то вы быстро войдете в интересную дискуссию о вариантах и способах решения разных технических задач.
Не важно с какой позиции вы пытаетесь оценить собеседника, со стороны собеседующего или со стороны собеседуемого, помните, что вы общаетесь с обычным человеком. Он может быть уставшим или не в настроении. Поэтому, если ваша задача лучше понять увлеченность потенциального коллеги, то не поленитесь потратить время на то, чтобы разговорить вашего собеседника. Тогда, пользуясь советами из этого поста, вы сможете узнать уровень его увлеченности.
Чтобы лучше уметь работать с людьми, в том числе на собеседованиях, рекомендую ознакомится с моим учебником для тимлидов. Он позволит не только получить навыки тимлида, но и поможет лучше понимать своего руководителя. А это прямой путь к росту в компании на любой позиции.
Максим Шаламов
#советы #разработчику
Я давно работаю в ИТ, собираю команды и собеседую людей. И есть один запрос, с которым я часто сталкиваюсь: как определить активного коллегу, человека знающего и умеющего, готового поделиться своими знаниями, с кем можно вместе достигать поставленных целей. Обычно все это сводится к понятию “человек, увлеченный своим делом” (профессионализм пока оставим за скобками, это вопрос отдельного поста). Проблемой поиска таких людей задаются, как команды, которые нанимают новых сотрудников, так и отдельные люди, которые ищут работу с коллективом, увлеченным своим делом.
В этих случаях, мы ищем людей, которые увлечены и мотивированы в рамках своей профессии или проекта. Соответственно, они могут делиться на два подтипа: люди, которым интересно развивать проект и делать все, для этого, и люди, которым в принципе интересно развиваться в рамках своей профессии, набираться новых навыков и умений на любых задачах и проектах.
Как определить таких людей на собеседовании?
Нащупать такое стремление в людях достаточно несложно даже на собеседовании. При этом, подход к определению увлеченных людей будет одинаковым и для собеседующего и для собеседуемого.
Интерес к проекту легко понять, начиная задавать уточняющие вопросы по этому проекту. Чем больше деталей и нюансов выдает вам собеседник, тем больше его увлеченность этим проектом. В идеале, попробовать сравнить проект с конкурентами, при таком обсуждении сразу будет понятно насколько человек ценит свой проект и как видит его на рынке относительно конкурентов.
С увлеченностью технической стороной работы, все тоже довольно просто. Либо обсуждая прошлые/текущие проекты, либо уже во время обсуждения технических задач, углубляйтесь в детали реализации, выбора технологий и т.д. Задавайте вопросы “как” и “почему”, делитесь своим видением. Если человеку интересны такие технические темы, то вы быстро войдете в интересную дискуссию о вариантах и способах решения разных технических задач.
Не важно с какой позиции вы пытаетесь оценить собеседника, со стороны собеседующего или со стороны собеседуемого, помните, что вы общаетесь с обычным человеком. Он может быть уставшим или не в настроении. Поэтому, если ваша задача лучше понять увлеченность потенциального коллеги, то не поленитесь потратить время на то, чтобы разговорить вашего собеседника. Тогда, пользуясь советами из этого поста, вы сможете узнать уровень его увлеченности.
Чтобы лучше уметь работать с людьми, в том числе на собеседованиях, рекомендую ознакомится с моим учебником для тимлидов. Он позволит не только получить навыки тимлида, но и поможет лучше понимать своего руководителя. А это прямой путь к росту в компании на любой позиции.
Максим Шаламов
#советы #разработчику
Когда делали запуск мини-курса, столкнулись с интересным мнением, что разработчик не должен вкладываться в отношения с бизнесом и вообще общаться с ним не обязан. Все это забота только бизнес-стороны и руководителя команды, вот они пусть и разбираются. Мы как раз открыли в канале комментарии, поэтому сейчас мы расскажем наше мнение на этот счет, а вы делитесь своим.
А должен ли что-то кому-то разработчик?
Сначала в общем, о том, кто кому что должен. В последнее время, много появилось разработчиков, которые больше думают о том, что должны им, а не о том, что должны делать они. Здесь, без сомнения, сказывается рынок, где стало легко найти работу даже младшему разработчику с минимальным опытом, да еще и за неплохую зарплату. К чему это приводит? Люди не боятся потерять работу, они не мотивированы расти и развиваться, перестают понимать, зачем им стараться, когда они итак могут спокойно работать. Но в таком положении кроется ловушка.
Эту ловушку можно четко увидеть, когда к тебе на собеседование приходит 40-летний разработчик, с трудом отвечающий на вопросы для младших сотрудников, с опытом однотипных задач, совершенно не смотрящий в сторону каких бы то ни было новых технологий. Нравится такое будущее? Это будущее человека, который никому ничего не должен. В том числе себе.
Так, а надо ли заморачиваться в общении с бизнесом?
Ну допустим, если вы не хотите уйти на пенсию джуном, вам стоит немного стараться в своей работе и к чему-то стремиться. А что на счет изначального вопроса? Должен ли разработчик тратить свое драгоценное время на общение с коллегами из бизнеса или это устаревшая концепция для микро-стартапов?
Начнем с того, что большинство топовых ИТ-компаний работают по гибким методологиям. Сюда войдут и Google, и Microsoft, и Яндекс и многие многие другие. О плюсах их использования для бизнеса мы уже не раз говорили. Гибкие методологии в своей основе предполагают ежедневное общение представителей бизнеса и разработки. Лично разработки, не через руководителя. Эти методологии и называются та гибкими, потому что именно такое взаимодействие позволяет продукту стать гибким, увеличивает скорость отклика на нужды бизнеса. Итак, для бизнеса это плюс, это проверено множеством компаний на практике.
А важны ли нужды бизнеса обычному разработчику? Этот вопрос можно перефразировать в другой: а хочет ли разработчик получить следующую зарплату или повышение? Ведь финансирование разработки складывается из прибыли компании. Если бизнес компании будет терпеть неудачу, то и о повышении зарплаты и новой должности тоже можно забыть. На это просто не будет денег. На самом деле, это не единственная причина, почему разработчик должен быть в этом заинтересован, их довольно много. Но она очевидна и понятна большинству. Хочешь роста? Старайся помочь своему бизнесу процветать. А для этого нельзя от него отгораживаться. Естественно, бизнес со своей стороны должен делать тоже самое. Как мы уже обсуждали, это полностью в его интересах. Но отношения с одной стороны не строятся.
Вот кратко наше мнение по этому поводу. Подробнее обо всем этом мы писали в мини-курсе, он доступен на нашем сайте.
А что думаете вы? Ждем ваше мнение в комментариях.
А должен ли что-то кому-то разработчик?
Сначала в общем, о том, кто кому что должен. В последнее время, много появилось разработчиков, которые больше думают о том, что должны им, а не о том, что должны делать они. Здесь, без сомнения, сказывается рынок, где стало легко найти работу даже младшему разработчику с минимальным опытом, да еще и за неплохую зарплату. К чему это приводит? Люди не боятся потерять работу, они не мотивированы расти и развиваться, перестают понимать, зачем им стараться, когда они итак могут спокойно работать. Но в таком положении кроется ловушка.
Эту ловушку можно четко увидеть, когда к тебе на собеседование приходит 40-летний разработчик, с трудом отвечающий на вопросы для младших сотрудников, с опытом однотипных задач, совершенно не смотрящий в сторону каких бы то ни было новых технологий. Нравится такое будущее? Это будущее человека, который никому ничего не должен. В том числе себе.
Так, а надо ли заморачиваться в общении с бизнесом?
Ну допустим, если вы не хотите уйти на пенсию джуном, вам стоит немного стараться в своей работе и к чему-то стремиться. А что на счет изначального вопроса? Должен ли разработчик тратить свое драгоценное время на общение с коллегами из бизнеса или это устаревшая концепция для микро-стартапов?
Начнем с того, что большинство топовых ИТ-компаний работают по гибким методологиям. Сюда войдут и Google, и Microsoft, и Яндекс и многие многие другие. О плюсах их использования для бизнеса мы уже не раз говорили. Гибкие методологии в своей основе предполагают ежедневное общение представителей бизнеса и разработки. Лично разработки, не через руководителя. Эти методологии и называются та гибкими, потому что именно такое взаимодействие позволяет продукту стать гибким, увеличивает скорость отклика на нужды бизнеса. Итак, для бизнеса это плюс, это проверено множеством компаний на практике.
А важны ли нужды бизнеса обычному разработчику? Этот вопрос можно перефразировать в другой: а хочет ли разработчик получить следующую зарплату или повышение? Ведь финансирование разработки складывается из прибыли компании. Если бизнес компании будет терпеть неудачу, то и о повышении зарплаты и новой должности тоже можно забыть. На это просто не будет денег. На самом деле, это не единственная причина, почему разработчик должен быть в этом заинтересован, их довольно много. Но она очевидна и понятна большинству. Хочешь роста? Старайся помочь своему бизнесу процветать. А для этого нельзя от него отгораживаться. Естественно, бизнес со своей стороны должен делать тоже самое. Как мы уже обсуждали, это полностью в его интересах. Но отношения с одной стороны не строятся.
Вот кратко наше мнение по этому поводу. Подробнее обо всем этом мы писали в мини-курсе, он доступен на нашем сайте.
А что думаете вы? Ждем ваше мнение в комментариях.
Инструкция, как собеседовать кандидата на совместимость с командой
Обязательна к применению на каждом собеседовании! Так что сохраняйте к себе и делитесь с коллегами.
Кстати, инструкция о том, как правильно вводить в курс дела нового сотрудника, чтобы он быстрее адаптировался и начал работать, есть в учебнике для тимлидов.
Обязательна к применению на каждом собеседовании! Так что сохраняйте к себе и делитесь с коллегами.
Кстати, инструкция о том, как правильно вводить в курс дела нового сотрудника, чтобы он быстрее адаптировался и начал работать, есть в учебнике для тимлидов.
100% способ выйти из рутины
Помните, как вы впервые столкнулись с рутиной? Для меня это было так. На одной из своих первых работ я занималась парсингом сайтов. Сначала это было в новинку, я неплохо выучила регулярки, научилась быстро разбираться в чужой верстке. Но, когда все новое было изучено, моя работа свелась к тому, чтобы открыть сайт, найти нужный тег и добавить одну из стандартных регулярок, которые я уже десятки раз использовала. Так младший разработчик впервые познакомился с рутиной. Очень быстро мне захотелось уволиться. Я не знала, что мне еще предстоит научиться справляться с рутинными задачами и найти в них свою прелесть, но об этом позже.
От чего вообще появляется рутина? Делая что-то новое, мы задействуем участки мозга, которые вместе еще не работали. Это очень большие затраты энергии и усилий. Повторяя действие раз за разом, мы усиливаем связи в мозге и действие становится для нас проще, а со временем и вообще автоматическим. Почему так происходит? Наш мозг - совершенная система оптимизации. Он действует по принципу: “А вдруг тигр нападет, а я уставший? Надо сохранить и выбирать автоматические действия, чтобы не думать и не уставать”. Вспомните о своей утренней рутине: встаем, чистим зубы, наливаем кофе, одеваемся, выходим из дома. А потом не можем вспомнить, закрыли ли дверь, потому что сделали это автоматически. Представьте, что вам бы пришлось полностью осознанно делать каждое это действие: “Итак, я проснулся, нужно открыть глаза, поднять руку, нажать кнопку - выключить будильник, поставить первую ногу на пол…” - да мы бы устали не дойдя до работы! Но наш мозг все эти действия оптимизировал, они происходят на автомате и не напрягают нас. Круто, правда?
Тоже происходит, когда мы делаем рабочие задачи. То, что мы делаем многократно, оптимизируется мозгом и начинает выполняться автоматически. И в этот момент появляется рутина. Представьте, что весь ваш день состоит из чистки зубов, надевания штанов и закрывания дверей, - с ума можно сойти! Нам просто становится скучно и неинтересно этим заниматься. Так, что же получается, если так работает наш мозг, то все, что мы делаем рано или поздно превратится в рутину и выхода нет? А что дальше, выгорание, тупик, смена профессии?
Все не так плохо. Все, что нужно сделать - всегда давать себе новые задачи, искать ситуации, где нужно придумывать новые решения. Не обязательно искать особенный проект или руководителя, который будет подбирать под вас отборные задачи. Нужно лишь изменить свой собственный подход к работе, научиться видеть возможности. Представьте, что вы выбираете варианты отпуска. Вы можете каждый раз оставаться дома и читать одну и ту же надоевшую книгу, а можете поехать поплавать в Байкале, ночуя в палатке, где не ловит телефон, или участвовать в музыкальном фестивале с шумной компанией друзей и оторваться по полной, провести отпуск на дальнем севере среди коренных жителей маленькой деревушки, или на карнавале в Рио-де-Жанейро. Это решение одной и той же задачи, а какой разный результат. Такой же выбор можно сделать и в работе.
Но ведь менять свои собственные подходы сложнее всего, с чего начать? Все очень просто, нужно только использовать уже готовую инструкцию и идти по конкретным, небольшим шагам. Ничего не нужно придумывать самостоятельно, мы уже подготовили для вас целых три плана избавления от рутины по разным направлениям. В планах вы найдете прямо конкретные действия и подходы, которые нужно использовать, чтобы найти для себя интересные задачи. Применение даже одного пункта плана уже поможет уменьшить количество рутины. А главное, применять можно сразу же после прочтения. Читаете первый пункт - применяете, получаете результат.
Решение остается за вами: останетесь в компании рутины или отправитесь в незабываемое путешествие? Если уже определились, то забирайте план путешествия.
Помните, как вы впервые столкнулись с рутиной? Для меня это было так. На одной из своих первых работ я занималась парсингом сайтов. Сначала это было в новинку, я неплохо выучила регулярки, научилась быстро разбираться в чужой верстке. Но, когда все новое было изучено, моя работа свелась к тому, чтобы открыть сайт, найти нужный тег и добавить одну из стандартных регулярок, которые я уже десятки раз использовала. Так младший разработчик впервые познакомился с рутиной. Очень быстро мне захотелось уволиться. Я не знала, что мне еще предстоит научиться справляться с рутинными задачами и найти в них свою прелесть, но об этом позже.
От чего вообще появляется рутина? Делая что-то новое, мы задействуем участки мозга, которые вместе еще не работали. Это очень большие затраты энергии и усилий. Повторяя действие раз за разом, мы усиливаем связи в мозге и действие становится для нас проще, а со временем и вообще автоматическим. Почему так происходит? Наш мозг - совершенная система оптимизации. Он действует по принципу: “А вдруг тигр нападет, а я уставший? Надо сохранить и выбирать автоматические действия, чтобы не думать и не уставать”. Вспомните о своей утренней рутине: встаем, чистим зубы, наливаем кофе, одеваемся, выходим из дома. А потом не можем вспомнить, закрыли ли дверь, потому что сделали это автоматически. Представьте, что вам бы пришлось полностью осознанно делать каждое это действие: “Итак, я проснулся, нужно открыть глаза, поднять руку, нажать кнопку - выключить будильник, поставить первую ногу на пол…” - да мы бы устали не дойдя до работы! Но наш мозг все эти действия оптимизировал, они происходят на автомате и не напрягают нас. Круто, правда?
Тоже происходит, когда мы делаем рабочие задачи. То, что мы делаем многократно, оптимизируется мозгом и начинает выполняться автоматически. И в этот момент появляется рутина. Представьте, что весь ваш день состоит из чистки зубов, надевания штанов и закрывания дверей, - с ума можно сойти! Нам просто становится скучно и неинтересно этим заниматься. Так, что же получается, если так работает наш мозг, то все, что мы делаем рано или поздно превратится в рутину и выхода нет? А что дальше, выгорание, тупик, смена профессии?
Все не так плохо. Все, что нужно сделать - всегда давать себе новые задачи, искать ситуации, где нужно придумывать новые решения. Не обязательно искать особенный проект или руководителя, который будет подбирать под вас отборные задачи. Нужно лишь изменить свой собственный подход к работе, научиться видеть возможности. Представьте, что вы выбираете варианты отпуска. Вы можете каждый раз оставаться дома и читать одну и ту же надоевшую книгу, а можете поехать поплавать в Байкале, ночуя в палатке, где не ловит телефон, или участвовать в музыкальном фестивале с шумной компанией друзей и оторваться по полной, провести отпуск на дальнем севере среди коренных жителей маленькой деревушки, или на карнавале в Рио-де-Жанейро. Это решение одной и той же задачи, а какой разный результат. Такой же выбор можно сделать и в работе.
Но ведь менять свои собственные подходы сложнее всего, с чего начать? Все очень просто, нужно только использовать уже готовую инструкцию и идти по конкретным, небольшим шагам. Ничего не нужно придумывать самостоятельно, мы уже подготовили для вас целых три плана избавления от рутины по разным направлениям. В планах вы найдете прямо конкретные действия и подходы, которые нужно использовать, чтобы найти для себя интересные задачи. Применение даже одного пункта плана уже поможет уменьшить количество рутины. А главное, применять можно сразу же после прочтения. Читаете первый пункт - применяете, получаете результат.
Решение остается за вами: останетесь в компании рутины или отправитесь в незабываемое путешествие? Если уже определились, то забирайте план путешествия.