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

Когда у вас проблемы на проекте, вам хочется прийти к руководителю, выговориться, пожаловаться, чтобы похвалили и сказали, что надо делать. И лучше, чтобы не по телефону, а лично. Если у вас такое было или есть (у меня было, знаю, о чем пишу), знайте: это нормальная человеческая реакция – в сложный момент хочется поддержки, выговориться, обняться и порыдать - но это непрофессиональная реакция. Вы не на сеансе у психолога, вы на работе. Здесь не платят за "послушать, обнять и принять".

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

Это очередная статья о том, чего не расскажут на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Leading индикаторы измеряют действия, которые происходят до достижения результата, и позволяют предсказывать успех или проблемы. Lagging индикаторы фиксируют результаты этих действий, которые можно измерить только после завершения работы. Оба типа метрик важны и взаимосвязаны: изменения в leading индикаторах могут повлиять на результаты, которые отражают lagging индикаторы.

Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. 

Не так давно мы стали внедрять Индивидуальные Планы Развития (ИПР-ы) в Хабре и это оказалось непросто. Нам стало любопытно: каким специалистам они подходят, как влияют на мотивацию, повышение и как их собирать, чтобы сотрудникам было по-настоящему интересно по ним идти. 

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

К исследованию подключили команду платформы корпоративного обучения Грейд от Яндекс Практикума — оказалось, что ребята умеют круто наполнять ИПР-ы и собирают индивидуальные образовательные треки под каждого специалиста. 

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

Привет! Нас зовут Даниэл Кнежевич и Максим Макеев. Мы руководим центром компетенций разработки в компании ITQ Group, отвечаем за бизнесовую и техническую часть работы подразделения. В этой статье мы обсудим предпроектное исследование — важный этап разработки IT-проектов. 

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

Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.

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

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

Что с ними не так? Предлагаю разобраться в причинах и следствиях.

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

Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи оставлю ссылки на 2 других статьи из серии.

Тимлиду постоянно приходится отвечать на вопрос «когда сделаете?» или «когда будет готово?». И часто для ответа на этот вопрос нужно отвлечь от работы своего сотрудника, обсудить с ним задачу и только после этого дать ответ.

Не факт, что ответ совпадет с реальностью. И любой руководитель знает, что для того, чтобы гарантированно уложиться в названый срок, нужно заложить минимум трехкратный запас времени. Заказчики этот принцип тоже знают и поэтому стремятся срезать срок, насколько это возможно. Тимлиду опять приходится отвлекать сотрудника и обсуждать с ним «варианты оптимизации сроков выполнения». Потом цикл повторяется до тех пор, пока кто-то — либо заказчик, либо тимлид — не упрется рогом, не продавит свое решение.

Недовольными, как правило, оказываются все. Тем не менее все постоянно играют в эту игру, и никто никому не верит.

Однако, если использовать исторические данные по сделанным ранее проектам и задачам, то можно узнать с 80% вероятностью срок исполнения задачи любого типа. Никакой магии. Просто математика и немного теории вероятностей :)) В этом суть Канбан-метода.

Привет! В одном из прошлых постов мы рассказывали вам, что в МКБ пришел Главный архитектор (ГА), Клецких Дмитрий. Проанализировав и оценив состояние дел, новый руководитель занялся изменениями, внедрением новых процессов и методологии. Собственно, об этом и будет пост.

Общее

Цель

• подготовка к рабочему дню и планирование его;
• оценка предыдущего своего рабочего дня;
• поделиться информацией и планами с коллегами;
• получить информацию от коллег, которая может пригодится в течение рабочего дня.

Привет, Хабр! Меня зовут Артур Темиров, я delivery‑менеджер в одном из продуктов X5 (о нём дальше в тексте). Над его созданием у нас трудятся 5 технических команд — в общей сложности это более 60 человек. В статье рассказываю о том, как визуализация является отправной точкой для эволюционного развития процессов, а также об ошибках, которые могут допускаться на этом пути.

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

На канбан-досках могут быть различные виды задач, в зависимости от конкретного проекта, типа бизнеса или потребностей команды. В этой статье разберём основы ведения учета задач на Канбан-доске, необходимые колонки, виды и типы задач, в том числе Epic, userstory, task.

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

Полезные борды и другие приёмы из личной практики.

Все руководители проектов слышали словосочетание «управление рисками». Если спросить на собеседовании, что такое риски и как ими управлять, видно, что РП усердно вспоминают определение риска, вспоминают слово «митигация», но вот ответить на вопрос о том, как с этим работать, не может почти никто. В тоже время есть много книг, посвященных управлению рисками в проектах, на Хабре есть несколько интересных статей (я гуглил, пока готовился).

Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?

Давайте разберемся с рисками.

Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 25 лет опыта в ИТ. Если вам такой опыт интересен, читайте другие мои статьи здесь на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Привет, архитекторы, разработчики и неопределившиеся! Меня зовут Сергей Врунов. Я работаю в ВТБ и занимаюсь развитием ИТ-архитектуры. Все мы сталкиваемся с религиозными «архитектурными» дискуссиями и производственными конфликтами на ровном месте. Кажется, у вас есть классное решение или предложение, но почему оно так плохо заходит или вообще не заходит? Что делать? Какой профиль успеха архитектора?

Архитектурная психология! Читайте наш «Кодекс архитектора», создавайте на его основе свой и приносите пользу организации.