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

Делитесь в комментариях своими идеями: что, с вашей точки зрения, лучше — сильная рука тимлида или доверительные отношения в команде?

Часто слышу от людей, которые только хотят войти в IT, что “если ты гуманитарий, а в QA идти не хочется, то есть один путь – в менеджеры проектов”. Им кажется, что рабочий день выглядит так: провел 2-3 встречи, выпил 3 чашки кофе, построил Гант, промотивировал команду и можно идти домой.

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

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

Некоторых разработчиков иногда сравнивают со снежинками — они уникальные, выдающиеся, и, естественно, самоуверенные. Работать с «обычными» сотрудниками легко. Гораздо труднее справляться с проблемными типажами. Одинокий волк, всезнайка, перфекционист — в каждой команде есть человек, с которым сложно и руководству, и коллегам. Автор статьи, программист и сооснователь digital-агенства Mindnow, Вадим Кравченко рассказывает, как не усугубить ситуацию с трудными сотрудниками, превратить сложности в возможности для роста и продолжить успешную командную работу. Особенно, если проблемный коллега талантлив и приносит пользу компании.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

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

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

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

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

Делимся своим подходом к разработке матриц компетенций. Статья сможет помочь тимлидам, руководителям ИТ-компаний и HR понять, как разработать и использовать матрицу компетенций, если у вас большое технологическое разнообразие в компании.

Привет! На связи снова стрим Люди+. В этом году мы запустили большой и очень амбициозный проект — системное управление компетенциями в ИТ. Проект огромный и состоит из нескольких ключевых блоков, о которых мы будем рассказывать в следующих статьях. Однако, начнем с основы основ любого управления компетенциями — матриц.

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

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

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

• Как отношения внутри команды влияют на достижение цели?
• Из-за чего сильные сотрудники могут не уживаться в коллективе?
• Как сделать команду привлекательной для новичков?
• Через какие этапы становления проходит команда?
• Какие кризисы связаны с переходом на новый этап?
• Как история IBM и Apple демонстрируют уровни спиральной динамики?

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

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

Получали когда‑нибудь от своих сотрудников подобные ответы? Особенно часто это бывает, когда речь идёт не о задаче в Jira, которая видна на доске, а о менее формальных договорённостях.

— прочитал доку к сегодняшней встрече? — не, не успел.

Привет, Хабр! Я Костя — Lead QA в tekmates. Мы в компании создаём цифровые продукты для бизнеса. Проработав более трёх лет проджект-менеджером и больше года лидом QA-инженеров, я много раз оценивал задачи по времени выполнения. И не всегда это давалось (да и даётся) легко… 

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

Привет. Я активно провожу собеседования с 2017 года на разные позиции. За период с 2022 по 2024 год провел больше 250 собеседований с scrum‑мастерами, agile коучами и руководителями agile трансформации. На прошлом месте работы кластер (на новом — домен) — это группа продуктов/платформ/сервисов. Они объединены вокруг пользовательского сегмента/индустрии или еще по какому‑либо принципу. В кластере/домене — от 300 до 1500 человек.

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

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

Этот опыт я описал для себя и напарников, и так же выкладываю кейсы в канал в telegram.

Привет, Хабр! Это Оля Муттер, руководитель IT-проектного офиса в Купере (ex СберМаркет). Жизнь заставила меня научиться настраивать процессы как боженька. Я стартовала карьеру в роли бизнес-аналитика, доросла до директора продукта в финтехе, успела побывать наставником для проджектов, создать несколько проектных офисов и центров компетенций — всего за десять лет.

Сейчас я рулю проектным офисом в Купере (ex СберМаркет) — это 1300+ человек в IT-команде. Как понять, работает ли такая большая система эффективно? И что делать, если какая-то веточка этого гигантского дерева растет не в ту сторону? Об этом моя сегодняшняя статья. 

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

На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox. 

В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.

Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.

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