Чем занят руководитель?
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.

Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.

В налаженных проектах, где нет бурного роста или большого накопленного долга (тех или бизнесового), руководители могут иметь много свободного времени, при этом претензий к ним быть не может. Все работает, развитие идет согласно плану, текучка делегирована или закрыта. Прийти к такому дорогого стоит, правда потом возникнет вопрос, а что дальше, но до этого надо дойти. Я дошел до этого один раз и принял решение двигаться дальше, в новой компании, с новыми вызовами и целями.
Так же, чем дальше вы от позиции руководителя команды, тем меньше ребята в командах понимают ваш вклад и вообще знают, когда вы подключались к решению проблемы, а когда нет.

Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.

Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.

Нештатные ситуации
Ну и казалось бы вот оно счастье, столько времени осталось свободного. Но дальше идет работа с нештатными ситуациями. Скажем если возьму просто прошлый день от написания статьи только по нештатным ситуациям будет такая картина за один день:

- нужно было договориться о перераспределении денег для выделения новых серверов под проекты;
убедить нескольких смежников проводить релиз так, как нужно нашей команде, потому что скорость критична;
- провести собеседование человека для усиления сопровождения, где были проблемы и надо срочно усиливаться;
- договориться о составе и размере команды под новый проект;
- убедить коллег из смежной системы поправить проблемы не по своему графику, а день в день.

Какие-то задачи приходится делать самому, в каких-то нужно найти правильных людей и свести со своими, где-то надо подпихнуть своих ребят. В общем, так оглядываешься порой и понимаешь, что рабочий день по графику то давно закончился. Понятно, что сейчас у нас на одном проекте период роста, а на втором глобальная перестройка, но моментами от этого не легче. Собственно, если есть желание делать проекты хорошо, то работа на любой позиции стороной вас не обойдет, главное быть на своем месте и получать удовольствие от процесса.

Максим Шаламов
#руководителю #разработчику

Что делать, если выбыл разработчик в середине спринта или релиза

Спланировали двухнедельный спринт, бизнес уже получил сроки по всем задам и остался ими вполне доволен, команда начала разработку. День делали, два делали и все прекрасно успевали и даже уходили вовремя домой. Тем временем, на город опустилась чума эпидемия гриппа. Сначала разработчики держались стойко, кое-кто даже повесил на шею чеснок (он конечно же помог). На четвертый день спринта, послышался первый кашель. На пятый кашляющего изолировали и заперли дома с температурой, но урон спринту был уже нанесен. Над командой начали сгущаться тучи.

С подобной ситуацией сталкивалась каждая команда. Как бы мы хорошо и правильно не планировали, форс-мажорные ситуации случаются, и иногда что-то изменить мы не в состоянии. Как минимизировать ущерб текущей работе и сохранить лицо команды в лучшем свете? Сейчас разберем алгоритм.

Что нужно подготовить заранее
Во-первых, если к беде не готовиться, то она обязательно застанет тебя врасплох. Поэтому, если вы не хотите в случае форс-мажора упасть в грязь лицом, то совершите некоторые приготовления. Самое важное, что вам нужно получить от бизнеса, по какому бы фреймворку вы не работали, это приоритеты. Мы никогда не устанем говорить о важности приоритетов. Именно они помогут команде при любых изменениях быстро сориентироваться и выдать лучшее, что они могут.

А можно просто работать по ночам и все затащить?
Вы можете задать законный вопрос: а почему бы просто не компенсировать выбывшего человека переработками? Вы вполне можете это сделать, особенно если у вас нет личной жизни и вы не планируете ее заводить. Но что делать, если выбыл не один человек, а два, а три? Все сильно зависит от команды и от плотности набранных задач. Но можно со всей уверенностью сказать, что рано или поздно ночные бдения вам не помогут.

Что делаем вместо бессонных ночей
Итак рассмотрим алгоритм, по которому надо действовать в таких ситуациях.

1. Первое, что вам нужно сделать, это посмотреть на приоритеты своих задач в спринте,

2. Посмотрите на цель своего спринта, проверьте не страдает ли она из-за того, что выбыл разработчик.

3. Определить какие задачи были на выбывшем человеке, их приоритеты и их статус.

4. Если разработчик работал над целью спринта или высокоприоритетными задачами, то необходимо перераспределить работу между оставшимися разработчиками таким образом, чтобы без исполнителя остались самые низко-приоритетные задачи. Соответственно, если выбывший уже работал над самыми низкоприоритетными задачами, то все оставляете, как было.

5. Обязательно оповестите своего владельца продукта и всех заинтересованных, о том, что выбыл человек, поэтому вместимость команды в этом спринте уменьшилась. Расскажите какие конкретно задачи из-за этого пострадали и не будут сделаны. Обязательно упомяните, что цель спринта не пострадала и все задачи с более высоким приоритетом будут готовы в срок.

Итак, самое важное, что нужно помнить: ваша главная задача не умереть на работе сделать все, что запланировано в спринте во что бы то ни стало, а донести до пользователя максимально возможную в имеющейся ситуации ценность.

Если хотите легко разруливать такие ситуации, все необходимое вы найдете в нашей книге "Гибкие методологии на практике". Там мы подробно расписали и о целях спринта, и о приоритетах, и о вместимости команды, и о том, кто за что отвечает, чем важно донесение ценности и что это вообще такое, а главное, как работать с такими форс-мажорами. В общем, все, что необходимо любому участнику команды для ежедневной работы.

Выгорание у джунов до старта работы - миф или реальность?

У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.

Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.

Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.

Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.

Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.

Александра Шаламова
#разработчику #тимлиду

Многоэтапные собеседования - зачем?

Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.

Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.

Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.

Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.

Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.

Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.

Максим Шаламов
#тимлиду #разработчику

Зачем нужны спринты

Спор нужны ли вообще технической команде спринты далеко не нов. Кто-то живет вообще без них и прекрасно справляется. Так зачем тогда вообще нужны спринты? Что они дают команде?

Дробление задач и быстрое донесение ценности
Самое главное, к чему должна стремиться команда - доносить до пользователя самый ценный функционал максимально быстро. Для этого важно уметь хорошо делить задачи на составляющие, которые можно сделать и отправить на продакшен отдельно от остального функционала согласно приоритетам. Дробление работы на отрезки времени ставит всех участников процесса в ситуацию, где приходится учиться декомпозировать задачи и определять последовательность работы через приоритеты. На практике немногие люди умеют хорошо дробить задачи и выделять, что нужно сделать сначала, а что потом. Особенно бизнесу это дается сложно, потому хочется всего и сразу, и приходится перестраиваться, чтобы начать определять приоритеты и выделять составляющие больших задач. Спринты обязывают думать более маленькими категориями, заставляя доносить максимальную ценность пользователю за короткий промежуток времени. И это самое важное, что могут дать спринты команде. Конечно же, чтобы это работало, команда должна понимать ценность такого подхода и строить свои работу соответственно. Если выкатывать один релиз раз в пол года, то такого преимущества спринты не дадут.

Итеративное обучение
Одно из основных преимуществ, которые дает итеративная работа технической команде это возможность итеративного обучения. Конец спринта - это возможность остановиться, оценить результаты своей работы, посмотреть на свои достижения и ошибки, и скорректировать свои процессы. Особенно это критично для новых команд и во время сильных изменений, когда команда еще не знает, как ей в новой ситуации работать, какие процессы именно ей лучше всего подходят.

А зачем обязательно нужно оценивать свою работу раз в какое-то время, почему не делать это от случая к случаю, когда увидели какие-то изменения? Ну во-первых, когда это бывает, чтобы что-то делали от случая к случаю стабильно. Изменения, происходящие в процессе работы, очень сложно заметить, важно специально обратить на них внимание. Но самое главное, что равные промежутки времени дают возможность сравнивать результаты прошлых итераций с текущими и наглядно видеть, как поменялись показатели команды. Подробно работу с показателями команды и итеративное обучение мы разбираем в нашей книге "Гибкие методологии на практике".

Точные сроки для бизнеса
Теперь перейдем к работе в продукте в целом и нашем любимом взаимодействии с бизнесом. Эксперименты показали, что относительные оценки оказываются в итоге более точными, чем оценки в человеко-часах/днях/месяцах. А итеративная разработка помогает дать бизнесу точные сроки, в которые его задача будет готова. После этого бизнес идет спокойно по своим делам до конца спринта и не дергает вас постоянными вопросами, а когда то и это будет готово.

Работа с обратной связью
Также в конце каждой итерации мы обязательно получаем обратную связь от всех заинтересованных в нашей работе лиц. Это еще одна возможность для обучения команды. Мы поработали с бизнесом, показали ему результаты, получили обратную связь, приняли решение, как нам под эту обратную связь улучшить свою работу и начали новый спринт уже чуть лучше, чем были до этого. И бизнес остался доволен, он увидел все, что хотел по результатам, задал все нужные вопросы, высказал свое мнение, и увидел, что поменялось в работе команды после прошлой обратной связи.

Продолжение в следующем посте ⤵️

А как же куча встрееееееееч?
Одной из самых болезненных тем, при обсуждении спринтов является большое количество встреч, которые нужно проводить каждый гребаный спринт. Эта куча встреч не дает честным разработчикам работать, а только отнимает время. Если честно, на эту тему можно говорить сутки на пролет и все равно всего не скажешь. Главное, что нужно помнить, каждая встреча должна и несет в себе определенный смысл. На пример, пункты выше как раз реализуются через эти самые встречи. А чтобы лучше понимать, зачем это все напридумывали, учите основы. Только зная основы и как определить приносит каждая встреча пользу или нет, можно понять нужна ли конкретная встреча вашей конкретной команде. Ну и не будем забывать, что встречи еще нужно и уметь проводить, об этом мы уже немного говорили раньше, но конечно же у каждой встречи есть свои особенности, опять же нужно учиться проводить каждую конкретную встречу правильно. А вообще отсутствие спринтов не спасет от кучи бесполезных встреч, они появляются от неумения строить правильные процессы и вести правильную коммуникацию, а не от выбора конкретных подходов.

Александра Шаламова
#agile_который_работает

Должен ли руководитель уметь сам проверить работу каждого?

В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.

Это вопрос сам по себе не имеет смысла, потому что в нем раскрыто сразу же полное непонимание, чем ты собираешься заниматься, как руководитель, и для чего. В такой постановке вопроса у меня есть предположение, что у руководителя должно быть экспертное знание во всех направлениях и языках, а также DevOps и сопровождении. Сомневаюсь, что эта история про реального человека, поэтому умение все проверить лучше всех - это иллюзия контроля, которая еще и замедляет работу команды. Не надо тешить свое эго тем, что ты везде и всюду умнее, ты формируешь команду и растишь ее, твоя цель, чтобы люди по целевым направлениям знали и умели больше тебя.

Про раздачу задач и вот это все. Ваша задача основная - сделать так, чтобы ваш проект работал хорошо, все выполнялось в срок и предсказуемо. Все остальное крутится вокруг достижения этого и подстраивается под реалии, в которых вы оказались. Если достаточно раздать задачи и все будет готово вовремя и в срок, то и отлично. Но обычно вам нужно все распланировать, проконтролировать итоговый результат (не руками, мы уже выяснили, что всего знать нельзя, но через тестирование и опытную эксплуатацию), организовать работу с багами и т.д. В какой-то момент вам может стать скучно, когда вы все наладите и делегируете, но обычно жизнь подбрасывает кучу изменений и нештатных ситуаций.

В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.

Еще статьи по теме задач руководителя, которые уже есть на канале:

Нужны ли руководителю технические знания

Чем занят руководитель

Чем отличается руководитель от разработчика

Задачи тимлида и техлида

Мой путь от разработчика к СТО


Максим Шаламов
#тимлиду #руководителю

Что делать, если тебя не уважают

Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?

Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.

Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.

Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.

На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.

Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающие его ваш продукт, это будет вызывать в нем уважение. Вы же свой человек, вы хотите того же, что и он, но делаете это методами, которыми он не владеет. А чтобы он видел, что это реально приносит пользу, опять же нужно учиться правильно преподносить результаты своей работы.

Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.

Александра Шаламова
#разработчику #тимлиду

Как руководителю заставить подчинённых и коллег себя уважать

Очень частая тема и проблема для начинающих да и вообще всех руководителей это уважение. Нужно чтобы люди уважали, что делать и как быть.

Что такое уважение
Я хочу зайти чисто с практической точки зрения, мне сложно сказать уважают люди меня или кого-то, вопрос в том, делают они то, что вам нужно или нет, контролируете ли вы их действия или нет. Потому что именно это важно на работе, вы можете уважать или даже любить кого-то, но не слушаться его. Будучи руководителем лучше меньше задумываться о том, кто, что и почему думает о вас, всем вы угодить точно не сможете. Поэтому, скорее всего, под уважением вы имеете ввиду восприятие вас, как человека, к которому будут прислушиваться, за кем будут идти, который будет контролировать процесс. Не берусь выставлять себя экспертом, но определенные вещи точно могу подсказать.

Внешность
Внешний вид. Да я знаю, что многих начнет трясти с этого, самовыражение и все такое. Дак вот, есть места, где ваш внешний вид может быть уместен или нет. И важно какое впечатление вы ожидаете произвести. Может вы и имеете право надеть клоунский костюм на работу (дресс кода почти ни у кого нет), но воспринимать серьезно вас будут немногие (если вы уникум харизмы, то вам точно все мои советы не интересны, вы хоть голый вывезете, но много ли таких людей?). Поэтому всегда думайте над тем, где и с кем вы будете взаимодействовать и как ожидается там быть одетым. Если вы хотите одеться как-то по-другому, то не ради самовыражения, а преследуя какие-то цели, например, показать, что отличаетесь или что вы из другой группы (если вы знаете что и зачем делаете, то бога ради). Есть некоторые ребята, которые ходят в очень мятых и заношенных вещах, думайте, что хотите, но они вызывают больше отторжения и вопросов у людей, которых не знают или которые их знают мало. Если вопрос того, как вас воспринимают, вам интересен, то используйте уместную и опрятную одежду.

Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.

Последовательность
Последовательность / своя позиция. Уважение вызывают люди, у которых есть своя понятная позиция, которую они последовательно отстаивают. Если вы все время прыгаете с идеи на идею, с подхода на подход, то будете восприниматься очень поверхностным и мало знающим. Взгляд на работу и то, как правильно ее делать, должны быть именно ваши и из вашего опыта.

Опыт
Опыт и готовность помочь. Очень укрепляют ваши позиции знания, опыт и, главное, готовность ими поделиться с другими. И ничто так не подрывает авторитет, как постоянно всплывающие подтверждения вашей некомпетентности по вашей прямой должности. Людей действительно знающих и готовых помогать мало и люди к таким тянуться.

Вообще не бойтесь запрашивать о себе и своей работе обратную связь, слушайте внимательно людей. Да, многие в лицо всего не выскажут, но скажут достаточно для того, кто хочет услышать. Неплохой способ внимательно посмотреть на себя в зеркало, посмотреть, как вы говорите и представить, что вы со стороны смотрите на такого человека, общее впечатление вы сможете составить. Я прошелся по самым верхам и тому, с чем можно быстро поработать. Книг по лидерству и развитию коммуникабельных навыков довольно много, выбирайте под себя. Если вам чего-то не хватает, но хочется, то вы сможете усилить свои слабые стороны.

Максим Шаламов
#тимлиду #руководителю

Говнокод или ступень роста

Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?

Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.

Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.

Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:

- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?

И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.

Александра Шаламова
#джуну #разработчику

Стоит ли рассматривать рост в руководителя команды, как обязательный этап

Вопрос об обязательности становится руководителем команды задается очень часто. Многие считают, что это естественный путь развития инженера.

Мое мнение, что этот этап не просто не обязателен, но и вообще не нужен большинству людей. Глобально, вы делаете шаг к смежной, но уже другой профессии и тут все зависит от того, нравится вам это или нет.

Давайте углубимся в детали. Зачем вам может захотеться идти в руководители:
- власть;
- уважение;
- деньги;
- возраст.

Наверное есть что-то еще, но возьму то, что слышу наиболее часто.

Власть
Власть. Сама по себе позиция руководителя команды не открывает каких-то невероятных просторов, чтобы развернуться. Во многих компаниях эта позиция не выделена в отдельную должность, а скорее идет как неформальная. И пусть это первая управляющая ступень, не все будут готовы признать ваш авторитет и лидерство. Вам нужно будет себя правильно поставить и постоянно поддерживать свою репутацию. Многие владельцы продукта в начале пытаются работать с позиции силы с лидами и командой, опытные или конфликтные сотрудники будут пытаться оспаривать ваше лидерство в спорных ситуациях, руководство техническое и бизнесовое начнет обращать на вас внимание и периодически звать на разборы проблем, где вам тоже нужно будет учиться ставить себя правильно. В этом нет чего-то невыполнимого, но большинству это все не нужно. И даже получив эту позицию, они будут бегать от проблем и конфликтов. В итоге ни власти, ни результатов.

Уважение
Уважение. Мы уже писали про уважение и само оно не появляется. Ваша должность сама по себе тут не поможет. Уважение придется заслуживать и как руководителю это сделать будет сложнее, чем будучи рядовым участником команды.

Деньги
Деньги. Опять же, поскольку позиция во многих компаниях не выделена, вы будете получать не особо больше опытных ребят из команды (а иногда и меньше). Но вот в вашей работе добавится много новых активностей, часть из которых не очень приятная. Конечно, чем дальше ты пройдешь (говоря о крупных компаниях или больше проявишь себя в мелких), тем выше будут и зарплаты, но это история про будущее, до которого не все дойдут. Поэтому я бы тоже сходу не питал иллюзий.

Возраст
Возраст. Самое смешное из того что я слышал, что уже годы и пора бы в руководители. Не пора бы. Возраст вообще на это никак не влияет + позиции руководящие, на мой взгляд, требуют много энергии, и, если вы ее не чувствуете, то вам сюда не надо.

Что еще
Что еще нужно учитывать:

- многие компании сейчас делают ветки для инженеров, где можно расти, как технический специалист. техлид, архитектор и т.д. Вы будете заниматься и тем, что вам нравится, и получать больше ответственности и денег.

- нет ничего плохого заниматься тем, что вам нравится. Не надо мучить себя ради эфемерных фантазий о том, как там оно. Делайте хорошо свою работу, получайте удовольствие, тем более, что оплачивается это более, чем достойно.

- если вы чувствуете что исчерпали свою нишу, но руководить не ваше, не мучайте себя, попробуйте смежные направления или совсем новые.

Резюмируя, чтобы переходить в руководители команды и управление, вам оно должно нравиться и вы должны видеть свое развитие в этом направлении. Не мучайте себя чужими стереотипами и занимайтесь тем, что вам нравится.

А если все таки поняли, что управлять командой - это ваше, то советую начать с моего учебника для руководителей команд. Найдете там всю нужную для начала информацию, начинаю с того, как получить эту позицию.

Максим Шаламов
#разработчику

Как все не просрать и оставаться хорошим разработчиком

Вот приходит на собеседование разработчик с 15-летним опытом, думаешь "ну все, сейчас он и меня научит, как делать надо!". А начинаешь спрашивать и он еле еле наскребает на слабого джуна. При этом сам весь вялый, апатичный, без энтузиазма, просто отбывающий свою текущую работу. Сидишь и думаешь, ну вот как ты, бедолага, такой получился? Давайте срочно разбираться, что можно сделать, чтобы с возрастом становиться крутым и опытным, а не бледным и вялым.

Не сидите в тухлом месте
Частая общая черта у вялых ребят это очень длительная работа на одном месте. Это не плохо само по себе, если вы нашли проект, который вас драйвит, дает интересные задачи и помогает развиваться. Но такое бывает очень и очень редко. Чаще всего это болото, в котором нужно делать однотипные задачи, без особой ответственности и вызовов. Оно может показаться комфортным и этот комфорт убьет в вас хорошего разработчика. Даже если вы к чему-то раньше стремились и чем-то интересовались, такое место высосет из вас жизнь. Но все однажды меняется, и болото иногда высыхает, тогда вы оказываетесь на рынке бесполезным и никому не нужным. Если вы попали в такое место, бегите оттуда как можно скорее.

Не бегайте от вызовов
У большинства задач есть несколько способов решения. Выбор нужного зависит от очень многих факторов, но никогда основным фактором не должна быть сложность выполнения лично для вас. Не ищите легких путей, если этого требует задача, берите на себя вызов и делайте то, что кажется вам сложным. Тоже самое при поиске работы, если вы чувствуете, что в компании вам может быть тяжело, нужно будет подтянуть свои знания, работать усерднее, не бойтесь браться за нее. Именно на противоположной стороне от болота вас и ждет максимальный рост.

Работайте над качеством кода
При ежедневной работе очень легко начать писать код на автомате и перестать замечать возможности сделать его лучше, постепенно скатываясь в говнокод. В нашем мини-курсе по борьбе с рутиной есть целый раздел про правильное отношение к написанию кода и как его в себе развить. Там мы разбираем 11 самых важных вопросов, которые вы должны себе задавать при выполнении любой задачи, чтобы не стать разработчиком-овощем. Повторяться не будем, доступ стоит 350р.

Берите на себя ответственность
Если при любой проблеме вы бежите к руководителю или владельцу продукта, не пытаясь ничего решить самостоятельно, это не только понижает вашу ценность, как разработчика, но и лишает вас возможности развиваться, делая вялым и безынициативным. Прежде чем просить у кого-то помощи, пробуйте разобраться с проблемой самостоятельно. Главное держитесь в рамках своих полномочий. Как решать разные проблемы с позиции разработчика, мы тоже разбирали в мини-курсе. Там есть подробный план действий на любой случай.

Будьте увлеченными
Ну и самое главное, что вам необходимо, чтобы оставаться на плаву - интерес к собственной работе. Желание узнавать больше, открывать для себя новые подходы, новые нюансы уже знакомых решений, и так далее и тому подобное. Интересуйтесь индустрией в целом и поддерживайте собственный интерес к работе, тогда вы никогда не устареете.

Александра Шаламова
#разработчику

Ответственность

Так случилось, что зашел у меня на днях разговор об ответственности и оказалось, что есть много людей, которые вообще не понимают, что это такое и как оно работает. Давайте сначала поговорим о термине в целом, а потом о его влиянии внутри работы.

Определение
Ответственность это способность человека отвечать за себя и свои собственные действия. То есть вы что-то сделали и сами же справляетесь с последствиями этих действий. Еще можно нести ответственность за что-то кроме себя, на пример, за какое-то дело, вещь или животное. В таком случае ваши действия будут зависеть от того, за что вы отвечаете. На пример, вы купили домой растение, теперь вы за него отвечаете. Вы не позволяете себе уехать надолго, не найдя того, кто будет его поливать. Ваши действия теперь зависят от потребностей вашего растения. Вы взяли за него ответственность.

Можно ли нести ответственность за человека? За взрослого, дееспособного человека нести ответственность невозможно. Каждый взрослый гражданин отвечает за себя и свои действия самостоятельно. Нести ответственность можно только за детей. На пример, если ваша жена поругалась с соседкой и врезала ей, то она будет сама отвечать за эти действия. Вас это несомненно тоже заденет, но вы не будете нести прямую ответственность за это. А вот если ваш двухлетний ребенок кинул камень в соседскую машину и оставил вмятину, то это уже полностью ваша проблема.

Передача ответственности
Можно ли как-то передавать ответственность? Например, вы можете платить другим людям за какие-то услуги, тогда они будут отвечать за свои задачи по этим услугам перед вами. Но полностью вас это от ответственности не избавит. На пример, я вызываю мастера заменить трубу, он отвечает за результат своей работы передо мной. Но если трубу после его работы прорвет, то я все равно буду отвечать перед соседями, которых она залила. И как ни крути, мастера я к этой ответственности смогу привлечь только косвенно, полностью скинуть на него это не получится. То есть обменять деньги на полную ответственность нельзя.

Тоже самое происходит на работе. Владелец компании нанимает людей и делегирует им часть ответственности, они отвечают перед ним. Если фирма разорится, это все равно будет его проблема. Но он уже может спрашивать со своих людей за их зоны ответственности, потому что у них есть договор обмена денег на работу. По сути владелец несет ответственность за выбор нужных людей и их организацию, если он сделает это плохо, то ему это аукнется и придется разбираться с последствиями. Также он отвечает за выполнение своей части договора перед сотрудниками, зарплату, условия труда и так далее.

В случае с подчиненными, вы также отвечаете за выбор людей и организацию их работы. Если подчиненный полностью провалил проект, уехав на жаркие острова, вы не отвечаете за его действия напрямую, уволят та все равно его, но отвечаете за то, что выбрали его и не проследили вовремя за выполнением задачи. Ну и разгребать это все конечно тоже вам - вы боретесь с последствиями. Поэтому в интересах руководителя найти способ заставить своих людей работать, где-то подбодрить, где-то поругать, в зависимости от ситуации. Он отвечает за конечный результат своей работы.

Ответственность за задачи
Если вам выдали задачу, или вы взяли на себя задачу, то вы становитесь за нее ответственным. Если она не будет сделана в срок, то вы и будете за это отвечать. А что, если, например, вы все сделали вовремя и правильно, а потом сервер упал в последний день и вы не смогли задачу выкатить? Исходим из определения: вы не можете отвечать за действия других людей, которые там все уронили и вовремя не подняли. Но вы отвечаете за задачу, поэтому вы должны выяснить все детали, знать что и почему произошло, чтобы мочь об этом отчитаться. Также вы должны постараться довести задачу до конца альтернативными способами, если это возможно. Это в ваших интересах, потому что вас спросят, почему все пошло не по плану, и вы должны иметь четкий ответ на этот вопрос.

Александра Шаламова
#советы

Как я помогаю подчиненным расти. Часть 1: период обучения.

Меня часто спрашивают, как я обеспечиваю рост людей, когда работаю с ними напрямую. Напрямую я сейчас работаю в основном с руководителями команд и направлений, поэтому писать буду о них. Но общие принципы я использую и для подчиненных не руководителей. В целом, я стараюсь выстроить всю работу так, чтобы люди всегда имели возможность расти. Поэтому расскажу, как я веду человека от самого момента найма в мою команду.

Начало работы
Первое, что я делаю, это даю вводные о себе и о том, чего жду от человека. Честно предупреждаю, что со мной напрямую работать сложно, я очень требовательный и прямой человек. Не смотря на то, что я мог бы разлить воды хоть на час, предпочитаю внутри своих отделов общаться по существу. Ожидаю прямую и честную коммуникацию, лучше так, чем вранье, которое все равно всплывет и мы скорее всего попрощаемся.

Следующим шагом, я проговариваю свое видение позиции, что нужно делать и что не нужно. Обязательно проговариваю моменты, где я не готов делегировать принятие решений и ожидаю согласование со мной. После чего обязательно слушаю мнение человека и мы можем скорректировать некоторые моменты, или как минимум я объясняю свою позицию.

Дальше мы обсуждаем цели на выбранный отрезок времени. Период обычно длительностью в квартал, с обязательным пояснением, какой результат должен быть достигнут и как будем это проверять. Тут ожидается активное участие человека, чтобы он сам подумал и оценил реалистичность и мы смогли внести корректировки, где это возможно.

С теми, с кем я работаю напрямую, я синхронизируюсь не реже раза в неделю, если человек только начинает, или его нужно подтягивать, то каждый день. Формат обсуждений следующий:

- Что сделано? Кратко человек говорит о проделанной работе с прошлого синка.

- Как мы идем по целям? Смотрим на наши цели и выделенные промежуточные точки. Определяем попадаем ли мы или есть проблемы.

- Обсуждение проблем. От проблем с достижением целей, до в целом любых проблем, которые мешают эффективно работать.

Исходя из моего понимания руководителя, как того, кто решает возникающие проблемы, я всегда готов помочь и подключиться. Но с теми, кого я подтягиваю или учу, я первое время хожу на большинство встреч и помогаю с текучкой. Мне важно показать человеку, чего я ожидаю, и чтобы он получил основное представление о том, как и что работает.

На этом с этапом обучения все. В следующем посте расскажу, как я работаю с человеком дальше.

Максим Шаламов
#руководителю #советы

Как я помогаю подчиненным расти. Часть 2: после обучения.

Итак, дав вводные и проведя обучение, что делать дальше? А дальше я оставляю наши синки, но выключаюсь из работы человека, давая ему возможность самому работать и проявлять себя. При этом я отслеживаю:

- Самостоятельность человека. Это очень важно для руководителя. Способен ли человек самостоятельно выполнять свою работу, решать в том числе и нестандартные вопросы в рамках своей ответственности.

- Своевременная эскалация(подсвечивание) проблем. Не все проблемы можно решить самому и не везде можно самому принимать решение. Человек должен знать момент, когда нужно подключать руководство и не должен бояться просить помощи. Боязнь просить помощи, что у коллег, что у руководства, это вообще частая проблема и с ней нужно бороться, делать все самому глупо и не эффективно. Что тут еще важно, это то, что я вовремя должен знать о всех значимых проблемах проекта, чтобы не получать неприятных сюрпризов.

- Закрытие целей. Обозначенные цели должны быть достигнуты вовремя, в требуемом качестве. Либо мы своевременно обсуждаем причины переноса, но по очень веским причинам.

- Умение аргументированно отстаивать свою позицию и свое мнение. У меня уже накоплен большой опыт и я обычно имею свое мнение на решение задач и сроков по ним. При этом я ожидаю, что, если я озвучиваю позицию и с ней не согласны, то я получу аргументированные возражения. Получив четкую раскладку по пути решения и срокам, и почему мой вариант не лучший, я приму предложенный вариант. И мы будем вместе думать устроит нас это решение по срокам (обычно в них вся проблема) или мы ищем еще какие-то компромиссы.

- Работа с людьми. Работа должна быть выстроена так, чтобы люди внутри команды и вне, как минимум, были готовы работать с этим человеком., Воспринимать адекватно его идеи и предложения. Постоянные неразрешимые конфликты ведут только к провалам и текучке.

Самое простое это отслеживать в конце периода достижение целей, если они адекватно зафиксированы, то споров будет минимально. Если вовремя не были скорректированы ожидания, то это вина человека, а не обстоятельств.

Самостоятельность отслеживается через количество обращений за помощью и их адекватностью. То есть после каждой помощи я проговариваю, что должен был сделать человек и, если он учится и повторно с таким не приходит, то все прекрасно. Проблемой может быть, неумение реагировать на любую новую проблему, но тут надо смотреть на позицию, где-то это может быть допустимо.

Естественно я смотрю на инциденты и проблемы, а главное на то, видел ли их человек заранее и смог ли он о них заранее предупредить и что-то предпринять. Если руководитель не умеет выявлять типовые возможные проблемы, то это приведет к частым срывам сроков и проблемам с качеством. Видеть проблемы мало, надо что-то с этим делать, если человек видел и не делал, это тоже засчитывается в минусы. Независимо от других обстоятельств, сообщил ли человек вовремя о проблеме или нет, тоже является важным фактором.

Из количества несоответствий по указанным пунктам, формируется мое мнение о человеке, его готовности и способности расти. Я ожиданию, что при получении постоянно обратной связи и помощи с новыми проблемами, человек будет уметь самостоятельно закрывать, или вовремя делегировать, 98% своих задач (цифра примерная). Самое долгое время, когда я бился, чтобы получить из человека отдачу - полтора года (успешно). Сейчас я принимаю решение за полгода, стоит ли дальше вкладывать силы и время в человека.

В конце замечу, что если вашим ростом занимаются, то это большой плюс. Нужно понимать, что чем выше ваша позиция, тем меньше времени у вашего наставника, и нужно ценить его время и возможности. Но обучение тоже должно совпадать с вашими планами на развитие. Если вам не интересно направление, в которое вас пытаются растить, то лучше откажитесь, чем тратить свое и чужое время.

Максим Шаламов
#руководителю #советы

Как создать конфликт в коллективе

Хочу поговорить о довольно распространенном способе внести в коллектив раскол и довести людей до конфликта. Ситуация по моим наблюдениям случается очень часто и поделюсь своей видением, как с этой ситуацией работать.

Итак представим ситуацию, что работаете вы себе и работаете, все бы хорошо, но у вас есть проблемы со смежными командами или отделами. Причем проблемы подтвержденные, серьезные и сильно влияющие на вас и вашу команду (возможно с точки зрения качества, возможно вам приходится постоянно сидеть вечерами из-за их ошибок или нерасторопности). Вы пытаетесь выровняться сами, выносите руководству эту ситуацию, но улучшений не видите. Время идет, проблема не решается. Внятно от руководства деталей вы не получаете, конечно, в какой-то момент, эта ситуация приводит к открытому конфликту.

Ситуация очень неприятная и случается часто. Прежде всего хочу сказать, что понимаю, как такое может случаться помимо нежелания руководства работать или вмешиваться в дела. Есть две возможности:

- сейчас человек/команда перегружены и вы оказались не в фокусе, они разбираются шаг за шагом с проблемами и дойдут до вас. Бывает, но обычно такое быстро выясняется и становится проще понимать проблематику.

- есть причины, не позволяющие жестко решить ситуацию, через увольнение, выговоры и т.д. Человека может быть трудно заменить и с этим не хотят связываться, с ним может уйти много людей, боятся идти на риск и т.п.

У меня тоже бывали и бывают ситуации, когда я не могу расстаться с человеком в моменте. Что же я обычно делаю. Те, кому это доставляет неудобства, обычно понимают причины почему мы не расстаемся с человеком (мы либо работаем над улучшением поведения, либо ищем замену, либо завершаем кусок работы и т.д.). Со своей стороны я стараюсь сгладить проблемы, перераспределяя часть несделанного (периодически на себя, если это организационные вопросы), чтобы минимизировать проблемы и не оставлять людей один на один с проблемой. Мое мнение: ваша основная задача, как руководителя, в этой ситуации не только решить проблему, но и дать людям объяснение вашего поведения, чтобы они не дергались, а могли отслеживать процесс улучшения ситуации. Очень плохо, когда люди остаются с проблемой и не понимают, что делать. Еще хуже, если вы на самом деле решаете проблему, но они не знают об этом, ведь люди могут уйти раньше.

Основной мой посыл - решайте проблемы, делитесь информацией с людьми по процессу решения проблем и всем будет работать проще и приятней.

Максим Шаламов
#руководителю #советы

Почему таблички “не беспокоить” не работают и почему это хорошо

Многие начинающие лиды тонут в текучке и особенно их допекает то, что вся команда ходит по каждой мелочи к ним (по крайней мере им так кажется). По их мнению, они пробуют все, чтобы к ним не ходили и даже ставят или вешают таблички “не беспокоить”, но это не работает.

Не работает все по простой и понятной причине - вы не выстроили процесс. А это значит, что люди не знают, что им делать с внештатными ситуациями и как идти по процессу. На самом деле, нужно радоваться, если в такой ситуации к вам идут. По крайней мере вы в курсе проблем и вас считают достойным того, чтобы спросить. Кидаться или обижаться на подчиненных в такой ситуации это верный путь испортить с ними отношения и, возможно, потом получить много неприятных сюрпризов, когда до вас в итоге с проблемой не дойдут.

Начну со списка дел, где советую лично подключаться:

- конфликты в команде
- конфликты с внешними командами
- пересмотр договоренностей по задачам
- общение с руководством
- обсуждение сроков
- обсуждение порядка выполнения задач
- приоритезация работ

Чтобы освободить свое время, вы должны выписать себе обычные причины обращения к вам и начать их устранять. Причин может быть много, но давайте я накидаю несколько с решением, чтобы вам было проще.

1. К вам приходят, чтобы вы провели ревью, потому что вы стоите, как обязательный ревьюер. Наверное самое частое из того, что я видел. На прямом контроле можно оставлять только ключевые задачи, для всего остального выделите в команде людей, чьим навыкам вы доверяете (если нет, то учите или нанимайте). Тут вы сами создаете себе и другим проблему, и все решается очень просто. Не тешьте себя иллюзией контроля, все равно с таким подходом качественно вы не сможете все отслеживать.

2. У малоопытных членов команды часто появляются вопросы по новым и сложным задачам, возможно по старым кускам системы. Кроме вас они не знают к кому идти, поэтому они будут ходить к вам. История решается примерно так же, выделите людей, к которым будут ходить до того, как пойдут к вам. Не завязывайте в себе скрытые знания, если что-то знаете только вы, то нужно передать эти знания еще минимум двум людям.

3. Частая проблема бывает с тем, что люди не понимают, как собирать и выкатывать проект. Документация часто бывает неполной или устаревшей. И снова должны быть источники знаний кроме вас, люди должны знать, что сначала обращаться нужно к ним.

Список можно продолжать и продолжать, но, в целом, большинство начинающих лидов на самом деле получают определенное удовольствие от того, что в них нуждаются. Так своя ценность кажется выше. И это все обычно работает не осознанно, но, по сути, человек сам делает себя необходимым и сам от этого страдает, но не может разорвать порочный круг. Поэтому следите, чтобы вы, по возможности, не были единственным источником знаний по своему проекту и не замыкайте на себе ничего, кроме ключевых вопросов.

Максим Шаламов
#руководителю #советы

Можно ли руководителю дружить с командой

Вопрос о дружбе руководителя с командой очень сложный с любой стороны. Рассмотрим варианты, когда вы дружили и пошел рост, и когда будучи руководителем начали сближаться.

Мой опыт
Начну с личного опыта, я нередко сближался с коллегам, как с товарищами. Очень часто это заканчивалось плохо, но оно того стоило для меня по двум причинам:

- я лучше понял мышление большинства людей
- я нашел так реально близких друзей и соратников, это штучная история, но она того стоила. Люди, которым я доверяю и которые всегда могут прямо высказать свое мнение, каким бы оно ни было.

Сейчас конечно я особо не пытаюсь разрывать дистанцию, которая автоматически образуется в парадигме начальник подчиненный. Мне нравится общаться со своими командами, с кем-то больше с кем-то меньше. Но я понимаю, что и я не могу всего сказать и они выбирают слова и формулировки. Это нормально.

Негативные последствия у дружбы с коллегами
Близкие отношения в работе это большое испытание для человеческих качеств. Я видел, как давние друзья переставали общаться, потому что один пошел в рост быстрее, как зависть подчиненного портила отношения, как чрезмерные ожидания руководителя от своего друга мешали и делу и портили отношения. Мы все головой понимаем, что работа это работа, а личное отдельно. Но по факту, это так не работает. Мы остаемся собой везде, и обиды, ожидания, амбиции, зависть и т.д. остаются с нами.

Много неприятных моментов было и лично у меня. Получал упреки, что мол мало работаю, а на виду, как руководитель я. Некоторых ребят начинал выделять под рост, тратил на них больше времени, а они интерпретировали это, как сигнал, что теперь можно и работать поменьше и требовать я должен с них не как со всех.

Все равно люди, которые тебе нравятся и на которых ты делаешь ставку, формируют у тебя лучшее отношение к себе, по-другому не получится. Однако, у меня таким людям с одной стороны хорошо - повышения и бонусы будут их первыми, но, с другой стороны, и плохо - требования мои намного выше, чем к другим. Кого не пугают трудности, остаются довольны, но кому-то это не подходит.

Тема дружбы на работе сложная, и каждый сам решит для себя, чего больше плюсов или минусов. Помните, что это отличная проверка человеческих качеств и ваших тоже. Если не уверены в себе или людях, и не хотите их терять, то не пробуйте.

Максим Шаламов
#руководителю

Можно ли расти просто работая

Хотел очень кратко обсудить тему, которая стала часто прослеживаться. Многие стали считать, что карьерный рост, интересные задачи, повышения и т.д. это полностью задача руководителя. Причем я имею ввиду полностью, руководитель должен понять, кто и что хочет, привести его за ручку к росту, помочь или сделать за человека и потом наградить тем, что человек хочет. Со своей стороны люди не готовы даже заявить о своих желаниях роста или других задач.

Мы все понимаем, что рынок сейчас с большой нуждой к специалистам и работу найти можно. Но обычно те, кто так подходят к вопросу, бегают с работы на работу от одних и тех же проблем. Причем сам процесс работы и переходов им не приносит никакого удовлетворения. Однако, остановиться и попробовать что-то изменить в своем подходе обычно никто не готов.

Со стороны руководителей и нанимающих такие люди тоже вызывают большую настороженность. Их конечно нанимают, но важные и ответственные направления им стараются не доверять. В рост особо не вкладываются, потому что понимают, что человек уйдет при первой же проблеме. Даже если не уйдет, поверить, что такой человек вовлекается в решение проблем на важных для компании направлениях мало кто решится.

В итоге, работу вы найдете, но ведь у многих запросы несколько выше, чем просто работа. В своей работе я постоянно пытаюсь что-то выбить для своих ребят и проектов, какие-то вещи и для своего роста (проекты, возможности и т.д.). В этом нет ничего унизительного, ваши желания кроме вас никто не знает. Интересных задач, приоритетных направлений и т.д. не так много, и желающих больше, чем возможностей. Поэтому, если вы чего-то хотите, то проявляйте активность, идите к этому, пытайтесь получить это, заявляйте о готовности вовлекаться (план, как получить повышение мы уже писали раньше). Не бойтесь, не стесняйтесь и не считайте себя лучше всех, тогда все у вас получится.

Максим Шаламов
#советы

Стоит ли лезть в личную жизнь сотрудников, если она мешает им работать

Личная жизнь - очень больная тема для большинства из нас, особенно, когда есть проблемы. Ряд семейных проблем или со здоровьем могут полностью замкнуть человека на себе. Конечно это печально скажется на работе.

Стоит ли лезть в личную жизнь подчиненного, чтобы исправить его работоспособность? Мое мнение такое, вы не врач и не друг, поэтому сильно глубоко в такие вещи лезть неправильно. Ваша задача поговорить с человеком и примерно понять его проблему (скорее всего глубоко в детали вас не пустят). В любом случае, нужно обсудить, как сам человек видит себя в работе, заинтересован ли он в ней. После этого нужно понять, проблема имеет краткосрочный характер или длительный. С краткосрочными проблемами можно отпустить человека в отпуск или снизить требования и ожидания к человеку на время. С долгосрочными проблемами сложнее. Пытаться затягивать можно, если специалист вам очень нужен или вы верите, что потом он наверстает. В любом случае, нужно наметить какие-то задачи на это время и срок, в который вы ожидаете, что человек вернется в строй. Тянуть бесконечно обычно плохая стратегия, потому что задачи будут падать на других ребят и это станет коллективной проблемой.

Если у вас хороший контакт, то вы можете что-то посоветовать из своего опыта, но с личными проблемами люди прислушиваются не всегда или обычно далеко не сразу. В любом случае, вам нужно общаться с человеком, понимать проблему и иметь совместный план по ее преодолению (в рамках работы). Не надо обижаться на человека или совершать резкие не обсужденные изменения.

Максим Шаламов
#руководителю

Важность похвалы

Я уже давно работаю управленцем и чем выше поднимаюсь, тем больше вижу тенденцию к отсутствию похвалы в работе в принципе. Недавно у нас был тренинг, после которого мой руководитель говорил мне, что хвалить не видят смысла, когда рядом зрелая команда и управленцы, нужно фокусироваться на целях и проблемах, а достижение целей само по себе считается похвальным и правильным.

Не знаю правильно ли это в управлении руководителями, но с начинающими так точно нельзя. Да и с ребятами в команде это не приведет ни к чему хорошему. В роли начинающего я такой подход оценил какое-то время назад, сходив на пробные занятия в стрелковый клуб и на скалодром. Оба похода объединяли крайне вялые инструкторы, которые после каждого упражнения говорили “идем дальше” с каменными лицами. При этом не забывая указывать на ошибки, когда делаешь что-то неправильно. Не смотря на то, что я головой понимаю, как это работает, удовольствие от работы с такими инструкторами было крайне сомнительным. Сменив стрелковый клуб, кстати, и попав на позитивного, вовлекающего инструктора, умеющего подбадривать в процессе, я сходил просто прекрасно, получил кучу позитива и продолжу ходить именно к этим ребятам.

К чему это я все? А к тому, какой бы зрелой ни была ваша команда и собеседник, не забывайте хвалить человека за хорошую работу. Как минимум это будет позитивным подкреплением, что очень важно. Второе, человек поймет, что его работу ценят и видят. Забывая хвалить людей, вы ставите их в очень странное положение, когда нет достаточной обратной связи о их работе. Получается, что человека только все время ругают (потому что проблему нужно обсуждать и решать). Таким подходом вы легко можете демотивировать и человека, и команду. У людей сложится впечатление, что вы придираетесь к ним и не видите их работы, а главное не цените их. Джунам и стажерам вы вообще можете отбить желание заниматься данной профессией, сложив впечатление, что они только ошибаются и ничего не делают правильно.

Никогда не забывайте оценивать заслуги людей. Но и не тратьте похвалу, если человек ее не заслужил. Поставьте себя на место человека и вам будет проще понять его ощущения.

Максим Шаламов
#руководителю