Повышение сотрудника с возможностью понижения назад

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

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

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

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

Управляемость или бюрократия

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

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

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

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

Формулировка задачи делает разницу в результате

Как бы мы не поставили задачу программисту, подразумевается, что он будет программировать, тестировщик —  тестировать, аналитик — анализировать и т.д. Однако, формулировка имеет значение, так как настраивает на правильное отношение к задаче.

Простой пример: у нас есть некоторое уже запрограммированное решение, нам надо его протестировать и выпустить.

Часто поступают следующим образом. Берут тестировщика и формулируют задачу так: «протестировать решение». Возможно, чуть более подробно: «Составить тест план, пройти по нему, проверить решение и т.п.».

Вроде нормально, но какой результат мы получим в конце? Например, возможны варианты: Читать далее

У вас нет багов от клиентов. Можно поздравить?

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

  1. Вы написали идеальный продукт.
  2. Ваш продукт не используют, даже если купили.

Сами выбирайте, в какой вариант выбрать.

Да, может быть еще один вариант — у вас сломаны почта, телефон, а аккаунт менеджеры мертвы, с вами просто не могут связаться.

SCRUM: scope спринта и срочная задача

При внедрении SCRUM часто возникает ситуация, когда в процессе спринта прилетает срочная задача. Например, критичный баг у клиента или на проде, задача от «большого начальника», который не привык ждать, и т.п. Возникает вопрос: «что делать и как с этим жить?».

Стандартно бывают несколько способов решить проблему:

  1. Если проект большой и над ним работает несколько продуктовых команд, то выделяют отдельную пожарную команду на исправление критичных багов.
  2. Всем прибегающим отказываем, мотивируя тем, что scope спринта не меняется и все будет, но в следующем спринте.
  3. Берем задачу в работу, потом в конце спринта констатируем, что вот опять не успели так как нежданчик прилетел. А если нежданчиков много, то можем и в принципе все планы не выполнить.

Разберем каждый из вариантов:

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

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

Берем задачу в работу, а потом жалуемся, что опять не успели и расстраиваемся по этому поводу и оправдываемся перед Product Owner’ом.

Читать далее

Как проводить собеседование с кандидатом: правила организации

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

Дружелюбное собеседование с кандидатом

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

Встреча кандидата

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

Процессы разработки ПО в большой и маленькой конторе

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

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

Читать далее

Внимание, манипуляция. Как легко вызвать доверие?

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

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

Читать далее

Мотивация человека зависит от поставленной задачи

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

Отсюда два вывода:

  • Берегите разработчиков и архитекторов, которые могут быстро и легко сделать документ. Такие люди редко встречаются. В частности, этот навык незаменим при прохождении различных сертификационных процедур, для которых нужно иметь HLA, Data Flow Diagram и т.п. Кроме этого, просто полезно иметь в своем распоряжении архитектурный документ. Пригодиться в будущем.
  • Если менеджер говорит: «У моего человека отличная мотивация и он легко сделает любую работу», то следует присмотреться к такому руководителю более пристально. Он может так говорить для красного словца, а, возможно, он просто плохой управленец. Ничего не понимающий в управлении командой и человеческой мотивацией. Необходимо понимать, мотивация работника зависит не только от лояльности к работодателю, но и от самой выполняемой задачи и формулировки при постановке цели.

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

В качестве начала обучения, рекомендую статью про ситуационную модель управления.

Лояльность к работодателю нельзя злоупотреблять. Да, человек не уволится и будет делать что вам нужно, но делать он будет медленно и «на отвали». Оно вам надо?

Кто такой технический директор или CTO?

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

То есть, чтобы не только отлично руководил, но мог и код писать.

СТО комикс

Читать далее