Как сделать задачу, если недостаточно требований?
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Командность
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
В чем смысл требовать опыт 1-2 года, если есть технические знания?
Столкнулась с таким вопросом в одном из чатов разработчиков: “Зачем в вакансиях требуют опыт 1-2 года, если у человека есть достаточно технических знаний, хоть он и не работал никогда?”. Давайте попробуем разобраться.
Основное, что дает вам опыт, это умение применять знания и находить решения там, где, казалось бы, их нет, в том числе умение искать решения (как ни странно, при всей доступности интернета, искать в нем решения тоже умеет не каждый). Все это приходит с опытом и никакими техническими знаниями не компенсируется.
У меня на практике была одна очень показательная история. Я работа ведущим фронтенд-разработчиком на проекте. У меня в команде были мидл/джун разработчики. Одному из них пришла задача сделать в многострочном блоке в конце троеточие. Из коробки такая задача не делается, такой технической возможности нет. Если начать гуглить решения люди всячески изгаляются, но у всех решений есть минусы. Человек в итоге зашел в тупик и пришел ко мне с этой проблемой. Я решила проблему просто: придумала альтернативное решение - заменить троеточие на градиент внизу блока, который делается элементарно, мы сходили и договорились с дизайнером о новом подходе к отображению блоков, объяснив ситуацию.
Чем показательна эта история? Разработчик был молодец, у него правда было достаточно технических знаний для его уровня. Но эта задача техническими знаниями не решалась, сколько ты в нее не бейся. Зато очень легко решалась в обход. Нужно было лишь придумать решение и правильно его аргументировать. В таких задачах как раз все решает опыт. Именно поэтому джуны без опыта работы смогут делать какие-то простые задачи, но на подобных ситуациях, а они случаются достаточно часто на практике, будут заходить в тупик. А вся эта лишняя работа будет падать на старших разработчиков и мешать им делать свои задачи. Такую инвестицию, с учетом того, что джуны растут быстрее, чем компания может их повышать, поэтому часто быстро увольняются, может себе позволить мало какая компания.
Умение договариваться и аргументировать, почему надо сделать не так, а иначе, особенно с ребятами из бизнеса, тоже приходит с опытом, после десятков споров и обсуждений. Никогда нельзя забывать, что наши коллеги из бизнеса не могут знать какие там точки где не получится поставить. А это еще очень просто объяснить, обычно все намного сложнее. Как-то раз, я битый час объясняла начальнику-бэкендеру, к которому пришла за помощью ПМ, которая вообще ничего не могла понять, почему отрисовка слишком длинного списка может повлиять на производительность браузера. Ему никак не удавалось понять, в чем у меня проблема перебрать значения в массиве и вывести этот злосчастный бесконечный список, который просит ПМ. А ведь он тоже разработчик, ребята из бизнеса - люди вообще никак не связанные с разработкой, попробуйте им такое объяснить (ПМ тогда просто стояла и беспомощно хлопала глазами, мне ее был честно жаль). Тем не менее, наша задача, как разработчиков, вовремя вмешаться в задачу и умело донести, что вот так делать не надо, это будет плохо, а сделать лучше вот так. И иногда это бывает очень сложно. Мы собрали целый список подобных примеров с разборами, как и в какой ситуации объяснить ПО или ПМу, почему что-то нужно сделать так, а не иначе, ознакомиться можно тут.
Вот основные моменты, которые приходят с опытом и никак не компенсируются техническими знаниями. Конечно недостаток всех этих умений придется компенсировать компании, и понятно почему они этого делать не хотят. Время - деньги, и за наше обучение никому платить не интересно. Кто вспомнит еще примеры знаний, которые приходят в опытом, пишите в комментариях, обсудим.
Александра Шаламова
#разработчику
Столкнулась с таким вопросом в одном из чатов разработчиков: “Зачем в вакансиях требуют опыт 1-2 года, если у человека есть достаточно технических знаний, хоть он и не работал никогда?”. Давайте попробуем разобраться.
Основное, что дает вам опыт, это умение применять знания и находить решения там, где, казалось бы, их нет, в том числе умение искать решения (как ни странно, при всей доступности интернета, искать в нем решения тоже умеет не каждый). Все это приходит с опытом и никакими техническими знаниями не компенсируется.
У меня на практике была одна очень показательная история. Я работа ведущим фронтенд-разработчиком на проекте. У меня в команде были мидл/джун разработчики. Одному из них пришла задача сделать в многострочном блоке в конце троеточие. Из коробки такая задача не делается, такой технической возможности нет. Если начать гуглить решения люди всячески изгаляются, но у всех решений есть минусы. Человек в итоге зашел в тупик и пришел ко мне с этой проблемой. Я решила проблему просто: придумала альтернативное решение - заменить троеточие на градиент внизу блока, который делается элементарно, мы сходили и договорились с дизайнером о новом подходе к отображению блоков, объяснив ситуацию.
Чем показательна эта история? Разработчик был молодец, у него правда было достаточно технических знаний для его уровня. Но эта задача техническими знаниями не решалась, сколько ты в нее не бейся. Зато очень легко решалась в обход. Нужно было лишь придумать решение и правильно его аргументировать. В таких задачах как раз все решает опыт. Именно поэтому джуны без опыта работы смогут делать какие-то простые задачи, но на подобных ситуациях, а они случаются достаточно часто на практике, будут заходить в тупик. А вся эта лишняя работа будет падать на старших разработчиков и мешать им делать свои задачи. Такую инвестицию, с учетом того, что джуны растут быстрее, чем компания может их повышать, поэтому часто быстро увольняются, может себе позволить мало какая компания.
Умение договариваться и аргументировать, почему надо сделать не так, а иначе, особенно с ребятами из бизнеса, тоже приходит с опытом, после десятков споров и обсуждений. Никогда нельзя забывать, что наши коллеги из бизнеса не могут знать какие там точки где не получится поставить. А это еще очень просто объяснить, обычно все намного сложнее. Как-то раз, я битый час объясняла начальнику-бэкендеру, к которому пришла за помощью ПМ, которая вообще ничего не могла понять, почему отрисовка слишком длинного списка может повлиять на производительность браузера. Ему никак не удавалось понять, в чем у меня проблема перебрать значения в массиве и вывести этот злосчастный бесконечный список, который просит ПМ. А ведь он тоже разработчик, ребята из бизнеса - люди вообще никак не связанные с разработкой, попробуйте им такое объяснить (ПМ тогда просто стояла и беспомощно хлопала глазами, мне ее был честно жаль). Тем не менее, наша задача, как разработчиков, вовремя вмешаться в задачу и умело донести, что вот так делать не надо, это будет плохо, а сделать лучше вот так. И иногда это бывает очень сложно. Мы собрали целый список подобных примеров с разборами, как и в какой ситуации объяснить ПО или ПМу, почему что-то нужно сделать так, а не иначе, ознакомиться можно тут.
Вот основные моменты, которые приходят с опытом и никак не компенсируются техническими знаниями. Конечно недостаток всех этих умений придется компенсировать компании, и понятно почему они этого делать не хотят. Время - деньги, и за наше обучение никому платить не интересно. Кто вспомнит еще примеры знаний, которые приходят в опытом, пишите в комментариях, обсудим.
Александра Шаламова
#разработчику
Чем занят руководитель?
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.
Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.
В налаженных проектах, где нет бурного роста или большого накопленного долга (тех или бизнесового), руководители могут иметь много свободного времени, при этом претензий к ним быть не может. Все работает, развитие идет согласно плану, текучка делегирована или закрыта. Прийти к такому дорогого стоит, правда потом возникнет вопрос, а что дальше, но до этого надо дойти. Я дошел до этого один раз и принял решение двигаться дальше, в новой компании, с новыми вызовами и целями.
Так же, чем дальше вы от позиции руководителя команды, тем меньше ребята в командах понимают ваш вклад и вообще знают, когда вы подключались к решению проблемы, а когда нет.
Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.
Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.
Нештатные ситуации
Ну и казалось бы вот оно счастье, столько времени осталось свободного. Но дальше идет работа с нештатными ситуациями. Скажем если возьму просто прошлый день от написания статьи только по нештатным ситуациям будет такая картина за один день:
- нужно было договориться о перераспределении денег для выделения новых серверов под проекты;
убедить нескольких смежников проводить релиз так, как нужно нашей команде, потому что скорость критична;
- провести собеседование человека для усиления сопровождения, где были проблемы и надо срочно усиливаться;
- договориться о составе и размере команды под новый проект;
- убедить коллег из смежной системы поправить проблемы не по своему графику, а день в день.
Какие-то задачи приходится делать самому, в каких-то нужно найти правильных людей и свести со своими, где-то надо подпихнуть своих ребят. В общем, так оглядываешься порой и понимаешь, что рабочий день по графику то давно закончился. Понятно, что сейчас у нас на одном проекте период роста, а на втором глобальная перестройка, но моментами от этого не легче. Собственно, если есть желание делать проекты хорошо, то работа на любой позиции стороной вас не обойдет, главное быть на своем месте и получать удовольствие от процесса.
Максим Шаламов
#руководителю #разработчику
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.
Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.
В налаженных проектах, где нет бурного роста или большого накопленного долга (тех или бизнесового), руководители могут иметь много свободного времени, при этом претензий к ним быть не может. Все работает, развитие идет согласно плану, текучка делегирована или закрыта. Прийти к такому дорогого стоит, правда потом возникнет вопрос, а что дальше, но до этого надо дойти. Я дошел до этого один раз и принял решение двигаться дальше, в новой компании, с новыми вызовами и целями.
Так же, чем дальше вы от позиции руководителя команды, тем меньше ребята в командах понимают ваш вклад и вообще знают, когда вы подключались к решению проблемы, а когда нет.
Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.
Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.
Нештатные ситуации
Ну и казалось бы вот оно счастье, столько времени осталось свободного. Но дальше идет работа с нештатными ситуациями. Скажем если возьму просто прошлый день от написания статьи только по нештатным ситуациям будет такая картина за один день:
- нужно было договориться о перераспределении денег для выделения новых серверов под проекты;
убедить нескольких смежников проводить релиз так, как нужно нашей команде, потому что скорость критична;
- провести собеседование человека для усиления сопровождения, где были проблемы и надо срочно усиливаться;
- договориться о составе и размере команды под новый проект;
- убедить коллег из смежной системы поправить проблемы не по своему графику, а день в день.
Какие-то задачи приходится делать самому, в каких-то нужно найти правильных людей и свести со своими, где-то надо подпихнуть своих ребят. В общем, так оглядываешься порой и понимаешь, что рабочий день по графику то давно закончился. Понятно, что сейчас у нас на одном проекте период роста, а на втором глобальная перестройка, но моментами от этого не легче. Собственно, если есть желание делать проекты хорошо, то работа на любой позиции стороной вас не обойдет, главное быть на своем месте и получать удовольствие от процесса.
Максим Шаламов
#руководителю #разработчику
Выгорание у джунов до старта работы - миф или реальность?
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
Многоэтапные собеседования - зачем?
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Что делать, если тебя не уважают
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающиеего ваш продукт, это будет вызывать в нем уважение. Вы же свой человек, вы хотите того же, что и он, но делаете это методами, которыми он не владеет. А чтобы он видел, что это реально приносит пользу, опять же нужно учиться правильно преподносить результаты своей работы.
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающие
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Говнокод или ступень роста
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику
Стоит ли рассматривать рост в руководителя команды, как обязательный этап
Вопрос об обязательности становится руководителем команды задается очень часто. Многие считают, что это естественный путь развития инженера.
Мое мнение, что этот этап не просто не обязателен, но и вообще не нужен большинству людей. Глобально, вы делаете шаг к смежной, но уже другой профессии и тут все зависит от того, нравится вам это или нет.
Давайте углубимся в детали. Зачем вам может захотеться идти в руководители:
- власть;
- уважение;
- деньги;
- возраст.
Наверное есть что-то еще, но возьму то, что слышу наиболее часто.
Власть
Власть. Сама по себе позиция руководителя команды не открывает каких-то невероятных просторов, чтобы развернуться. Во многих компаниях эта позиция не выделена в отдельную должность, а скорее идет как неформальная. И пусть это первая управляющая ступень, не все будут готовы признать ваш авторитет и лидерство. Вам нужно будет себя правильно поставить и постоянно поддерживать свою репутацию. Многие владельцы продукта в начале пытаются работать с позиции силы с лидами и командой, опытные или конфликтные сотрудники будут пытаться оспаривать ваше лидерство в спорных ситуациях, руководство техническое и бизнесовое начнет обращать на вас внимание и периодически звать на разборы проблем, где вам тоже нужно будет учиться ставить себя правильно. В этом нет чего-то невыполнимого, но большинству это все не нужно. И даже получив эту позицию, они будут бегать от проблем и конфликтов. В итоге ни власти, ни результатов.
Уважение
Уважение. Мы уже писали про уважение и само оно не появляется. Ваша должность сама по себе тут не поможет. Уважение придется заслуживать и как руководителю это сделать будет сложнее, чем будучи рядовым участником команды.
Деньги
Деньги. Опять же, поскольку позиция во многих компаниях не выделена, вы будете получать не особо больше опытных ребят из команды (а иногда и меньше). Но вот в вашей работе добавится много новых активностей, часть из которых не очень приятная. Конечно, чем дальше ты пройдешь (говоря о крупных компаниях или больше проявишь себя в мелких), тем выше будут и зарплаты, но это история про будущее, до которого не все дойдут. Поэтому я бы тоже сходу не питал иллюзий.
Возраст
Возраст. Самое смешное из того что я слышал, что уже годы и пора бы в руководители. Не пора бы. Возраст вообще на это никак не влияет + позиции руководящие, на мой взгляд, требуют много энергии, и, если вы ее не чувствуете, то вам сюда не надо.
Что еще
Что еще нужно учитывать:
- многие компании сейчас делают ветки для инженеров, где можно расти, как технический специалист. техлид, архитектор и т.д. Вы будете заниматься и тем, что вам нравится, и получать больше ответственности и денег.
- нет ничего плохого заниматься тем, что вам нравится. Не надо мучить себя ради эфемерных фантазий о том, как там оно. Делайте хорошо свою работу, получайте удовольствие, тем более, что оплачивается это более, чем достойно.
- если вы чувствуете что исчерпали свою нишу, но руководить не ваше, не мучайте себя, попробуйте смежные направления или совсем новые.
Резюмируя, чтобы переходить в руководители команды и управление, вам оно должно нравиться и вы должны видеть свое развитие в этом направлении. Не мучайте себя чужими стереотипами и занимайтесь тем, что вам нравится.
А если все таки поняли, что управлять командой - это ваше, то советую начать с моего учебника для руководителей команд. Найдете там всю нужную для начала информацию, начинаю с того, как получить эту позицию.
Максим Шаламов
#разработчику
Вопрос об обязательности становится руководителем команды задается очень часто. Многие считают, что это естественный путь развития инженера.
Мое мнение, что этот этап не просто не обязателен, но и вообще не нужен большинству людей. Глобально, вы делаете шаг к смежной, но уже другой профессии и тут все зависит от того, нравится вам это или нет.
Давайте углубимся в детали. Зачем вам может захотеться идти в руководители:
- власть;
- уважение;
- деньги;
- возраст.
Наверное есть что-то еще, но возьму то, что слышу наиболее часто.
Власть
Власть. Сама по себе позиция руководителя команды не открывает каких-то невероятных просторов, чтобы развернуться. Во многих компаниях эта позиция не выделена в отдельную должность, а скорее идет как неформальная. И пусть это первая управляющая ступень, не все будут готовы признать ваш авторитет и лидерство. Вам нужно будет себя правильно поставить и постоянно поддерживать свою репутацию. Многие владельцы продукта в начале пытаются работать с позиции силы с лидами и командой, опытные или конфликтные сотрудники будут пытаться оспаривать ваше лидерство в спорных ситуациях, руководство техническое и бизнесовое начнет обращать на вас внимание и периодически звать на разборы проблем, где вам тоже нужно будет учиться ставить себя правильно. В этом нет чего-то невыполнимого, но большинству это все не нужно. И даже получив эту позицию, они будут бегать от проблем и конфликтов. В итоге ни власти, ни результатов.
Уважение
Уважение. Мы уже писали про уважение и само оно не появляется. Ваша должность сама по себе тут не поможет. Уважение придется заслуживать и как руководителю это сделать будет сложнее, чем будучи рядовым участником команды.
Деньги
Деньги. Опять же, поскольку позиция во многих компаниях не выделена, вы будете получать не особо больше опытных ребят из команды (а иногда и меньше). Но вот в вашей работе добавится много новых активностей, часть из которых не очень приятная. Конечно, чем дальше ты пройдешь (говоря о крупных компаниях или больше проявишь себя в мелких), тем выше будут и зарплаты, но это история про будущее, до которого не все дойдут. Поэтому я бы тоже сходу не питал иллюзий.
Возраст
Возраст. Самое смешное из того что я слышал, что уже годы и пора бы в руководители. Не пора бы. Возраст вообще на это никак не влияет + позиции руководящие, на мой взгляд, требуют много энергии, и, если вы ее не чувствуете, то вам сюда не надо.
Что еще
Что еще нужно учитывать:
- многие компании сейчас делают ветки для инженеров, где можно расти, как технический специалист. техлид, архитектор и т.д. Вы будете заниматься и тем, что вам нравится, и получать больше ответственности и денег.
- нет ничего плохого заниматься тем, что вам нравится. Не надо мучить себя ради эфемерных фантазий о том, как там оно. Делайте хорошо свою работу, получайте удовольствие, тем более, что оплачивается это более, чем достойно.
- если вы чувствуете что исчерпали свою нишу, но руководить не ваше, не мучайте себя, попробуйте смежные направления или совсем новые.
Резюмируя, чтобы переходить в руководители команды и управление, вам оно должно нравиться и вы должны видеть свое развитие в этом направлении. Не мучайте себя чужими стереотипами и занимайтесь тем, что вам нравится.
А если все таки поняли, что управлять командой - это ваше, то советую начать с моего учебника для руководителей команд. Найдете там всю нужную для начала информацию, начинаю с того, как получить эту позицию.
Максим Шаламов
#разработчику
Как все не просрать и оставаться хорошим разработчиком
Вот приходит на собеседование разработчик с 15-летним опытом, думаешь "ну все, сейчас он и меня научит, как делать надо!". А начинаешь спрашивать и он еле еле наскребает на слабого джуна. При этом сам весь вялый, апатичный, без энтузиазма, просто отбывающий свою текущую работу. Сидишь и думаешь, ну вот как ты, бедолага, такой получился? Давайте срочно разбираться, что можно сделать, чтобы с возрастом становиться крутым и опытным, а не бледным и вялым.
Не сидите в тухлом месте
Частая общая черта у вялых ребят это очень длительная работа на одном месте. Это не плохо само по себе, если вы нашли проект, который вас драйвит, дает интересные задачи и помогает развиваться. Но такое бывает очень и очень редко. Чаще всего это болото, в котором нужно делать однотипные задачи, без особой ответственности и вызовов. Оно может показаться комфортным и этот комфорт убьет в вас хорошего разработчика. Даже если вы к чему-то раньше стремились и чем-то интересовались, такое место высосет из вас жизнь. Но все однажды меняется, и болото иногда высыхает, тогда вы оказываетесь на рынке бесполезным и никому не нужным. Если вы попали в такое место, бегите оттуда как можно скорее.
Не бегайте от вызовов
У большинства задач есть несколько способов решения. Выбор нужного зависит от очень многих факторов, но никогда основным фактором не должна быть сложность выполнения лично для вас. Не ищите легких путей, если этого требует задача, берите на себя вызов и делайте то, что кажется вам сложным. Тоже самое при поиске работы, если вы чувствуете, что в компании вам может быть тяжело, нужно будет подтянуть свои знания, работать усерднее, не бойтесь браться за нее. Именно на противоположной стороне от болота вас и ждет максимальный рост.
Работайте над качеством кода
При ежедневной работе очень легко начать писать код на автомате и перестать замечать возможности сделать его лучше, постепенно скатываясь в говнокод. В нашем мини-курсе по борьбе с рутиной есть целый раздел про правильное отношение к написанию кода и как его в себе развить. Там мы разбираем 11 самых важных вопросов, которые вы должны себе задавать при выполнении любой задачи, чтобы не стать разработчиком-овощем. Повторяться не будем, доступ стоит 350р.
Берите на себя ответственность
Если при любой проблеме вы бежите к руководителю или владельцу продукта, не пытаясь ничего решить самостоятельно, это не только понижает вашу ценность, как разработчика, но и лишает вас возможности развиваться, делая вялым и безынициативным. Прежде чем просить у кого-то помощи, пробуйте разобраться с проблемой самостоятельно. Главное держитесь в рамках своих полномочий. Как решать разные проблемы с позиции разработчика, мы тоже разбирали в мини-курсе. Там есть подробный план действий на любой случай.
Будьте увлеченными
Ну и самое главное, что вам необходимо, чтобы оставаться на плаву - интерес к собственной работе. Желание узнавать больше, открывать для себя новые подходы, новые нюансы уже знакомых решений, и так далее и тому подобное. Интересуйтесь индустрией в целом и поддерживайте собственный интерес к работе, тогда вы никогда не устареете.
Александра Шаламова
#разработчику
Вот приходит на собеседование разработчик с 15-летним опытом, думаешь "ну все, сейчас он и меня научит, как делать надо!". А начинаешь спрашивать и он еле еле наскребает на слабого джуна. При этом сам весь вялый, апатичный, без энтузиазма, просто отбывающий свою текущую работу. Сидишь и думаешь, ну вот как ты, бедолага, такой получился? Давайте срочно разбираться, что можно сделать, чтобы с возрастом становиться крутым и опытным, а не бледным и вялым.
Не сидите в тухлом месте
Частая общая черта у вялых ребят это очень длительная работа на одном месте. Это не плохо само по себе, если вы нашли проект, который вас драйвит, дает интересные задачи и помогает развиваться. Но такое бывает очень и очень редко. Чаще всего это болото, в котором нужно делать однотипные задачи, без особой ответственности и вызовов. Оно может показаться комфортным и этот комфорт убьет в вас хорошего разработчика. Даже если вы к чему-то раньше стремились и чем-то интересовались, такое место высосет из вас жизнь. Но все однажды меняется, и болото иногда высыхает, тогда вы оказываетесь на рынке бесполезным и никому не нужным. Если вы попали в такое место, бегите оттуда как можно скорее.
Не бегайте от вызовов
У большинства задач есть несколько способов решения. Выбор нужного зависит от очень многих факторов, но никогда основным фактором не должна быть сложность выполнения лично для вас. Не ищите легких путей, если этого требует задача, берите на себя вызов и делайте то, что кажется вам сложным. Тоже самое при поиске работы, если вы чувствуете, что в компании вам может быть тяжело, нужно будет подтянуть свои знания, работать усерднее, не бойтесь браться за нее. Именно на противоположной стороне от болота вас и ждет максимальный рост.
Работайте над качеством кода
При ежедневной работе очень легко начать писать код на автомате и перестать замечать возможности сделать его лучше, постепенно скатываясь в говнокод. В нашем мини-курсе по борьбе с рутиной есть целый раздел про правильное отношение к написанию кода и как его в себе развить. Там мы разбираем 11 самых важных вопросов, которые вы должны себе задавать при выполнении любой задачи, чтобы не стать разработчиком-овощем. Повторяться не будем, доступ стоит 350р.
Берите на себя ответственность
Если при любой проблеме вы бежите к руководителю или владельцу продукта, не пытаясь ничего решить самостоятельно, это не только понижает вашу ценность, как разработчика, но и лишает вас возможности развиваться, делая вялым и безынициативным. Прежде чем просить у кого-то помощи, пробуйте разобраться с проблемой самостоятельно. Главное держитесь в рамках своих полномочий. Как решать разные проблемы с позиции разработчика, мы тоже разбирали в мини-курсе. Там есть подробный план действий на любой случай.
Будьте увлеченными
Ну и самое главное, что вам необходимо, чтобы оставаться на плаву - интерес к собственной работе. Желание узнавать больше, открывать для себя новые подходы, новые нюансы уже знакомых решений, и так далее и тому подобное. Интересуйтесь индустрией в целом и поддерживайте собственный интерес к работе, тогда вы никогда не устареете.
Александра Шаламова
#разработчику
Ловушка незаменимого
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Почему нельзя просто сорвать сроки? Какие могут быть последствия?
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Почему руководитель не хочет повышать разработчика?
Кажется, что делаешь все, работаешь лучше других, но тебя все равно не повышают. Сидишь на одной и той же зарплате и должности, пока не найдешь новую работу, где сразу дают больше. Так в чем же дело? Разберем несколько возможных причин.
Вы не превосходите ожидания от вашей позиции
Повышают не за хорошую работу, а за то, что ты перерос свою текущую позицию или зарплату и готов оправдывать более высокую. Если вы просто выполняете свою работу хорошо, то вы просто окупаете свою текущую зарплату. Чтобы получить заветное повышение, нужно показать руководителю, и тем, кто будет принимать решение о вашем повышении, что вы готовы к новой роли, что вы можете работать на новом уровне. Ваше руководство должно быть готово тратить новую сумму на вас и доверить вам новые обязанности, это должно быть для них оправдано. Грубо говоря, если им дороже обойдется ваш уход в другую компанию, потому что такого, как вы, им и искать и растить очень долго, то им проще будет вас повысить, чем рисковать остаться с кем-то, кто не справляется.
Вы изначально пришли на более высокий оклад
Еще одна причина, по которой вас могут не хотеть повышать, изначально слишком высокая зарплата, которая превышает обычную на вашей должности. Может быть вас переоценили на собеседовании или просто слишком хотели вас получить, поэтому дали зарплату выше, чем обычно. Это может полностью устраивает руководство, но еще больше оно дать уже не готово. Здесь также можно посоветовать расти и перебираться на новый уровень, где еще более высокая зарплата будет нормальной.
Нарушение сроков и целей
Проблема, которая вроде и очевидна, но ее может быть сложно заметить. Допустим вы работает в целом хорошо, иногда делаете больше, чем от вас ждут. Но при этом вы периодически сильно срываете сроки выполнения своих задач, не выполняете поставленных целей, при этом не предупреждая руководство заранее, иногда складываете продакшен или делаете что-то в обход общепринятых инструкций. Такие промахи, даже когда они случаются не так часто, могут перечеркивать всю хорошую работу до этого. В итоге, последующие победы просто компенсируют желание уволить работника после провала, но не доводят до возможности повысить. Если вы хотите добиться повышения, то работайте над своим умением укладываться в сроки и выполнять поставленные цели. Как раз этому мы будем учиться на нашем марафоне на следующей неделе, так что обязательно посмотрите все материалы, чтобы не оказаться в такой незавидной ситуации.
#разработчику
Кажется, что делаешь все, работаешь лучше других, но тебя все равно не повышают. Сидишь на одной и той же зарплате и должности, пока не найдешь новую работу, где сразу дают больше. Так в чем же дело? Разберем несколько возможных причин.
Вы не превосходите ожидания от вашей позиции
Повышают не за хорошую работу, а за то, что ты перерос свою текущую позицию или зарплату и готов оправдывать более высокую. Если вы просто выполняете свою работу хорошо, то вы просто окупаете свою текущую зарплату. Чтобы получить заветное повышение, нужно показать руководителю, и тем, кто будет принимать решение о вашем повышении, что вы готовы к новой роли, что вы можете работать на новом уровне. Ваше руководство должно быть готово тратить новую сумму на вас и доверить вам новые обязанности, это должно быть для них оправдано. Грубо говоря, если им дороже обойдется ваш уход в другую компанию, потому что такого, как вы, им и искать и растить очень долго, то им проще будет вас повысить, чем рисковать остаться с кем-то, кто не справляется.
Вы изначально пришли на более высокий оклад
Еще одна причина, по которой вас могут не хотеть повышать, изначально слишком высокая зарплата, которая превышает обычную на вашей должности. Может быть вас переоценили на собеседовании или просто слишком хотели вас получить, поэтому дали зарплату выше, чем обычно. Это может полностью устраивает руководство, но еще больше оно дать уже не готово. Здесь также можно посоветовать расти и перебираться на новый уровень, где еще более высокая зарплата будет нормальной.
Нарушение сроков и целей
Проблема, которая вроде и очевидна, но ее может быть сложно заметить. Допустим вы работает в целом хорошо, иногда делаете больше, чем от вас ждут. Но при этом вы периодически сильно срываете сроки выполнения своих задач, не выполняете поставленных целей, при этом не предупреждая руководство заранее, иногда складываете продакшен или делаете что-то в обход общепринятых инструкций. Такие промахи, даже когда они случаются не так часто, могут перечеркивать всю хорошую работу до этого. В итоге, последующие победы просто компенсируют желание уволить работника после провала, но не доводят до возможности повысить. Если вы хотите добиться повышения, то работайте над своим умением укладываться в сроки и выполнять поставленные цели. Как раз этому мы будем учиться на нашем марафоне на следующей неделе, так что обязательно посмотрите все материалы, чтобы не оказаться в такой незавидной ситуации.
#разработчику
Почему люди уходят из компании
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Как получить оффер: мои фишки прохождения собеседования
Хочу рассказать вам подходы к собеседованиям на разработчика, которые помогают мне получать оффер с большинства встреч. Я расскажу со стороны кандидата, что именно мне помогает.
Правильный настрой
Самое самое важное, что у вас должно быть на собеседовании это правильный настрой. Все знания и подготовка пойдут коту под хвост, если вы правильно не настроитесь. Поверьте, ваш настрой виден и создает впечатление о вас. Поэтому я стараюсь максимально сосредоточится и откинуть все мысли о результате и страхе опозориться, вы все это переживете. Вы идете показать себя и посмотреть на других, вам не обязательно быть идеалом, вы можете ошибиться, дайте себе на это право и максимально расслабьтесь. Это поможет вам выдать свой максимум.
Подготовка
Как-то у нас сменилось начальство в компании, мы все по очереди увольнялись и обсуждали с коллегами подготовку к собеседованиям. Один коллега посмотрел на нас удивленными глазами и спросил: "а вы что готовитесь к собеседованиям? Типа как к экзамену, что-ли?". Да, чтобы хорошо пройти собеседование туда, куда вам нужно, вам надо к нему готовится. Особенно в начале карьеры это просто необходимо. Но даже разработчик с опытом может забыть элементарные вещи, если не будет их повторять. Как готовится? На самом деле в интернете давно есть списки вопросов, можно начать с них. Потом записывать каждый вопрос с собеседования, на который вы не смогли ответить и разбирать его. Так вы накопите свою базу и закроете свои пробелы. Кстати, отличная возможность общаться с другими увольняющимися коллегами, узнаете, что сейчас в моде спрашивать заранее.
Правильный отбор компаний
Мы уже ни раз писали про то, как выбирать компании на собеседовании(тут и тут), но самый начальный отбор нужно делать вообще до собеседования. Если вы видите, что компания вообще не вашего уровня, что их требования или проекты не совпадают с вашими интересами, просто не тратьте свое время. Разговор не пойдет, если вы изначально ориентируетесь на разное. Полезно сходить в компании, к которым вы стремитесь, но еще не готовы, но к тем, которые вы уже переросли смысла идти нет.
Представление себя
Подумайте, как вы себя преподносите потенциальному работодателю. Начинайте еще с резюме: изложите все свои достижения на каждом месте работы, расскажите, чем конкретно вы занимались, какие крупные задачи можете отметить. В идеале, по вашему опыту не должно быть вопросов после прочтения резюме, но кто ж его будет читать... Поэтому обязательно подготовьте устный рассказ о своем прошлом опыте. Выберите лучшие примеры и смело рассказывайте, как вы себя проявили. Также к собеседованию подберите подходящую одежду, выглядите опрятно, но не переборщите.
Уважение к прошлым работодателям
Осторожно отвечайте на вопросы почему вы ушли с предыдущих мест работы. Не стоит откровенно ругать прошлого работодателя, иначе новый решит, что про них вы будете потом рассказывать что-то подобное. Однако, это хороший момент, чтобы выяснить, отличается ли новая компания от предыдущей. Корректно опишите основную причину и задайте вопросы, как это работает у них в компании.
Спрячьте свое эго
Да, мы все тут крутые ребята, и каждый лучше всех знает свою работу. Но забудьте об этом на время собеседования. Отслеживайте надменность и самодовольство, и старайтесь их избегать. Если на собеседовании возник спор по поводу кода, хороший вариант попросить проверить решение на компьютере. Но скорее всего вас все равно после этого уже не позовут. Мало кто готов признать свою неправоту и продолжить работать с человеком, который ущемил его эго. Если не готовы отказываться от оффера ради спора, то просто уверено скажите ваше правильнее решение и оставьте человеку право ошибаться. Но помните, что это хорошая возможность оценить будущих коллег, ведь вам с ними тоже еще работать.
Если вы уже задумались над очередной сменой работы, для начала посмотрите наш мини-курс по борьбе с рутиной. Он поможет разогнать скуку на текущем месте и оставаться классным, востребованным специалистом.
Александра Шаламова
#разработчику #советы
Хочу рассказать вам подходы к собеседованиям на разработчика, которые помогают мне получать оффер с большинства встреч. Я расскажу со стороны кандидата, что именно мне помогает.
Правильный настрой
Самое самое важное, что у вас должно быть на собеседовании это правильный настрой. Все знания и подготовка пойдут коту под хвост, если вы правильно не настроитесь. Поверьте, ваш настрой виден и создает впечатление о вас. Поэтому я стараюсь максимально сосредоточится и откинуть все мысли о результате и страхе опозориться, вы все это переживете. Вы идете показать себя и посмотреть на других, вам не обязательно быть идеалом, вы можете ошибиться, дайте себе на это право и максимально расслабьтесь. Это поможет вам выдать свой максимум.
Подготовка
Как-то у нас сменилось начальство в компании, мы все по очереди увольнялись и обсуждали с коллегами подготовку к собеседованиям. Один коллега посмотрел на нас удивленными глазами и спросил: "а вы что готовитесь к собеседованиям? Типа как к экзамену, что-ли?". Да, чтобы хорошо пройти собеседование туда, куда вам нужно, вам надо к нему готовится. Особенно в начале карьеры это просто необходимо. Но даже разработчик с опытом может забыть элементарные вещи, если не будет их повторять. Как готовится? На самом деле в интернете давно есть списки вопросов, можно начать с них. Потом записывать каждый вопрос с собеседования, на который вы не смогли ответить и разбирать его. Так вы накопите свою базу и закроете свои пробелы. Кстати, отличная возможность общаться с другими увольняющимися коллегами, узнаете, что сейчас в моде спрашивать заранее.
Правильный отбор компаний
Мы уже ни раз писали про то, как выбирать компании на собеседовании(тут и тут), но самый начальный отбор нужно делать вообще до собеседования. Если вы видите, что компания вообще не вашего уровня, что их требования или проекты не совпадают с вашими интересами, просто не тратьте свое время. Разговор не пойдет, если вы изначально ориентируетесь на разное. Полезно сходить в компании, к которым вы стремитесь, но еще не готовы, но к тем, которые вы уже переросли смысла идти нет.
Представление себя
Подумайте, как вы себя преподносите потенциальному работодателю. Начинайте еще с резюме: изложите все свои достижения на каждом месте работы, расскажите, чем конкретно вы занимались, какие крупные задачи можете отметить. В идеале, по вашему опыту не должно быть вопросов после прочтения резюме, но кто ж его будет читать... Поэтому обязательно подготовьте устный рассказ о своем прошлом опыте. Выберите лучшие примеры и смело рассказывайте, как вы себя проявили. Также к собеседованию подберите подходящую одежду, выглядите опрятно, но не переборщите.
Уважение к прошлым работодателям
Осторожно отвечайте на вопросы почему вы ушли с предыдущих мест работы. Не стоит откровенно ругать прошлого работодателя, иначе новый решит, что про них вы будете потом рассказывать что-то подобное. Однако, это хороший момент, чтобы выяснить, отличается ли новая компания от предыдущей. Корректно опишите основную причину и задайте вопросы, как это работает у них в компании.
Спрячьте свое эго
Да, мы все тут крутые ребята, и каждый лучше всех знает свою работу. Но забудьте об этом на время собеседования. Отслеживайте надменность и самодовольство, и старайтесь их избегать. Если на собеседовании возник спор по поводу кода, хороший вариант попросить проверить решение на компьютере. Но скорее всего вас все равно после этого уже не позовут. Мало кто готов признать свою неправоту и продолжить работать с человеком, который ущемил его эго. Если не готовы отказываться от оффера ради спора, то просто уверено скажите ваше правильнее решение и оставьте человеку право ошибаться. Но помните, что это хорошая возможность оценить будущих коллег, ведь вам с ними тоже еще работать.
Если вы уже задумались над очередной сменой работы, для начала посмотрите наш мини-курс по борьбе с рутиной. Он поможет разогнать скуку на текущем месте и оставаться классным, востребованным специалистом.
Александра Шаламова
#разработчику #советы
"Почему меня не уважают?"
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Ты хочешь чего-то стоить или просто уволиться?
Ребят, ну серьезно, меня бомбит от таких комментариев: "зачем мне чета делать, проще уволиться". Так и хочется ответить: "ну и сиди, как лох, когда ребята, которым не лень оторвать жопу от дивана говорят, что тебе делать, пока их не переманят в место поприкольнее, да в проект поинтереснее".
Вы для себя в первую очередь решите, а чего вам по жизни та вообще нужно? Вот правда сидеть в уголке и решать хреново описанные задачи в стол это предел ваших мечтаний? Быть никогда никем не замеченным, никем не уважаемым, серым исполнителем, который при первой же проблеме увольняется, просто потому что рынок переполнен вакансиями, а самому ему вообще все равно, где отбывать повинность до пенсии, - это твои планы на жизнь?
Или ты все таки хочешь быть тем человеком, который реально что-то может в своем деле? Который берет и делает круто, как никто другой не может. К которому прислушиваются коллеги. Который, не важно с какой позиции, говорит и команда делает, потому что понимает, что лучше его все равно никто не знает. К которому бизнес САМ приходит спросить "а стоит ли так делать или это плохая идея", потому что помнит, что прошлый раз именно ты их спас от провала. Неужели не хочется забыть про все эти выгорания и постоянное ощущение бессмысленности того, что ты делаешь, и хоть немного получать удовольствие от своей работы, хоть немного гордиться тем, что ты сам из себя представляешь? Но видимо не хочется, ведь проще уволится.
Александра Шаламова
#разработчику #крикдуши
Ребят, ну серьезно, меня бомбит от таких комментариев: "зачем мне чета делать, проще уволиться". Так и хочется ответить: "ну и сиди, как лох, когда ребята, которым не лень оторвать жопу от дивана говорят, что тебе делать, пока их не переманят в место поприкольнее, да в проект поинтереснее".
Вы для себя в первую очередь решите, а чего вам по жизни та вообще нужно? Вот правда сидеть в уголке и решать хреново описанные задачи в стол это предел ваших мечтаний? Быть никогда никем не замеченным, никем не уважаемым, серым исполнителем, который при первой же проблеме увольняется, просто потому что рынок переполнен вакансиями, а самому ему вообще все равно, где отбывать повинность до пенсии, - это твои планы на жизнь?
Или ты все таки хочешь быть тем человеком, который реально что-то может в своем деле? Который берет и делает круто, как никто другой не может. К которому прислушиваются коллеги. Который, не важно с какой позиции, говорит и команда делает, потому что понимает, что лучше его все равно никто не знает. К которому бизнес САМ приходит спросить "а стоит ли так делать или это плохая идея", потому что помнит, что прошлый раз именно ты их спас от провала. Неужели не хочется забыть про все эти выгорания и постоянное ощущение бессмысленности того, что ты делаешь, и хоть немного получать удовольствие от своей работы, хоть немного гордиться тем, что ты сам из себя представляешь? Но видимо не хочется, ведь проще уволится.
Александра Шаламова
#разработчику #крикдуши
Сменить работу не значит решить проблему
До первого места работы, где я проработал долго и плодотворно, я сменил 9 компаний, нигде не проработав и года. Везде, в целом, были одни и те же проблемы: сложности с бизнесом, сложности с ростом, мало интересных задач, повышения происходят не так, как ты хочешь и ждешь. В какой-то момент я понял, что как специалист я за счет этого расширил кругозор, но я не расту вглубь, как по технике, так и по софт части. И в целом я понял, что работы меняются, а я нет. Это понимание дало мне огромный толчок, позволило получить интересные проекты, рост, собрать команду, с которой мне было интересно работать и главное теперь это воспроизводится на новых местах, потому что проблемы везде похожие, а адаптироваться и расти нужно именно тебе. Тогда ты сможешь решить многое из проблем.
Собственно к чему это все? Многие бегают с работы на работу и каждый раз попадают в одни и те же проблемы. В итоге, удовлетворенность от работы на любом месте низкая, карьера идет не так, как хочется. Виноваты все вокруг, пойду вон к тем, там все по-другому. На самом деле, чтобы прийти к чему-то другому, нужно поменять себя. Тогда вы будете выбирать коллег и компании по-другому, смотреть на другие вещи и сможете решать типовые проблемы. А решать проблемы придется всегда, на любой позиции. Повышения, интересные задачи, новые вызовы, зоны роста - все это нужно уметь стабильно получать, уметь где-то подождать, а где-то с опытом понимать, что твоих сил изменить компанию недостаточно и тогда действительно идти дальше.
Главное не заниматься самообманом, а начинать поиск проблемы с себя, тогда ты будешь и расти, и лучше понимать, как получить желаемое. Если вы решили для себя, что расти и развиваться самому это ваш вариант, то посмотрите наш небольшой курс по борьбе с рутиной. Мы там как раз описали подходы, которые вырабатывают привычку к постоянному самосовершенствованию.
Максим Шаламов
#советы #разработчику #руководителю
До первого места работы, где я проработал долго и плодотворно, я сменил 9 компаний, нигде не проработав и года. Везде, в целом, были одни и те же проблемы: сложности с бизнесом, сложности с ростом, мало интересных задач, повышения происходят не так, как ты хочешь и ждешь. В какой-то момент я понял, что как специалист я за счет этого расширил кругозор, но я не расту вглубь, как по технике, так и по софт части. И в целом я понял, что работы меняются, а я нет. Это понимание дало мне огромный толчок, позволило получить интересные проекты, рост, собрать команду, с которой мне было интересно работать и главное теперь это воспроизводится на новых местах, потому что проблемы везде похожие, а адаптироваться и расти нужно именно тебе. Тогда ты сможешь решить многое из проблем.
Собственно к чему это все? Многие бегают с работы на работу и каждый раз попадают в одни и те же проблемы. В итоге, удовлетворенность от работы на любом месте низкая, карьера идет не так, как хочется. Виноваты все вокруг, пойду вон к тем, там все по-другому. На самом деле, чтобы прийти к чему-то другому, нужно поменять себя. Тогда вы будете выбирать коллег и компании по-другому, смотреть на другие вещи и сможете решать типовые проблемы. А решать проблемы придется всегда, на любой позиции. Повышения, интересные задачи, новые вызовы, зоны роста - все это нужно уметь стабильно получать, уметь где-то подождать, а где-то с опытом понимать, что твоих сил изменить компанию недостаточно и тогда действительно идти дальше.
Главное не заниматься самообманом, а начинать поиск проблемы с себя, тогда ты будешь и расти, и лучше понимать, как получить желаемое. Если вы решили для себя, что расти и развиваться самому это ваш вариант, то посмотрите наш небольшой курс по борьбе с рутиной. Мы там как раз описали подходы, которые вырабатывают привычку к постоянному самосовершенствованию.
Максим Шаламов
#советы #разработчику #руководителю
Вы не должны перерабатывать, чтобы хорошо работать
Был у нас с Максимом в университете замечательный преподаватель по Python и архитектуре, который любит говорить, что самый лучший программист это ленивый программист. И к сожалению, большинство ребят, с которыми я говорила, этого не понимают.
Хорошо работать у большинства ассоциируется с переработками. Да есть у нас такое ошибочное мышление, если Вася работал в выходные, значит он хороший работник, надо его повысить. Но "много" не имеет ничего общего с "хорошо". А даже наоборот. Чем хуже вы что-то сделали, тем больше вам прилетает дополнительной работы: правки, баги, доработки. В итоге, именно "плохо работал" обычно превращается в "много работал". Хотите работать мало? Делайте сразу нормально и думайте наперед. Лучше сделать чуть больше в первый раз, чтобы следующие похожие задачи шли быстрее, чем сделать быстро одну, но повторять все тоже самое еще 10 раз.
Поверьте, никому ни разу еще не позвонили в 3 часа ночи, чтобы сказать: "чувак, ты так хорошо и надежно написал свой код, что он все еще работает без проблем, так что давай вставай и смотри с нами, как он хорошо работает". А вот если вы написали так, что все развалилось, вот тогда вам точно придется вставать и все исправлять, а утром снова тащиться на работу, чтобы снова сделать хреново и снова потом сидеть в нерабочее время исправлять. И не надоедает ведь.
Не согласны? Тогда жду в комментариях.
Александра Шаламова
#советы #разработчику
Был у нас с Максимом в университете замечательный преподаватель по Python и архитектуре, который любит говорить, что самый лучший программист это ленивый программист. И к сожалению, большинство ребят, с которыми я говорила, этого не понимают.
Хорошо работать у большинства ассоциируется с переработками. Да есть у нас такое ошибочное мышление, если Вася работал в выходные, значит он хороший работник, надо его повысить. Но "много" не имеет ничего общего с "хорошо". А даже наоборот. Чем хуже вы что-то сделали, тем больше вам прилетает дополнительной работы: правки, баги, доработки. В итоге, именно "плохо работал" обычно превращается в "много работал". Хотите работать мало? Делайте сразу нормально и думайте наперед. Лучше сделать чуть больше в первый раз, чтобы следующие похожие задачи шли быстрее, чем сделать быстро одну, но повторять все тоже самое еще 10 раз.
Поверьте, никому ни разу еще не позвонили в 3 часа ночи, чтобы сказать: "чувак, ты так хорошо и надежно написал свой код, что он все еще работает без проблем, так что давай вставай и смотри с нами, как он хорошо работает". А вот если вы написали так, что все развалилось, вот тогда вам точно придется вставать и все исправлять, а утром снова тащиться на работу, чтобы снова сделать хреново и снова потом сидеть в нерабочее время исправлять. И не надоедает ведь.
Не согласны? Тогда жду в комментариях.
Александра Шаламова
#советы #разработчику
Почему не надо 10 лет работать разработчиком, чтобы стать руководителем разработки?
Есть популярное мнение, что для того, чтобы стать руководителем в команде разработчиков, нужно стать мега спецом в своей области, потратив не менее 10 лет. И только тогда уже думать об управлении. В общем случае это полный бред.
Погружение в специфику нужно
Давайте сделаю отступление, что в любом случае, став руководителем команды, нужно какое-то погружение в специфику работы и проекта, понимать общие вещи и способы решать проблемы. Есть места, где просто не выделяют отдельно такую роль / позицию, и там вариантов вообще нет. Это полезно, но не будет критичным.
Управление – другая профессия
Давайте я объясню, что не так в целом с мнением, что сначала нужно отработать 10 лет в разработке. Первое, управление командой это просто другая работа. Руководить кем-то или чем-то это не тоже самое, что выполнять задачи в этой же сфере. Поэтому хоть 50 лет проведи разработчиком, руководить ты от этого не научишься.
Все технологии отдела выучить невозможно
У нас сейчас тенденция к полнофункциональным командам, то есть там будут специалисты разных областей знаний. Никакой жизни не хватит все учить по 10 лет, да и остальное уже будет не актуально через 10 лет.
Продолжая прошлый пункт, часть знаний быстро теряет актуальность, а будучи лидом постоянно держать контекст и обновлять знания у вас не получится.
Углубление в технологии мешает раскрываться управленческим навыкам
Глубокое знание предмета, часто мешает людям раскрыться, как руководителям. Это кажется странным, но такое происходит постоянно. Это приводит к завышенным ожиданиям от подчиненных, постоянным попыткам сделать все самому (ну так же быстрее), постоянной печали, что накопленные навыки теряются (на первых этапах есть у всех).
Конечно знания не бывают лишними и то, что я пришел из разработки в управление мне очень помогает. Но я давно уже понял, что хороший инженер и хороший руководитель могут как сочетаться в одном человеке, так и быть взаимоисключающими. Поэтому надо понимать, что ваши технические знания вам пригодятся, но не настолько, чтобы это было ключевым. И да, под специфику вашей команды и проекта вам придется подтянуть знания, но не на уровне топ специалиста в любой отрасли нужной для проекта.
А что учить вместо 10 лет разработки?
Если хотите стать руководителем, то нужно набираться именно управленческих знаний. Как раз для таких случаев я писал свой учебник для начинающих руководителей технических команд, чтобы дать всю нужную начальную информацию разработчику, который решил перейти в управление, но еще не знает, как это сделать. Если задумываетесь об управлении, то берите учебник – не пожалеете.
Максим Шаламов
#разработчику #руководителю
Есть популярное мнение, что для того, чтобы стать руководителем в команде разработчиков, нужно стать мега спецом в своей области, потратив не менее 10 лет. И только тогда уже думать об управлении. В общем случае это полный бред.
Погружение в специфику нужно
Давайте сделаю отступление, что в любом случае, став руководителем команды, нужно какое-то погружение в специфику работы и проекта, понимать общие вещи и способы решать проблемы. Есть места, где просто не выделяют отдельно такую роль / позицию, и там вариантов вообще нет. Это полезно, но не будет критичным.
Управление – другая профессия
Давайте я объясню, что не так в целом с мнением, что сначала нужно отработать 10 лет в разработке. Первое, управление командой это просто другая работа. Руководить кем-то или чем-то это не тоже самое, что выполнять задачи в этой же сфере. Поэтому хоть 50 лет проведи разработчиком, руководить ты от этого не научишься.
Все технологии отдела выучить невозможно
У нас сейчас тенденция к полнофункциональным командам, то есть там будут специалисты разных областей знаний. Никакой жизни не хватит все учить по 10 лет, да и остальное уже будет не актуально через 10 лет.
Продолжая прошлый пункт, часть знаний быстро теряет актуальность, а будучи лидом постоянно держать контекст и обновлять знания у вас не получится.
Углубление в технологии мешает раскрываться управленческим навыкам
Глубокое знание предмета, часто мешает людям раскрыться, как руководителям. Это кажется странным, но такое происходит постоянно. Это приводит к завышенным ожиданиям от подчиненных, постоянным попыткам сделать все самому (ну так же быстрее), постоянной печали, что накопленные навыки теряются (на первых этапах есть у всех).
Конечно знания не бывают лишними и то, что я пришел из разработки в управление мне очень помогает. Но я давно уже понял, что хороший инженер и хороший руководитель могут как сочетаться в одном человеке, так и быть взаимоисключающими. Поэтому надо понимать, что ваши технические знания вам пригодятся, но не настолько, чтобы это было ключевым. И да, под специфику вашей команды и проекта вам придется подтянуть знания, но не на уровне топ специалиста в любой отрасли нужной для проекта.
А что учить вместо 10 лет разработки?
Если хотите стать руководителем, то нужно набираться именно управленческих знаний. Как раз для таких случаев я писал свой учебник для начинающих руководителей технических команд, чтобы дать всю нужную начальную информацию разработчику, который решил перейти в управление, но еще не знает, как это сделать. Если задумываетесь об управлении, то берите учебник – не пожалеете.
Максим Шаламов
#разработчику #руководителю