Как выбрать книгу по управлению проектами

Какую проблему должна помочь решить книга

Запрос «книги по управлению проектами» объединяет разные потребности. Один читатель осваивает профессию и хочет разобраться в терминах. Другой выбирает способ организации работы команды. Третий знает названия методологий, но каждую пятницу снова выясняет, что обещанный результат не готов. Им нужен разный порядок чтения.

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

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

Какие книги отвечают на разные вопросы

Для выбора полезно различать три вопроса: как устроен Scrum, что означает Agile и как связать цель проекта с задачами и планом. «Как приготовить проект», которому посвящён этот сайт, разбирает последний вопрос.

МИФ представляет книгу Сазерленда как изложение Scrum от разработчика методики. Такой выбор уместен, когда вопрос читателя связан именно с этим подходом. Сначала стоит определить, какие затруднения команды предполагается решать с его помощью, и затем сопоставить ожидания с содержанием.

В описании «Чистого Agile» у издательства «Питер» Agile рассматривается применительно к небольшим командам программистов и их проектам. Это более определённый контекст, чем любое управление работой вообще. Для читателя вне разработки сначала полезно посмотреть фрагмент и оценить, насколько понятны примеры.

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

Пример: почему готовая страница ещё не означает готовый запуск

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

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

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

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

Какие главы открыть для такого проекта

В главе 3 «Цели, задачи, сроки и этапы» разделы «Цель», «Задача» и «Меню постановщика» помогают развести желаемый результат и действия для его получения. Для примера со страницей это различие между «опубликовать форму» и получить работающую регистрацию. «Меню исполнителя» позволяет посмотреть на описание с другой стороны: достаточно ли информации, чтобы принять работу.

В главе 6 «Проектирование» раздел «Карточка проекта» объясняет, зачем хранить актуальные цели и договорённости в доступном участникам документе. Раздел «Чек-лист» обращает внимание на маршрут запуска, зависимости и тайминги. Именно сюда относится проверка согласований и готовности соседних участников.

В главе 7 «Планирование», в разделе «Проектное планирование», разобраны регулярная сверка задач, сроки, ответственные и возвращение к дедлайну. Это продолжение предыдущих решений: документ должен обновляться по ходу работы. Для знакомства с темой на сайте есть отдельный разбор плана проекта, а для сравнения подходов — Agile и Waterfall.

Как понять, что выбранная книга пригодится

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

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