Владимир Корниенко

Рекомендую курсы Ивана Селиховкина, считаю, что это лучший тренер по хард скиллс менеджера проекта.

Он рассматривает как гибкие методологии, так и более тяжеловесные. В своей действенности опирается на рекомендации PMI (project management institute) и его PMBoK (Project Management Body of Knowledge). Читать его самостоятельно я бы не рекомендовал, т.к. не книга в привычном понимании, там нет нарратива и какого-то связанного повествования, это именно, что свод знаний, справочник, если угодно. Он ОЧЕНЬ тяжело читается, чаще всего его стоит читать, когда уже есть опыт.

Также можно пройти бесплатные курсы от Google на Coursere (но там уже через VPN). Там рассказываются совсем основы, но если нет базы, то можно проходить, они довольно объёмные.

Есть opensource проект Redmine, он бесплатный и продолжает развиваться. Выглядит не очень, но есть темы, которые можно использовать. Есть и гант, интеграции с гитом и всё остальное

Если я правильно понял твой вопрос, то calendly должен подойти

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

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

Возможно причины проблем на проектах в компромиссах, баги и недоработки могли произойти не потому что кто-то плохой или криворукий, а из-за сроков/бюджетов/задач. (Хотя возможно, конечно, кто-то и криворукий).

Процитирую здесь Фёдора Борщёва, хоть этот текст для программистов, мне кажется, что это частично ответ на вопрос:

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

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

Могу дать другой совет — старайтесь улучшать всё. Если вы старше мидла — подходы к кодированию на проекте для вас уже не могут быть константой. Даже на самом чистом проекте с самой высокой инженерной культурой, весь код, который вы видите — это результат компромисса со временем. Если бы код писали безкомпромиссно, скорее всего компания, в которой вы работаете, уже не существовала бы.

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

Здесь есть встречные вопросы:

• 7 проектов = 7 команд?
  
• Сколько человек в подчинении у менеджера?
  
• Работают ли эти люди только с ним?
  
• Этот же менеджер следит не только за перформансом проекта, но и за состоянием людей?
  

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

Что такое работа PM?
Чаще всего это: знание предметной области (строительство, еком, косметика, медицина, что угодно), коммуникации с людьми, понимание бизнеса, и знание методов управления проектами и людьми. Если вы PM в разработке, то понимать базу разработки обязательно, уметь программировать не обязательно.

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

Знания сами по себе никому не нужны. Если вы где-то работаете, попробуйте взять на себя доп.работу по ведению проекта, или помогите кому-то в управлении. Это потом можно будет занести в резюме. Главное, чтобы были результаты.

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

Курсы:

• Бесплатный и короткий курс об основах профессии от PMClub: https://pmclub.pro/courses/pm-101
  
• Бесплатный и короткий курс об основах профессии от школы Стратоплан: https://stratoplan-school.com/edu/pm-101/
  
• Фундаментальный курс про управление проектами: https://selihovkin.com/p/pmp-exam-prep
  

Ютюб:
Гибкое управление продуктом в двух словах. Видео

Книги:

1. Борис Вольфсон - “Гибкие методологии разработки”. Комментарий: Кратко и по делу об основных гибких методологиях разработки.
   
2. Селиховкин Иван - “Управление ИТ-проектом”. Комментарий: Даёт хорошую теоретическую основу. pmlead.ru/books.html.
   
3. Джефф Сазерленд - SCRUM. Революционный метод управления проектами.
   
4. Максим Батырев - “45 татуировок менеджера”.
   
5. Сарычева, Ильяхов - “Новые правила деловой переписки”.
   
6. Борис Спирт - “Отчаянные аккаунт менеджеры” (за исключением части про характеры). Комментарий: Если работаете в аутсорсной организации. помогает понять как действовать с клиентом
   
7. Дэвид Ален - GTD (Getting Things Done). “Как привести дела в порядок”. Комментарий: классика, многие критикуют, но если вы далеки от тайм менеджмента, поможет хоть как-то структурировать.
   
8. C. Дж. Скотт. - “Ноль во Входящих”. Комментарий: Горячо рекомендую подход к управлению почтой Zero Inbox
   
9. Джим Кэмп - “Сначала скажите нет”.
   
10. Гэвин Кеннеди - “Договориться можно обо всем! Как добиваться максимума в любых переговорах.
    
11. Том Де Марко - Deadline. Роман об управлении проектами.
    

Методологии управления проектами:

1. SCRUM (Лучше прочитать книгу Сазерленда и методичку Вольфсона выше, но кратко вот)
   
2. Канбан (habr)
   
3. Waterfall, каскад (wiki, third)
   

Как можно развиваться:

• Предметная область
  
• Теория менеджмента проектов
  
• Управление командой
  

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

Теория менеджмента проектов.
Здесь непаханое поле. Есть PMBoK (6-я версия, зимой вроде выходит 7-я), по факту это больше справочник, чем учебник, но он очень объёмный и сложный. Можно купить курс подготовке к PMP. Ребят с таким сертификатом очень уважают на рынке. Можно пойти в сторону британской PRINCE2, и тоже сдать сертификат.

Управление командой.
Самая холиварная часть. В бóльшей части компаний менеджер управляет командой и их настроениями. Управление людьми тоже объёмная тема. Книг тысячи, курсов и спикеров тоже. Можно посмотреть разные открытые курсы/видео (из популярных Фридман), можно тоже купить курс. Лично я рекомендую Школу менеджеров Стратоплан, там дают внятные инструменты работы с людьми, которые можно внедрять хоть завтра.

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

Плюсую ответ Константин Нагибович, книга Ивана Селиховкина - топ, она как раз по PMI.

Скопирую свой ответ из другого вопроса, правила вроде разрешают.

Если есть деньги, можно купить курс у больших онлайн-платформ (скилбокс, нетология, гикбрейнс), но если есть мотивация и время, то можно начать самому.

Курсы:

• Бесплатный и короткий курс об основах профессии: https://pmclub.pro/courses/pm-101
  
• Фундаментальный курс про управление проектами, если пройдёте весь (действительно пройдёте), вы будете не хуже 20-30% рынка управленцев: https://selihovkin.com/p/pmp-exam-prep
  

Ютюб:

• Азбука программиста. Даст понимание о веб разработке. О чем вообще речь.
  
• Гибкое управление продуктом в двух словах. Видео
  

Книги:

1. Борис Вольфсон - “Гибкие методологии разработки”. Комментарий: Кратко и по делу об основных гибких методологиях разработки.
   
2. Селиховкин Иван - “Управление ИТ-проектом”. Комментарий: Даёт хорошую теоретическую основу.
   
3. Джефф Сазерленд - SCRUM. Революционный метод управления проектами.
   
4. Максим Батырев - “45 татуировок менеджера”.
   
5. Сарычева, Ильяхов - “Новые правила деловой переписки”.
   
6. Борис Спирт - “Отчаянные аккаунт менеджеры” (за исключением части про характеры). Комментарий: Если работаете в аутсорсной организации. помогает понять как действовать с клиентом
   
7. Дэвид Ален - GTD (Getting Things Done). “Как привести дела в порядок”. Комментарий: классика, многие критикуют, но если вы далеки от тайм менеджмента, поможет хоть как-то структурировать.
   
8. C. Дж. Скотт. - “Ноль во Входящих”. Комментарий: Горячо рекомендую подход к управлению почтой Zero Inbox
   
9. Джим Кэмп - “Сначала скажите нет”.
   
10. Гэвин Кеннеди - “Договориться можно обо всем! Как добиваться максимума в любых переговорах.
    
11. Том Де Марко - Deadline. Роман об управлении проектами.
    

Методологии управления проектами:

1. SCRUM (Лучше прочитать книгу Сазерленда и методичку Вольфсона выше, но кратко вот)
   
2. Канбан (habr)
   
3. Waterfall, каскад (wiki, third)
   

---

Знания сами по себе никому не нужны, изучайте темы и пробуйте инструменты в работе, которые вам близки.

Ранее упоминали генераторы, тоже о них подумал. Например getterms, довольно гибкий в настройках.

Думаю, что с юристами лучше всё равно обсудить полученные документы, но это должно быть дешевле, чем делать с нуля.

Должны подойти простые To-do сервисы. Здесь в топе:

• Todoist
  
• Any.do
  
• Microsoft To-Do (приемник WunderList)
  
• TickTick
  
• Если пользуетесь Gmail, можно использовать нативный трекер от Google
  

Trello, Asana - тоже можно использовать. Хотя они наверно больше командные.

У меня солянка из:

• Trello для больших задач. Например: Ремонт в квартире, оформление документов, личные проекты и т.д.
  
• Для "долгих списков" Google Keep. Например: список книг, фильмов, игр т.д.
  
• Для "коротких" списков Google Keep или Microsoft To-Do (ex-Wunderlist). Например: покупка продуктов, быстрые записки для дел
  

• Для совместной разработки GitLab
  
• Для общения Discord или Slack подойдут. Есть аналоги вроде RocketChat.
  
• Для организации процесса Trello или Redmine (интерфейс старый, но есть много разных настроек для выкладывание в паблик и для команды).