Плюсы и минусы продолжительной работы на одном месте
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
О чем еще нужно помнить
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Как сделать задачу, если недостаточно требований?
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Командность
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
В чем смысл требовать опыт 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 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду