Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Безопасная разработка, управление рисками и внутренний контроль
📌 Проектирование архитектуры через User Stories, часть 1. Вовлекаем в процесс заказчика
📌 Осмысленная визуализация при анализе и проектировании в действии
📌 Проектирование интеграции. Чек-лист — как подготовить архитектурное решение
📌 Искусство предсказаний: 12 правил для точной оценки разработки проекта



Карьера и навыки менеджера проекта
🥇Основы тайм-менеджмента: как эффективно распоряжаться своим временем
🥇Сложности перехода на эфемерную среду тестирования или к чему готовиться проектному менеджеру?



Команда проекта
👨‍👦‍👦 «Нельзя просто так взять и построить команду мечты» – а я рассказываю, как это получилось у меня
👨‍👦‍👦 Архитектор 2.0
👨‍👦‍👦 WIP-лимиты помогают тимлиду усилить команду: рассказываем, как их внедрить и какие могут быть ошибки
👨‍👦‍👦 Как я стала тимлидом и стоило ли оно того
👨‍👦‍👦Доводим разработчика до выгорания: три простых шага
👨‍👦‍👦Как мы создавали и внедряли свою матрицу компетенций
👨‍👦‍👦Какие проблемы может помочь решить DevOps as a Service? Пожар инфраструктуры и управление командой
👨‍👦‍👦Подчинённые сигнализируют, что их руководитель некомпетентен. Что делать, как реагировать?
👨‍👦‍👦Внутреннее обучение в компании



Кейсы, опыт, советы, мнения
🦋 Как заказчик пришел к нам за новой фичей, а мы его отговорили
🦋 Релиз без ошибок. Невозможное возможно?
🦋 5 исходов, которые ждут бизнес, если в разработке не будет участвовать ЛПР
🦋 Как грамотно управлять командой и всё успевать, не срывая дедлайны?
🦋 Почему так важно писать техническое задание


Инструментарий
🛠 Книги по менеджменту vs. ГОСТы
🛠 Обзор сервиса Доски — простого и мощного инструмента для командной работы
🛠 Использование опросов в проектном менеджменте



YouTube
🔴 Проектирование системы от нефункциональных требований
🔴 Как Канбан пришел в Россию. История развития Канбан-метода
🔴 Лекция от Дмитрия Макарова по теории проектирования функциональности продукта: Модель Кано
🔴 Кроссдоменный проект
🔴 Требования или модели - как писать постановки
🔴 Персональная стратегия развития в области бизнес- и системного анализа
🔴 Не по шаблону: выбираем подходящую структуру ТЗ
🔴 Бережливая работа с требованиями или почему ТЗ больше не нужно
🔴 Процесс управления требованиями
🔴 Как говорить на языке заказчика
🔴 Сказка о масштабировании команды и потерянном времени
🔴 Gunther Verheyen talks about "Moving (your) Scrum Downfield"

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌Scrum ужасен
📌От бизнес-идеи к техническому заданию. Список необходимой информации
📌Техническое задание: как и зачем его писать, и почему без него не обойтись
📌Инструкция. Как брифовать клиента
📌«Кто на ком стоял?» Про страдательный залог в технической документации
📌Не спринт, а марафон: как выстроить процесс согласования на ИТ-проекте
📌25 вопросов и ответов по терминам REST API на собеседовании по вакансии системного аналитика
📌Полный релиз бесплатного интерактивного 700-страничного учебника по тестированию
📌Рассчитываем бэклог спринта не на глаз



Карьера и навыки менеджера проекта
🥇Как презентовать дизайн-концепцию, чтобы не обосраться перед заказчиком. Готовый скрипт + чек-лист
🥇Метод SMART. Что это и почему про него важно знать руководителю?
🥇Зачем нужен проектный офис, если компания работает в продуктовом подходе?
🥇Вы — новый руководитель. Как успешно пройти адаптацию в сложившемся коллективе?
🥇Как капля стресса превращается в волну проблем и что с этим делать
🥇Пять ошибок начинающих проджект-менеджеров
🥇Уводим стартап от «конвеерной штамповки фичей». Включаем продуктовый подход и начинаем считать ROI



Команда проекта
👨‍👦‍👦  Критика и два вида душности: Душилы и душнилы
👨‍👦‍👦 Почему в OKR командные цели работают лучше персональных?
👨‍👦‍👦 Обратная связь: как прийти к результату и не потерять команду

Кейсы, опыт, советы, мнения
🦋 LOD-ка, или один из способов «потопить» проект
🦋Как работать с legacy проектами: проблемы и стратегии решений
🦋Опыт IT-компании: как отслеживать окупаемость проектов и трекать затраты


Инструментарий
🛠 Архитектура веб-приложений, Gitflow и REST API: доклады с Backend-митапа red_mad_robot
🛠 Искал таск-трекер, а нашёл чудо! Точнее, российский таск-трекер Kaiten со встроенной системой Service Desk



YouTube
🔴 Когда стоит делегировать документацию техническому писателю
🔴 Круглый стол: Грейды и компетенции в разных компаниях
🔴 Requirements & API. Part 2 out of 2.
🔴 Не говори никому, что делаешь трансформацию! Kanban Maturity Model
🔴 Децентрализация функции бизнес-аналитиков: как не потерять в качестве.
🔴 Вебинар: «Process Mining – способ анализа процессов»
🔴 Проектирование системы от нефункциональных требований

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Как спектральный анализ улучшает оценку задач и снижает стресс в команде разработки
📌 Пользовательская документация как путеводитель по продукту
📌 Критерии приемки для пользовательских историй: цели, форматы, примеры и лучшие практики
📌 Проведение Triforce встреч для определения критериев приемки
📌 Основы Scrum менее чем за 10 минут (Scrum Alliance)
📌 Методология Водопад (Waterfall) в IT

Карьера и навыки менеджера проекта
🥇Из PM-ов в разрабы. Шаг назад для продвижения вперёд
🥇Продакт против директора
🥇Эффективное управление отношениями со стейкхолдерами
🥇Как побеждать выгорание в IT и жить свою лучшую жизнь на удалёнке?
🥇50 когнитивных искажений v1.5
🥇Как проджекту найти работу: 5 лайфхаков

Команда проекта
👨‍👦‍👦 Конфликт — двигатель прогресса. Как привить в компании культуру конфликтов
👨‍👦‍👦 Бывший разработчик не станет предпринимателем, пока не научится строить команду
👨‍👦‍👦 Продуктовые команды: строим правильно
👨‍👦‍👦 Не бойтесь брать джунов
👨‍👦‍👦 Мечтают ли сотрудники о целях компании?
👨‍👦‍👦 Как мы в Авито открыли школу тимлидов аналитики и за 3 месяца подготовили 15 будущих руководителей
👨‍👦‍👦 15 способов мотивировать сотрудников без денег. Когда повышение зарплаты вредит?
👨‍👦‍👦 Удаленное управление: наши лайфхаки по объединению команды
👨‍👦‍👦 Воркейшн, театр продуктивности и другие 13 слов и выражений, которые позабавят фанатов удаленки
👨‍👦‍👦 Формирование культуры, ориентированной на разработчиков

Кейсы, опыт, советы, мнения
🦋 Как мы перешли на кроссплатформенность в середине проекта и успели в срок
🦋 Что делать, если разработчики и бизнес-подразделения компании не могут договориться
🦋 Плохо девелопмент
🦋 Как превратить сырую идею в реально успешный продукт: полезные советы, лайфхаки и немного личных историй

Инструментарий
🛠 Как язык моделирования ArchiMate помогает IT аналитикам в решении их задач
🛠 Как из брейншторма выжать максимум: мнение эксперта и 5 сервисов, чтобы раскрыть потенциал команды
🛠 Сможет ли Squadus заменить Teams в 2023 году: делимся опытом первого пилота
🛠 MeetGeek: как ничего не упустить на большом созвоне — без пересмотра видео, регистрации и смс
🛠 Как содержать документы и базы знаний в порядке: замена Confluence российским сервисом EvaWiki
🛠 «‎Ваш идеальный инструмент для связи» или Заключительная часть рассказа про новинку среди Российских мессенджеров
🛠 Сколько стоит «джентльменский набор» для бизнеса и как сэкономить 300 000 ₽
🛠 Обзор российских онлайн-досок: что выбрать для бизнеса?

YouTube
🔴 PRO Конфликты: учимся разжигать и тушить с пользой для дела и карьеры
🔴 Организовали самоуправление в компании. Кейс косметической компании
🔴 How to Be a High-Performing Business Analyst
🔴 Метод триггера. Как безоценочно дорабатывать идеи во время мозгового штурма?
🔴 Формула эффективности команды. Как измерить Scrum-мастера
🔴 Feature Adoption: как выжать из фичи максимум
🔴 Путеводитель по оценкам задач
🔴 Шаг 0: контекст незнакомой команды
🔴 Как большая Человечность позволяет добиваться выдающихся результатов
🔴 Вас много, а я один: как измерять эффективность команд, когда их у тебя 105000?

Всем привет!
Крайне редкая (пока) рубрика "Спрашивали - отвечаем" 😁

В.: Что делать, если план по которому шли 70% разработки, стал неактуален и затрещал по швам и сейчас нет никакого плана будто бы и разработка ведется интуитивно.
Как тут не обосраться и добавить прозрачность и контроль разработке?

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

В каком-то смысле любой проект - это борьба планирования с катастрофой.
Что делать, если (опять) произошла катастрофа? Очевидно, снова делать план. Настоящий план - он как автопересчет в экселе: каждый раз должен меняться вслед за изменениями во вводных и откликаться на каждую аномалию в ожиданиях.

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

По "прозрачности и контролю". В ситуации катастрофы важна локализация. Вряд ли у нас накрылось прямо всё - и, если это, слава богу, так, то надо отделить зону стабильности, так чтобы туда не проникли хаос и паника. И такие же островки стабильности нужно искать в "зоне катастрофы". Поначалу R&D (поиск причин и перестройка) будут не поддаваться планированию, это нормально. Но как только мы начнем справляться и понимать, - начинаем планировать, а затем и корректировать планы.

PS. Написано с утра, на языке метафор и аккурат после такой очередной микро-"катастрофы", не судите строго)

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Что такое HADI-циклы и как они помогают управлять техническим продуктом
📌 "Я не понял. Давайте делать”. Как правильно давать обратную связь
📌 Кто такой Scrum-мастер, и зачем он нужен команде
📌 Управление проектами в IT-индустрии: лучшие практики и инновационные подходы
📌 Где брать знания бизнес-аналитику? Подборка бесплатных ресурсов
📌 Покер планирования: как максимально прозрачно планировать спринты
📌 Writing An Efficient Software Design Document
📌 CodeCraft: Agile Strategies for Crafting Exemplary Software
📌 The Difference Between Right Sizing and Same Sizing of Work Items (and Why You Should Care)


Карьера и навыки менеджера проекта
🥇Как делегировать задачи сотрудникам в зависимости от стиля управления
🥇Как получить максимальную пользу от опыта международных ИТ-проектов: главные уроки в текущей реальности
🥇Убийство без крови… Как не превратить коммуникацию с клиентом в хоррор
🥇Гибкость руководителя проектов: Ключ к успеху в быстро изменяющемся мире
🥇10 Signs You Might be Micromanaging your Scrum team
🥇Типы и стили лидерства: как стать лидером, а не просто руководителем

Команда проекта
👨‍👦‍👦  Как цели ведут команды к успеху
👨‍👦‍👦  Остаться в живых. Токсичность в ИТ глазами девушки-лида
👨‍👦‍👦  Быстро, без стресса и лишних созвонов: как небольшая команда Kaiten работает над продуктом
👨‍👦‍👦  Наняли 30 джунов за год: рассказываем, зачем и как
👨‍👦‍👦  Без стресса, дедлайнов и каши в голове: 5 секретов продуктивной командной работы
👨‍👦‍👦 Ролевые игры в офисе. Как проводить диагностику команды при помощи ролевых игр
👨‍👦‍👦  Как собрать крепкую команду, если вы недавно стали тимлидом
👨‍👦‍👦  Без начальников и менеджеров: как компании дают сотрудникам полную свободу
👨‍👦‍👦  «Человеческая» сторона ИТ. Распространённые проблемы разработки, связанные с людьми
👨‍👦‍👦  Метод «помидора» для повышения эффективности продуктовых команд

Кейсы, опыт, советы, мнения
🦋 Планировали, планировали и выпланировали
🦋 Вы точно хотите пойти программистом в gamedev?
🦋 Как повысить эффективность техподдержки в 3 раза и спасти сотрудников от нервного срыва. Кейс Core12
🦋 Как команда технарей свой бизнес создавала. Сезон 4 – крах и рост в серийного предпринимателя с амбициозным проектом

Инструментарий
🛠 Как рынок заставил нас сделать аналог Jira (расшифровка аудио записи)
🛠 Принципы непрерывного рефакторинга
🛠 Zetep рубль бережет: бюджетный аналог Asana

YouTube
🔴 Как OKR помог нам выстроить работу в компании. Кейс Тинькофф
🔴 Не говори никому, что делаешь трансформацию! Kanban Maturity Model
🔴 Техника мозгового штурма холивар. Как найти позитивное решение в любом вопросе?
🔴 Do You Really Have a Team?

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Мастерство гибких процессов в заказной разработке. Ключевые шаги к успешному сотрудничеству между вендором и заказчиком
📌 Проектируйте правильно
📌 Product Manager IT проектов
📌 Хороший, плохой, никакой: почему важно проектировать дизайн и как это делать?
📌 Ваша карта не будет бита: как добавить Impact Map, CJM и USM в документ и не пострадать
📌 Как использовать фреймворк JTBD в разработке IT-продукта: пошаговая инструкция
📌 CJM или клиентское путешествие: коротко о главном или повторение — мать учения
📌 За что компании уровня Google и Intel любят OKR?


Карьера и навыки менеджера проекта
🥇Микроменеджмент — что это за зверь и как с ним бороться
🥇Наставнический стиль руководства: как эффективно «вырастить» сотрудника
🥇Может ли школьный учитель управлять IT-проектом?
🥇Как понять, что профессия менеджер проектов — для тебя?
🥇Как выиграть дуэль с тим-лидом и клиентом. Правила мгновенной прокачки экспертизы и уверенных переговоров в любой подход

Команда проекта
👨‍👦‍👦  Performance Review: путь от чайка-менеджмента к системной оценке сотрудников
👨‍👦‍👦 Как поднять холодильник на новый уровень: рецепты эффективной командной работы
👨‍👦‍👦 Нужно ли разработчикам проектирование?
👨‍👦‍👦 Автономия разработчиков. Как устроены компании нового типа
👨‍👦‍👦 «Я его обучу, а он уйдёт». Формула, которая должна остаться шуткой
👨‍👦‍👦 Как российская IT-компания выстраивает корпоративную культуру для удаленных сотрудников, не хуже, чем в Google
👨‍👦‍👦 Как раскрыть потенциал аналитиков
👨‍👦‍👦 Как общаться с коллегами, которые бесят, и не перейти на КАПС?
👨‍👦‍👦 Как устроить работу между дизайнером и продактом, чтобы не рисовать концепты в стол
👨‍👦‍👦 Почему материальная мотивация не работает и что действительно вдохновляет людей идти к чему-то большему?
👨‍👦‍👦 Как предупредить негативные настроения в команде
👨‍👦‍👦 Что делать, если вы — главный пессимист в команде

Кейсы, опыт, советы, мнения
🦋 Если процесс нельзя роботизировать, то он кривой
🦋 Поговорим о руководителях, как удержать тимлида от развала команды?
🦋 Управление командой - Weekly встреча
🦋 Как визуализация приоритетности задач позволила нам ускорить процесс разработки и сделать его прозрачным для всех
🦋 Подход, который помог нам точно оценить трудозатраты на разработку дизайн-системы

Инструментарий
🛠 Обзор инструментов для управления ресурсами в «Первой Форме». Взгляд руководителя с IT-командой 40+ человек
🛠 OpenAPI/Swagger для начинающих
🛠 ADVANTA создала «умных» помощников для оперативной работы над проектами
🛠 Jira, Confluence, Miro, Trello больше нет. Гайд: как грамотно выбрать российские аналоги площадок для совместной работы

YouTube
🔴 Интервью с автором Learning Domain-Driven Design
🔴 Рынок ИТ: как изменились зарплаты и вакансии для джунов за 2023 год
🔴 Практика по стратегиям поведения в конфликте
🔴 Использование UML в тест менеджменте: как экономить свое (и не только) время
🔴 У нас Agile: Давайте уволим тестировщиков, а тестировать будут разработчики
🔴 50 оттенков обратной связи как инструмент руководителя и не только
🔴 Лекция от Марии Серёгиной про исследование клиентского опыта
🔴 Пользовательские истории — типичные ошибки и пути их решения
🔴 Исследование в продуктовом дизайне. Research OPS в B2B и оптимизация
🔴 FIT INTERVIEW: как, когда, зачем и с кем?

Прочитал книгу “Карта гипотез” Александра Бындю, и у меня очень положительные впечатления. Подход несомненно эффективный и привлекательный.

Суть: мы должны до начала работ (по проекту/продукту) вербализировать и визуализировать наши представления:
- что мы хотим сделать
- кто будет объектом нашего влияния
- какие гипотезы (идеи) мы берем за основу
- какие задачи нужно решить, исходя из всего этого.
Как понятно из названия, подход выстроен вокруг гипотез. А гипотеза (по тексту еще часто “идея”) - это однозначно интерпретируемая формулировка типа “Если (какое-то действие), То (нужное нам последствие), Потому что (вот тут собственно и гипотеза)”.
По мнению Александра, именно такой подход к изменениям, продуктам и проектам должен сделать планирование и управление более эффективным. Потому что команда будет знать не только свои конкретные задачи, но и видеть за ними общий курс, а значит, сможет адаптироваться к изменениям, быстрее завоевывать рынок, передавать знания и т.д.

Важно ли это? Безусловно важно. Существует ли проблема непонимания компаниями своих стратегических целей? Конечно, существует и спасибо Александру за еще один инструмент стратегического планирования.

Но есть и вещи, которые меня смутили.

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

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

Второй момент - универсальность метода. Со слов автора, он одинаково хорошо подходит и для личных целей, и для корпоративных. При этом инструменты, которые даются, рассчитаны на корпоративное применение (например, стратегические сессии со множеством участников), а про личное применение как-то в итоге не хватает конкретики. Но, возможно, это мое личное недоверие к универсальным “отмычкам”.

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

В целом же, я очень рад появлению такой книги, с интересом буду следить за развитием “карты гипотез” как фреймворка и применять на практике, конечно)

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Что такое бэклог простыми словами?
📌Статус RAG и как его использовать в проектах
📌Какой должна быть продолжительность спринта
📌О Важном в управлении проектами
📌Эволюция методологий разработки
📌Какие типы вопросов задавать при выявлении требований?
📌Получи максимум от анализа документов
📌Что такое CJM: на примере покупки «теслы»
📌Как тимлиду прогнозировать выполнение задач с вероятностью 80-90%
📌Ошибки при внедрении OKR. Как связаны KPI и OKR?
📌Подборка материалов про аутентификацию и авторизацию
📌Руководство по недостижению целей


Карьера и навыки менеджера проекта
🥇«Я всегда работал по Agile, просто не знал этого». Когда Agile не профессия, а часть собственной философии
🥇Как менять подход к управлению с ростом команды и проекта
🥇Менеджмент собак и людей
🥇Что делать, если достал менеджер проектов?
🥇Стили лидерства в менеджменте. Когда и зачем применять лидерство-служение
🥇Work-life balance, или Как я перестал беспокоиться и полюбил свою работу

Команда проекта
👨‍👦‍👦  50 советов управления командой в 2024
👨‍👦‍👦  Как дневник эмоций помог мне настроить процессы в рабочей команде
👨‍👦‍👦  Как стать сеньором слишком рано
👨‍👦‍👦  Как выбрать тимлида в команду
👨‍👦‍👦  Онбординг аналитиков. Опыт Bimeister
👨‍👦‍👦  Десять условий для взращивания джунов в компании.
👨‍👦‍👦  From Zero to Hero: как автоматизировать онбординг в ИТ
👨‍👦‍👦  Как мы с помощью ИИ залезли в головы 30 предпринимателям и узнали об их подходах к работе с командой
👨‍👦‍👦  Кто как обзывается, сам так называется: как получить фидбек по работе и не обидеться
👨‍👦‍👦  Кумовство 2.4 – как нетворкинг и личный бренд в диджитале влияют на ЗП


Кейсы, опыт, советы, мнения
🦋 Аналитика на грани компетенций
🦋 Как выдержать бурный рост IT-проекта и не закрыться
🦋 Почему разработчикам тяжело запускать свои проекты? Делюсь личным опытом
🦋 Мой опыт в IT компании
🦋 Хроники пикирующего бота или как важно не пропускать стадию QA в проектах
🦋 Тирания маргинального юзера. Почему всё вокруг становится примитивнее
🦋 Кейс Dprofile. Все этапы разработки отечественной платформы для дизайнеров: от идеи до выхода на монетизацию
🦋 Продажа разработки: как получать доверие заказчика и проекты при большом цикле сделки

Инструментарий
🛠 Дорожная карта проекта в продуктовом маркетинге
🛠 Из IT в строительство: как сотрудники проектного института организовали работу по Канбан-методу в Kaiten
🛠 Нейросервис, которым я пользуюсь каждый день уже девять месяцев и экономлю до 15-20 часов в неделю
🛠 Обновления Zetep в ноябре
🛠 Лучшая замена Notion для российских пользователей – Teamly
🛠 Зачем эти нервы, если можно сделать сразу и нормально? Каким проектам лучше не использовать Тильду


YouTube
🔴 Как взаимодействовать со стейкхолдерами?
🔴 Счастливый заказчик. Как управлять ИТ-проектом, не привлекая внимание санитаров?
🔴 Как провести продуктовую революцию? Кейс и советы по дизайну организационной структуры
🔴 Sailing to the Unknown: Onboarding to Document-Less Project
🔴 Работа с требованиями при автоматизации процессов планирования

😍 Берите на заметку для будущих проектов и дизайнов!

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

Я сейчас работаю с наймом и вижу, насколько устаревшими методами работают рекрутеры. Перешлю статью нашим HR-партнерам)
https://vc.ru/hr/951968-pochemu-kofe-i-pechenki-v-vakansiyah-bolshe-ne-rabotayut

Лучшее про проекты и проектное управление за эту неделю

Основы и гайды
📌 Анонимные опросники в проектном менеджменте
📌 Управление изменениями
📌 PI-планирование: как с его помощью мы выстроили здоровую коммуникацию с заказчиком
📌 Реформа проектного управления: как устроена целевая модель для наведения порядка в процессах
📌 Как тестировать бизнес-идеи без разработчиков?
📌 Что нужно знать о gRPC системному аналитику

Карьера и навыки менеджера проекта
🥇Delivery Manager – очередной хайп или новый тренд управления
🥇Power is the new soft. Почему софтскилы пора переименовать
🥇Менеджмент в рекламном агентстве: руководителем может стать (не) каждый
🥇Как удаленная работа превратит вашу жизнь в ад: 5 советов, чтобы этого избежать
🥇«Пятница, вечер, и начинается — миллион вопросов в личку»: истории про то, как на работе «дёргают» в нерабочее время

Команда проекта
👨‍👦‍👦 Никто никогда не учит писать качественный софт
👨‍👦‍👦 Как диалог с сотрудниками помогает решать проблемы и оптимизировать бизнес-процессы?
👨‍👦‍👦 Десять условий для взращивания джунов в компании. Часть 2
👨‍👦‍👦 Как провести незабываемую ретроспективу с нуля?
👨‍👦‍👦 Архитектурные ката: отсекаем всё лишнее в Agile
👨‍👦‍👦 Как помочь адаптироваться новому сотруднику
👨‍👦‍👦 Приходят в компанию, уходят от руководителя. Как удерживать сотрудников в период нехватки кадров?
👨‍👦‍👦 Почему «кофе и печеньки» в вакансиях больше не работаютПроактивные и реактивные команды
👨‍👦‍👦 Мотивируйте заботой, а не страхом: 5 советов о том, как повысить продуктивность команды


Кейсы, опыт, советы, мнения
🦋 Как мы оптимизировали процессы обеспечения качества
🦋 Как мы сервис крупного проекта коллегам из Индии передавали
🦋 Как мы не забили на внутренних заказчиков, или Внутренняя автоматизация как продукт
🦋 Как мы делаем проекты
🦋 Как я пытался облегчить работу в поликлинике
🦋 Как мы описываем требования к REST API для бэкенда в Confluence
🦋 Руководство к действию: как внедрить ERP-систему в крупной компании
🦋 Как получить чистый, как слеза младенца, код?
🦋 Про регламенты в маленьких компаниях и почему лучше заранее, а не когда уже поздно
🦋 Что я понял о цифровой трансформации бизнеса спустя десять лет разработки IT-систем для компаний
🦋 3 шага к проекту без правок
🦋 Как облегчить эксплуатацию продукта и избавиться от кошмаров с релизами

Инструментарий
🛠 Что использовать вместо Jira и Confluence
🛠 Как CPO организовать работу продуктового отдела в Kaiten
🛠 Фейковые турецкие аккаунты, VPN и принятие: как разработчики «Планёрки» перешли из Jira в Kaiten
🛠 Teamly сделали это — свой «Notion» в базе знаний, а не наоборот. Это мало увидеть, этим нужно пользоваться!

Youtube
🔴 Проектная кухня «Тренды и лучшие практики управления проектами в 2024 году»
🔴 Разработка требований к экосистемам
🔴 Руководитель проекта / Системный аналитик. Совмещать нельзя запретить...
🔴 Как объединить бизнес и IT? Эффективное управление проектами
🔴 Учимся задавать вопросы осмысленно

Всем привет! Завтра дайджеста не будет. У меня не хватило ресурсов (( Извините, пожалуйста!

Источник проблемы - Битрикс24. Именно на нем пару лет назад я начал автоматизировать в своей компании CRM и внутренние процессы. Облачный Битрикс плюс большой обвес из интеграций с API и вебхуков. Когда проектировали, модель казалась оптимальной: ресурсов ест мало, результат отличный, отказоустойчивость высокая. Так и было достаточно долго.
Но три дня назад ЦОД Битрикса лёг под ддосом, много что не работает, пользователи зло дышат в наш адрес. Обычно в похожих ситуациях я включал нетворкинг (попросту говоря, теребил знакомых сотрудников вендора) и проблему решали чуть быстрее. А в этот раз просто проблемище: любая перестройка будет долгой и сложной. Всё время у меня уходило на управление пользователями, поиск временных решений и попытки найти контуры новой конфигурации.
Мрак и безнадёга. При этом еще и техподдержка молчит. Сообщения прочитаны, но не отвечены. Живы или умерли - неизвестно.
Но вот сегодня всё раздышалось. То ли ддос подустал, то ли вендор нашел решение, не знаю, но стало значительно лучше. Я снова могу заниматься своими проектами и не думать, как за вечер перевести работу компании на другой продукт.
Как же это хорошо! И спасибо поддержке, что работала, хоть и не ставя нас в курс.
Друзья, желаю всем вам спокойного вечера и будущей недели!

Оказывается, ваш покорный слуга - "высокопрофессиональный" (ну так написано!) эксперт российского Агентства стратегических инициатив по направлению "Культура".

Звучит сложно, но содержание простое. Учреждения культуры (от районных библиотек и до больших федеральных структур) иногда изобретают новые форматы работы с аудиторией - где-то очень точечные (например, работа библиотек с детьми с ОВЗ), где-то масштабные (федеральные концертные мероприятия и фестивали). Авторы тестируют такие форматы у себя (проект), и если им кажется, что всё хорошо, то запускают процедуру подготовки к тиражированию. Цель - чтобы коллеги из других регионов смогли реализовать у себя такое же.
Моя роль - скромная. Как эксперт, я анализирую результативность, эффективность проекта и потенциал его тиражирования. Если всё ок - пропускаю, и дальше проект попадает в руки реципиентов. Если проект норм, но есть что доработать - делаю подробное ревью и пишу, что улучшить. Ну, и бывают случаи, когда просто заворачиваю.
Таких проектов за год через меня проходит до сотни. Работа полностью волонтерская, но интересная.

Как я туда попал - история отдельная, связана она с моим темным прошлым кандидата культурологии и исследователя культуры, а также с анимационным проектом "Колобанга", с которым я долго был связан.

Такое вот странное волонтерство/хобби у меня, IT project manager'a.

Снова выступлю как невольный амбассадор ребят из System Education - в мире дайджестов они умеют делать лучшие подборки. Уже были большие подборки про базы данных и интеграцию, а сейчас вот, аккурат под праздники - про бизнес-анализ.
https://t.iss.one/systems_education/662

Лучшее про проекты и проектное управление за эту неделю

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

Основы и гайды
📌 Спринты — самая большая ошибка в программной инженерии, примите eXtreme Go Horse
📌 Книга «Канбан Метод. Базовая практика»
📌 12 принципов Agile: как приготовить новогодний оливье
📌 Как прогнозировать время выполнения задач
📌 Как оценить эффект от внедрения проекта?
📌 Наши заказчики любят работать по T&M. Рассказываем, почему иногда лучше выбрать Fixed Price
📌 Сторипоинты или человеко-часы, сроки или спринты, терпеть или уволить — обсудили, как выстроить работу с командой

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

Команда проекта
👨‍👦‍👦 Ценности как инструмент принятия сложных решений: как мы упрощаем взаимодействие команд и приходим к единому мнению
👨‍👦‍👦 Chat GPT как замена системного аналитика: сравнение эффективности
👨‍👦‍👦 Как малые и средние компании по заказной разработке ПО живут без системных аналитиков?
👨‍👦‍👦 Помогут ли оливье и десять выходных справиться с выгоранием?
👨‍👦‍👦 Выгорание в IT: в специализациях, квалификациях, командах и других сегментах
👨‍👦‍👦 Жесткие факты о софт скилах
👨‍👦‍👦 50 оттенков мягкого: зачем и как развивать софт скиллы у сотрудников
👨‍👦‍👦 Метрики для оценки эффективности команд на удаленке и не только
👨‍👦‍👦 Как повысить эффективность коммуникаций в команде: учимся решать конфликты
👨‍👦‍👦 7 способов развалить даже самую крепкую команду
👨‍👦‍👦 Подбор сотрудников в команду: на что обратить внимание при оценке кандидатов

Кейсы, опыт, советы, мнения
🦋 Как не про…пустить все дедлайны. Таск-трекер в деле
🦋 Почему люди не пользуются вашим продуктом (даже если он может спасти тысячи жизней)
🦋 Учить или не учить: почему внедрение даже простого ПО не работает без погружения сотрудников
🦋 Как мы делали поддержку прозрачнее для бизнеса с помощью сервисного подхода
🦋 Как мы создали сервис подбора фильмов
🦋 Про оценку времени выполнения задач в ИТ
🦋 Что такое продуктовый подход и особенности использования его элементов в государственном банке
🦋 Одна модель, чтобы править IT-проектами, и наш долгий путь к ней
🦋 «Оседлать хаос»: Как 1000+ инженеров повысили сходимость бэклога до 95%

Инструментарий
🛠 Hippotable — анализ данных прямо в браузере
🛠 Следящий софт: как показать сотруднику, что у вас цифровой концлагерь
🛠 Обновлённая «МойОфис Таблица»: как мы ускорили работу с документами в 50 (и более) раз
🛠 Сервис, аналоги которому ещё поискать нужно или «Портал руководств, доков, wiki и справок»
🛠 Планирование, управление, встречи, мозговой штурм и диаграммы в одном сервисе — это не сказки, это Доски!

Youtube
🔴 Как AI помогает Project Managers: Перспективы, Навыки и Делегирование
🔴 Как искусственный интеллект помогает в работе с требованиями
🔴 Применение ТРИЗ для решения задач с предельным уровнем неопределенности
🔴 Тенденции в использовании Канбан Метода. К чему идем?
🔴 Виды аналитиков. Зачем каждый из них нужен?
🔴 Moving your Scrum Downfield
🔴 Поговорим о НФТ
🔴 A2_Я предлагаю - они отказываются!
🔴 Практические подходы к измерению KPI аналитиков в Agile-проектах
🔴 Какие сервисы делать на gRPC?

Друзья!

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

Практика оргпроектирования (организационный дизайн) - коротко о курсе

Я немного адепт курсов Никиты Сергеева - мне они импонируют своей содержательностью, высокой детализированностью, демократичным стилем изложения и стоимостью (да, это тоже важно).
Как-то уже делился впечатлениями от курса по PMBOK 7 - великолепный материал, наверное, единственный в своем роде.

В конце 2023 г. Никита выпустил новый курс, посвященный организационному дизайну. В двух словах, он про то, как моделировать и корректировать организационную структуру компании - структура, подразделения, отделы, функции и т.д.
Сам курс относительно небольшой (~5-6 часов), в нем много дополнительных материалов (статей, ссылок, заметок, презентаций и схем), а также очень много практической работы по моделированию организационной структуры компаний и корпораций.

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

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

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

В своей практике чаще всего встречаюсь с Опоздунами, Пессимистами-нытиками и Безынициативными. [...]
Пессимисты и нытики — большая проблема для коллектива. Такие сотрудники начинают заражать своим настроением всех вокруг, что неизбежно отражается на работе. А если в компании кризис или на проекте сложная ситуация, то пессимистичный настрой растет в коллективе в геометрической прогрессии.
Я, как правило, вначале пытаюсь объяснить, как такое поведение влияет на коллектив. Если не срабатывает, требую не ныть не по работе, а если такое все же происходит, задаю вопрос: «Что мы с тобой можем с этим сделать?» Если и это не срабатывает, прошу на каждую жалобу предлагать решение. В крайнем случае, когда больше ничего не работает, ищем с сотрудником более подходящее место в компании или расстаемся.

Узнали? Согласны?
Этот текст взят из недавней публикации на Хабре - меня заинтересовало, как безобидная типизация может из инструмента для анализа команды и распределения ролей и функций превратиться в деструктивную практику навешивания ярлыков. Достаточно всего-то не учитывать условность любых классификаций, а принимать их как руководство к действию, и тогда сотрудники из сложных личностей, создающих продукты и инновации, превращаются в “нытиков” и “пессимистов”.

Могу сказать тезисно:
⚽️ Любая классификация - это моделирование, и чем сложнее объект моделирования (особенно в социальной среде), тем она условнее и дальше от реальности. Само собой, что в чистом виде такие типы мы встретим редко или не встретим вообще, а значит, и заявленные методы работы с ними не сработают или сработают криво. Не надо вешать на людей ярлыки :-) И это касается не только IT.

⚽️ Вне контекста вашей организации и организационной культуры заявления про типы не имеют смысла. Один и тот же человек в разных организационных контекстах может вести себя совершенно по-разному ("относиться к разным типам"). И это повод не только менять людей, но и менять организационную культуру. А может быть, и в первую очередь именно ее.

⚽️ Делать классификации удобно тогда, когда вы сами находитесь вне предмета исследования. Но если мы сами тимлид / РП - мы внутри предмета. Рассматривать нужно не людей как таковых, а роли в команде. И поскольку мы тоже часть команды (как менеджер) - напрашивается и определение нашей роли. В разных командах и с разными менеджерами один и тот же человек может кардинально менять свой "тип". Более того, роль динамична - даже в одной и той же команде она может меняться.
⚽️ Всё это не значит, что от типизации нужно отказываться - она крайне полезна. Но она не должна заслонять собой сложную систему реальности.

Про уютные коммуникации
#мнение

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

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

Но есть одна угроза - неосознанная подмена коммуникациями собственно руководства проектом. Мы занимаемся выстраиванием отношений и "созданием процессов в команде". Начинаем воспринимать себя как "мать/отца команды", "няньку", "организатора", "коммуникатора" - и само по себе это замечательно. Но тут и возникает угроза замещения "процессами" того, ради чего нас и взяли в компанию, - реализацию проекта. Как бы мы ни выстраивали процессы и связи, важно держать в фокусе достижение проектных целей. Мы - про результат. И если процессы есть, коммуникации есть, а результата нет, то и наша ценность для бизнеса (компании) под вопросом. В общем случае, бизнес нас нанимает, чтобы мы искали решения нетривиальных задач - внутренних или для клиентов. И как бы ни хотелось оставаться в гомеостазе внутри "уютных процессов", которые мы создали, нужно понимать, что в какой-то момент они могут разрушиться, перекомбинироваться и т.д. - если этого потребует новая проектная задача или новые обстоятельства. Это - норма. То, что вчера мы заказывали пиццу, выкатив долгожданный релиз, а сегодня всех распускаем, т.к. получили задачи, для которых своя команда не требуется, - тоже норма (главное, сделать все максимально по-человечески).

В целом, всё это было бы банальностью, если бы не приводило к быстрому выгоранию тех, кто пришел в РП за отношениями в команде, а вместо этого получает негатив от руководства. Если мы примем, что коммуникация и отношения - не самоцель, а инструмент для решения нетривиальных задач бизнеса, - то меньше будет стресса и выгорания.

Инфостарт (это такой сайт для разработчиков и пользователей 1С: Предприятие) с недавнего времени тоже развивает направление менеджмента проектов.

Вот отдельная небольшая подборка их материалов:
📌 Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?
📌 Компетенции руководителя проекта: по версии PMI и здравомусмыслу. Часть первая. Часть вторая
📌 Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей
Житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте.
📌 Как воспитать в себе РП? Часть первая
Что должен знать и уметь менеджер проекта внедрения.
📌 Как воспитать в себе РП? Часть вторая
Про роль ведущего руководителя проектов, задающего и формирующего политику управления проектами в компании.

Видео:
🔴 “Как прокачать руководителей проектов внедрения? Опыт Инфостарта”
🔴 Мастер-класс по построению тепловой карты рисков в ИТ-проектах
🔴 Мастер-класс по построению модели управления рисками“Галстук-бабочка”
🔴 Как находить общий язык с заказчиком и с командой проекта? 3 инструмента руководителей проектов
🔴 Компетенции руководителя проекта в современных условиях.
🔴 Вебинар-диагностика ваших компетенций в управлении проектами.
🔴 Проектное управление в наши дни: как управлять проектом в условиях высокой неопределенности? Советы экспертов и опыт практиков
🔴 Проектные разборы - способ повышения компетенций для РП
🔴 Разбираем практические кейсы из управления проектами. Welcome-вебинар "Базового курса по управлению ИТ-проектами.