#полезности

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

Большой находкой оказался старый блог Леши Пименова с обзорами книг, он прикреплен в конце. Там очень много серьезных книг, про которые я даже не слышал.
https://www.notion.so/artemletyushev/c3b82fe620fc4cd1a39caf164ffce94c

#иное
Тут кой-чего оффлайн замышляется

Митап «SPM Meetup #87. Outdoor edition»

Когда: 3 июля (суббота) 2021 года с 16:00 до 19:00 (по Москве).

Организатор: SPb SPM: Software Managers Club (t.me/spbspm)

Повестка:

1. Безвыходная ситуация, когда ПМ оказался в продукте или сервисе.
Поговорим о инструментах и навыках, которые могут пригодиться менеджеру проектов в нетипичной для него обстановке.
Топикстартер - Летюшев Артем, менеджер-аналитик

2. Условиях и принципы построения эффективных команд на удаленке.
Мы все строим команды в любой не понятной ситуации. Но так ли мы много знаем об их поддержании и развитии?
Топикстартер - Алексей Васильев, основатель bipulse.ru

Мероприятие бесплатное, но приход оффлайн обязателен.

Ссылка на мероприятие: https://spbspm-club.timepad.ru/event/1685500/

#рецепт
Советы для резюме
Дорогой читатель, не важно начинающий ли джун или матерый АшПМО, ты наверняка задумывался о том как сделать резюме привлекательным.

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

Ниже краткая выдержка советов на основе недавней переписки в одной из чятиков:

1. Смотрят на всего 3 вещи: область, должность и достижения.
Как скринят резюме? Так, IT еще и DWH, отлично!; работал проджектом, ага!; еще и 2 команды поднял с нуля и уложил проект в срок на пару месяцев раньше! - Наш кандидат.
Остальное второстепенно и смотрится в последнюю очередь.

2. Скиллы/навыки/инструменты
Не стройте графики владения скиллом, из разряда Exсel на 90%. Камон
Не пишите очевидные клише, вроде "коммуникабельный", "проактивный". Навыки "Эмоциональный интеллект" и "управление переговорами" смотрятся куда лучше и несут реальный смысл.
Не пишите в навыки то, чем вы не владеете на практике или знаете лишь по наслышке. Для примера слово Scrum встречается у 90% респондентов и 80% из них не могут связать пару слов об этом, лишь 5% из них реально использовали это на практике. (200 человек из 1000 поверхностно понимают что это и 10 человек вообще юзали).

3. Фото
Портретное фото желательно на однотонном фоне, чтобы можно было разглядеть человека и составить о нем визуальное представление.
Не надо фото в бок, в полный рост или еще с кем-то.
Рекомендация от @releaved_dave прогонять фото через https://www.photofeeler.com/

4. Контакты
Посмотрите распространенные соцсети и указывайте их. Не вайбер или мейл ру агент.
Не пишите ники в уморительном формате. Я видел почту yakotikpoliglotik@mail.ru

5. О себе
Не пишите в этом разделе то, что можно понять по другим пунктам резюме. Не надо писать "я хочу устроится проджект менеджером, потому что уже работаю 2 года в этом направлении", это ультраочевидно по содержанию документа.
Не пишите туда шутки, из разряда "я настолько преисполнился в календарно-сетовом, будто уже 100 миллионов миллиардов лет...".
Этот раздел - гвоздь программы, напишите туда то, что позволит зацепить читающего, сказать ему "обана, вот это персонаж, организовал с нуля фестиваль по вейбордингу в Воркуте за 3 дня и даже не ушел в минус".

6. Опыт работы
Краткое описание вашего профессионального опыта на 5-6 строчках в формате:
*Название компании
*Краткое описание компании (в одну строчку), так как не все могут знать компанию, в которой ты ранее работал и из какой она индустрии.
*Название позиции/должности
*Обязанности. В обязанностях 3-6 пунктов, а не больших абзацев.
*Достижения. 3-6 пунктов, описывающих ключевые результаты твоих действий. Желательно количественно. "Завершил проект раньше срока", не ок. "Завершил проект длительностью в год за 5 месяцев без сокращения объема работ и сэкономил 1000 деняк", ок.

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

9. Формат документа
Никаких .docx или .rtf, уважайте людей, они могут смотреть с устройства без ворда + открывается это не быстро.
Идеально - ссылка на hh/linkedin. Но pdf в гугл диске тоже ничего.

10. Структура
Не придумывайте свою оригинальную структуру. "ФИО+фото→Контакты→Опыт работы→Навыки→О себе" вот идельная структура, к которой привыкло большинство рекрутеров.
Просто воспользуйтесь сервисом из разряда hh/linkedin/dou/хабр карьера.

11. Стиль описания
Не пиши кучу канцеляризмов и профессионализмов. Резюме пишется для HR в подавляющем большинстве случаев. "Оптимизировал VSM с помощью ревью CJM на базе показателей Нортона-Каплана" писать явно не стоит.
Не стоит нагромождать юридические конструкции, как и писать "сделал офигенный ЦОД".
Вычитайте резюме и уберите все ошибки, будь то речевые, синтаксические или орфографические.

​#рецепт
Продолжение про резюме
12. Мусор
Мусором является лишняя вода, пространные описания рейтинга прошлой компании и сегмента.
Мусором является нерелевантный опыт, например рекрутеру вряд ли интересно, что вы работали 15 лет назад курьером деловой документации.
Мусор - это куча личной информации, из разряда кличка вашей собаки или информация что вы работали с братом в одной коммерческой фирме.

13. Размер
Не пишите резюме в пол странички - создается впечатление что вы ничего не умеете.
Не пишите резюме на 5 страниц - его лень читать и создается впечатление что вы не умеете кратко излагать свои мысли.
Идеально 2 страницы, край 3.

Надеюсь эти советы будут тебе полезны и помогут найти работу мечты.
Текст описан опираясь на переписку с @IvLitovchenko в чате @pmi_ru
P.S. Нет, свое резюме не приложу.

#полезности
Работа с изменениями
Отличный пост коллеги подход к внедрению изменений и работе с сопротивлениями. Там в серии ещё 3 поста про это.

Мне он пришёлся очень кстати, надеюсь поможет и тебе.
P. S. Нет, это не про change request-ы и управление изменениями в проектах.

Как то в начале дневника я упоминал про то, как можно работать с изменениями https://t.me/myscrum/9 Там я рассказывал про формулу изменений и матрицу изменений (план приверженности). Сегодня хочу поделиться основными причинами сопротивления изменениям и стратегиями работы с этим сопротивлением. Я обещал рассказать об этом Артему Летюшеву (@artemletya). Придумал не я. Эти материалы я взял из оконченного мной курса MBA Открытого университета Великобритании (Книга 3. Управление организацией и персоналом: Учебное пособие для слушателей/Пер. с англ. - АНО ВО МИМ ЛИНК, 2019). Это работает и помогает. Я применяю это в своей работе, проверено все это многократно. Итак есть пять классических операционных стратегий управления изменениями:
1. Директивная стратегия. Быстрая. Степень сопротивления высокая. Сопротивление ломают.
2. Экспертная стратегия. Достаточно быстрая. Управление изменением как технической проблемой. Привлечение специалистов-экспертов при поддержке сверху. Степень сопротивления выше средней.
3. Переговорная стратегия. Средний темп. Переговоры и уступки. Вовлечение в изменение. Сопротивление среднее и ниже среднего.
4. Образовательная стратегия. Медленная. Формирование видения будущего (вспоминаем второй элемент формулы изменений https://t.me/myscrum/9) Сопротивление небольшое. Формирование приверженности изменениям.
5. Стратегия участия. Медленная. Вовлечение участников. Формирование группы энтузиастов-волонтеров. Сопротивление низкое.
Стратегии эти применяются для различных людей и групп людей. Нет одинаковой стратегии для всех. Для проведения изменений можно использовать матрицу, которую я описывал https://t.me/myscrum/10. Дальше я расскажу про причины сопротивления.

#полезности #рекомендация
Ментор для менти
Коллега @am_disciplined прошла большой путь от журналиста до менеджера, собрала приличное количество шишек и готова ими поделиться с начинающими РП:

Всем привет! Я - Настя, работаю менеджером проектов 3 года.

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

У меня есть два варианта, которые я могу предложить:

1) Я могу брать желающих на короткие митапы для какого-либо совета, рекомендации по кейсу, отвечать на вопросы, которые не требуют подробного изучения. Этот вариант не предполагает постоянное наставничество и я могу быть часто не доступна.

2) Я могу взять вас индивидуально и вести по этапам, помогая вам войти в тему. Я составила учебную программу, которая включает в себя в том числе домашние задания, разбор кейсов, составление резюме и тестовые собеседования. Программа корректируется индивидуально под вас с учетом вашего профессионального бэкграунда. Это платное обучение, стоимость почасовая, вы можете ознакомиться с программой по запросу и исключить те модули, которые вам не нужны.
Вот здесь можно ознакомится с программой https://www.notion.so/2e4bb066e8c24c768b77c6c558281ea3

Буду рада стать вашим наставником. Всем удачи!

P.S. Это не платная реклама, тут таких не будет.

​#мнение
С чего зайти в Канбан
Дорогой читатель, недавно ты у меня спросил с чего я начинал изучение канбан-метода.

Собственно отвечаю. Я впервые познакомился с ним как и все: увидел доску в трелло и решил что раз создавать + двигать карточки я умею, то я уже преисполнился.

Но затем я увидел одно из выступлений @pimenaus и оно немного поменяло шестеренки в моей голове. Дальше продолжил просмотром скопом видео на его канале.

Далее было чтение Essential Kanban Condensed (если что малость устарело и лучше читать Канбан гайд), после общение в чятике практиков @kanban_talks и там дальше по наклонной.

Я бы предложил немного другой путь - сыграть в одну из симуляций, а именно в getKanban. В идеале конечно оффлайн формат, но в нынешней ситуации это не всегда доступно. Поэтому рекомендую смело идти в http://www.kanbanboardgame.com/.

Игра довольно занятная как для одного человека, так и для компании и богата на откровения

Например, по ней можно постичь смысл таких фраз как:
1) Вытягивающая система (но не до конца);
2) Классы обслуживания;
3) Точка принятия обязательств;
3) Пополнение;
5) Кумулятивная диаграмма потока и т.д.

В самой игре довольно много тактик, ниже приведена таблица из комбинаций всего 2 показателей, из которых складывают правила поведения при работе. Я (субъективно) выделил 8 таких показателей, 8^2 = 64 тактики всего из 2 правил. Я если еще и играть не в одиночку, то там добавятся еще и разные мнения. Шикарно.

P.S. Это субъективное мнение начинающего канбан-практика, AKT не бейте тапками))

#рецепт
Проджекты хотят быть продактами
Сейчас есть мода на то, что руководители проектов не нужны. Давно уже идет массовых исход в продакты.

Сильный коллега (в плане скилза)
в чате @pmi_ru высказал ряд предложений как с этим быть:

1. Если люди не хотят вести проект, то их не удержишь, надо тюнить настройки стратегии проектного офиса. Это странно, когда РП не хочет вести проект. РП должен любить свое ремесло, это baseline;

2. Если РП сильнее продактов (обыгрывают по всем дисциплинам), то это вопрос позиционирования роли РП в команде и договоренностей с руководителем подразделения продактов (и самими продактами). Грамотный РП должен быть готов быть №2 в команде;

3. Надо накинуть кэш и сократить дистанцию в доходах между продактом и проджектом. Полступени между ролями должны быть и в деньгах полступенью;

4. Вести пропаганду, что первые без вторых, как машина без двигателя;

5. Продакт и проджект должны минимум 1 раз в неделю встречаться вдвоем и обсуждать задачи друг друга. Оба на равных обсуждать проблемы и задачи. Second opinion - важная часть движения вперед при реализации;

6. Требовать от РП цитирую дословно: "умение говорить с людьми, умение слушать и слышать их, умение найти ZOPA (zone of possible agreement) всех сторон и сделать так, чтоб люди приходили к нужным умозаключениям исключительно самостоятельно. Т.е. так, чтоб им казалось, что они сами это придумали, а значит безгранично верили в это. Ну а фактически это твоих тончайших манипуляций работа", т.е. РП должен заземлять продакта в процессе производства ИТ решения. Ученик не превзойдет учителя, если видит в нем образец, а не соперника;

7. Нанимать продактов с участием руководителя проектного офиса с правом принятия решения о найме кандидата;

8. При непреодолимом желании перехода на позицию PO/PdM проработать программу трансфера с прохождением квалификационного экзамена. Переход должен быть закреплен испытательным сроком и апгрейдом ЗП после его прохождения.

Текст Евгения @Eugean1980

#почтовый_ящик
Ленивый менеджер

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

Поэтому запускаю новый формат - почтовый ящик. Как это будет работать?

1) Напиши мне в личные сообщения интересующий тебя вопрос (ссылка в описании);
2) Я дам развернутый ответ в виде структурированного поста для развернутого ответа;
3) Появится отдельная ветка постов помеченных тегом #почтовый_ящик. Выходить они будут раз в неделю.

P.S. Я понимаю что формат не нов и содержит толику жеманности. Но у меня сейчас немного не хватает ресурса на полноценный блог, да и новый цикл Даннинга-Крюгера начался.

​#мнение
Ретро не работает
Дорогой читатель, этот пост точно заставит тебя негодовать если ты не дочитаешь его до конца.

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

Почему он опасен?
Ретроспектива убивает доверие к менеджеру/любому лицу, кто имплементирует "ретру". Также бонусом убивает доверие между членами команды. У этого есть 3 причины:
1) Участники не слышат друг друга. Обсуждаются не действительно важные вещи для команды, а индивидуально важные. Либо вообще просто идеации. Действия с ретро уходят в никуда и на следующей встрече вы анализируете выполнение того, что было не нужно.

Вам дарили, то, что вы терпеть не можете? Потому что вас не поняли или забыли про это?

Вот такие же впечатления у участников;

2) Участники не выполняют обещания. Раскрыли душу, обсудили насущные точки роста (проблемы/достижения), потратили на это время и запланировали изменения. К следующей встрече планы были не выполнены.

Конфликтовали с партнером из-за какой-то проблемы в отношениях? Разбирали проблему и договаривались как почините? А потом видели что на проблему забили и ничего не поменялось?

Схожие ощущения у участников;

3) Ретроспектива не к месту. Кто-то, у кого низкий уровень понимания вашего контекста или к кому у вас нет доверия и уважения пришел к вам и начал утверждать, что вы должны честно ему рассказать о ваших проблемах, чтобы их решить. И тут не понятно, почему участники должны: довериться что время будет потрачено не в пустую, довериться и рассказать о проблемах, довериться что проблемы будут решены.

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

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

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

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

4) Визуальные игры. Кроме самой собственно встречи и простого общения на человеческом языке есть вспомогательные инструменты - стикеры, визуализации вроде корабля и т.д. Легко от решения проблем уйти в "красивый и интересный" воркшоп;

5) Управление выполнением экшен-айтемов. Чтобы выполнить эти задачи с "ретры", нужно ведь также их спланировать. И тут все сложнее чем кажется. Приоритет у них чаще всего низкий, делаем по остаточному принципу. А еще задачи небольшие, поэтому переключаемся на них между делом.

Ты наверняка задался вопросом, зачем ты прочитал это?

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

Каждый из 8 пунктов это узкий момент, который легко превращается в проблему ведет к тому что ретро не работает.

Главный месседж - топливо ретро это доверие, без него это просто бесполезная формальная встреча.

​#почтовый_ящик
Как повлиять ПМу у субподрядчика на ПМа заказчика, если 2 довольно мягкий и прогибается под любое мнение?

Довольно интересный кейс. Я в нем уже бывал, причем опыт был именно с ГОС проектом.
Я рекомендую использовать две вещи:
1) Механизм обратной связи. Есть всем известные 1-1 и типовые правила их проведения . Разумеется их можно применять не только для своих сотрудников.

Стоит завести первую встречу и в ней обсудить с фактами и отрешенностью от личности "пластичность" принятия решений и влияние 3 лиц. Разобрать конкретные случаи и описать ваш взгляд (как субподрядчика) о негативном влиянии принятых решений на цели проекта и критерии его достижимости. Я подобное переносил в полностью объективную плоскость и обсуждал с ПМом заказчика именно влияние на проект, а не на меня самого или мою компанию.

Тут есть одно большое НО, Это работает только если:
а) Целью вашего проекта является достижение цели проекта для заказчика. На самом деле у вас 2 разных проекта, один у ПМа подрядчика и другой у ПМа заказчика. Вполне возможна ситуация, когда они не подразумевают взаимного выполнения друг друга. Или вообще исключают. Такое особенно часто случается в аусторсе.
б) Проект важен ПМу заказчика и он разделяет цель проекта. Вполне может быть что проект ему не важен и это все объясняет.

2) Ченж реквести как интрига. Почему интрига - строится мини-заговор. Каждый раз когда происходит запрос на значительные изменения вы собираете встречу на двоих с ПМом заказчика и обсуждаете влияние на проект. Одна голова хорошо, а две лучше. Учитываются интересы обеих команд, обе цели и самое главное вы подставляете плечо коллеге и выстраиваете доверительные отношения.

Тут тоже есть одно большое НО, ПМ заказчика должен видеть в вас коллегу и доверять вам.

Так как же быть? А довольно просто:
1) Выясняете реальную цель своего проекта и реальную цель проекта заказчика;
2) Выясняете отношение ПМа заказчика к себе;
3) Строите доверительные или хотя бы уважительные отношения с ПМом заказчика;
4) Выбираете один из 2 инструментов: 1-1 или интригу;
5) PROFIT.

P.S. Если вы считаете, что такой вопрос решается по другому, то всегда можете написать об этом в комментарии.

​#рецепт
Как стать IT PM вообще с нуля?

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

Состоя в довольно большом количестве сообществ я заметил, что один вопрос мелькает с завидной регулярностью. "Как стать ПМом в IT с нуля?".

Ниже приведен небольшой алгоритм, который гарантированно поможет стать руководителем проектов за 6 месяцев бесплатно. Единственное что потребуется большая сила воли.
Чтобы стать ПМом нужно:

1) Подумать, почему вам все таки интересна эта область/домен, например IT. Узнать какие в ней есть поддомены. Ресерч проекты с ML и разработка CRM отличаются колоссально;

2) Если все таки выбрано IT, то узнать какие есть роли и специальности. Разобраться в том, какие типовые роли и специальности есть в IT, узнать их смысл (для чего они), области знаний и инструменты они используют. Составить для себя в голове понимание специфики каждого конкретного направления, от QA и до администратора баз данных;

3) Понять для себя: "а что мне интересно?". Только после того как появится критическая масса информации, можно принимать какие-то решения. И тут просто надо сматчить 2 вещи: "мне хочется X" и "специальность Y, которая может это закрыть";

Остановка
Зачем вообще пункты 1-3? Очень часто начинающие выбирают ПМ даже не разобравшись что это и идут потому что модно. Получается нелогичная ситуация, похожая на профориентацию в 11 классе. Я ничего не знаю про наноматериалы, но иду учиться на это направление. Часто тут появляется потеря мотивации.

4) В пункте 3 был выбран руководитель проектов. Выбрать специализацию для старта, чтобы получить необходимый опыт контекста. У вас уже появилось знания о специальностях в IT. Нужно выбрать на первое время ту, в которую порог входа проще всего для вас и устроится на работу;

5) Устроившись на работу по максимуму погружаться в контекст и потихоньку брать на себя инициативу;

6) После появления некоторого количества инициативы (например, пришли тестировщиком, но помогаете писать ТЗ проджекту) начать брать на себя принятие решений по этой инициативе, а следом уже и ответственность за принятые решения;

7) Качать теорию проектного управления. Для этого хорошо подойдет бесплатный курс PM 101 или книга Вани Селиховкина;

8) Поняв вершки теории проектного управления применять на практике в своей работе. Найти в своей рабочей деятельности проект и добиться роли его руководителя. Если такого нет, придумать его и создать. Например, устроились тестировщиком, возьмите проект по автоматизации тестирования или внедрению практик нагрузочного тестирования;

9) Начать поиск вакансии руководителя проектов. Тут 2 пути:
а) Пойти к руководителю в своей текущей компании и сказать о том, что вы хотите быть РП и доказать на фактах что вы уже получили такой опыт;
б) Пройти в другую организацию и устроится там с нуля РП.

Я сам прошел такой путь и множество моих коллег. При должной силе воли и мотивации этот путь можно пройти за пол-года.. Все в ваших руках. Развивайтесь!

#полезности
Хороший канал с авторским

Коллега ведёт очень приятный канал https://t.me/how_to_be_a_pm

Юля как ПМ с декабря 2020 года, разрабатывает образовательные продукты (сейчас в основном для школьников, но есть и для взрослых).

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

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

Настоятельно рекомендую почитать её посты, особенно https://t.me/how_to_be_a_pm/5

​#мнение
Методология не методология?)

Здравствуй, дорогой читатель. Это будет крамольный пост. Надеюсь он заставит тебя порефлексировать. Никакой фрустрации!

Давай сперва начнем с простого вопроса. Какие ты знаешь методологии управления проектами?
Сразу хочется выдать стандартный перечень вроде "Waterfall, Scrum, Agile, Kanban, PMBOK, Prince2 и т.д." Но давай разберемся.

Waterfall - это нарицательное, которое ввел У. Ройс для обозначения предиктивного жизненного цикла разработки ПО. Получается waterfall это просто SDLC.
Scrum - фреймворк управления разработкой продукта.
Agile - набор ценностей и принципов, мировоззрение или философия.
Kanban - метод выявления, управления и развития сервисами нематериального производства.
PMBOK - свод знаний по управлению проектами.
Prince2 - метод по управлению проектами.

Этот список можно продолжать довольно далеко, но я уверен с 75% что ни одной методологии в вашем перечне окажется. Как так? Почему тогда во всех вакансиях пишут "знания методологий". В сердцах хочется воскликнуть, "Да что такое эта ваша методология?"

Давай так и сделаем, заодно разберемся. Похожий вопрос появился в одном чате, привожу ссылку на старт треда https://t.me/kanban_talks/39680

Методика - это конкретное инженерное решение, это делай раз, делай два, делай три - профит. Способ применения чего-то определенного и описанного четко.
Аналогия - чертеж табуретки.

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

Метод - это методика придумывания методик - это уровень чуть выше. Это способ придумывания способов решения проблем.
Аналогия - ящик с инструментами, с помощью которого можно сделать как табуретку, так и доску для серфинга.

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

P.S. А теперь вернись к первому вопросу. Так что же у нас есть из методологий в арсенале?

#полезности
Обзор PMBOK 7

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

P.S. Ваню я так называю за глаза, за качество материалов и вклад в популяризацию проектного управления.

Экспресс-обзор PMBoK7:
- Предыдущая версия vs новая (и почему PMBoK 6 не устарел)
- Кратко о PMBoK 7: 12 принципах и 8 доменах - как я на них смотрю и как проще запомнить новую структуру?
- Тем кто планировал сдавать экзамен PMP - на что ориентироваться, нужно ли переучиваться?

1 час 35 минут: https://youtu.be/Y5oDQAYpWjI

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

Сообщества:
@agile_ru - Можно узнать как правильно имплементировать скрам и почему lean не до конца работает в IT;
@BA_PO_PM_PdM - сидят суровые менеджеры и аналитики, которые расскажут за кровавый энтерпрайз;
@kanban_talks - чат практиков канбан-метода, помогают и разъясняют;
@PM_lunch - сообщество менеджеров проектов преимущественно из СПб, регулярно собираются оффлайн и кушают еду;
@spbspm - более "серьезное" сообщество менеджеров IT проектов из СПб, проводящее регулярные мини-митапы
@pmin_ru - приверженцы PMBOK и акулы календарно-сетевого планирования;
@ru_scrum - сообщество скрам-мастеров и практиков скрама. Хейтерам не заходить;
@FrancisBaconClub - сообщество IT-шников про теорию систем, психология, теория вариаций и прочие жуткие вещи. Новичкам не рекомендуется;
@technicalexcellenceru - uруппа практиков инженерных навыков: TDD, Pair Programming, CI/CD, DevOps
@TeamLeadTalks - чат сообщества тимлидов с суровой культурой, не для слабонервных;
@OgileKambanScram - группа для разбора и объяснения неправильных статей и видео про agile и около него;
@pmclubvrn - клуб проектного управления преимущественно из Воронежа;
@Scrum_Community - сообщество скрам-мастеров вокруг Раффайзена.

Статьи:
@psilonsk
@pm_god
@managerjournal
@selihovkin
@pmdaily
@borisbutton
@beardpm
@ravingrabbid
@sn_hack
@how_to_be_a_pm
@pmclub
@myscrum

События:
@PM_Events
@agile_events
@it_drinkups
@kanban_events
@product_events
@agile_ru_webinars

Канал временно на паузе на неделю, идет квартальное планирование и чувствую себя Грейджоем "То что мертво умереть не может".

#полезности
Занятная конфа от Тинькофф
22 октября приглашаем на Tinkoff Agile Conference. Обсудим лидерство, командообразование, инженерные подходы и практики управления. Тема этого года — «Масштабирование изменений от команд до организации».

Эксперты отрасли и agile-тренеры расскажут о менеджменте инноваций, инженерных подходах, практическом опыте построения компаний. Всего — 16 докладов от спикеров из Авито, Альфа-Банка, Тинькофф, Циана, Scrumtrek и других компаний. Будут воркшопы и, разумеется, афтепати.

Онлайн-трансляция главного зала бесплатна для всех, нужна только регистрация. Участие в конференции офлайн в Москве — пожертвование 2000 ₽ в Фонд борьбы с лейкемией. Регистрируйтесь и переходите по ссылке для оплаты в ответном письме. Очное участие возможно только с QR-кодом.

Подробная программа и регистрация по ссылке: https://v.tinkoff.ru/tac2021

P.S. Нет не продался, это дружественная реклама, организует ее знакомый.

#полезности
Составим компанию PMBoK

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

1) Project Management Body of Knowledge (PMBoK)
2) Business Analysis Body of Knowledge (BABoK)
3) Business Process Management Common Body of Knowledge (CBoK)
4) Data Management Body of Knowledge (DMBoK)
5) Software Engineering Body of Knowledge (SWBoK)
6) Systems Engineering Body of Knowledge (SEBoK)
7) Business Architecture Body of Knowledge (BIZBoK)
8) Information Technology Architecture Body of Knowledge (ITABoK)
9) The Digital Practitioner Body of Knowledge (DPBoK)
10) Automation Body of Knowledge (ABoK)
11) Body of Knowledge and Curriculum to Advance Systems Engineering (BoKCASE)
12) Enterprise Architecture Body of Knowledge (EABoK)

Как уже догадался искушенный читатель почти в любой области есть своды знаний, которые претендуют на звание стандартов.
Они все разные, от 30 страниц в своде по развитию систем и до 1100 в своде по разработке ПО, где то описаны всеобъемлющие подходы и модели, как в SEBoK, а где то только общие черты как в BIZBoK. Общее у них одно - они описывают выжимку хороших практик и структурируют знания в определенной области. Почти как ГОСТы и IEEE).

Правда есть одно большое НО - это BoK-и именно то чем они являются, они не международные или государственные стандарты (хотя PMBoK очень пытается) и делая что-то ровно по ним ним нельзя сделать правильно. Вести холивары за чтобы процессы анализа были как в условном BABoK и по Вигерсу! не имеет особого смысла. Поэтому просто используйте мудрость этих документов и опыт ваших предшественников. Ведь нельзя сказать, что опыт был неправильным, верно?)