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

Спасибо. Интересно. Но вот про энтропию с девушкой было самое интересное. Но в данном примере вы и заказчик и исполнитель. Вывод:
1. Иметь четкий план отдохнуть с девушкой в обозначенный срок.
2. Минимизировать риски - найти запасных девушек. Риск-карта.
3. Оценить худший вариант - ни одна не полетела.
4. Иметь план Б. Сдать билет, получить деньги.
5. По прилёту использовать сэкономленные в предыдущем пункте ресурсы на местную девушку или девушек. Тайминг. Не затягивать с этим. С UX можно разобраться потом, главное чтобы она быстро ответила да. Поклонники Agile пусть собирают ромашки и выбирают конфеты.
6. Постоянно сверяться с техническим специалистом, можно ли реализовать все желания, если вы не в Голландии.

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

Вы точно знаете, что означает слово энтропия?

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

Комментарий недоступен

Очень интересно, спасибо. Я сам разработчик, и сейчас пробую себя на позиции PM, поэтому такая статья очень полезна.

беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки

што?

грамотное планирование и средняя по профессионализму команда дадут лучший результат, чем плохое планирование и топовая команда- это нужно на первую полосу
Хорошая статья! Ждём продолжения

Очень круто, описано доступным языком, спасибо.

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

Говорю по своему опыту, когда в начале работы клиенту рассказываешь как делать все правильно: проектирование, ТЗ, тесты потом озвучиваешь что стоимость разработки увеличится раза в 2-3 клиент сразу прыгает в кусты ))

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

Менеджер проекта руководящий разработкой? Это возможно только в небольших проектах. Да и тут непонятно зачем менеджеру проекта подменять тим-лида или тим-лиду брать на себя обязанности менеджера.

"После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска."

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

"Все планы заносятся в таблицу. Мы получаем список рисков, отсортированный по степени урона проекту, и детальное описание планов по уменьшению степени влияния риска на проект."

А что дает степень урона? Возможность отсортировать риски по значимости?)

Отлично написано, жду продолжения

Материал отличный. Спасибо

"Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования."
Тут, вероятно, одно из другого и следует. Не понаслышке знаю, как не выспавшиеся менеджеры ставят задачи и что в итоге получается.

"Риск-карта — это таблица, в которой указываются все риски, разбитые по категориям, их шанс случиться, урон для проекта, а также план по их нейтрализации."
Зачем нужны цифры, если они всё равно заполняются субъективно? Так можно и просто две категории оставить - "как-нибудь выкрутимся" и "abandon ship!".

А так-то в целом, да, жду второй части.

Законспектировал.

Спасибо за отличную статью!

Великолепная статья, спасибо!

Материал отличны! Спасибо.
Неделя прошла, специально зашел проверить не пропустил ли что.
Фидбеки хорошие, людям нравится, вторую часть еще писать не передумали или просто времени нет?