Когда-то многие компании строили свои HR-бренды вокруг красивых офисов с парковками, спортзалами и оплаченными обедами. Но с приходом удалёнки всё это перестало быть столь же важным, как раньше. Что поменялось в мотивации сотрудников со времён начала пандемии?

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

Привет, Хабр! Меня зовут Игорь Десятников, я Chief Technical Officer в компании Neuro.net. Несколько раз встречал на Хабре статьи с попыткой рассказать о роли СТО, об эволюции этой должности при расширении компании и т.п. С некоторыми вещами согласен, с другими — нет.

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

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

#1 Доверяйте своим сотрудникам

Многие руководители привыкли к офисному формату, когда они в любой момент могут дойти до сотрудника ногами и выяснить, «чем это он там занимается». У некоторых даже развиваются мысли, что если не приглядывать за сотрудниками, то они сразу перестают работать, целый день сидят в интернете или играют в игры. Менеджеры, вы серьезно?
Если кто-то хочет играть или сидеть в интернете, он вполне может делать это и на своем рабочем месте в офисе.

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

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

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

Инструкция написана в общем стиле и подойдет для руководителя почти любого уровня при смене места работы. Поехали!

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

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

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

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

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

Сегодня я попробую рассказать мою точку зрения на этот вопрос. Если вам интересно, добро пожаловать под кат!

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

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

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

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

– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!

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

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

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

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

Я читал и читаю довольно много книг. Хорошие книги, которые мне понравилось, записываю, чтобы потом порекомендовать. Я решил сделать небольшую подборку must have книг, которые должен прочитать каждый начинающий руководитель. Одно из требований, чтобы эти книги были не только полезными, но и интересными. Книги должны заинтересовать человека развиваться в управлении, ни в коем случае не демотивировать.

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

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

Беседовал я как-то с техническим директором одного из крупнейших банков России. В какой-то момент речь у нас зашла о премировании сотрудников. Тогда я ему говорю, что у нас в компании есть премирование сотрудников за вовремя сделанные проекты и задачи. Тут он завис секунд на пять, долгое молчание, недоумение в глазах:
– Кхм… Так за это же программистам зарплату платят! – говорит он.
– Да, платят. Но если изучить статистику успешных проектов в IT, становится грустно и хочется платить премию за выполненные в срок задачи.

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

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

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

Совещание заставляет бросить все свои дела и переключиться на что-то другое. Уверены ли вы, что часовое совещание, ради которого вы отрываете 8 человек, обычно высокооплачиваемых человек, стоит целого дня одного сотрудника? Часто ли совещания того стоят?

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

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

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

Как часто вы слышали от своих подчиненных такой вопрос? Почему именно этот вопрос о повышении верный? Давайте разбираться вместе.

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

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