А как же куча встрееееееееч?
Одной из самых болезненных тем, при обсуждении спринтов является большое количество встреч, которые нужно проводить каждыйгребаный спринт. Эта куча встреч не дает честным разработчикам работать, а только отнимает время. Если честно, на эту тему можно говорить сутки на пролет и все равно всего не скажешь. Главное, что нужно помнить, каждая встреча должна и несет в себе определенный смысл. На пример, пункты выше как раз реализуются через эти самые встречи. А чтобы лучше понимать, зачем это все напридумывали, учите основы. Только зная основы и как определить приносит каждая встреча пользу или нет, можно понять нужна ли конкретная встреча вашей конкретной команде. Ну и не будем забывать, что встречи еще нужно и уметь проводить, об этом мы уже немного говорили раньше, но конечно же у каждой встречи есть свои особенности, опять же нужно учиться проводить каждую конкретную встречу правильно. А вообще отсутствие спринтов не спасет от кучи бесполезных встреч, они появляются от неумения строить правильные процессы и вести правильную коммуникацию, а не от выбора конкретных подходов.
Александра Шаламова
#agile_который_работает
Одной из самых болезненных тем, при обсуждении спринтов является большое количество встреч, которые нужно проводить каждый
Александра Шаламова
#agile_который_работает
Должен ли руководитель уметь сам проверить работу каждого?
В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.
Это вопрос сам по себе не имеет смысла, потому что в нем раскрыто сразу же полное непонимание, чем ты собираешься заниматься, как руководитель, и для чего. В такой постановке вопроса у меня есть предположение, что у руководителя должно быть экспертное знание во всех направлениях и языках, а также DevOps и сопровождении. Сомневаюсь, что эта история про реального человека, поэтому умение все проверить лучше всех - это иллюзия контроля, которая еще и замедляет работу команды. Не надо тешить свое эго тем, что ты везде и всюду умнее, ты формируешь команду и растишь ее, твоя цель, чтобы люди по целевым направлениям знали и умели больше тебя.
Про раздачу задач и вот это все. Ваша задача основная - сделать так, чтобы ваш проект работал хорошо, все выполнялось в срок и предсказуемо. Все остальное крутится вокруг достижения этого и подстраивается под реалии, в которых вы оказались. Если достаточно раздать задачи и все будет готово вовремя и в срок, то и отлично. Но обычно вам нужно все распланировать, проконтролировать итоговый результат (не руками, мы уже выяснили, что всего знать нельзя, но через тестирование и опытную эксплуатацию), организовать работу с багами и т.д. В какой-то момент вам может стать скучно, когда вы все наладите и делегируете, но обычно жизнь подбрасывает кучу изменений и нештатных ситуаций.
В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.
Еще статьи по теме задач руководителя, которые уже есть на канале:
Нужны ли руководителю технические знания
Чем занят руководитель
Чем отличается руководитель от разработчика
Задачи тимлида и техлида
Мой путь от разработчика к СТО
Максим Шаламов
#тимлиду #руководителю
В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.
Это вопрос сам по себе не имеет смысла, потому что в нем раскрыто сразу же полное непонимание, чем ты собираешься заниматься, как руководитель, и для чего. В такой постановке вопроса у меня есть предположение, что у руководителя должно быть экспертное знание во всех направлениях и языках, а также DevOps и сопровождении. Сомневаюсь, что эта история про реального человека, поэтому умение все проверить лучше всех - это иллюзия контроля, которая еще и замедляет работу команды. Не надо тешить свое эго тем, что ты везде и всюду умнее, ты формируешь команду и растишь ее, твоя цель, чтобы люди по целевым направлениям знали и умели больше тебя.
Про раздачу задач и вот это все. Ваша задача основная - сделать так, чтобы ваш проект работал хорошо, все выполнялось в срок и предсказуемо. Все остальное крутится вокруг достижения этого и подстраивается под реалии, в которых вы оказались. Если достаточно раздать задачи и все будет готово вовремя и в срок, то и отлично. Но обычно вам нужно все распланировать, проконтролировать итоговый результат (не руками, мы уже выяснили, что всего знать нельзя, но через тестирование и опытную эксплуатацию), организовать работу с багами и т.д. В какой-то момент вам может стать скучно, когда вы все наладите и делегируете, но обычно жизнь подбрасывает кучу изменений и нештатных ситуаций.
В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.
Еще статьи по теме задач руководителя, которые уже есть на канале:
Нужны ли руководителю технические знания
Чем занят руководитель
Чем отличается руководитель от разработчика
Задачи тимлида и техлида
Мой путь от разработчика к СТО
Максим Шаламов
#тимлиду #руководителю
Что делать, если тебя не уважают
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающиеего ваш продукт, это будет вызывать в нем уважение. Вы же свой человек, вы хотите того же, что и он, но делаете это методами, которыми он не владеет. А чтобы он видел, что это реально приносит пользу, опять же нужно учиться правильно преподносить результаты своей работы.
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающие
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Как руководителю заставить подчинённых и коллег себя уважать
Очень частая тема и проблема для начинающих да и вообще всех руководителей это уважение. Нужно чтобы люди уважали, что делать и как быть.
Что такое уважение
Я хочу зайти чисто с практической точки зрения, мне сложно сказать уважают люди меня или кого-то, вопрос в том, делают они то, что вам нужно или нет, контролируете ли вы их действия или нет. Потому что именно это важно на работе, вы можете уважать или даже любить кого-то, но не слушаться его. Будучи руководителем лучше меньше задумываться о том, кто, что и почему думает о вас, всем вы угодить точно не сможете. Поэтому, скорее всего, под уважением вы имеете ввиду восприятие вас, как человека, к которому будут прислушиваться, за кем будут идти, который будет контролировать процесс. Не берусь выставлять себя экспертом, но определенные вещи точно могу подсказать.
Внешность
Внешний вид. Да я знаю, что многих начнет трясти с этого, самовыражение и все такое. Дак вот, есть места, где ваш внешний вид может быть уместен или нет. И важно какое впечатление вы ожидаете произвести. Может вы и имеете право надеть клоунский костюм на работу (дресс кода почти ни у кого нет), но воспринимать серьезно вас будут немногие (если вы уникум харизмы, то вам точно все мои советы не интересны, вы хоть голый вывезете, но много ли таких людей?). Поэтому всегда думайте над тем, где и с кем вы будете взаимодействовать и как ожидается там быть одетым. Если вы хотите одеться как-то по-другому, то не ради самовыражения, а преследуя какие-то цели, например, показать, что отличаетесь или что вы из другой группы (если вы знаете что и зачем делаете, то бога ради). Есть некоторые ребята, которые ходят в очень мятых и заношенных вещах, думайте, что хотите, но они вызывают больше отторжения и вопросов у людей, которых не знают или которые их знают мало. Если вопрос того, как вас воспринимают, вам интересен, то используйте уместную и опрятную одежду.
Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.
Последовательность
Последовательность / своя позиция. Уважение вызывают люди, у которых есть своя понятная позиция, которую они последовательно отстаивают. Если вы все время прыгаете с идеи на идею, с подхода на подход, то будете восприниматься очень поверхностным и мало знающим. Взгляд на работу и то, как правильно ее делать, должны быть именно ваши и из вашего опыта.
Опыт
Опыт и готовность помочь. Очень укрепляют ваши позиции знания, опыт и, главное, готовность ими поделиться с другими. И ничто так не подрывает авторитет, как постоянно всплывающие подтверждения вашей некомпетентности по вашей прямой должности. Людей действительно знающих и готовых помогать мало и люди к таким тянуться.
Вообще не бойтесь запрашивать о себе и своей работе обратную связь, слушайте внимательно людей. Да, многие в лицо всего не выскажут, но скажут достаточно для того, кто хочет услышать. Неплохой способ внимательно посмотреть на себя в зеркало, посмотреть, как вы говорите и представить, что вы со стороны смотрите на такого человека, общее впечатление вы сможете составить. Я прошелся по самым верхам и тому, с чем можно быстро поработать. Книг по лидерству и развитию коммуникабельных навыков довольно много, выбирайте под себя. Если вам чего-то не хватает, но хочется, то вы сможете усилить свои слабые стороны.
Максим Шаламов
#тимлиду #руководителю
Очень частая тема и проблема для начинающих да и вообще всех руководителей это уважение. Нужно чтобы люди уважали, что делать и как быть.
Что такое уважение
Я хочу зайти чисто с практической точки зрения, мне сложно сказать уважают люди меня или кого-то, вопрос в том, делают они то, что вам нужно или нет, контролируете ли вы их действия или нет. Потому что именно это важно на работе, вы можете уважать или даже любить кого-то, но не слушаться его. Будучи руководителем лучше меньше задумываться о том, кто, что и почему думает о вас, всем вы угодить точно не сможете. Поэтому, скорее всего, под уважением вы имеете ввиду восприятие вас, как человека, к которому будут прислушиваться, за кем будут идти, который будет контролировать процесс. Не берусь выставлять себя экспертом, но определенные вещи точно могу подсказать.
Внешность
Внешний вид. Да я знаю, что многих начнет трясти с этого, самовыражение и все такое. Дак вот, есть места, где ваш внешний вид может быть уместен или нет. И важно какое впечатление вы ожидаете произвести. Может вы и имеете право надеть клоунский костюм на работу (дресс кода почти ни у кого нет), но воспринимать серьезно вас будут немногие (если вы уникум харизмы, то вам точно все мои советы не интересны, вы хоть голый вывезете, но много ли таких людей?). Поэтому всегда думайте над тем, где и с кем вы будете взаимодействовать и как ожидается там быть одетым. Если вы хотите одеться как-то по-другому, то не ради самовыражения, а преследуя какие-то цели, например, показать, что отличаетесь или что вы из другой группы (если вы знаете что и зачем делаете, то бога ради). Есть некоторые ребята, которые ходят в очень мятых и заношенных вещах, думайте, что хотите, но они вызывают больше отторжения и вопросов у людей, которых не знают или которые их знают мало. Если вопрос того, как вас воспринимают, вам интересен, то используйте уместную и опрятную одежду.
Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.
Последовательность
Последовательность / своя позиция. Уважение вызывают люди, у которых есть своя понятная позиция, которую они последовательно отстаивают. Если вы все время прыгаете с идеи на идею, с подхода на подход, то будете восприниматься очень поверхностным и мало знающим. Взгляд на работу и то, как правильно ее делать, должны быть именно ваши и из вашего опыта.
Опыт
Опыт и готовность помочь. Очень укрепляют ваши позиции знания, опыт и, главное, готовность ими поделиться с другими. И ничто так не подрывает авторитет, как постоянно всплывающие подтверждения вашей некомпетентности по вашей прямой должности. Людей действительно знающих и готовых помогать мало и люди к таким тянуться.
Вообще не бойтесь запрашивать о себе и своей работе обратную связь, слушайте внимательно людей. Да, многие в лицо всего не выскажут, но скажут достаточно для того, кто хочет услышать. Неплохой способ внимательно посмотреть на себя в зеркало, посмотреть, как вы говорите и представить, что вы со стороны смотрите на такого человека, общее впечатление вы сможете составить. Я прошелся по самым верхам и тому, с чем можно быстро поработать. Книг по лидерству и развитию коммуникабельных навыков довольно много, выбирайте под себя. Если вам чего-то не хватает, но хочется, то вы сможете усилить свои слабые стороны.
Максим Шаламов
#тимлиду #руководителю
Говнокод или ступень роста
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику
Стоит ли рассматривать рост в руководителя команды, как обязательный этап
Вопрос об обязательности становится руководителем команды задается очень часто. Многие считают, что это естественный путь развития инженера.
Мое мнение, что этот этап не просто не обязателен, но и вообще не нужен большинству людей. Глобально, вы делаете шаг к смежной, но уже другой профессии и тут все зависит от того, нравится вам это или нет.
Давайте углубимся в детали. Зачем вам может захотеться идти в руководители:
- власть;
- уважение;
- деньги;
- возраст.
Наверное есть что-то еще, но возьму то, что слышу наиболее часто.
Власть
Власть. Сама по себе позиция руководителя команды не открывает каких-то невероятных просторов, чтобы развернуться. Во многих компаниях эта позиция не выделена в отдельную должность, а скорее идет как неформальная. И пусть это первая управляющая ступень, не все будут готовы признать ваш авторитет и лидерство. Вам нужно будет себя правильно поставить и постоянно поддерживать свою репутацию. Многие владельцы продукта в начале пытаются работать с позиции силы с лидами и командой, опытные или конфликтные сотрудники будут пытаться оспаривать ваше лидерство в спорных ситуациях, руководство техническое и бизнесовое начнет обращать на вас внимание и периодически звать на разборы проблем, где вам тоже нужно будет учиться ставить себя правильно. В этом нет чего-то невыполнимого, но большинству это все не нужно. И даже получив эту позицию, они будут бегать от проблем и конфликтов. В итоге ни власти, ни результатов.
Уважение
Уважение. Мы уже писали про уважение и само оно не появляется. Ваша должность сама по себе тут не поможет. Уважение придется заслуживать и как руководителю это сделать будет сложнее, чем будучи рядовым участником команды.
Деньги
Деньги. Опять же, поскольку позиция во многих компаниях не выделена, вы будете получать не особо больше опытных ребят из команды (а иногда и меньше). Но вот в вашей работе добавится много новых активностей, часть из которых не очень приятная. Конечно, чем дальше ты пройдешь (говоря о крупных компаниях или больше проявишь себя в мелких), тем выше будут и зарплаты, но это история про будущее, до которого не все дойдут. Поэтому я бы тоже сходу не питал иллюзий.
Возраст
Возраст. Самое смешное из того что я слышал, что уже годы и пора бы в руководители. Не пора бы. Возраст вообще на это никак не влияет + позиции руководящие, на мой взгляд, требуют много энергии, и, если вы ее не чувствуете, то вам сюда не надо.
Что еще
Что еще нужно учитывать:
- многие компании сейчас делают ветки для инженеров, где можно расти, как технический специалист. техлид, архитектор и т.д. Вы будете заниматься и тем, что вам нравится, и получать больше ответственности и денег.
- нет ничего плохого заниматься тем, что вам нравится. Не надо мучить себя ради эфемерных фантазий о том, как там оно. Делайте хорошо свою работу, получайте удовольствие, тем более, что оплачивается это более, чем достойно.
- если вы чувствуете что исчерпали свою нишу, но руководить не ваше, не мучайте себя, попробуйте смежные направления или совсем новые.
Резюмируя, чтобы переходить в руководители команды и управление, вам оно должно нравиться и вы должны видеть свое развитие в этом направлении. Не мучайте себя чужими стереотипами и занимайтесь тем, что вам нравится.
А если все таки поняли, что управлять командой - это ваше, то советую начать с моего учебника для руководителей команд. Найдете там всю нужную для начала информацию, начинаю с того, как получить эту позицию.
Максим Шаламов
#разработчику
Вопрос об обязательности становится руководителем команды задается очень часто. Многие считают, что это естественный путь развития инженера.
Мое мнение, что этот этап не просто не обязателен, но и вообще не нужен большинству людей. Глобально, вы делаете шаг к смежной, но уже другой профессии и тут все зависит от того, нравится вам это или нет.
Давайте углубимся в детали. Зачем вам может захотеться идти в руководители:
- власть;
- уважение;
- деньги;
- возраст.
Наверное есть что-то еще, но возьму то, что слышу наиболее часто.
Власть
Власть. Сама по себе позиция руководителя команды не открывает каких-то невероятных просторов, чтобы развернуться. Во многих компаниях эта позиция не выделена в отдельную должность, а скорее идет как неформальная. И пусть это первая управляющая ступень, не все будут готовы признать ваш авторитет и лидерство. Вам нужно будет себя правильно поставить и постоянно поддерживать свою репутацию. Многие владельцы продукта в начале пытаются работать с позиции силы с лидами и командой, опытные или конфликтные сотрудники будут пытаться оспаривать ваше лидерство в спорных ситуациях, руководство техническое и бизнесовое начнет обращать на вас внимание и периодически звать на разборы проблем, где вам тоже нужно будет учиться ставить себя правильно. В этом нет чего-то невыполнимого, но большинству это все не нужно. И даже получив эту позицию, они будут бегать от проблем и конфликтов. В итоге ни власти, ни результатов.
Уважение
Уважение. Мы уже писали про уважение и само оно не появляется. Ваша должность сама по себе тут не поможет. Уважение придется заслуживать и как руководителю это сделать будет сложнее, чем будучи рядовым участником команды.
Деньги
Деньги. Опять же, поскольку позиция во многих компаниях не выделена, вы будете получать не особо больше опытных ребят из команды (а иногда и меньше). Но вот в вашей работе добавится много новых активностей, часть из которых не очень приятная. Конечно, чем дальше ты пройдешь (говоря о крупных компаниях или больше проявишь себя в мелких), тем выше будут и зарплаты, но это история про будущее, до которого не все дойдут. Поэтому я бы тоже сходу не питал иллюзий.
Возраст
Возраст. Самое смешное из того что я слышал, что уже годы и пора бы в руководители. Не пора бы. Возраст вообще на это никак не влияет + позиции руководящие, на мой взгляд, требуют много энергии, и, если вы ее не чувствуете, то вам сюда не надо.
Что еще
Что еще нужно учитывать:
- многие компании сейчас делают ветки для инженеров, где можно расти, как технический специалист. техлид, архитектор и т.д. Вы будете заниматься и тем, что вам нравится, и получать больше ответственности и денег.
- нет ничего плохого заниматься тем, что вам нравится. Не надо мучить себя ради эфемерных фантазий о том, как там оно. Делайте хорошо свою работу, получайте удовольствие, тем более, что оплачивается это более, чем достойно.
- если вы чувствуете что исчерпали свою нишу, но руководить не ваше, не мучайте себя, попробуйте смежные направления или совсем новые.
Резюмируя, чтобы переходить в руководители команды и управление, вам оно должно нравиться и вы должны видеть свое развитие в этом направлении. Не мучайте себя чужими стереотипами и занимайтесь тем, что вам нравится.
А если все таки поняли, что управлять командой - это ваше, то советую начать с моего учебника для руководителей команд. Найдете там всю нужную для начала информацию, начинаю с того, как получить эту позицию.
Максим Шаламов
#разработчику
Как все не просрать и оставаться хорошим разработчиком
Вот приходит на собеседование разработчик с 15-летним опытом, думаешь "ну все, сейчас он и меня научит, как делать надо!". А начинаешь спрашивать и он еле еле наскребает на слабого джуна. При этом сам весь вялый, апатичный, без энтузиазма, просто отбывающий свою текущую работу. Сидишь и думаешь, ну вот как ты, бедолага, такой получился? Давайте срочно разбираться, что можно сделать, чтобы с возрастом становиться крутым и опытным, а не бледным и вялым.
Не сидите в тухлом месте
Частая общая черта у вялых ребят это очень длительная работа на одном месте. Это не плохо само по себе, если вы нашли проект, который вас драйвит, дает интересные задачи и помогает развиваться. Но такое бывает очень и очень редко. Чаще всего это болото, в котором нужно делать однотипные задачи, без особой ответственности и вызовов. Оно может показаться комфортным и этот комфорт убьет в вас хорошего разработчика. Даже если вы к чему-то раньше стремились и чем-то интересовались, такое место высосет из вас жизнь. Но все однажды меняется, и болото иногда высыхает, тогда вы оказываетесь на рынке бесполезным и никому не нужным. Если вы попали в такое место, бегите оттуда как можно скорее.
Не бегайте от вызовов
У большинства задач есть несколько способов решения. Выбор нужного зависит от очень многих факторов, но никогда основным фактором не должна быть сложность выполнения лично для вас. Не ищите легких путей, если этого требует задача, берите на себя вызов и делайте то, что кажется вам сложным. Тоже самое при поиске работы, если вы чувствуете, что в компании вам может быть тяжело, нужно будет подтянуть свои знания, работать усерднее, не бойтесь браться за нее. Именно на противоположной стороне от болота вас и ждет максимальный рост.
Работайте над качеством кода
При ежедневной работе очень легко начать писать код на автомате и перестать замечать возможности сделать его лучше, постепенно скатываясь в говнокод. В нашем мини-курсе по борьбе с рутиной есть целый раздел про правильное отношение к написанию кода и как его в себе развить. Там мы разбираем 11 самых важных вопросов, которые вы должны себе задавать при выполнении любой задачи, чтобы не стать разработчиком-овощем. Повторяться не будем, доступ стоит 350р.
Берите на себя ответственность
Если при любой проблеме вы бежите к руководителю или владельцу продукта, не пытаясь ничего решить самостоятельно, это не только понижает вашу ценность, как разработчика, но и лишает вас возможности развиваться, делая вялым и безынициативным. Прежде чем просить у кого-то помощи, пробуйте разобраться с проблемой самостоятельно. Главное держитесь в рамках своих полномочий. Как решать разные проблемы с позиции разработчика, мы тоже разбирали в мини-курсе. Там есть подробный план действий на любой случай.
Будьте увлеченными
Ну и самое главное, что вам необходимо, чтобы оставаться на плаву - интерес к собственной работе. Желание узнавать больше, открывать для себя новые подходы, новые нюансы уже знакомых решений, и так далее и тому подобное. Интересуйтесь индустрией в целом и поддерживайте собственный интерес к работе, тогда вы никогда не устареете.
Александра Шаламова
#разработчику
Вот приходит на собеседование разработчик с 15-летним опытом, думаешь "ну все, сейчас он и меня научит, как делать надо!". А начинаешь спрашивать и он еле еле наскребает на слабого джуна. При этом сам весь вялый, апатичный, без энтузиазма, просто отбывающий свою текущую работу. Сидишь и думаешь, ну вот как ты, бедолага, такой получился? Давайте срочно разбираться, что можно сделать, чтобы с возрастом становиться крутым и опытным, а не бледным и вялым.
Не сидите в тухлом месте
Частая общая черта у вялых ребят это очень длительная работа на одном месте. Это не плохо само по себе, если вы нашли проект, который вас драйвит, дает интересные задачи и помогает развиваться. Но такое бывает очень и очень редко. Чаще всего это болото, в котором нужно делать однотипные задачи, без особой ответственности и вызовов. Оно может показаться комфортным и этот комфорт убьет в вас хорошего разработчика. Даже если вы к чему-то раньше стремились и чем-то интересовались, такое место высосет из вас жизнь. Но все однажды меняется, и болото иногда высыхает, тогда вы оказываетесь на рынке бесполезным и никому не нужным. Если вы попали в такое место, бегите оттуда как можно скорее.
Не бегайте от вызовов
У большинства задач есть несколько способов решения. Выбор нужного зависит от очень многих факторов, но никогда основным фактором не должна быть сложность выполнения лично для вас. Не ищите легких путей, если этого требует задача, берите на себя вызов и делайте то, что кажется вам сложным. Тоже самое при поиске работы, если вы чувствуете, что в компании вам может быть тяжело, нужно будет подтянуть свои знания, работать усерднее, не бойтесь браться за нее. Именно на противоположной стороне от болота вас и ждет максимальный рост.
Работайте над качеством кода
При ежедневной работе очень легко начать писать код на автомате и перестать замечать возможности сделать его лучше, постепенно скатываясь в говнокод. В нашем мини-курсе по борьбе с рутиной есть целый раздел про правильное отношение к написанию кода и как его в себе развить. Там мы разбираем 11 самых важных вопросов, которые вы должны себе задавать при выполнении любой задачи, чтобы не стать разработчиком-овощем. Повторяться не будем, доступ стоит 350р.
Берите на себя ответственность
Если при любой проблеме вы бежите к руководителю или владельцу продукта, не пытаясь ничего решить самостоятельно, это не только понижает вашу ценность, как разработчика, но и лишает вас возможности развиваться, делая вялым и безынициативным. Прежде чем просить у кого-то помощи, пробуйте разобраться с проблемой самостоятельно. Главное держитесь в рамках своих полномочий. Как решать разные проблемы с позиции разработчика, мы тоже разбирали в мини-курсе. Там есть подробный план действий на любой случай.
Будьте увлеченными
Ну и самое главное, что вам необходимо, чтобы оставаться на плаву - интерес к собственной работе. Желание узнавать больше, открывать для себя новые подходы, новые нюансы уже знакомых решений, и так далее и тому подобное. Интересуйтесь индустрией в целом и поддерживайте собственный интерес к работе, тогда вы никогда не устареете.
Александра Шаламова
#разработчику
Ответственность
Так случилось, что зашел у меня на днях разговор об ответственности и оказалось, что есть много людей, которые вообще не понимают, что это такое и как оно работает. Давайте сначала поговорим о термине в целом, а потом о его влиянии внутри работы.
Определение
Ответственность это способность человека отвечать за себя и свои собственные действия. То есть вы что-то сделали и сами же справляетесь с последствиями этих действий. Еще можно нести ответственность за что-то кроме себя, на пример, за какое-то дело, вещь или животное. В таком случае ваши действия будут зависеть от того, за что вы отвечаете. На пример, вы купили домой растение, теперь вы за него отвечаете. Вы не позволяете себе уехать надолго, не найдя того, кто будет его поливать. Ваши действия теперь зависят от потребностей вашего растения. Вы взяли за него ответственность.
Можно ли нести ответственность за человека? За взрослого, дееспособного человека нести ответственность невозможно. Каждый взрослый гражданин отвечает за себя и свои действия самостоятельно. Нести ответственность можно только за детей. На пример, если ваша жена поругалась с соседкой и врезала ей, то она будет сама отвечать за эти действия. Вас это несомненно тоже заденет, но вы не будете нести прямую ответственность за это. А вот если ваш двухлетний ребенок кинул камень в соседскую машину и оставил вмятину, то это уже полностью ваша проблема.
Передача ответственности
Можно ли как-то передавать ответственность? Например, вы можете платить другим людям за какие-то услуги, тогда они будут отвечать за свои задачи по этим услугам перед вами. Но полностью вас это от ответственности не избавит. На пример, я вызываю мастера заменить трубу, он отвечает за результат своей работы передо мной. Но если трубу после его работы прорвет, то я все равно буду отвечать перед соседями, которых она залила. И как ни крути, мастера я к этой ответственности смогу привлечь только косвенно, полностью скинуть на него это не получится. То есть обменять деньги на полную ответственность нельзя.
Тоже самое происходит на работе. Владелец компании нанимает людей и делегирует им часть ответственности, они отвечают перед ним. Если фирма разорится, это все равно будет его проблема. Но он уже может спрашивать со своих людей за их зоны ответственности, потому что у них есть договор обмена денег на работу. По сути владелец несет ответственность за выбор нужных людей и их организацию, если он сделает это плохо, то ему это аукнется и придется разбираться с последствиями. Также он отвечает за выполнение своей части договора перед сотрудниками, зарплату, условия труда и так далее.
В случае с подчиненными, вы также отвечаете за выбор людей и организацию их работы. Если подчиненный полностью провалил проект, уехав на жаркие острова, вы не отвечаете за его действия напрямую, уволят та все равно его, но отвечаете за то, что выбрали его и не проследили вовремя за выполнением задачи. Ну и разгребать это все конечно тоже вам - вы боретесь с последствиями. Поэтому в интересах руководителя найти способ заставить своих людей работать, где-то подбодрить, где-то поругать, в зависимости от ситуации. Он отвечает за конечный результат своей работы.
Ответственность за задачи
Если вам выдали задачу, или вы взяли на себя задачу, то вы становитесь за нее ответственным. Если она не будет сделана в срок, то вы и будете за это отвечать. А что, если, например, вы все сделали вовремя и правильно, а потом сервер упал в последний день и вы не смогли задачу выкатить? Исходим из определения: вы не можете отвечать за действия других людей, которые там все уронили и вовремя не подняли. Но вы отвечаете за задачу, поэтому вы должны выяснить все детали, знать что и почему произошло, чтобы мочь об этом отчитаться. Также вы должны постараться довести задачу до конца альтернативными способами, если это возможно. Это в ваших интересах, потому что вас спросят, почему все пошло не по плану, и вы должны иметь четкий ответ на этот вопрос.
Александра Шаламова
#советы
Так случилось, что зашел у меня на днях разговор об ответственности и оказалось, что есть много людей, которые вообще не понимают, что это такое и как оно работает. Давайте сначала поговорим о термине в целом, а потом о его влиянии внутри работы.
Определение
Ответственность это способность человека отвечать за себя и свои собственные действия. То есть вы что-то сделали и сами же справляетесь с последствиями этих действий. Еще можно нести ответственность за что-то кроме себя, на пример, за какое-то дело, вещь или животное. В таком случае ваши действия будут зависеть от того, за что вы отвечаете. На пример, вы купили домой растение, теперь вы за него отвечаете. Вы не позволяете себе уехать надолго, не найдя того, кто будет его поливать. Ваши действия теперь зависят от потребностей вашего растения. Вы взяли за него ответственность.
Можно ли нести ответственность за человека? За взрослого, дееспособного человека нести ответственность невозможно. Каждый взрослый гражданин отвечает за себя и свои действия самостоятельно. Нести ответственность можно только за детей. На пример, если ваша жена поругалась с соседкой и врезала ей, то она будет сама отвечать за эти действия. Вас это несомненно тоже заденет, но вы не будете нести прямую ответственность за это. А вот если ваш двухлетний ребенок кинул камень в соседскую машину и оставил вмятину, то это уже полностью ваша проблема.
Передача ответственности
Можно ли как-то передавать ответственность? Например, вы можете платить другим людям за какие-то услуги, тогда они будут отвечать за свои задачи по этим услугам перед вами. Но полностью вас это от ответственности не избавит. На пример, я вызываю мастера заменить трубу, он отвечает за результат своей работы передо мной. Но если трубу после его работы прорвет, то я все равно буду отвечать перед соседями, которых она залила. И как ни крути, мастера я к этой ответственности смогу привлечь только косвенно, полностью скинуть на него это не получится. То есть обменять деньги на полную ответственность нельзя.
Тоже самое происходит на работе. Владелец компании нанимает людей и делегирует им часть ответственности, они отвечают перед ним. Если фирма разорится, это все равно будет его проблема. Но он уже может спрашивать со своих людей за их зоны ответственности, потому что у них есть договор обмена денег на работу. По сути владелец несет ответственность за выбор нужных людей и их организацию, если он сделает это плохо, то ему это аукнется и придется разбираться с последствиями. Также он отвечает за выполнение своей части договора перед сотрудниками, зарплату, условия труда и так далее.
В случае с подчиненными, вы также отвечаете за выбор людей и организацию их работы. Если подчиненный полностью провалил проект, уехав на жаркие острова, вы не отвечаете за его действия напрямую, уволят та все равно его, но отвечаете за то, что выбрали его и не проследили вовремя за выполнением задачи. Ну и разгребать это все конечно тоже вам - вы боретесь с последствиями. Поэтому в интересах руководителя найти способ заставить своих людей работать, где-то подбодрить, где-то поругать, в зависимости от ситуации. Он отвечает за конечный результат своей работы.
Ответственность за задачи
Если вам выдали задачу, или вы взяли на себя задачу, то вы становитесь за нее ответственным. Если она не будет сделана в срок, то вы и будете за это отвечать. А что, если, например, вы все сделали вовремя и правильно, а потом сервер упал в последний день и вы не смогли задачу выкатить? Исходим из определения: вы не можете отвечать за действия других людей, которые там все уронили и вовремя не подняли. Но вы отвечаете за задачу, поэтому вы должны выяснить все детали, знать что и почему произошло, чтобы мочь об этом отчитаться. Также вы должны постараться довести задачу до конца альтернативными способами, если это возможно. Это в ваших интересах, потому что вас спросят, почему все пошло не по плану, и вы должны иметь четкий ответ на этот вопрос.
Александра Шаламова
#советы
Как я помогаю подчиненным расти. Часть 1: период обучения.
Меня часто спрашивают, как я обеспечиваю рост людей, когда работаю с ними напрямую. Напрямую я сейчас работаю в основном с руководителями команд и направлений, поэтому писать буду о них. Но общие принципы я использую и для подчиненных не руководителей. В целом, я стараюсь выстроить всю работу так, чтобы люди всегда имели возможность расти. Поэтому расскажу, как я веду человека от самого момента найма в мою команду.
Начало работы
Первое, что я делаю, это даю вводные о себе и о том, чего жду от человека. Честно предупреждаю, что со мной напрямую работать сложно, я очень требовательный и прямой человек. Не смотря на то, что я мог бы разлить воды хоть на час, предпочитаю внутри своих отделов общаться по существу. Ожидаю прямую и честную коммуникацию, лучше так, чем вранье, которое все равно всплывет и мы скорее всего попрощаемся.
Следующим шагом, я проговариваю свое видение позиции, что нужно делать и что не нужно. Обязательно проговариваю моменты, где я не готов делегировать принятие решений и ожидаю согласование со мной. После чего обязательно слушаю мнение человека и мы можем скорректировать некоторые моменты, или как минимум я объясняю свою позицию.
Дальше мы обсуждаем цели на выбранный отрезок времени. Период обычно длительностью в квартал, с обязательным пояснением, какой результат должен быть достигнут и как будем это проверять. Тут ожидается активное участие человека, чтобы он сам подумал и оценил реалистичность и мы смогли внести корректировки, где это возможно.
С теми, с кем я работаю напрямую, я синхронизируюсь не реже раза в неделю, если человек только начинает, или его нужно подтягивать, то каждый день. Формат обсуждений следующий:
- Что сделано? Кратко человек говорит о проделанной работе с прошлого синка.
- Как мы идем по целям? Смотрим на наши цели и выделенные промежуточные точки. Определяем попадаем ли мы или есть проблемы.
- Обсуждение проблем. От проблем с достижением целей, до в целом любых проблем, которые мешают эффективно работать.
Исходя из моего понимания руководителя, как того, кто решает возникающие проблемы, я всегда готов помочь и подключиться. Но с теми, кого я подтягиваю или учу, я первое время хожу на большинство встреч и помогаю с текучкой. Мне важно показать человеку, чего я ожидаю, и чтобы он получил основное представление о том, как и что работает.
На этом с этапом обучения все. В следующем посте расскажу, как я работаю с человеком дальше.
Максим Шаламов
#руководителю #советы
Меня часто спрашивают, как я обеспечиваю рост людей, когда работаю с ними напрямую. Напрямую я сейчас работаю в основном с руководителями команд и направлений, поэтому писать буду о них. Но общие принципы я использую и для подчиненных не руководителей. В целом, я стараюсь выстроить всю работу так, чтобы люди всегда имели возможность расти. Поэтому расскажу, как я веду человека от самого момента найма в мою команду.
Начало работы
Первое, что я делаю, это даю вводные о себе и о том, чего жду от человека. Честно предупреждаю, что со мной напрямую работать сложно, я очень требовательный и прямой человек. Не смотря на то, что я мог бы разлить воды хоть на час, предпочитаю внутри своих отделов общаться по существу. Ожидаю прямую и честную коммуникацию, лучше так, чем вранье, которое все равно всплывет и мы скорее всего попрощаемся.
Следующим шагом, я проговариваю свое видение позиции, что нужно делать и что не нужно. Обязательно проговариваю моменты, где я не готов делегировать принятие решений и ожидаю согласование со мной. После чего обязательно слушаю мнение человека и мы можем скорректировать некоторые моменты, или как минимум я объясняю свою позицию.
Дальше мы обсуждаем цели на выбранный отрезок времени. Период обычно длительностью в квартал, с обязательным пояснением, какой результат должен быть достигнут и как будем это проверять. Тут ожидается активное участие человека, чтобы он сам подумал и оценил реалистичность и мы смогли внести корректировки, где это возможно.
С теми, с кем я работаю напрямую, я синхронизируюсь не реже раза в неделю, если человек только начинает, или его нужно подтягивать, то каждый день. Формат обсуждений следующий:
- Что сделано? Кратко человек говорит о проделанной работе с прошлого синка.
- Как мы идем по целям? Смотрим на наши цели и выделенные промежуточные точки. Определяем попадаем ли мы или есть проблемы.
- Обсуждение проблем. От проблем с достижением целей, до в целом любых проблем, которые мешают эффективно работать.
Исходя из моего понимания руководителя, как того, кто решает возникающие проблемы, я всегда готов помочь и подключиться. Но с теми, кого я подтягиваю или учу, я первое время хожу на большинство встреч и помогаю с текучкой. Мне важно показать человеку, чего я ожидаю, и чтобы он получил основное представление о том, как и что работает.
На этом с этапом обучения все. В следующем посте расскажу, как я работаю с человеком дальше.
Максим Шаламов
#руководителю #советы
Как я помогаю подчиненным расти. Часть 2: после обучения.
Итак, дав вводные и проведя обучение, что делать дальше? А дальше я оставляю наши синки, но выключаюсь из работы человека, давая ему возможность самому работать и проявлять себя. При этом я отслеживаю:
- Самостоятельность человека. Это очень важно для руководителя. Способен ли человек самостоятельно выполнять свою работу, решать в том числе и нестандартные вопросы в рамках своей ответственности.
- Своевременная эскалация(подсвечивание) проблем. Не все проблемы можно решить самому и не везде можно самому принимать решение. Человек должен знать момент, когда нужно подключать руководство и не должен бояться просить помощи. Боязнь просить помощи, что у коллег, что у руководства, это вообще частая проблема и с ней нужно бороться, делать все самому глупо и не эффективно. Что тут еще важно, это то, что я вовремя должен знать о всех значимых проблемах проекта, чтобы не получать неприятных сюрпризов.
- Закрытие целей. Обозначенные цели должны быть достигнуты вовремя, в требуемом качестве. Либо мы своевременно обсуждаем причины переноса, но по очень веским причинам.
- Умение аргументированно отстаивать свою позицию и свое мнение. У меня уже накоплен большой опыт и я обычно имею свое мнение на решение задач и сроков по ним. При этом я ожидаю, что, если я озвучиваю позицию и с ней не согласны, то я получу аргументированные возражения. Получив четкую раскладку по пути решения и срокам, и почему мой вариант не лучший, я приму предложенный вариант. И мы будем вместе думать устроит нас это решение по срокам (обычно в них вся проблема) или мы ищем еще какие-то компромиссы.
- Работа с людьми. Работа должна быть выстроена так, чтобы люди внутри команды и вне, как минимум, были готовы работать с этим человеком., Воспринимать адекватно его идеи и предложения. Постоянные неразрешимые конфликты ведут только к провалам и текучке.
Самое простое это отслеживать в конце периода достижение целей, если они адекватно зафиксированы, то споров будет минимально. Если вовремя не были скорректированы ожидания, то это вина человека, а не обстоятельств.
Самостоятельность отслеживается через количество обращений за помощью и их адекватностью. То есть после каждой помощи я проговариваю, что должен был сделать человек и, если он учится и повторно с таким не приходит, то все прекрасно. Проблемой может быть, неумение реагировать на любую новую проблему, но тут надо смотреть на позицию, где-то это может быть допустимо.
Естественно я смотрю на инциденты и проблемы, а главное на то, видел ли их человек заранее и смог ли он о них заранее предупредить и что-то предпринять. Если руководитель не умеет выявлять типовые возможные проблемы, то это приведет к частым срывам сроков и проблемам с качеством. Видеть проблемы мало, надо что-то с этим делать, если человек видел и не делал, это тоже засчитывается в минусы. Независимо от других обстоятельств, сообщил ли человек вовремя о проблеме или нет, тоже является важным фактором.
Из количества несоответствий по указанным пунктам, формируется мое мнение о человеке, его готовности и способности расти. Я ожиданию, что при получении постоянно обратной связи и помощи с новыми проблемами, человек будет уметь самостоятельно закрывать, или вовремя делегировать, 98% своих задач (цифра примерная). Самое долгое время, когда я бился, чтобы получить из человека отдачу - полтора года (успешно). Сейчас я принимаю решение за полгода, стоит ли дальше вкладывать силы и время в человека.
В конце замечу, что если вашим ростом занимаются, то это большой плюс. Нужно понимать, что чем выше ваша позиция, тем меньше времени у вашего наставника, и нужно ценить его время и возможности. Но обучение тоже должно совпадать с вашими планами на развитие. Если вам не интересно направление, в которое вас пытаются растить, то лучше откажитесь, чем тратить свое и чужое время.
Максим Шаламов
#руководителю #советы
Итак, дав вводные и проведя обучение, что делать дальше? А дальше я оставляю наши синки, но выключаюсь из работы человека, давая ему возможность самому работать и проявлять себя. При этом я отслеживаю:
- Самостоятельность человека. Это очень важно для руководителя. Способен ли человек самостоятельно выполнять свою работу, решать в том числе и нестандартные вопросы в рамках своей ответственности.
- Своевременная эскалация(подсвечивание) проблем. Не все проблемы можно решить самому и не везде можно самому принимать решение. Человек должен знать момент, когда нужно подключать руководство и не должен бояться просить помощи. Боязнь просить помощи, что у коллег, что у руководства, это вообще частая проблема и с ней нужно бороться, делать все самому глупо и не эффективно. Что тут еще важно, это то, что я вовремя должен знать о всех значимых проблемах проекта, чтобы не получать неприятных сюрпризов.
- Закрытие целей. Обозначенные цели должны быть достигнуты вовремя, в требуемом качестве. Либо мы своевременно обсуждаем причины переноса, но по очень веским причинам.
- Умение аргументированно отстаивать свою позицию и свое мнение. У меня уже накоплен большой опыт и я обычно имею свое мнение на решение задач и сроков по ним. При этом я ожидаю, что, если я озвучиваю позицию и с ней не согласны, то я получу аргументированные возражения. Получив четкую раскладку по пути решения и срокам, и почему мой вариант не лучший, я приму предложенный вариант. И мы будем вместе думать устроит нас это решение по срокам (обычно в них вся проблема) или мы ищем еще какие-то компромиссы.
- Работа с людьми. Работа должна быть выстроена так, чтобы люди внутри команды и вне, как минимум, были готовы работать с этим человеком., Воспринимать адекватно его идеи и предложения. Постоянные неразрешимые конфликты ведут только к провалам и текучке.
Самое простое это отслеживать в конце периода достижение целей, если они адекватно зафиксированы, то споров будет минимально. Если вовремя не были скорректированы ожидания, то это вина человека, а не обстоятельств.
Самостоятельность отслеживается через количество обращений за помощью и их адекватностью. То есть после каждой помощи я проговариваю, что должен был сделать человек и, если он учится и повторно с таким не приходит, то все прекрасно. Проблемой может быть, неумение реагировать на любую новую проблему, но тут надо смотреть на позицию, где-то это может быть допустимо.
Естественно я смотрю на инциденты и проблемы, а главное на то, видел ли их человек заранее и смог ли он о них заранее предупредить и что-то предпринять. Если руководитель не умеет выявлять типовые возможные проблемы, то это приведет к частым срывам сроков и проблемам с качеством. Видеть проблемы мало, надо что-то с этим делать, если человек видел и не делал, это тоже засчитывается в минусы. Независимо от других обстоятельств, сообщил ли человек вовремя о проблеме или нет, тоже является важным фактором.
Из количества несоответствий по указанным пунктам, формируется мое мнение о человеке, его готовности и способности расти. Я ожиданию, что при получении постоянно обратной связи и помощи с новыми проблемами, человек будет уметь самостоятельно закрывать, или вовремя делегировать, 98% своих задач (цифра примерная). Самое долгое время, когда я бился, чтобы получить из человека отдачу - полтора года (успешно). Сейчас я принимаю решение за полгода, стоит ли дальше вкладывать силы и время в человека.
В конце замечу, что если вашим ростом занимаются, то это большой плюс. Нужно понимать, что чем выше ваша позиция, тем меньше времени у вашего наставника, и нужно ценить его время и возможности. Но обучение тоже должно совпадать с вашими планами на развитие. Если вам не интересно направление, в которое вас пытаются растить, то лучше откажитесь, чем тратить свое и чужое время.
Максим Шаламов
#руководителю #советы
Как создать конфликт в коллективе
Хочу поговорить о довольно распространенном способе внести в коллектив раскол и довести людей до конфликта. Ситуация по моим наблюдениям случается очень часто и поделюсь своей видением, как с этой ситуацией работать.
Итак представим ситуацию, что работаете вы себе и работаете, все бы хорошо, но у вас есть проблемы со смежными командами или отделами. Причем проблемы подтвержденные, серьезные и сильно влияющие на вас и вашу команду (возможно с точки зрения качества, возможно вам приходится постоянно сидеть вечерами из-за их ошибок или нерасторопности). Вы пытаетесь выровняться сами, выносите руководству эту ситуацию, но улучшений не видите. Время идет, проблема не решается. Внятно от руководства деталей вы не получаете, конечно, в какой-то момент, эта ситуация приводит к открытому конфликту.
Ситуация очень неприятная и случается часто. Прежде всего хочу сказать, что понимаю, как такое может случаться помимо нежелания руководства работать или вмешиваться в дела. Есть две возможности:
- сейчас человек/команда перегружены и вы оказались не в фокусе, они разбираются шаг за шагом с проблемами и дойдут до вас. Бывает, но обычно такое быстро выясняется и становится проще понимать проблематику.
- есть причины, не позволяющие жестко решить ситуацию, через увольнение, выговоры и т.д. Человека может быть трудно заменить и с этим не хотят связываться, с ним может уйти много людей, боятся идти на риск и т.п.
У меня тоже бывали и бывают ситуации, когда я не могу расстаться с человеком в моменте. Что же я обычно делаю. Те, кому это доставляет неудобства, обычно понимают причины почему мы не расстаемся с человеком (мы либо работаем над улучшением поведения, либо ищем замену, либо завершаем кусок работы и т.д.). Со своей стороны я стараюсь сгладить проблемы, перераспределяя часть несделанного (периодически на себя, если это организационные вопросы), чтобы минимизировать проблемы и не оставлять людей один на один с проблемой. Мое мнение: ваша основная задача, как руководителя, в этой ситуации не только решить проблему, но и дать людям объяснение вашего поведения, чтобы они не дергались, а могли отслеживать процесс улучшения ситуации. Очень плохо, когда люди остаются с проблемой и не понимают, что делать. Еще хуже, если вы на самом деле решаете проблему, но они не знают об этом, ведь люди могут уйти раньше.
Основной мой посыл - решайте проблемы, делитесь информацией с людьми по процессу решения проблем и всем будет работать проще и приятней.
Максим Шаламов
#руководителю #советы
Хочу поговорить о довольно распространенном способе внести в коллектив раскол и довести людей до конфликта. Ситуация по моим наблюдениям случается очень часто и поделюсь своей видением, как с этой ситуацией работать.
Итак представим ситуацию, что работаете вы себе и работаете, все бы хорошо, но у вас есть проблемы со смежными командами или отделами. Причем проблемы подтвержденные, серьезные и сильно влияющие на вас и вашу команду (возможно с точки зрения качества, возможно вам приходится постоянно сидеть вечерами из-за их ошибок или нерасторопности). Вы пытаетесь выровняться сами, выносите руководству эту ситуацию, но улучшений не видите. Время идет, проблема не решается. Внятно от руководства деталей вы не получаете, конечно, в какой-то момент, эта ситуация приводит к открытому конфликту.
Ситуация очень неприятная и случается часто. Прежде всего хочу сказать, что понимаю, как такое может случаться помимо нежелания руководства работать или вмешиваться в дела. Есть две возможности:
- сейчас человек/команда перегружены и вы оказались не в фокусе, они разбираются шаг за шагом с проблемами и дойдут до вас. Бывает, но обычно такое быстро выясняется и становится проще понимать проблематику.
- есть причины, не позволяющие жестко решить ситуацию, через увольнение, выговоры и т.д. Человека может быть трудно заменить и с этим не хотят связываться, с ним может уйти много людей, боятся идти на риск и т.п.
У меня тоже бывали и бывают ситуации, когда я не могу расстаться с человеком в моменте. Что же я обычно делаю. Те, кому это доставляет неудобства, обычно понимают причины почему мы не расстаемся с человеком (мы либо работаем над улучшением поведения, либо ищем замену, либо завершаем кусок работы и т.д.). Со своей стороны я стараюсь сгладить проблемы, перераспределяя часть несделанного (периодически на себя, если это организационные вопросы), чтобы минимизировать проблемы и не оставлять людей один на один с проблемой. Мое мнение: ваша основная задача, как руководителя, в этой ситуации не только решить проблему, но и дать людям объяснение вашего поведения, чтобы они не дергались, а могли отслеживать процесс улучшения ситуации. Очень плохо, когда люди остаются с проблемой и не понимают, что делать. Еще хуже, если вы на самом деле решаете проблему, но они не знают об этом, ведь люди могут уйти раньше.
Основной мой посыл - решайте проблемы, делитесь информацией с людьми по процессу решения проблем и всем будет работать проще и приятней.
Максим Шаламов
#руководителю #советы
Почему таблички “не беспокоить” не работают и почему это хорошо
Многие начинающие лиды тонут в текучке и особенно их допекает то, что вся команда ходит по каждой мелочи к ним (по крайней мере им так кажется). По их мнению, они пробуют все, чтобы к ним не ходили и даже ставят или вешают таблички “не беспокоить”, но это не работает.
Не работает все по простой и понятной причине - вы не выстроили процесс. А это значит, что люди не знают, что им делать с внештатными ситуациями и как идти по процессу. На самом деле, нужно радоваться, если в такой ситуации к вам идут. По крайней мере вы в курсе проблем и вас считают достойным того, чтобы спросить. Кидаться или обижаться на подчиненных в такой ситуации это верный путь испортить с ними отношения и, возможно, потом получить много неприятных сюрпризов, когда до вас в итоге с проблемой не дойдут.
Начну со списка дел, где советую лично подключаться:
- конфликты в команде
- конфликты с внешними командами
- пересмотр договоренностей по задачам
- общение с руководством
- обсуждение сроков
- обсуждение порядка выполнения задач
- приоритезация работ
Чтобы освободить свое время, вы должны выписать себе обычные причины обращения к вам и начать их устранять. Причин может быть много, но давайте я накидаю несколько с решением, чтобы вам было проще.
1. К вам приходят, чтобы вы провели ревью, потому что вы стоите, как обязательный ревьюер. Наверное самое частое из того, что я видел. На прямом контроле можно оставлять только ключевые задачи, для всего остального выделите в команде людей, чьим навыкам вы доверяете (если нет, то учите или нанимайте). Тут вы сами создаете себе и другим проблему, и все решается очень просто. Не тешьте себя иллюзией контроля, все равно с таким подходом качественно вы не сможете все отслеживать.
2. У малоопытных членов команды часто появляются вопросы по новым и сложным задачам, возможно по старым кускам системы. Кроме вас они не знают к кому идти, поэтому они будут ходить к вам. История решается примерно так же, выделите людей, к которым будут ходить до того, как пойдут к вам. Не завязывайте в себе скрытые знания, если что-то знаете только вы, то нужно передать эти знания еще минимум двум людям.
3. Частая проблема бывает с тем, что люди не понимают, как собирать и выкатывать проект. Документация часто бывает неполной или устаревшей. И снова должны быть источники знаний кроме вас, люди должны знать, что сначала обращаться нужно к ним.
Список можно продолжать и продолжать, но, в целом, большинство начинающих лидов на самом деле получают определенное удовольствие от того, что в них нуждаются. Так своя ценность кажется выше. И это все обычно работает не осознанно, но, по сути, человек сам делает себя необходимым и сам от этого страдает, но не может разорвать порочный круг. Поэтому следите, чтобы вы, по возможности, не были единственным источником знаний по своему проекту и не замыкайте на себе ничего, кроме ключевых вопросов.
Максим Шаламов
#руководителю #советы
Многие начинающие лиды тонут в текучке и особенно их допекает то, что вся команда ходит по каждой мелочи к ним (по крайней мере им так кажется). По их мнению, они пробуют все, чтобы к ним не ходили и даже ставят или вешают таблички “не беспокоить”, но это не работает.
Не работает все по простой и понятной причине - вы не выстроили процесс. А это значит, что люди не знают, что им делать с внештатными ситуациями и как идти по процессу. На самом деле, нужно радоваться, если в такой ситуации к вам идут. По крайней мере вы в курсе проблем и вас считают достойным того, чтобы спросить. Кидаться или обижаться на подчиненных в такой ситуации это верный путь испортить с ними отношения и, возможно, потом получить много неприятных сюрпризов, когда до вас в итоге с проблемой не дойдут.
Начну со списка дел, где советую лично подключаться:
- конфликты в команде
- конфликты с внешними командами
- пересмотр договоренностей по задачам
- общение с руководством
- обсуждение сроков
- обсуждение порядка выполнения задач
- приоритезация работ
Чтобы освободить свое время, вы должны выписать себе обычные причины обращения к вам и начать их устранять. Причин может быть много, но давайте я накидаю несколько с решением, чтобы вам было проще.
1. К вам приходят, чтобы вы провели ревью, потому что вы стоите, как обязательный ревьюер. Наверное самое частое из того, что я видел. На прямом контроле можно оставлять только ключевые задачи, для всего остального выделите в команде людей, чьим навыкам вы доверяете (если нет, то учите или нанимайте). Тут вы сами создаете себе и другим проблему, и все решается очень просто. Не тешьте себя иллюзией контроля, все равно с таким подходом качественно вы не сможете все отслеживать.
2. У малоопытных членов команды часто появляются вопросы по новым и сложным задачам, возможно по старым кускам системы. Кроме вас они не знают к кому идти, поэтому они будут ходить к вам. История решается примерно так же, выделите людей, к которым будут ходить до того, как пойдут к вам. Не завязывайте в себе скрытые знания, если что-то знаете только вы, то нужно передать эти знания еще минимум двум людям.
3. Частая проблема бывает с тем, что люди не понимают, как собирать и выкатывать проект. Документация часто бывает неполной или устаревшей. И снова должны быть источники знаний кроме вас, люди должны знать, что сначала обращаться нужно к ним.
Список можно продолжать и продолжать, но, в целом, большинство начинающих лидов на самом деле получают определенное удовольствие от того, что в них нуждаются. Так своя ценность кажется выше. И это все обычно работает не осознанно, но, по сути, человек сам делает себя необходимым и сам от этого страдает, но не может разорвать порочный круг. Поэтому следите, чтобы вы, по возможности, не были единственным источником знаний по своему проекту и не замыкайте на себе ничего, кроме ключевых вопросов.
Максим Шаламов
#руководителю #советы
Можно ли руководителю дружить с командой
Вопрос о дружбе руководителя с командой очень сложный с любой стороны. Рассмотрим варианты, когда вы дружили и пошел рост, и когда будучи руководителем начали сближаться.
Мой опыт
Начну с личного опыта, я нередко сближался с коллегам, как с товарищами. Очень часто это заканчивалось плохо, но оно того стоило для меня по двум причинам:
- я лучше понял мышление большинства людей
- я нашел так реально близких друзей и соратников, это штучная история, но она того стоила. Люди, которым я доверяю и которые всегда могут прямо высказать свое мнение, каким бы оно ни было.
Сейчас конечно я особо не пытаюсь разрывать дистанцию, которая автоматически образуется в парадигме начальник подчиненный. Мне нравится общаться со своими командами, с кем-то больше с кем-то меньше. Но я понимаю, что и я не могу всего сказать и они выбирают слова и формулировки. Это нормально.
Негативные последствия у дружбы с коллегами
Близкие отношения в работе это большое испытание для человеческих качеств. Я видел, как давние друзья переставали общаться, потому что один пошел в рост быстрее, как зависть подчиненного портила отношения, как чрезмерные ожидания руководителя от своего друга мешали и делу и портили отношения. Мы все головой понимаем, что работа это работа, а личное отдельно. Но по факту, это так не работает. Мы остаемся собой везде, и обиды, ожидания, амбиции, зависть и т.д. остаются с нами.
Много неприятных моментов было и лично у меня. Получал упреки, что мол мало работаю, а на виду, как руководитель я. Некоторых ребят начинал выделять под рост, тратил на них больше времени, а они интерпретировали это, как сигнал, что теперь можно и работать поменьше и требовать я должен с них не как со всех.
Все равно люди, которые тебе нравятся и на которых ты делаешь ставку, формируют у тебя лучшее отношение к себе, по-другому не получится. Однако, у меня таким людям с одной стороны хорошо - повышения и бонусы будут их первыми, но, с другой стороны, и плохо - требования мои намного выше, чем к другим. Кого не пугают трудности, остаются довольны, но кому-то это не подходит.
Тема дружбы на работе сложная, и каждый сам решит для себя, чего больше плюсов или минусов. Помните, что это отличная проверка человеческих качеств и ваших тоже. Если не уверены в себе или людях, и не хотите их терять, то не пробуйте.
Максим Шаламов
#руководителю
Вопрос о дружбе руководителя с командой очень сложный с любой стороны. Рассмотрим варианты, когда вы дружили и пошел рост, и когда будучи руководителем начали сближаться.
Мой опыт
Начну с личного опыта, я нередко сближался с коллегам, как с товарищами. Очень часто это заканчивалось плохо, но оно того стоило для меня по двум причинам:
- я лучше понял мышление большинства людей
- я нашел так реально близких друзей и соратников, это штучная история, но она того стоила. Люди, которым я доверяю и которые всегда могут прямо высказать свое мнение, каким бы оно ни было.
Сейчас конечно я особо не пытаюсь разрывать дистанцию, которая автоматически образуется в парадигме начальник подчиненный. Мне нравится общаться со своими командами, с кем-то больше с кем-то меньше. Но я понимаю, что и я не могу всего сказать и они выбирают слова и формулировки. Это нормально.
Негативные последствия у дружбы с коллегами
Близкие отношения в работе это большое испытание для человеческих качеств. Я видел, как давние друзья переставали общаться, потому что один пошел в рост быстрее, как зависть подчиненного портила отношения, как чрезмерные ожидания руководителя от своего друга мешали и делу и портили отношения. Мы все головой понимаем, что работа это работа, а личное отдельно. Но по факту, это так не работает. Мы остаемся собой везде, и обиды, ожидания, амбиции, зависть и т.д. остаются с нами.
Много неприятных моментов было и лично у меня. Получал упреки, что мол мало работаю, а на виду, как руководитель я. Некоторых ребят начинал выделять под рост, тратил на них больше времени, а они интерпретировали это, как сигнал, что теперь можно и работать поменьше и требовать я должен с них не как со всех.
Все равно люди, которые тебе нравятся и на которых ты делаешь ставку, формируют у тебя лучшее отношение к себе, по-другому не получится. Однако, у меня таким людям с одной стороны хорошо - повышения и бонусы будут их первыми, но, с другой стороны, и плохо - требования мои намного выше, чем к другим. Кого не пугают трудности, остаются довольны, но кому-то это не подходит.
Тема дружбы на работе сложная, и каждый сам решит для себя, чего больше плюсов или минусов. Помните, что это отличная проверка человеческих качеств и ваших тоже. Если не уверены в себе или людях, и не хотите их терять, то не пробуйте.
Максим Шаламов
#руководителю
Можно ли расти просто работая
Хотел очень кратко обсудить тему, которая стала часто прослеживаться. Многие стали считать, что карьерный рост, интересные задачи, повышения и т.д. это полностью задача руководителя. Причем я имею ввиду полностью, руководитель должен понять, кто и что хочет, привести его за ручку к росту, помочь или сделать за человека и потом наградить тем, что человек хочет. Со своей стороны люди не готовы даже заявить о своих желаниях роста или других задач.
Мы все понимаем, что рынок сейчас с большой нуждой к специалистам и работу найти можно. Но обычно те, кто так подходят к вопросу, бегают с работы на работу от одних и тех же проблем. Причем сам процесс работы и переходов им не приносит никакого удовлетворения. Однако, остановиться и попробовать что-то изменить в своем подходе обычно никто не готов.
Со стороны руководителей и нанимающих такие люди тоже вызывают большую настороженность. Их конечно нанимают, но важные и ответственные направления им стараются не доверять. В рост особо не вкладываются, потому что понимают, что человек уйдет при первой же проблеме. Даже если не уйдет, поверить, что такой человек вовлекается в решение проблем на важных для компании направлениях мало кто решится.
В итоге, работу вы найдете, но ведь у многих запросы несколько выше, чем просто работа. В своей работе я постоянно пытаюсь что-то выбить для своих ребят и проектов, какие-то вещи и для своего роста (проекты, возможности и т.д.). В этом нет ничего унизительного, ваши желания кроме вас никто не знает. Интересных задач, приоритетных направлений и т.д. не так много, и желающих больше, чем возможностей. Поэтому, если вы чего-то хотите, то проявляйте активность, идите к этому, пытайтесь получить это, заявляйте о готовности вовлекаться (план, как получить повышение мы уже писали раньше). Не бойтесь, не стесняйтесь и не считайте себя лучше всех, тогда все у вас получится.
Максим Шаламов
#советы
Хотел очень кратко обсудить тему, которая стала часто прослеживаться. Многие стали считать, что карьерный рост, интересные задачи, повышения и т.д. это полностью задача руководителя. Причем я имею ввиду полностью, руководитель должен понять, кто и что хочет, привести его за ручку к росту, помочь или сделать за человека и потом наградить тем, что человек хочет. Со своей стороны люди не готовы даже заявить о своих желаниях роста или других задач.
Мы все понимаем, что рынок сейчас с большой нуждой к специалистам и работу найти можно. Но обычно те, кто так подходят к вопросу, бегают с работы на работу от одних и тех же проблем. Причем сам процесс работы и переходов им не приносит никакого удовлетворения. Однако, остановиться и попробовать что-то изменить в своем подходе обычно никто не готов.
Со стороны руководителей и нанимающих такие люди тоже вызывают большую настороженность. Их конечно нанимают, но важные и ответственные направления им стараются не доверять. В рост особо не вкладываются, потому что понимают, что человек уйдет при первой же проблеме. Даже если не уйдет, поверить, что такой человек вовлекается в решение проблем на важных для компании направлениях мало кто решится.
В итоге, работу вы найдете, но ведь у многих запросы несколько выше, чем просто работа. В своей работе я постоянно пытаюсь что-то выбить для своих ребят и проектов, какие-то вещи и для своего роста (проекты, возможности и т.д.). В этом нет ничего унизительного, ваши желания кроме вас никто не знает. Интересных задач, приоритетных направлений и т.д. не так много, и желающих больше, чем возможностей. Поэтому, если вы чего-то хотите, то проявляйте активность, идите к этому, пытайтесь получить это, заявляйте о готовности вовлекаться (план, как получить повышение мы уже писали раньше). Не бойтесь, не стесняйтесь и не считайте себя лучше всех, тогда все у вас получится.
Максим Шаламов
#советы
Стоит ли лезть в личную жизнь сотрудников, если она мешает им работать
Личная жизнь - очень больная тема для большинства из нас, особенно, когда есть проблемы. Ряд семейных проблем или со здоровьем могут полностью замкнуть человека на себе. Конечно это печально скажется на работе.
Стоит ли лезть в личную жизнь подчиненного, чтобы исправить его работоспособность? Мое мнение такое, вы не врач и не друг, поэтому сильно глубоко в такие вещи лезть неправильно. Ваша задача поговорить с человеком и примерно понять его проблему (скорее всего глубоко в детали вас не пустят). В любом случае, нужно обсудить, как сам человек видит себя в работе, заинтересован ли он в ней. После этого нужно понять, проблема имеет краткосрочный характер или длительный. С краткосрочными проблемами можно отпустить человека в отпуск или снизить требования и ожидания к человеку на время. С долгосрочными проблемами сложнее. Пытаться затягивать можно, если специалист вам очень нужен или вы верите, что потом он наверстает. В любом случае, нужно наметить какие-то задачи на это время и срок, в который вы ожидаете, что человек вернется в строй. Тянуть бесконечно обычно плохая стратегия, потому что задачи будут падать на других ребят и это станет коллективной проблемой.
Если у вас хороший контакт, то вы можете что-то посоветовать из своего опыта, но с личными проблемами люди прислушиваются не всегда или обычно далеко не сразу. В любом случае, вам нужно общаться с человеком, понимать проблему и иметь совместный план по ее преодолению (в рамках работы). Не надо обижаться на человека или совершать резкие не обсужденные изменения.
Максим Шаламов
#руководителю
Личная жизнь - очень больная тема для большинства из нас, особенно, когда есть проблемы. Ряд семейных проблем или со здоровьем могут полностью замкнуть человека на себе. Конечно это печально скажется на работе.
Стоит ли лезть в личную жизнь подчиненного, чтобы исправить его работоспособность? Мое мнение такое, вы не врач и не друг, поэтому сильно глубоко в такие вещи лезть неправильно. Ваша задача поговорить с человеком и примерно понять его проблему (скорее всего глубоко в детали вас не пустят). В любом случае, нужно обсудить, как сам человек видит себя в работе, заинтересован ли он в ней. После этого нужно понять, проблема имеет краткосрочный характер или длительный. С краткосрочными проблемами можно отпустить человека в отпуск или снизить требования и ожидания к человеку на время. С долгосрочными проблемами сложнее. Пытаться затягивать можно, если специалист вам очень нужен или вы верите, что потом он наверстает. В любом случае, нужно наметить какие-то задачи на это время и срок, в который вы ожидаете, что человек вернется в строй. Тянуть бесконечно обычно плохая стратегия, потому что задачи будут падать на других ребят и это станет коллективной проблемой.
Если у вас хороший контакт, то вы можете что-то посоветовать из своего опыта, но с личными проблемами люди прислушиваются не всегда или обычно далеко не сразу. В любом случае, вам нужно общаться с человеком, понимать проблему и иметь совместный план по ее преодолению (в рамках работы). Не надо обижаться на человека или совершать резкие не обсужденные изменения.
Максим Шаламов
#руководителю
Важность похвалы
Я уже давно работаю управленцем и чем выше поднимаюсь, тем больше вижу тенденцию к отсутствию похвалы в работе в принципе. Недавно у нас был тренинг, после которого мой руководитель говорил мне, что хвалить не видят смысла, когда рядом зрелая команда и управленцы, нужно фокусироваться на целях и проблемах, а достижение целей само по себе считается похвальным и правильным.
Не знаю правильно ли это в управлении руководителями, но с начинающими так точно нельзя. Да и с ребятами в команде это не приведет ни к чему хорошему. В роли начинающего я такой подход оценил какое-то время назад, сходив на пробные занятия в стрелковый клуб и на скалодром. Оба похода объединяли крайне вялые инструкторы, которые после каждого упражнения говорили “идем дальше” с каменными лицами. При этом не забывая указывать на ошибки, когда делаешь что-то неправильно. Не смотря на то, что я головой понимаю, как это работает, удовольствие от работы с такими инструкторами было крайне сомнительным. Сменив стрелковый клуб, кстати, и попав на позитивного, вовлекающего инструктора, умеющего подбадривать в процессе, я сходил просто прекрасно, получил кучу позитива и продолжу ходить именно к этим ребятам.
К чему это я все? А к тому, какой бы зрелой ни была ваша команда и собеседник, не забывайте хвалить человека за хорошую работу. Как минимум это будет позитивным подкреплением, что очень важно. Второе, человек поймет, что его работу ценят и видят. Забывая хвалить людей, вы ставите их в очень странное положение, когда нет достаточной обратной связи о их работе. Получается, что человека только все время ругают (потому что проблему нужно обсуждать и решать). Таким подходом вы легко можете демотивировать и человека, и команду. У людей сложится впечатление, что вы придираетесь к ним и не видите их работы, а главное не цените их. Джунам и стажерам вы вообще можете отбить желание заниматься данной профессией, сложив впечатление, что они только ошибаются и ничего не делают правильно.
Никогда не забывайте оценивать заслуги людей. Но и не тратьте похвалу, если человек ее не заслужил. Поставьте себя на место человека и вам будет проще понять его ощущения.
Максим Шаламов
#руководителю
Я уже давно работаю управленцем и чем выше поднимаюсь, тем больше вижу тенденцию к отсутствию похвалы в работе в принципе. Недавно у нас был тренинг, после которого мой руководитель говорил мне, что хвалить не видят смысла, когда рядом зрелая команда и управленцы, нужно фокусироваться на целях и проблемах, а достижение целей само по себе считается похвальным и правильным.
Не знаю правильно ли это в управлении руководителями, но с начинающими так точно нельзя. Да и с ребятами в команде это не приведет ни к чему хорошему. В роли начинающего я такой подход оценил какое-то время назад, сходив на пробные занятия в стрелковый клуб и на скалодром. Оба похода объединяли крайне вялые инструкторы, которые после каждого упражнения говорили “идем дальше” с каменными лицами. При этом не забывая указывать на ошибки, когда делаешь что-то неправильно. Не смотря на то, что я головой понимаю, как это работает, удовольствие от работы с такими инструкторами было крайне сомнительным. Сменив стрелковый клуб, кстати, и попав на позитивного, вовлекающего инструктора, умеющего подбадривать в процессе, я сходил просто прекрасно, получил кучу позитива и продолжу ходить именно к этим ребятам.
К чему это я все? А к тому, какой бы зрелой ни была ваша команда и собеседник, не забывайте хвалить человека за хорошую работу. Как минимум это будет позитивным подкреплением, что очень важно. Второе, человек поймет, что его работу ценят и видят. Забывая хвалить людей, вы ставите их в очень странное положение, когда нет достаточной обратной связи о их работе. Получается, что человека только все время ругают (потому что проблему нужно обсуждать и решать). Таким подходом вы легко можете демотивировать и человека, и команду. У людей сложится впечатление, что вы придираетесь к ним и не видите их работы, а главное не цените их. Джунам и стажерам вы вообще можете отбить желание заниматься данной профессией, сложив впечатление, что они только ошибаются и ничего не делают правильно.
Никогда не забывайте оценивать заслуги людей. Но и не тратьте похвалу, если человек ее не заслужил. Поставьте себя на место человека и вам будет проще понять его ощущения.
Максим Шаламов
#руководителю
Как использовать право вето для мотивации руководителей команд
Часто вижу вопрос, как повысить уверенность и вовлеченность своих сотрудников-руководителей. В нормальной структуре руководителей не должно быть слишком много, поэтому индивидуальный подход будет хорошим решением. Но если говорить о чем-то общем, то, на мой взгляд, очень важно дать человеку право принимать решения.
У меня очень простой подход: руководитель по определению может перекрыть любое решение своего подчиненного. На этом строится возможность выстраивания стратегии сверху и использование опыта (которого у руководителя в идеале должно быть много). И тут тем, кто это слышит в первый раз, начинает казаться, что я буду диктовать им по шагам каждый их рабочий день. На самом деле нет. У меня много работы и помимо этого, более того, я считаю, что человек на своем месте должен справляться с работой, либо покидать ее. Поэтому, если я диктую человеку что делать, то это либо новая ситуация для него или есть обстоятельства диктующие такое решение, либо ему пора задуматься над тем, как хорошо он делает свою работу.
Со своими ребятами я всегда стараюсь четко проговорить все детали, где я жду, что они будут решать проблему сами (сообщив мне результаты), а где они идут за согласованием (и даже тут идеально прийти с вариантами решения). Возможность принимать решения, самому решать проблемы и достигать результата очень мотивирует людей, ориентированных на результат и рост.
Тем, кто себя отлично проявляет, я даю право вето на ряд решений. Например, они могут сказать нет на найме кандидата, его переводе или увольнении, даже если я буду считать, что это стоит сделать. С правом вето надо быть очень аккуратным, это позволяет чувствовать себя максимально уверенно, но надо понимать, что не все ситуации подвластны нам и всегда требуется гибкость. Давайте такое только проверенным ребятам и очерчивайте границы. Тут есть важный момент - нельзя потом просто взять и проигнорировать вето своего сотрудника, вы обесцените это, как мотивацию и подорвете доверие к себе.
В заключении скажу, всегда делегируйте людям положенные им задачи, ищите тех, кто будет справляться, а не пытайтесь все проконтролировать сами. Помните, что в управление надо выдвигать тех, кто готов к ответственности и может давать результат.
Больше об управлении людьми, вы найдете в моем учебнике “Тимлид: базовый уровень”. В нем, помимо разбора всех основных умений руководителя команды, я добавил целую главу про делегирование полномочий.
Максим Шаламов
#руководителю
Часто вижу вопрос, как повысить уверенность и вовлеченность своих сотрудников-руководителей. В нормальной структуре руководителей не должно быть слишком много, поэтому индивидуальный подход будет хорошим решением. Но если говорить о чем-то общем, то, на мой взгляд, очень важно дать человеку право принимать решения.
У меня очень простой подход: руководитель по определению может перекрыть любое решение своего подчиненного. На этом строится возможность выстраивания стратегии сверху и использование опыта (которого у руководителя в идеале должно быть много). И тут тем, кто это слышит в первый раз, начинает казаться, что я буду диктовать им по шагам каждый их рабочий день. На самом деле нет. У меня много работы и помимо этого, более того, я считаю, что человек на своем месте должен справляться с работой, либо покидать ее. Поэтому, если я диктую человеку что делать, то это либо новая ситуация для него или есть обстоятельства диктующие такое решение, либо ему пора задуматься над тем, как хорошо он делает свою работу.
Со своими ребятами я всегда стараюсь четко проговорить все детали, где я жду, что они будут решать проблему сами (сообщив мне результаты), а где они идут за согласованием (и даже тут идеально прийти с вариантами решения). Возможность принимать решения, самому решать проблемы и достигать результата очень мотивирует людей, ориентированных на результат и рост.
Тем, кто себя отлично проявляет, я даю право вето на ряд решений. Например, они могут сказать нет на найме кандидата, его переводе или увольнении, даже если я буду считать, что это стоит сделать. С правом вето надо быть очень аккуратным, это позволяет чувствовать себя максимально уверенно, но надо понимать, что не все ситуации подвластны нам и всегда требуется гибкость. Давайте такое только проверенным ребятам и очерчивайте границы. Тут есть важный момент - нельзя потом просто взять и проигнорировать вето своего сотрудника, вы обесцените это, как мотивацию и подорвете доверие к себе.
В заключении скажу, всегда делегируйте людям положенные им задачи, ищите тех, кто будет справляться, а не пытайтесь все проконтролировать сами. Помните, что в управление надо выдвигать тех, кто готов к ответственности и может давать результат.
Больше об управлении людьми, вы найдете в моем учебнике “Тимлид: базовый уровень”. В нем, помимо разбора всех основных умений руководителя команды, я добавил целую главу про делегирование полномочий.
Максим Шаламов
#руководителю
Ловушка незаменимого
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Кто такой профессионал и когда им становятся?
Вот есть у нас младшие специалисты, есть средние, есть старшие и ведущие. А кто такой профессионал? В какой момент человек становится профессионалом? Давайте сегодня порассуждаем на эту тему.
Образ профессионала
Мы можем много составлять списки компетенций, мягких навыков и тому подобное. Но, в конечном итоге, все сводится к одному - способности решать проблемы. Профессионал - это не тот, кто хорошо знает свои инструменты, языки программирования и фреймворки, не тот, у кого 10 высших образований, не тот, кто написал много проектов или проработал много лет. Профессионал - это человек, которому ты даешь задачу и с 99,9999% уверенностью знаешь, что он ее выполнит, причем выполнит в срок и с наилучшим качеством. А если не выполнит, то вряд ли бы и кто-то другой справился. И даже если случится апокалипсис, он запустит ваш сайт на мешке картошки и старом проигрывателе.
Что все это значит на практике в нашей профессии?
Давайте рассмотрим основные качества, которые присущи профессионалу. Для примера возьмем разработчика.
Умение находить решения
В принципе хорошая черта для любого исполнителя. Это значит, что человек является полноценным инструментом в решении своих задач. Если, на пример, при выполнении задачи, оказалось, что использующийся фреймворк не дает возможности выполнить условия задачи, то профессионал найдет решение. Доработка ли это будет фреймворка, написание какой-то альтернативы или что-то еще, факт в том, что решение будет найдено и задача будет выполнена.
Качество
Несмотря на умение находить решения, профессионал не оставляет костылей, с которыми невозможно будет продолжать дальнейшую работу над проектом. Он находит лучший из возможных способ внедрить решение, не превращая проект в говнокод. Здесь конечно же все зависит от скорости, с которой нужно выполнить задачу. Тем не менее, профессионал должен уметь находить баланс и думать о качестве в любой ситуации, на любой скорости, на то он и профессионал.
Широкий кругозор и умение вникать в смежные области
Если вы давно работаете, то точно встречались с фразами вроде "проблема не на нашей стороне". Для профессионала это допустимая фраза только в политическом случае, когда нужно заставлять людей работать над их зоной ответственности. В остальном, профессионал будет способен сказать, на чьей именно стороне проблема, примерно сказать в чем она заключается и, при желании и необходимости, разобраться в смежной области, чтобы найти какое-то решение. Грубо говоря, если все, кто только можно, в отпуске, и ваш проект вдруг перестал работать, профессионал найдет проблему и ее решение даже вне зоны своих компетенций. Конечно же решение может быть не такого же качества, как в его зоне ответственности, но он что-нибудь да придумает. Конечно же такое стоит делать только в исключительных случаях, когда нет другого выбора.
Мягкие навыки
Не все проблемы профессионал решает самостоятельно. Брать на себя лишнюю работу это не профессионально. Поэтому он хорошо умеет общаться с коллегами, договариваться, доносить свое мнение, умеет взять нужные части работы и информацию с коллег, хорошо умеет в процессы, потому что без них все развалится, и нарушает их только при острой необходимости.
Обладает даром предвидения
Опыт профессионала помогает ему предотвратить многие ошибки и неправильный выбор действий. Так часто он может предугадать, что что-то пойдет не так уже на этапе постановки задачи и предложить поменять план до наступления проблемы.
На каком уровне человек становится профессионалом
С одной стороны знания и опыт являются неотъемлемой частью профессионализма, поэтому искать профессионалов среди начинающих не стоит. Однако, не каждый синьор является профессионалом. К профессионализму приводят не знания и не рабочий стаж, к нему приводит правильный подход к работе. Правильный подход - главная направляющая профессионала. Хотите узнать какой именно подход? Тогда собираем реакции на этом посте и сделаем продолжение.
Считаете себя профессионалом своего дела? Что бы вы добавили в этот список?
Александра Шаламова
#разное
Вот есть у нас младшие специалисты, есть средние, есть старшие и ведущие. А кто такой профессионал? В какой момент человек становится профессионалом? Давайте сегодня порассуждаем на эту тему.
Образ профессионала
Мы можем много составлять списки компетенций, мягких навыков и тому подобное. Но, в конечном итоге, все сводится к одному - способности решать проблемы. Профессионал - это не тот, кто хорошо знает свои инструменты, языки программирования и фреймворки, не тот, у кого 10 высших образований, не тот, кто написал много проектов или проработал много лет. Профессионал - это человек, которому ты даешь задачу и с 99,9999% уверенностью знаешь, что он ее выполнит, причем выполнит в срок и с наилучшим качеством. А если не выполнит, то вряд ли бы и кто-то другой справился. И даже если случится апокалипсис, он запустит ваш сайт на мешке картошки и старом проигрывателе.
Что все это значит на практике в нашей профессии?
Давайте рассмотрим основные качества, которые присущи профессионалу. Для примера возьмем разработчика.
Умение находить решения
В принципе хорошая черта для любого исполнителя. Это значит, что человек является полноценным инструментом в решении своих задач. Если, на пример, при выполнении задачи, оказалось, что использующийся фреймворк не дает возможности выполнить условия задачи, то профессионал найдет решение. Доработка ли это будет фреймворка, написание какой-то альтернативы или что-то еще, факт в том, что решение будет найдено и задача будет выполнена.
Качество
Несмотря на умение находить решения, профессионал не оставляет костылей, с которыми невозможно будет продолжать дальнейшую работу над проектом. Он находит лучший из возможных способ внедрить решение, не превращая проект в говнокод. Здесь конечно же все зависит от скорости, с которой нужно выполнить задачу. Тем не менее, профессионал должен уметь находить баланс и думать о качестве в любой ситуации, на любой скорости, на то он и профессионал.
Широкий кругозор и умение вникать в смежные области
Если вы давно работаете, то точно встречались с фразами вроде "проблема не на нашей стороне". Для профессионала это допустимая фраза только в политическом случае, когда нужно заставлять людей работать над их зоной ответственности. В остальном, профессионал будет способен сказать, на чьей именно стороне проблема, примерно сказать в чем она заключается и, при желании и необходимости, разобраться в смежной области, чтобы найти какое-то решение. Грубо говоря, если все, кто только можно, в отпуске, и ваш проект вдруг перестал работать, профессионал найдет проблему и ее решение даже вне зоны своих компетенций. Конечно же решение может быть не такого же качества, как в его зоне ответственности, но он что-нибудь да придумает. Конечно же такое стоит делать только в исключительных случаях, когда нет другого выбора.
Мягкие навыки
Не все проблемы профессионал решает самостоятельно. Брать на себя лишнюю работу это не профессионально. Поэтому он хорошо умеет общаться с коллегами, договариваться, доносить свое мнение, умеет взять нужные части работы и информацию с коллег, хорошо умеет в процессы, потому что без них все развалится, и нарушает их только при острой необходимости.
Обладает даром предвидения
Опыт профессионала помогает ему предотвратить многие ошибки и неправильный выбор действий. Так часто он может предугадать, что что-то пойдет не так уже на этапе постановки задачи и предложить поменять план до наступления проблемы.
На каком уровне человек становится профессионалом
С одной стороны знания и опыт являются неотъемлемой частью профессионализма, поэтому искать профессионалов среди начинающих не стоит. Однако, не каждый синьор является профессионалом. К профессионализму приводят не знания и не рабочий стаж, к нему приводит правильный подход к работе. Правильный подход - главная направляющая профессионала. Хотите узнать какой именно подход? Тогда собираем реакции на этом посте и сделаем продолжение.
Считаете себя профессионалом своего дела? Что бы вы добавили в этот список?
Александра Шаламова
#разное
Лучшее враг хорошего. Как сделать так, чтобы инициатива не была наказуема?
Часто можно столкнуться с ситуацией, когда исполнители, из благих намерений, делают вещи, которые в рамках их задачи не ожидаются. Например: “а сделаю ка я рефакторинг проекта” или “поменяю методы, чтобы было удобнее” и т.д. В итоге, мы получаем либо срыв сроков, либо неожиданное поведение функционала, либо новые ошибки, а часто и комбинацию всего перечисленного. Как-то мы принимали дизайн для своего проекта и вместо дизайна лендинга нашего приложения, мы получили наброски персонажа для приложения. И вроде и идея хорошая, но и что делать с этим не понятно. Сроки дизайна лендинга сорваны и сделано не то, что надо было, а вроде идея то была хорошая.
Обычно тут случается неприятный разговор между руководителем / заказчиком и исполнителем. Оба остаются недовольными друг другом, а мотивация исполнителя подрывается.
Что делать руководителю
Ситуация и правда непростая, потому что людей, которые правда хотят делать хорошо, улучшать и развивать проекты, вкладывая сверхусилия, не так и много. Поэтому руководителям я рекомендую проводить разъяснительные беседы, как нужно такие вещи делать. То есть говорим, что рады старанию и вовлечению, но нужно сначала сделать свою запланированную часть, а дополнительные работы обсудить и согласовать, чтобы оно как минимум ничего не сломало и не противоречило заказу.
Что делать исполнителю
Исполнителям я бы посоветовал не забывать, что все таки наша основная цель - решать поставленные задачи. Непредсказуемое поведение, срывы сроков и тому подобное все равно будет идти в минус и вам, и проекту, для которого вы стараетесь. Хотите сделать больше - обсудите, что и как вы будете делать и вперед. Не делайте неприятных сюрпризов команде, заказчику и руководству, тогда ваши усилия принесут много пользы и вам и проекту.
Максим Шаламов
#советы
Часто можно столкнуться с ситуацией, когда исполнители, из благих намерений, делают вещи, которые в рамках их задачи не ожидаются. Например: “а сделаю ка я рефакторинг проекта” или “поменяю методы, чтобы было удобнее” и т.д. В итоге, мы получаем либо срыв сроков, либо неожиданное поведение функционала, либо новые ошибки, а часто и комбинацию всего перечисленного. Как-то мы принимали дизайн для своего проекта и вместо дизайна лендинга нашего приложения, мы получили наброски персонажа для приложения. И вроде и идея хорошая, но и что делать с этим не понятно. Сроки дизайна лендинга сорваны и сделано не то, что надо было, а вроде идея то была хорошая.
Обычно тут случается неприятный разговор между руководителем / заказчиком и исполнителем. Оба остаются недовольными друг другом, а мотивация исполнителя подрывается.
Что делать руководителю
Ситуация и правда непростая, потому что людей, которые правда хотят делать хорошо, улучшать и развивать проекты, вкладывая сверхусилия, не так и много. Поэтому руководителям я рекомендую проводить разъяснительные беседы, как нужно такие вещи делать. То есть говорим, что рады старанию и вовлечению, но нужно сначала сделать свою запланированную часть, а дополнительные работы обсудить и согласовать, чтобы оно как минимум ничего не сломало и не противоречило заказу.
Что делать исполнителю
Исполнителям я бы посоветовал не забывать, что все таки наша основная цель - решать поставленные задачи. Непредсказуемое поведение, срывы сроков и тому подобное все равно будет идти в минус и вам, и проекту, для которого вы стараетесь. Хотите сделать больше - обсудите, что и как вы будете делать и вперед. Не делайте неприятных сюрпризов команде, заказчику и руководству, тогда ваши усилия принесут много пользы и вам и проекту.
Максим Шаламов
#советы