Отличная подборка инструментов, спасибо доброму человеку.

Интересно, как "проджект-менеджмент", он же "управление проектами", из предмета, заряженного математикой, исполнительской дисциплиной и хищным адреналиновым драйвом превращается в безобидное "вечериночное" занятие, в котором все основные риски сваливаются на спины стейкхолдеров и тимлидов, а главной задачей ПМа, вместо собственно появления продукта проекта, является социальная - всех примирить, создать комфорт для участников, ни в коем случае не демонстрировать токсичность, в чем бы она ни выражалась. В лекции по ссылке ниже именно эти функции в фокусе.
Что интересно, на вопрос, "как ПМ должен набирать команду проекта", на курсе Яндекса не смогли ответить. Оказалось, что сейчас другие тренды - ПМ приходит на уже сформированную команду разрабов, никого не собеседует, никого не выгоняет, работает с тем, что дали.
Еще одним откровением стало то, что кураторы курса не работают с рисками, от слова совсем. Формально заполняют таблички, но реальным анализом и выработкой стратегии не занимаются, ибо... "и так всё понятно и зачем на это тратить время".

https://www.youtube.com/watch?v=NBlCDXxKmTI

"Где платят - там и хорошо"
Один из партнёров 1С провел опрос среди "одинэсников" (а я напомню, что это большой пласт разработчиков и аналитиков, работающих на довольно денежном рынке).
Результаты отличные: все больше работают удаленно, средние зарплаты в районе 150k, востребованность высокая, софт отечественный, в будущем - позитив. Искренне рад результатам.
Что зацепило, так это очередной удар по "корпоративной культуре". Она ожидаемо в аутсайдерах при выборе работодателя. Ожидаемо - не только из-за того, что ее не умеют продавать HR, но и из-за того, что корпоративная культура - это не то, из-за чего приходят в коллектив. Она скорее то, почему из коллектива (не) уходят ;-)
https://infostart.ru/journal/analytics/1715603/

Хороший материал о том, как создавать базу знаний внутри компании. Конфлюэнс, жира и миро в топе инструментов, кстати. https://www.youtube.com/watch?v=D_e-kajMGeQ

Материал о том, как автоматизировали завод - перевели с зарубежной ERP на учетную систему 1С. Кейс отличный, и хотя подозреваю, что очень много скрыто за кулисами (слезы, договоренности, риски), но в целом это хороший "мув" в сторону сближения внедрения 1С [для таких проектов обычно построенных на waterfall и больших ТЗ] к итерационной разработке.
https://habr.com/ru/post/688782/

А ведь действительно, аналитику не только в скраме, но и в целом в проектной/продуктовой разработке уделяется не так уж много внимания. Аналитика в популярных схемах нередко проходит где-то или до старта проекта (этап сбора требований), или параллельно разработке, на подхвате у нее. А еще аналитик - это тот, кем затыкают коммуникации: РП слишком занят, разработчики на вес золота, менеджер по продажам уже окучивает другого клиента, - а вот ты, аналитик, иди-ка пообсуждай с пользователем его проблемы.
https://habr.com/ru/post/689518/

Хорошая публикация для любого, кто собирает (извлекает) требования и пользовательские истории и моделирует, кто и как будет пользоваться продуктом/фичей: https://habr.com/ru/post/690872/

Прочитал совсем небольшую книжку Крогеруса и Чеппелера "Книга проектов. Действуйте!" (рус. пер. 2022).
Прямо совсем небольшую: если вычесть иллюстрации, выйдет страниц 150.
Представьте, что кто-то собрал 3-4 десятка популярных постов на adme / pikabu / linkedin на темы "Как правильно ...", слегка их упорядочил и сделал легкую редактуру. Ценна она, наверное, будет тем, кто раньше не рефлексировал над своей деятельностью. Остальным, и особенно тем, кто более-менее плотно в теме "проектов", делать в этой книге совершенно нечего: это поверхностная компиляция Карнеги, скрама, дизайн-мышления, которую обычно выдают на вводных бесплатных курсах для проджектов. https://disk.yandex.ru/i/JZ2FCuG9yEj10Q

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

Оригинал

Неплохая статейка по Use Case
https://habr.com/ru/post/699522/

Нестандартный пост, но вынужден его сделать. Хочу поздравить с днем рождения замечательного бизнес-аналитика и человека - Иннокентия Бодрова, мудрого, позитивного и очень внимательного. А еще автора канала https://t.iss.one/spherical_analyst, - одного из самых полезных для меня.
Иннокентий, всего самого хорошего!

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

Очень наглядная и при этом веселая публикация вышла на хабре про 44-ФЗ и, в целом, адаптацию социальной реальности к ограничивающим нормам. Рекомендую всем, кто разрабатывает "правила игры" для процессов.
https://habr.com/ru/post/702320/

Любопытные "заметки на полях" про причины провалов руководителя проекта.
Любопытные тем, что с одной стороны, всё правильно: коммуникация - это ключевая компетенция РП. Без нее скорее всего не взлетит.
С другой стороны, в заметке явный перекос в эту сторону. Гипертрофия коммуникации подменяет технологическую сторону. Проблемы с требованиями, с целями, с рисками, с планированием и оценкой - это типа несущественно. Да, лучше, когда РП - весёлый и энергичный балабол, но ещё лучше, когда он умен и не заливает допущенные технологические ошибки тезисами "ладно, договоримся".
https://vc.ru/u/403869-pavel-zaycev/564891-5-prichin-vashih-provalov-kak-rukovoditelya-proekta

Друзья, с наступающим новым оборотом Земли вокруг Солнца! Пусть этот процесс не останавливается!

В декабре я наконец-то закончил курс "Менеджер проектов" в Яндекс.Практикуме и, пока не всё выветрилось, решил написать несколько впечатлений об обучении. Вдруг кому-то интересно узнать, как у нас готовят ПМ-ов)
bit.ly/3WImo2a

Что вы делаете после того, как задача ("таска") выполнена разработчиком, протестирована и принята заказчиком? Конечно, закрываете ее. А дальше, как часто бывает, задача скрывается в пучине "done" и теряет любую ценность, кроме исторической.
Автор публикации дает простой и дельный совет: у завершенных задач вполне может быть своя и очень полезная для проекта/продукта "жизнь после смерти". Если, например, фича, реализованная в рамках задачи, в итоге была отброшена после тестирования, то будет здорово отметить это и в статусе задачи, - меньше будет вопросов, "почему вы потратили на нее столько часов, а в итоге она не реализована". https://habr.com/ru/post/710614/

Прочитал The Ride of a Lifetime Роберта Айгера (в русском переводе "Умение предвидеть", без комментариев). Айгер - без преувеличения легендарный менеджер, именно при нем Disney стал глобальным медиагигантом. Совсем недавно Айгер ушел на пенсию (и об этом намёк в последней главе), но буквально несколько месяцев назад вернулся в строй.
У бизнес-истории "мышиного дома" библиография большая и на любой вкус, но от такого автора поневоле ждешь откровений. А поскольку это Дисней - то еще и по привычке в захватывающей форме. И точно, книга начинается, как производственный триллер, in medias res, - с описания ЧП корпоративного масштаба, выхваченного из середины карьеры: во время командировки в Китай топ-менеджер узнает новость о трагедии на родине и пострадавших сотрудниках. Мы видим, как Айгер берет себя в руки и привычным усилием выбирает правильное решение, которое не только снимает проблему, но и задаёт дальнейшую бизнес-стратегию. Дальше повествование обращается к началу карьеры и... Всё, больше сюжетными приемами она уже не балует, идёт по мемуарной хронологии. Как не радует и фабулой. При всей эпичности и масштабности это всё же типичная "официальная" ("каноническая", "партийная") биография, где каждое решение - правильное, каждое сомнение - пророческое, каждое отступление - исторически оправданное. Здесь нет места неправильным сделкам, кадровым ошибкам (за одним, как будто нарочно сделанным исключением), просчетам и провалам. Нет мучений, нет стресса, нет анализа ошибок и альтернатив. Вместо этого мы, картина за картиной, видим, как Айгер рос как менеджер и принимал самые правильные решения: вот рискованный запуск Twin Peaks (в итоге - революция в телевещании), поглощение Pixar, Marvel, StarWars и Fox , вот открытие Диснейлендов по всему миру и успешный запуск собственного стримингового сервиса. И вроде не поспоришь - все это действительно титанические победы и эпохальные события, о которых интересно читать. Но, к сожалению, бизнесовая ценность этого опыта очень небольшая, если его попытаться натянуть на свой бизнес и более "земные" проекты. Как принимать решения, благодаря которым компания останется на плаву и превратится в глобального игрока, чем руководствоваться, какие модели и инструменты использовать - все это остается за кулисами эпоса.
https://bombora.ru/book/81985/