Привет! Я IT-лидер с 15-ю годами управления сложными процессами, проектами и командами 100+ человек. Сочетаю в себе профиль: tech + business + people + transformation. Основной мой трудовой путь сосредоточен в телекоме и производстве. У меня накопилось достаточно систематизированных знаний, чтобы поделиться ими с широкой аудиторией.
Это моя первая статья — делюсь анализом ситуации в найме «звезд».
Покупка профессионала из другой компаний — это не приобретение готового решения.
Для повышения эффективности управления производством часто предлагают ввести жёсткий контроль за каждым работником, сократить количество перекуров и повысить уровень дисциплины. Однако сотрудники — не бездушные механизмы, которые могут постоянно поддерживать одинаковый уровень производительности. Подобное отношение к людям может привести к их переутомлению и эмоциональному выгоранию. В результате они потеряют мотивацию и желание хорошо выполнять свою работу.
Тогда какие действия можно предпринять, что добиться той самой эффективности?
Почти 6 лет мы в WPP.DIGITAL использовали классические грейды, чтобы оценивать квалификацию наших разработчиков. За это время пережили многое: проводили многочасовые интервью, шлифовали матрицу компетенций, убеждали сеньоров не скромничать, а джунов – не быть слишком уверенными в себе. Но вопросы все равно оставались: что делать, когда разработчик крут в одном стеке, но новичок в другом? Какой у него грейд? И главное – отражают ли оценки реальную эффективность специалиста?
Рынок digital-услуг в России в 2025-м остается хаотичным, без четких стандартов и объективных критериев качества. Клиенты не могут заранее понять, кто выполнит работу хорошо, а кто просто продаст красивую презентацию. Изначальные причины этого понятны. Агентства не продают готовый продукт, а оказывают услугу по созданию этого продукта, поэтому их реальный уровень становится очевидным только после начала работы. Это базовые условия, проблем не в этом факте, а в том, что происходит дальше.
В мире, где «культ обучения» обгоняет «успешный успех» и каждый уважающий себя работодатель считает важным обучать сотрудников чему угодно, зачастую сталкиваешься с парадоксом: многие хотят учиться, но далеко не все используют предоставленные возможности.
В этой статье я постарался честно и вдумчиво проанализировать свой опыт выгорания и последующего восстановления нормального уровня энергии. Если что-то упустил, спрашивайте в комментариях.
Мне 48 лет, сидячий образ жизни, интеллектуальный труд. С одной стороны вредных привычек нет, с другой, — спорта тоже явно не хватает. Похожая ситуация с питанием: не хожу в фастфуд, но и не сижу на ПП (полезное питание). Самый большой стресс для меня — это общение с людьми, которые мне не рады и выполнение задач, которые не интересны. Мне нравится глубоко изучать вопрос, так что, если статья покажется затянутой, не обессудьте.
В этом материале американский программист с двадцатилетним опытом работы объясняет, почему заниженная зарплата и семидесятичасовая рабочая неделя губительны для любого стартапа.
Приходила ли вам голову мысль вроде: «Мне нужна такая работа, на которой мне будут платить гораздо, гораздо меньше, чем стоит мой труд?». Вот и я никогда так не думал. И тем не менее существуют такие компании, которые не только платят меньше, но еще и гордятся этим фактом. Позвольте объяснить, о чем я говорю.
Недавно я увидел вакансию как раз от одного из таких стартапов. В подобных случаях я обычно раздражительно закатываю глаза и иду себе дальше, но текст этого объявления настолько поразил меня своим содержанием, что если бы я отреагировал как обычно, то мои глаза смотрели бы сейчас мне в затылок.
Читать полностью »
Эффект Зейгарник может помочь повысить вашу работоспособность. Сначала я объясню, в чем заключается идея, а затем дам практический совет, как можно применить ее в обучении.
(начало статьи здесь)
С другой стороны — этот эффект не имеет названия; возможно, его следовало бы именовать «десятикрадничеством» — плохие разработчики будут стоить вам отнюдь не незначительного ухудшения производительности труда. Нет, по целому ряду трудноуловимых причин они способны катастрофически саботировать сложную программную систему. Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте. Хуже того, работа по разбору завалов потребует привлечения усилий гораздо большего количества хороших разработчиков, и на более длительное время.
В этом моменте разработка программного обеспечения является полной противоположностью другим отраслям — скажем, аэрокосмической, — в которых некомпетентность и грубые ошибки гораздо более очевидны; их легче обнаружить и исправить на ранних этапах, пока стоимость такого исправления ещё не выросла до небес. Отсроченные кризисы (вроде конструкции самолёта, в которой в ходе реальной эксплуатации обнаружился фатальный дефект) также гораздо легче удержать от распространения, изолировать и исправить.
