Цитаты из книги «Сделано»

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

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

Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально» ), однако сейчас я подразумеваю продуктивность

Как говорил Карл Поппер Смысл в том, чтобы учиться на чужих ошибках. Хотя детали провалов могут быть разными в зависимости от проекта, основные причины или ошибочные действия команды вполне можно применить к вашему случаю (и избежать их). Пора прекратить прятаться от поражений. Напротив, нужно рассматривать их как возможность чему-то научиться. Какие факторы стали причиной неудачи? Какие из них можно свести к минимуму или полностью исключить? Согласно Петроски, знания, которые мы черпаем из неудач, — самый богатый источник прогресса, если нам хватит смелости проанализировать, что произошло.

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

Согласно принципам вероятности, риск возникновения ряда независимых событий равняется произведению вероятностей каждого события в отдельности ( ). Другими словами, если вероятность того, что вы дочитаете эту и следующую главы, составляет 9 из 10 (9/10), общая вероятность, что вы дочитаете обе главы, составляет не 9/10, а 81/100.

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

Определить базовые показатели доверия прогнозам. Догадка = 40% доверия. Обоснованный расчет = 70%. Детальный и тщательный анализ = 90%. Лидеры команды должны согласовать, какая точность им нужна, сколько времени они дают программистам на ее расчеты и как справиться с рисками, если прогнозы не оправдаются.

Отметив предложенные идеи на диаграмме, можно увидеть, как они влияют на все три подхода. Опираясь на свой общий взгляд на проект, МП имеет возможность объединить все три подхода в один.

Планирование проекта предполагает поиск ответа на два вопроса. Ответ на первый: «Что нам нужно сделать?» — принято называть сбором требований. Ответ на второй: «Как мы это сделаем?» — называют проектированием и спецификациями (рис. 3.1). Требование — подробное описание критериев работы