Многие хотят повышения в должности, но когда долгожданное повышение приходит, то результат может оказаться разочарованными. Почему так происходит?
При повышении с позиции разработчик на позицию старший разработчик, проблем обычно не бывает. Зарплата становится больше, задачи сложнее и интереснее, такое большинству нравится. А вот в случае, когда происходит повышение до позиции teamlead или руководитель проекта, то могут возникнуть проблемы. Человек становится маленьким руководителем, на него сваливаются административные задачи. Он начинает плавно мигрировать в другую профессию, от специалиста в управленца, а профессия управленца нравится не всем.
Помучавшись некоторое время, повышенный сотрудник увольняется и уходит работать в другое место на позицию специалиста. В результате компания теряет хорошего специалиста, который так и не стал руководителем.
Что делать в такой ситуации? Повышая человека, сразу проговорите, что если ему не понравится, то вы все вернете назад, нужно только сказать об этом. На моей практике несколько человек воспользовались джокером на возвращение. Более того, они стали супер лояльными по отношению к компании и линейным руководителям. Побывав в их шкуре, они понимают, что быть начальником не так уж и просто.
Многие компании тонут в подмене понятий — управляемость измеряют бюрократией и формальностями. Чем более формализованный процесс, чем больше согласований, тем лучше управляемость. Все в точности наоборот.
Когда любое действие требует четко зафиксированного процесса и апрува, то в итоге все замыкается на самого большого начальника, который становится бутылочным горлышком. Казалось бы — вот оно управленческое счастье, все у тебя под контролем, а на практике получается, что ты не можешь осмысленно принимать такое количество решений и начинаешь согласовывать все подряд. В результате имеем «бардак, зато ты главный».
Альтернативный вариант: меньше бюрократии, больше делегировать на места, самому заниматься высокоуровневыми вопросами.
Возникает резонный вопрос: «Как не допускать ошибок? Вдруг подчиненные накосячат и все сломается?»
Ответ: «Никак, без ошибок не получится, но можно избежать фатальных ошибок.» Как это сделать расскажу в следующих сериях.
Как бы мы не поставили задачу программисту, подразумевается, что он будет программировать, тестировщик — тестировать, аналитик — анализировать и т.д. Однако, формулировка имеет значение, так как настраивает на правильное отношение к задаче.
Простой пример: у нас есть некоторое уже запрограммированное решение, нам надо его протестировать и выпустить.
Часто поступают следующим образом. Берут тестировщика и формулируют задачу так: «протестировать решение». Возможно, чуть более подробно: «Составить тест план, пройти по нему, проверить решение и т.п.».
Вроде нормально, но какой результат мы получим в конце? Например, возможны варианты: Читать далее →
Если у вас нет багов и жалоб от клиентов, то причины возможны две:
- Вы написали идеальный продукт.
- Ваш продукт не используют, даже если купили.
Сами выбирайте, в какой вариант выбрать.
Да, может быть еще один вариант — у вас сломаны почта, телефон, а аккаунт менеджеры мертвы, с вами просто не могут связаться.
При внедрении SCRUM часто возникает ситуация, когда в процессе спринта прилетает срочная задача. Например, критичный баг у клиента или на проде, задача от «большого начальника», который не привык ждать, и т.п. Возникает вопрос: «что делать и как с этим жить?».
Стандартно бывают несколько способов решить проблему:
- Если проект большой и над ним работает несколько продуктовых команд, то выделяют отдельную пожарную команду на исправление критичных багов.
- Всем прибегающим отказываем, мотивируя тем, что scope спринта не меняется и все будет, но в следующем спринте.
- Берем задачу в работу, потом в конце спринта констатируем, что вот опять не успели так как нежданчик прилетел. А если нежданчиков много, то можем и в принципе все планы не выполнить.
Разберем каждый из вариантов:
Пожарная команда — это наказание, быть в ней скучно. Чем ей заниматься, если багов не прилетает тоже непонятно. Могут, конечно, править старые баги или техническими долгами заниматься, но это все демотивирует разработчиков.
Не меняем scope спринта. Начнем с того, что всем не откажешь. Всегда есть человек с нужным административным ресурсом, которому отказать не удастся. Но даже если отказывать умеем, то что делать с лежащим продом? Обычно он не готов ждать до следующего спринта, чинить надо здесь и сейчас. Поэтому такой вариант ведет к бесконечным конфликтам с контрагентами, эскалациям, а делать все равно придется.
Берем задачу в работу, а потом жалуемся, что опять не успели и расстраиваемся по этому поводу и оправдываемся перед Product Owner’ом.
Ниже 11 простых правил, которые помогут поднять мотивацию у ваших подчиненных. Однако, их постоянное соблюдение может потребовать усилий.
- Избегайте заблуждения: «Все работают только за деньги». В технологических компаниях (а я пишу в основном про IT) сотрудников мотивируют интересные задачи. При отсутствии интересной работы от вас все разбегутся, не смотря на хорошую зарплату, а оставшиеся – это люди, которым все равно что делать. Таких надо увольнять самому.
- Интересные задачи – это здорово, но нельзя ухудшать условия труда сотрудников. Сразу поползут слухи, что в компании всё плохо, а это быстро демотивирует весь коллектив.
- Используйте объективные критерии при премировании.
- Создавайте возможности для профессионального роста и творческой самореализации сотрудников. Давайте людям задачи для развития, старайтесь выбирать такие, которые им интересны.
- Хвалите их за успехи, говорите «спасибо». Не бойтесь хвалить публично. Когда рассказывайте об успехах команды или отдела, обязательно скажите, кто конкретно отличился. А вот ругать и делать замечания нужно один на один.
- Фокусируйтесь на сильных сторонах персонала. Ошибка обращать внимание на сотрудника только тогда, когда он допустит промах.
Интересные материалы:
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов: Читать далее →
Собеседование с кандидатом при приеме на работу всегда является двухсторонним процессом. Не только вы оцениваете кандидата, но и он вас. Возможно, при найме на низкоквалифицированные позиции в магазине «Пятёрочка» абсолютно не важно, что о вас подумают, но в случае поиска специалистов в области информационных технологий это не так.
Сейчас квалифицированный человек может легко получить несколько предложений о работе за пару недель походов по собеседованиям, и он будет выбирать работу, а не работа его. Поэтому важно проводить собеседование с кандидатом так, чтобы он захотел с вами работать.
Встреча кандидата
Отнеситесь к проведению собеседования с кандидатом, как ко встрече с партнером. Вы ведь рассчитываете, что этот человек будет работать у вас. Красную ковровую дорожку стелить не требуется, но можно организовать базовые приятные вещи: Читать далее →
Однажды к нам в команду пришел талантливый программист Константин, который до этого работал в небольшом интернет магазине. Магазин был продвинутый, не просто сайт на стандартном шаблоне, а собственная разработка, боты для социальных сетей, чат боты и все на тот момент самое модное и современное. Константин занимался всеми этими задачи, имел широкий кругозор и хорошо знал много технологий.
Но была у него одна проблема. Полное непонимание различий процессов разработки в маленькой компании и большом проекте. В небольшой фирме разработчик уровня Константина является самым главным техническим специалистом, он сам выбирает технологии, определяет процедуры разработки, отвечает за качество. Задачи он обсуждает с самим владельцем фирмы. В общем, является уважаемым и самостоятельным человеком.
по RSS
Последние комментарии