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

[musicorc]

Друзья джедаи и прокрастинотологи, поделитесь опытом какие книги/статьи почитать по управлению проектами в IT.
Какие книги быстрее и эффективнее помогли вам разобраться в этом вопросе?
Какие книги не оправдали ожидания?

В первую очередь хочу разобраться что и как должен делать проджет менеджер.
Как не закопаться в большом проекте сроком на пол года/год и разбить его на части.
С чего начать и как на этапе старта заложить правильную структуру сервиса, которую можно будет расширять и развивать без необходимости переделать все через 6 месяцев после запуска?

[ТыжМенеджер]

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

Как не закопаться в большом проекте сроком на пол года/год и разбить его на части.
С чего начать и как на этапе старта заложить правильную структуру сервиса, которую можно будет расширять и развивать без необходимости переделать все через 6 месяцев после запуска?

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

[Андрей Титов]

У меня сопутствующий, уточняющий вопрос.

А какими такими компетенциями должен обладать ПМ в отличие от обычного руководителя или вовсе специалиста, что ему требуется читать спецлитературу?

[Максим Дорофеев]

В свое время давным-давно мне понравились:
Джо Мараско, Заметки с передовой (по-моему как-то так в русском переводе)

А еще лет 8 назад я сделал небольшой обзорчик: http://cartmendum.livejournal.com/2569.html

[Sergey Martynenko]

Основная задача операционного менеджмента - улучшение качества производственного потока.

Неожиданно, правда?

Соответственного, порядок:
1. Приведение потока в статистически управляемое состояние.
2. Уменьшение вариаций.
3. Уменьшение связанного капитала.
4. ...(потом)

Первый пункт абсолютно необходим и обязательно идет первым. Без него проект неуправляем в принципе. Смотреть здесь: http://blog.shumoos.com/ по тегам:
http://blog.shumoos.com/archives/catego ... neii-caaa/
http://blog.shumoos.com/archives/catego ... oaeaiinoa/

Глубинные знания (из того, что читал я):
1. Понимание системы: Голдратт (все книги, но для начал Цель-3, Цель-1, Критическая цепь. В таком порядке)
2. Теория вариаций: Генри Нив, Деминг, Шухарт, ГОСТ Р 50779.42-99
3. Психология: Чалдини, Питер Уотс, Элиазер Юдковский (http://lesswrong.ru/)
4. Методы познания мира: Элиазер Юдковский (http://lesswrong.ru/), Лю Цысинь
До нового года хватит, потом снова спросите.
Если хотите именно по разработке, то Макс выложил файлик. Там много хороших книг.


PMBoK - мусор
"Ментальные ловушки" Куклы - мусор

[Максим Дорофеев]

Когда-то давным давно мы с @Sergey Martynenko сделали вот этот файлик:

рекомендации к чтению v5.xlsx

(28.75 KiB) Downloaded 876 times

Там много рекомендаций еще.

[Андрей Степенко]

В первую очередь хочу разобраться что и как должен делать проджет менеджер.
Как не закопаться в большом проекте сроком на пол года/год и разбить его на части.
С чего начать и как на этапе старта заложить правильную структуру сервиса, которую можно будет расширять и развивать без необходимости переделать все через 6 месяцев после запуска?

Есть условно 3 вещи, которые надо держать в уме. Как устроена твоя команда, как устроен потребитель и как работает твой организационный канал перевода энергии одних в энергию других. Обе стороны (потребители и команда) с твоей помощью должны куда-то качественно расти.
Тут Саша сказал, про роли. Можно их нарезать по разному. На проект в 150 человек одна нарезка, на 20 другая. Где-то стрим-менеджеры нужны, где-то технический менеджер в помощь пму хватит. Главный инженер проекта, как это говорили до перестройки. Нарезку нужно с экспертами обсуждать.
У меня начинается все с показателей и ответа на вопрос зачем каждой из групп стейхолдеров вся эта байда? И конечно на базе "нарезки" ролей, которая тоже может "плавать". Стейхолдеры что-то там говорят. Иногда не внятно. Иногда ничего. Часто намеренно врут. Часто говорят, что им выгодно и как стопудов надо сделать.
Потом ты мысленно послылаешь всех нафиг и спрашиваешь себя или какого-то советчика-рисоквика, как сделать, чтобы все эти холдеры не погубили проект своими неотвратимым оттягиванием одеяла на себя? И назначаешь волюнтариским решением свои показатели. Т.е. делаешь модель сервиса, что хорошо и что плохо. Куды бечь? Что будешь поощрять и как будешь оценивать, что ты движешься к цели?
Убеждаешь всех, что это именно то, что они хотят. Как получится. Дальше детали. До этого момента икс тебе не поможет никакая книга. Потому что эта книга - это твоя модель мира заработанная отдельными тупиками и размышлениями о вариантах "вокруг". Смог сделать модель - руководитель проекта. Не смог - можешь читать книги.
Что-то есть у молодого Голдрата в теме "предложение мафии" и чтото у Рекхема в "спин-продажах". Что-то есть у старого Голдрата. Что-то есть у Деминга. Серега в Максом там даже список подготовил.
То, что будет после этого момента икс - книг мульён. Толку от них будет, когда сделаешь ляп и поймешь, про что было в книге.
И момент этот обычно начинается не с первых дней проекта. Последний раз месяц потребовался, чтобы я понял как. И еще два месяца, чтобы я понял, как объяснить другим, как измерять прогресс. Т.е. это процесс. Вначале проекта ежедневный. Ночью лучше про все забывать.
И модели сервиса (модели пользователей сервиса) должно быть понятно, как отчетные периоды разрезают твой проект на итерации твоих же показателей, а не итерации разработки.
Ну тоже не сразу. А где-то с второй третьей итерации измерений. И до того как они выкристализуются никому лучше не говорить почему и как.
Нужно увидеть игру, в которой ты архитектор и сам не участвуешь, как игрок. Хотя можно как тренер, но чтобы архитектура от этого не страдала. Тогда проект не расползется.
Ну потом мозг тоже можно отформатировать, все равно тебя никто не поймет. Хотя если есть кому понять, успех проекта очень высокий. Два человека - это очень много. И "дальше" нужно сделать ставку, кто из людей вокруг будет ждать твои инструкции, а кто будет думать своей головой и предлагать решения. Потом расслабиться и получать удовольствие потому, что все будет все равно не так, как вначале это показалось. ... найдутся люди со своими предложениями. Часто хорошие.
Главное, чтобы другие думали что ты руководитель и ты сам себе в этом верил.
Ничего нового, примерно также, как стать ёжиками.

[Anton Dadiani]

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

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

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

Помимо стандартных инструментов планирования (типа диаграммы Ганта, доски канбан), стоит почитать про Agile, но нельзя его использовать бездумно.
- PMI PMBoK: кратко по сути - https://youtu.be/pZXqfFOClw4 (10 минут достаточно)
- Советую хорошо разобраться с MS Project'ом (на маке лучша программа - OmniPlan). Обратите внимание на метод критического пути, планирование ресурсов.
- Гибкие методологии (Scrum) за 15 минут: https://youtu.be/loVd5MTCBWI
- А. Коуберн, "Каждому проекту своя методология" (http://www.maxkir.com/sd/methyperproject_RUS.htm)
- Э. Йордон, "Путь камикадзе"

Не пугайтесь программерской специфики - эта отрасль на острие управления проектами, т.к. там очень много неопределенностей и результат трудно "пощупать".

[Sergey Martynenko]

...
Потом ты мысленно послылаешь всех нафиг и спрашиваешь себя или какого-то советчика-рисоквика, как сделать, чтобы все эти холдеры не погубили проект своими неотвратимым оттягиванием одеяла на себя? И назначаешь волюнтариским решением свои показатели. Т.е. делаешь модель сервиса, что хорошо и что плохо. Куды бечь? Что будешь поощрять и как будешь оценивать, что ты движешься к цели?
Убеждаешь всех, что это именно то, что они хотят. Как получится. Дальше детали. До этого момента икс тебе не поможет никакая книга.
...

2Андрей. Ну ты загнул! Я сам не с первого раза понял. А я с тобой знаком лет ... много. Пожалей мозги окружающих.

2Остальные. Андрей прав, если вы не смогли доказать и он это принял, что он не прав. Иное тоже возможно, но маловероятно.

[Sergey Martynenko]

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

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

Ни разу не является целью. Поскольку не проходит классификатор Голдратта. Такую цель - сразу в мусорною корзину. И закрыть крышкой.