Как делать проекты, не стреляя себе в ногу
Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.
Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.
Это лучшее, что я читал по управлению проектами.
Подозреваю что такой подход спас бы много проектов, в которых я участвовал как разработчик.
Спасибо. Интересно. Но вот про энтропию с девушкой было самое интересное. Но в данном примере вы и заказчик и исполнитель. Вывод:
1. Иметь четкий план отдохнуть с девушкой в обозначенный срок.
2. Минимизировать риски - найти запасных девушек. Риск-карта.
3. Оценить худший вариант - ни одна не полетела.
4. Иметь план Б. Сдать билет, получить деньги.
5. По прилёту использовать сэкономленные в предыдущем пункте ресурсы на местную девушку или девушек. Тайминг. Не затягивать с этим. С UX можно разобраться потом, главное чтобы она быстро ответила да. Поклонники Agile пусть собирают ромашки и выбирают конфеты.
6. Постоянно сверяться с техническим специалистом, можно ли реализовать все желания, если вы не в Голландии.
А если серьезно, то риски оценивать приходится тогда, когда вы работаете при дефиците ресурсов. Любых: время, деньги, информация. Привлекать технического специалиста (ов)нужно всегда. Основа реализации должна быть легко трансформируемой, расширяемой. И четкий, понятный в деталях алгоритм исключает самый опасный - человеческий фактор, то есть хотя бы руководитель проекта должен понимать все что происходит. В идеале три: заказчик, руководитель проекта, исполнитель.
девушка - waterfall или девушка - agile. Вот вопрос вопросов
Вы точно знаете, что означает слово энтропия?
Крутая и годная статья о том как проходит живой процесс сотворения проектов.
Сожалею что меня не учат таким методом управления в Универе, которые действительно помогали бы в процессе. В нашу эпоху уже не годиться старые графики и теории по управлению бизнесом либо же проектами , но мало кто из профессоров умеет потребить и подать правильно на блюде для студентов инновационные фичи.
Возможно я чересчур критичен.... Но современное высшее (да и школьное) в стране это потеря времени и практически нулевой выхлоп (за исключением некоторых сфер типа медицины, инженеров где действительно без знания теории можно потерять человеческие жизни). Ну бывают ещё учителя от бога...
В основном же впихивают не те знания и не так да ещё и винтик из человека делают.
Замечу, что почти все это указывается в стандарте PMBoK - ему лет почти столько же, сколько мне :) Дело, наверное, не в том что теории устарели - а как их подают.
Но, рад если мои мысли показались вам полезными.
Комментарий недоступен
а энтропия?
Очень интересно, спасибо. Я сам разработчик, и сейчас пробую себя на позиции PM, поэтому такая статья очень полезна.
беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки
што?
простите, затупил спросонья
минусов отгрузите, пожалуйста
грамотное планирование и средняя по профессионализму команда дадут лучший результат, чем плохое планирование и топовая команда- это нужно на первую полосу
Хорошая статья! Ждём продолжения
Очень круто, описано доступным языком, спасибо.
Жаль только что вся эта красивая теория ломается когда заказчик проекта это микро-бизнес, у которого тупо нет столько средств чтобы пройти все эти правильные ступени, при этом он это прекрасно понимает и готов мирится с отсутствием всего что есть в статье, да и в этом случае разработчик как правило всего один.
Говорю по своему опыту, когда в начале работы клиенту рассказываешь как делать все правильно: проектирование, ТЗ, тесты потом озвучиваешь что стоимость разработки увеличится раза в 2-3 клиент сразу прыгает в кусты ))
Опять же есть у меня много примеров проектов когда не было ни ТЗ ни проектирования, разработка велась с помощью постановок задач в вайбере и ничего страшного не случилось, т.к. проект небольшой, только для личного использования в компании заказчика
Разработка индивидуальных, кастомных решений, где все перечисленные этапы - это необходимость, становится уделом крупных заказчиков. Выбор микро-бизнеса - шаблонные и коробочные решения. Либо это микро-проекты :)
Менеджер проекта руководящий разработкой? Это возможно только в небольших проектах. Да и тут непонятно зачем менеджеру проекта подменять тим-лида или тим-лиду брать на себя обязанности менеджера.
есть такое понятие, как «менеджер продукта». И это уже точно не для «небольших» проектов
"После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска."
Один сановник трижды думал прежде, чем что-то сделать. Услышав об этом, Конфуций сказал:
- Достаточно и двух раз.
"Все планы заносятся в таблицу. Мы получаем список рисков, отсортированный по степени урона проекту, и детальное описание планов по уменьшению степени влияния риска на проект."
А что дает степень урона? Возможность отсортировать риски по значимости?)
Привет.
1. Ну да :)
2. Степень урона нужна для понимания, что более важно, что менее важно. Предположим, что у нас есть всего три риска:
- Риск того, что дизайнер не успеет сдать в срок и мы не сможем вовремя начать фронт. Назначим ему значение урона 400 из 1000, а вероятность 3 из 5 (не лучший у нас дизайнер, раздолбай)
- Риск того, что внешняя платформа поменяет какие-нибудь методы API и что-то нам запретит из нужного. Вероятность 1 из 5, а урон 900 из 1000, проект вообще не случится без этого.
- И еще один риск того, что нам не поставят вовремя контент для шеров. Урон не страшный - всего 100 из 1000, а вероятность пусть будет 4 из 5.
В этой оценке мы понимаем, что внешняя платформа это конечно хорошо, она вроде как нам запарывает проект, но шанс этого не высок. Можно прописать план, что будем делать, если вдруг - и будем ждать. А вот дизайн, который сместит нам весь фронт - это серьезно, здесь надо внимательно следить.
Да, в общем и целом это нужно для сортировки и понимания, куда направить фокус внимания на разных временных участках разработки. На примере с тремя рисками можно держать все в голове. Но если у нас проект имеет 40-50 рисков, 3-5 разных подрядчиков, кучу людей - это все становится актуальным, потому что голова одна - а проблем очень много.
Отлично написано, жду продолжения
Материал отличный. Спасибо
"Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования."
Тут, вероятно, одно из другого и следует. Не понаслышке знаю, как не выспавшиеся менеджеры ставят задачи и что в итоге получается.
"Риск-карта — это таблица, в которой указываются все риски, разбитые по категориям, их шанс случиться, урон для проекта, а также план по их нейтрализации."
Зачем нужны цифры, если они всё равно заполняются субъективно? Так можно и просто две категории оставить - "как-нибудь выкрутимся" и "abandon ship!".
А так-то в целом, да, жду второй части.
Законспектировал.
Спасибо за отличную статью!
Великолепная статья, спасибо!
Материал отличны! Спасибо.
Неделя прошла, специально зашел проверить не пропустил ли что.
Фидбеки хорошие, людям нравится, вторую часть еще писать не передумали или просто времени нет?
Привет!
Не передумал, но пока не получается написать ее хорошо. А публиковать то, что мне заведомо не нравится я не хочу :)