Управление проектами *

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

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

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

Одно недопонимание на встрече может стоить вам недель переделок. В этой статье рассказываем, какие визуальные нотации помогут бизнес-аналитикам и командам понимать друг друга без лишних ошибок. Простые схемы и диаграммы, которые ускорят работу и сделают процессы понятнее для всех: от заказчика до разработчика. Узнайте, как выбирать и применять BPMN, ERD, Sequence Diagram и User Story Mapping в реальных проектах.

Карта стейкхолдеров, карта эмпатии, agile чаще проваливается, мотивация по Герчикову, эффект Черномырдина, цезари, запрещенные фразы и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В недавнем материале о становлении отраслей в Китае я проводил параллели между мегапроектами КНР и СССР, где ключевую роль играли партийное администрирование, номенклатура и идеология. Это классическая модель «сверху» — когда государственная воля создает индустрию на пустом месте.

Но возникает вопрос: а возможен ли обратный путь? Может ли новая отрасль родиться «снизу» — не по указу, а благодаря энергии и энтузиазму лидеров, фанатов своего дела? Были ли в России подобные прецеденты?

Оказывается, да. И история эта уникальна. Представьте себе отрасль, которая начинается не с нуля, а с минуса. Когда «невидимая рука рынка» не просто не помогает, а душит любую инициативу. Государство остается в стороне. Первые участники рынка балансируют на грани выживания, а многие и вовсе сходят с дистанции с огромными потерями.

А теперь — прыжок на 30 лет вперед. Картина радикально меняется: игроки богатеют, товарооборот растет как на дрожжах, бюджет получает солидные отчисления.
Но самое удивительное — появляется и активно работает отраслевая наука: научные школы, исследовательские центры, конструкторские бюро. Фантастика? В России?

Поверьте, это не вымысел. Это реальная история успеха, в которой замешаны Николай Верещагин, Дмитрий Менделеев и… российское маслоделие.
Как это было? Причем тут экосистемы в ИТ? Расскажу прямо сейчас.

Здесь приведен перевод критической статьи из блога "John Farrier for software engineers" об "исследовании" о том, что "Agile-проекты проваливаются на 268% чаще".

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.

Если вам нравится восточная философия, устраивайтесь поудобнее. Сегодня рекомендуем книгу о том, как команда Alibaba нашла баланс между восточной и западной моделями управления и превратила некогда небольшой стартап в глобальную цифровую империю.

Автор книги — Брайан Вонг, бывший сотрудник Alibaba и один из первых американских работников компании. Он занимал ключевые позиции, включая роль помощника Джека Ма, и участвовал в стратегическом развитии бизнеса. На страницах он делится тем, что позволяет руководству Alibaba проявлять изобретательность и гибкость, а ещё рассказывает о ценностях компании и философии «ДАО Alibaba».

Слушай, друг, давай без лишних церемоний. Знаю, что заголовок звучит как очередная паникёрская статейка про то, как ИИ всех уничтожит. И да, понимаю — скорее всего, ты сюда зашёл с лёгким холодком в животе. Мол, блин, а что если правда? Что если завтра утром мне скажут: «Спасибо, Вася, но у нас теперь есть ChatGPT-менеджер»?

Расслабься. Налей себе чай (или что покрепче, если уже вечер), и давай поговорим по душам.

Страх — это нормально, но паника — нет

Я тоже проектный менеджер. За плечами больше 15 лет в проектах и бизнесе, видел взлёты и падения десятков проектов, руководил командами от 5 до 50 человек. И знаешь что? Когда десяток лет назад все начали кричать про ИИ, у меня тоже ёкнуло сердце. Думаю: «А что, если эти алгоритмы действительно умнее меня?»

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

Вот тут-то я и понял: заголовок этой статьи — полная чушь.

Почему ИИ не заменит проектных менеджеров

Человеческий фактор доверия

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

Ветеранам Хабра пора напрячься: время летит слишком быстро... В этом году нашему корпоративному блогу стукнуло 10 лет! За это время мы исследовали мир айтишки через самые разные сферы: от киберспорта и «фантазий о будущем» до классических технических «заглядываний под капот» с сотнями строк кода.

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

Вы часто слышите на конференциях: «Нужно быть продуктовой компанией!», «Проводите CustDev!», «Замеряйте метрики!». А на совещании звучит: «Почему мы не проводим A/B-тесты?», «Давайте сделаем CustDev с 100 пользователями!». Вы видите, что команда уходит в бессмысленную активность, а руководство требует «быть как Яндекс». В суровой реальности B2B-сделок, кастомных внедрений и длинных циклов продаж "продуктовые советы" часто разбиваются о необходимость сделать сложную интеграцию, соблюсти нефункциональные требования и договориться с комитетом из десяти человек.

Эта статья для CPO/PM и руководителей B2B, у кого сделки длятся 6–12 месяцев, решение покупает комитет, а 70% усилий уходят в интеграции и надёжность. Разбираем, где продуктовые практики дают отдачу, а где решают доменная экспертиза и безупречный delivery. Короче для тех, кто разрывается между «давайте сделаем продукт» и суровой реальностью проектов, кастома и длинных B2B-сделок. Разберёмся, когда CustDev и «быстрые эксперименты» дают ценность, а когда решает именно контекст и предметная экспертиза, чем полезна продуктовая функция, где PM не обязателен, и как управлять в циклах 6–12 месяцев без самообмана и продуктового фетишизма.

Ну и традиционно подписывайтесь на канал StrategicMove, там будет оповещение о новых вебинарах и полезностях.

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

В рамках еженедельных образовательных стримов прошла встреча по фреймворку для продуктовых команд - Scrum. Я скептически относилась к нему в десятые, когда "внедрение" было скорее модным, чем полезным. Но сегодня, имея в организационной структуре компании выделенные продуктовые команды можно точно сказать - Scrum лучший набор инструментов для разработки/создания нового продукта (и речь не только о цифровом продукте, конечно).

Запись встречи можно посмотреть здесь. Отвечу на любые вопросы. Ниже кратко резюме:
Scrum — фреймворк из группы гибких подходов (Agile). Может быть в комбинации с другими гибкими фреймворками. Немного о терминологии:
🕊️ Методология - система принципов, практик, процессов и правил для управления проектами на уровне всей компании. Правила организации процесса готовки с набором кулинарных книг и требованиям к кухне.
🕊️ Фреймворк - гибкая структура с набором рекомендаций, но без строгих правил. Позволяет адаптироваться под контекст. Рецепт конкретного блюда, где, вместо молока, если у вас аллергия, вы не можете добавить воду. Приготовьте другое блюдо.
🕊️ Подход - общая стратегия или философия управления проектами. Будете ли вы пользовать книгой рецептов при готовке или нет? Концептуально. Если да - европейская кухня или русская?
🕊️ Метод - конкретный способ решения задачи в рамках методологии или фреймворка. Обжаривать на открытом огне или с крышкой?
🕊️ Инструмент - инструмент. Не знаю, какое ему дать определение) Ложка, масло.
Итак:
🕊️ Подход: проектный
🕊️ Методология: Agile
🕊️ Фреймворк: Scrum
🕊️ Метод: Спринт, бэклог, ретроспектива и т.д.
🕊️ Инструмент: Agile poker planning, диаграмма сгорания спринта, kanban-board и т.д.

Если вы хоть раз работали в стартапе или команде с неопытным менеджером, то знаете этот особый вид утреннего кофе. Ты садишься за рабочий стол, открываешь чат, и ещё до первого глотка узнаёшь: "Всё отменяем! Срочно делаем вот это!"

На Хабре, как и в любом живом техническом сообществе, время от времени вспыхивают споры: «Зачем программисту гуманитарные науки?», «Философия — это пустословие», «От неё ни пользы, ни кода». Я не раз слышал подобные комментарии под своими статьями — и каждый раз они вызывали у меня не раздражение, а скорее грусть.
Потому что за этими словами стоит не просто непонимание, а потеря масштаба.
А масштаб — это как раз то, что отличает инженера от квалифицированного исполнителя, учёного — от техника.

Меня зовут Елизавета Ковальчук, и моя задача как бизнес-аналитика — быть связующим звеном между бизнес-задачами и технологическими решениями. Я не пишу код для роботов, а создаю для них технические задания — детальные инструкции, которые превращают рутинные операции в автоматизированные процессы. В этой статье я расскажу, как при выборе платформы Primo RPA мы сфокусировались не на быстрой замене, а на создании надежного фундамента для будущей автоматизации, сделав осознанный шаг к построению безопасной среды для автоматизации.

Agile-проекты проваливаются на 268% чаще. Исследование

Исследование, в котором приняли участие 600 инженеров-программистов из Великобритании и США, показало, что проекты, в которых применяются методы Agile Manifesto, на 268% чаще заканчиваются неудачей, чем проекты, в которых используются другие методы.

Исследования показывают, что с помощью новой методологии Impact Engineering можно снизить количество неудачных проектов по разработке программного обеспечения в 6,5 раз.

Внедрение Impact Engineering может сэкономить 115 млрд долларов США в год на бесполезных расходах на исследования и разработки в США, а британские налогоплательщики могут сэкономить около 7 млрд фунтов стерлингов в год на неудачных государственных проектах по цифровой трансформации.

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

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

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

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

И со временем я заметил: в неопределённости мы не выбираем, кем быть. Мы возвращаемся к «заводским настройкам» — к тем автоматизмам, которые и формируют паттерны поведения. Я назвал их метафорически — «социопат», «дохристианин», «кантианец», «христианин», «буддист» — не как вероисповедание, а как архетипы отношения к миру, к другому человеку, к несправедливости.

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

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

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