#книгаНедели
Попробуем разбавить дайджест новой рубрикой. Периодически я делюсь впечатлениями от про менеджмент и проекты в IT и не только. Надеюсь, что такие посты-отзывы имеют для вас ценность.
Сегодня в рубрике - книга Гюнтера Верхеена "Скрам. Правила игры".
Верхеен - широко известная фигура, фактически официальный представитель скрама. Кстати, именно он, еще будучи консультантом, ввел в обиход знаменитые три вопроса на daily (что сделано, что будешь делать, что мешает).
"Правила игры" - это, наверное, идеальное руководство по фреймворку. И вот почему:
- компактное, но не настолько, как скрам-гайд
- ёмкое и структурированное, последовательно ведет по пути от самых основ agile и scrum до практик, тактик, инструментов и перспектив применения фреймворка в будущем
- очень бережно относится к читателю, не только терпеливо и доступно объясняет сложные понятия, но и дает право на личную интерпретацию
- познавательно даже для тех, кто хорошо знает фреймворк
- пронизано гуманизмом и уважением к людям и их труду.
В целом, это очень удачный пример сочетания "манифеста" и практического руководства. Рекомендую всем)
https://alpinabook.ru/catalog/book-skram-pravila-igry/

Всем привет!
В новом обзоре публикаций:
- гайд по созданию дорожной карты развития IT-продукта;
- этапы разработки проекта по ГОСТу (с мемами);
- чем плох микроменеджмент;
- сертификация на Р3
- как аналитику влиять на процессы компании (не всегда это легко);
- требования к аналитикам в Газпромбанке;
- чек-лист для проверки ТЗ;
- как команда сама стала определять зарплату менеджера о_О;
- новые "замены" Слаку, ватсапу и система управдения проектами в Notion.

Хороших выходных :)

Всем привет!
Я с обновлением :)
Теперь у всех публикаций, собранных для Дайджеста, есть копия в вики Notion. Копии прикреплены к каждому дайджесту.
Что это дает?
1) ресурс превращается из списка в ссылок в полноценную базу знаний, библиотеку отфильтрованных и отрецензированных материалов по управлению проектами (сейчас - около 600)
2) очень эффективно теперь работает поиск - выдача по запросам куда более релевантная, чем на сайтах-источниках (где в выдаче много мусора). Пример - на скрине.
3) мы застрахованы от удаления материала автором или площадкой.
А такое случается, и в этом случае можно будет прочитать копию материала, несмотря на инцидент.

Так что если вам или вашим коллегам нужно найти полезный/содержательный материал по какому-то аспекту проджект-менеджмента - смело используйте! И буду благодарен за обратную связь!

Очередной дайджест - уже на Vc.ru и в Notion, теперь не только со ссылками, но и с сохраненными публикациями.
Отдельно отмечу:
- шикарный материал про "гибкое" планирование
- гайд по расчету скорости спринта
- как делать постмортемы

А также шпаргалки по SQL и Jira)
Всем хороших выходных и успешных проектов!

Всем хороших выходных

Дайджест публикаций о проектах за неделю - уже на VC.RU
В подборке почти 30 материалов - читайте, сохраняйте, комментируйте!
Хиты недели:
⭐️ Как запустить команду разработки
⭐️Как проджекту и продакту управлять рабочим и личным временем, чтобы комфортно работать, всё успевать и не выгорать
⭐️Самый полный обзор курса Google Project Management: Professional Certificate
⭐️Как понять, что мидл стал синьором: процесс performance review аналитиков в Авито
⭐️Монолит или микросервисы — это не вопрос технологических предпочтений, это про time-to-market
⭐️Выбор трекера для проекта: что вместо Jira? Наш опыт поиска и сравнений

Вот и прошла неделя - и вас ждет новый дайджест.
В этот раз отдельно отмечу материалы:
⭐️ Зачем и как подводить итоги проекта в заказной разработке: наш опыт и советы
⭐️ Менеджер VS дизайнеры и копирайтеры: кто должен вести коммуникацию с заказчиком
⭐️ Шесть типов гениев на работе
⭐️ Как пасти котов в условиях российского IT?
⭐️ Конфликты в команде разработки: как сохранить фокус на результате

PS. Давно (3 недели!) я не делал свои обзоры на книги и курсы, - всё потому, что штудирую просто гигантский курс по PMBOK 7, про который напишу на след. неделе.

Всем привет! Среди ~30 публикаций, отобранных для этого дайджеста по управлению проектами, отдельно отмечу шорт-лист:
⭐️ обзор "производственной цепочки" проектов веб-студии - узнаете, как формируется ценность и стоимость
⭐️ подробный рассказ о переходе в ПМ и ключевые навыки для развития в этой роли
⭐️ чек-лист проблем и рисков в проекте
⭐️ методика "дерева целей" - способ быстро разобраться в проекте, если ты попал в него уже после старта

Читайте, сохраняйте, изучайте - и отдыхайте! Впереди много интересного!

Прошел курс "Управление проектами: Полное погружение в PMBOK 7", и это очень хороший курс для тех, кто хочет понять связь практики управления проектом с "матчастью" в виде PMBOK 7.

Рекомендую пройти его тем, кто в начале пути РП, а также "практикам", которые стихийно научились вести проекты, но чувствуют, что не хватает понятно изложенной, структурированной теории. Если вы уже читали и тем более хорошо ориентируетесь в PMBOK (и применяете), курс даст меньше, но даже в этом случае он может быть полезен, - есть готовые шаблоны артефактов, есть авторские интерпретации. Да и в целом, Никита Сергеев - один из контрибуторов/соавторов PMBOK 7, и слушать его интересно.

Теперь, как положено, о плюсах и "особенностях".
Плюсы:
+ Курс очень содержательный, около 25 часов на прохождение - это не преувеличение.
+ Насыщенная и разнообразная программа: лекции, дополнительные материалы, задачи, кейсы, в том числе по созданию проектных артефактов, а также тесты на знание (но есть нюанс, см. далее)
+ Действительно охвачен весь PMBOK 7. В целом структура курса такая:
- обзор ключевых понятий (проект, выгоды, ЖЦ, PMO и т.д.)
- структура PMBOK 7
- обзор каждого домена, выделенного в PMBOK 7
- общеиспользуемые артефакты
- общеиспользуемые модели
- общеиспользуемые методы
- адаптация
- окружение проекта, продукты, ценности, принципы
- PMO
+ Курс соответствует концепции стандарта. Автора не уносит в "личные" интерпретации, нет перекосов в какую-то из прикладных областей.
+Изложение очень комфортное, язык человеческий - автор успешно выдерживает баланс между "своими словами" и "не отходя от терминов PMBOK".
+ Много примеров из разных областей применения: геймдев, IT, медиапроекты, в том числе из проектов, в которых участвовал автор.
+ По окончании курса, при условии сдачи всех тестов, выдается сертификат.
+ Стоимость. Тут даже не знаю, как комментировать - курс сейчас стоит всего 1000 рублей, а при использовании промо-кодов и того дешевле. В заключение курса автор выдает промо-код на все свои курсы 50% скидку (INFINITY).

Теперь особенности:

* Как я понял, курс изначально был сделан для Udemy (да и сейчас там тоже присутствует, с очень высокими оценками). Это не мешает проходить его на stepik, но в курсе есть несколько ссылок на другие курсы автора на Udemy, и, допустим, из России зарегистрироваться там нельзя.
* Много разнообразных тестов, однако большая часть - из разряда "напиши что-нибудь в поле ответа, а потом узнай правильный". Это не способствует мотивации и закреплению материала. Тем не менее, есть и классические тесты с вариантами ответов, при этом штрафов за неверные попытки нет. В качестве положительной стороны - каждые тест и задание содержат подробное объяснение, почему именно этот вариант верный.
* В отдельных случаях изложение можно назвать многословным и не очень быстрым. Но это моя придирка, да и поставить скорость на 1,75 Stepik позволяет.
* Местами мне не хватало текстуальной привязки к самому стандарту. Было бы более круто, если бы в каждой из глав курса присутствовало соотнесение с "местом" в PMBOK. Если после курса слушатель откроет стандарт впервые, то он может быть дезориентирован - в курсе материалы немного в другом порядке.
* И еще не хватило более детального сопоставления с предшествующими версиями стандарта. С другой стороны, курс для начинающих, и детальная инвентаризация отличий тут не нужна.

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

Всем привет!
26-ой обзор полезностей для управления проектами уже ждет!
НА этой неделе нам рассказывали:
- об использовании критического пути в планировании проекта,
- о разнице между проектным и продуктовым подходами,
- о том, как сделать работу ПМа похожей на сказку и что этому мешает,
- о чаптерах как альтернативах обычным командам,
- о важности онбординга и R&D.
Отличная выдалась неделя!
А еще нашему дайджесту стукнуло полгода:
26 выпусков,
~800 публикаций вошло в обзоры,
почти сотня подписчиков
и десятки тысяч просмотров.
Принимаем поздравления 🎉

Давайте не игнорировать роль продюсера проектов
#заметкиНаПолях
Мы привыкли к РП/PM/руководителю проектов, но, как обычно, когда возникает общеупотребительный термин, всегда находятся "еретические движения". И "продюсер проектов" - это ересь, которая мне нравится 😜

Само слово "продюсер" уходит в медиа и entertainment, мы помним, как в 1990-ых на ТВ и в кино стали появляться эти непонятные фигуры в титрах. На самом деле, вполне понятные: продюсер не только отвечает за результат кино/тв-проекта, но и инициирует проект согласно своему видению, потребностям аудитории и т.д. И, разумеется, привлекает к реализации проекта других менеджеров и специалистов, исходя из нужных для этого проекта компетенций.

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

Я когда-то работал в медиа, и приходилось эпизодически быть "продюсером". Но потом я (снова) оказался в ИТ и понял, что роль у меня примерно та же самая. Я не получаю идею проекта от заказчика. Почти всегда я придумываю идею сам, просчитываю и собираю нужные ресурсы и веду проект к результату.

Тем не менее, русскоязычные публикации или курсы такому, как правило, не учат ( в отличие от англоязычных, кстати). Про "продюсера проектов" говорят разве что в связи с проектами в медиа и edtech'е. Приятным исключением являются публикации вроде этой, где "продюсер" - это тип РП, наряду с типами аккаунт-менеджера и администратора проекта.

Что еще более неприятно. Когда я учился на одном солидном курсе РП, я задал вопрос: "Почему нас, слушателей, не учат подбирать персонал или подрядчиков". С точки зрения "продюсирования проектов" - вполне логичная и даже обязательная задача. Но кураторы ответили, что, мол, это вообще не входит в задачи РП, т.к. он, как правило, работает с уже сформированной командой, а новых участников ему в клюве приносит HR, и заботиться о том, как выбрать и воспитать новичка в проекте, проджекту, в общем-то, и не надо. То же касалось и работы с подрядчиками, - и такие ответы, да еще и под видом "это же очевидно" вызвали у меня недоумение.

В общем, я всё чаще вижу себя именно как продюсера проектов. Не на визитке и не в должности, а в ролевой модели. И именно в сторону продюсирования стараюсь вести своих коллег.

За что я люблю лекции и вебинары Иннокентия - они всегда полезны и интересны, даже если вы вроде бы хорошо знакомы с темой.
Эту недавнюю трансляцию очень рекомендую всем, кто занимается сбором требований.
https://youtu.be/Y6H6zXP9VHQ

Всем привет!
В новом обзоре публикаций:
- причины, по которым не взлетают Agile, скрам и канбан (три отдельные статьи, но вот так кучно вышли)
- подготовка к P3.Express (ребята из Pmclub молодцы - теперь уже и мне хочется пройти этот курс). От них же прекрасная статья про ошибки ПМа.
- правила успешных тимлидов
- очень много классного опыта:
* странные паттерны автоматизации (у каждого заказчика свои тараканы)
* как выкрутиться из ситуации, когда на проекте нет документации
* вкусные кейсы по разработке продуктов для социальных служб и грантовых конкурсов.
- ОЧЕНЬ много публикаций про переезд с Трелло на...
Спасибо, что читаете! 😊

#книгаНедели
В магазине "Настольная книга project-менеджера" Владимира Завертайлова (а это основатель скрам-студии "Сибирикс") производит внушительное впечатление. Во-первых, 750 страниц - это вам не худосочные скрам-гайды и прочие "Дедлайны". Сразу видно, что управлять проектами - это не проскроллить пару статей на хабре и готово, а все-таки полноценный кусок гранита науки. Во-вторых, на открывшемся случайном развороте было много выстраданных крепких слов. Это давало надежду на искренность, непосредственность, много кейсов и жизненного опыта.
Конечно же, я купил и прочитал.

Главная фишка книги - ее энциклопедичность. Автор пишет эпичное полотно, посвященное управлению диджитал-проектами "от А до Я", в котором нашлось место практически всем темам и проблемам, с которыми можно столкнуться, реализуя проект. Здесь и скрам, и продуктовая разработка, и карта компетенций ПМа, и OKR, и оценка персонала, и работа с интеграциями, и риск-менеджмент, и даже микрокурс по основам технической грамотности. Бери, читай и используй и большие никакие материалы не нужны. Причем написано всё не заумными словами, требующими примечаний или гуглежа, а просто и понятно, как для своих, с приколами и цитатами из фильмов.

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

Еще интересный момент - это "голос автора" (помните, в школьной филологии так называется позиция рассказчика, стоящая за всеми описанными событиями). Голос "Владимира Завертайлова" суров и во многом авторитарен. Если вы верите в возможность самоорганизации, спиральную динамику и бирюзовые компании, вам лучше читать книгу с осторожностью, потому что в ее основе - фраза Трумэна "Любое действительно эффективное управление на поверку оказывается диктатурой". В книге нет других точек зрения, кроме авторской, и хоть и изредка, но, к сожалению, она напоминает долгий монолог босса на собрании, с прибаутками и поучениями.

И наконец, есть простой вопрос, на который я не смог найти однозначного ответа. Кому бы я порекомендовал эту книгу?
Вряд ли начинающим ПМам - у них нет релевантного опыта, чтобы спроецировать примеры автора на свою работу. Да и объем такой, что пока доберешься до конца - забудешь начало. Лучше уж более фастфудные книги, статьи и курсы.
Возможно, что опытным проджектам - из принципиально нового они узнают нюансы веб-разработки (если ей не занимались), ну и, конечно же, кейсы. Но тут может слегка отпугнуть тот самый "голос автора".
Пока главная ЦА книги, кажется, - руководители таких же, как "Сибирикс", веб-студий, которые смогут узнать, как разработка устроена у одного из лидеров рынка. Но это довольно мало...

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

Собрал материалы за неделю.
Отдельно отмечу вышедшие на неделе публикации про
- определение стоимости проекта/продукта
- диаграмму Гантта
- организацию дискавери-стадии
- проблемы коммуникации в команде
- культуру работы с ошибками
- переход с Trello на отечественные решения и свободное ПО.

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

Местами книга требует вникать в мат. статистику и немного экзотические предметные области, но in nuce она довольно простая: есть феномен "шума", когда по одному вопросу разные эксперты (или даже один и тот же) высказывают разные суждения, дают сильно дифференцирующие прогнозы.

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

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

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

Книга совсем не про управление проектами, но авторы регулярно проецируют свою теорию на работу аналитиков, предпроектные исследования и прогнозы трудозатрат проектов.

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

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

А еще я сейчас с интересом читаю небольшие монографии Юрия Дубровского про аналитику, аналитиков, бизнес-требования и пресейлы. Если интересен мой подробный обзор, - ставьте лайки, так у меня точно будет дополнительный стимул 😇
https://vc.ru/books/809592-mnogo-chek-listov-stressovye-relizy-i-kak-byt-kogda-tebe-figovo-proektnyy-daydzhest-29

#книгаНедели
Почти случайно набрел на новинку - книгу Татьяны Тиминой "Секреты аналитики, или Аналитика без секретов".
Как говорится, прочитал ее, чтобы вам не пришлось. Книга не столько про аналитику и требования, сколько про основы построения интерпретационных моделей и data-driven подход в управлении и маркетинге.

Главная тема - анализ данных как источник улучшения бизнес-процессов и роста бизнеса. На примере одного сквозного примера (кейса) нам показывают, как можно превратить сырые данные в аналитическую модель. А ее, в свою очередь, сделать основой для постановки целей компании и планирования изменений. По стилю книга нечто среднее между производственным романом (в духе "Дедлайна"), академической лекцией и постом в инстаграме. Местами крайне поверхностно, местами поглубже.

Плюсы:
- Хорошо и доступно изложены концепции аналитической модели, KPI, ABC, gap- и root-cause-анализа и т.д.
- Много практических и загружаемых примеров анализа и представления информации в excel (других средств автор избегает)
- Много примеров из фармы (родная сфера для автора)
Минусы:
- Не совсем про аналитику и не для аналитиков ;-)
- Хотя книга рассчитана на новичков в анализе данных, часть понятий (например, регрессионный анализ) изложены недостаточно понятно и доступно.
- Книга издана самим автором (self-publishing) со всеми вытекающими опечатками (это терпимо) и не отфильтрованными лирическими отступлениями (что нередко мешает читать и воспринимается скорее как неизбежная дань).

Рекомендовать не буду - разве что если вы случайно оказались в роли биздева с кучей отчетов на столе и совсем не знаете, с какого бока к ним подступиться.
https://www.litres.ru/book/tatyana-timina/sekrety-analitiki-ili-analitika-bez-sekretov-69510253/

Не могу не поделиться - люблю систематизированные данные, особенно если они для аналитиков и РП.

⭐️ Коллеги из Systems Education собрали гигантскую базу инфо по базам данных - Каталог ссылок на тему баз данных и анализа данных для аналитиков и проектировщиков.
В составе:
Основы использования реляционных баз данных
Структура языка SQL
Получение данных. Основы SQL (DQL: Data Query Language)
Базовые операторы SQL
Использование соединений
Агрегатные и аналитические функции
Генерация SQL-запросов
Основы оптимизации запросов
Разработка реляционных баз данных
Производительность и оптимизация SQL
Индексы в таблицах
Планы запроса
Денормализация
Теорема CAP
Транзакции в БД, OLTP, ACID, TCL
Команды администрирования баз данных в SQL
Ограничение видимости данных с помощью представлений
Обновление схем БД, Миграция данных
Администрирование реляционных баз данных
Команды администрирования баз данных в SQL
Ограничение видимости данных с помощью представлений
Обновление схем БД
Миграция данных
Документарные БД
Базы «ключ-значение»
Документарные БД
Колоночные БД
Основы анализа данных
Основы статистики
Основы анализа данных в Excel
Анализ данных с помощью SQL

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

Очередная подборка полезных материалов по управлению проектами.
В этот раз особо отмечу:
🔥 Безусловно, большую базу знаний по IT Project management, Авторы собрали в общую базу огромное количество материалов и тем практически по всем аспектам работы ПМа и управления проектами. Часть писали сами, часть компилировали из источников. Труд, достойный уважения! Читайте и ставьте в закладки!
🟢 Саммари-перевод руководства по написанию требований INCOSE (к стыду, я впервые про него узнал)
🟢 Материалы по сертификации P3.Express и PMP Exam
🟢 Лайфхаки по уходу в отпуск во время проекта, онбордингу, решению конфликтов в команде
🟢 Много кейсов и инструментов - в фокусе снова переход с Трелло и Jira.

#книгаНедели
Открыл для себя книги Юрия Дубровского - про бизнес-анализ и работу аналитика. Всего пока нашел 4 книги, все прочитал и, если вы не против, немного порассказываю.

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

Книга "Живые требования" - посвящена "созреванию" требований. Автор берет метафорический образ фрукта. Изменчивость требований часто недооценивается, а иногда и вовсе отвергается: собрали на старте - несём в неизменном виде до завершения проекта. Это "простая модель требований" - экономная и дает твердую почву под ногами. Но чем сложнее проект и будущая система - тем большими связями обрастает требование и тем меньше неизменны эти связи. Не говоря уже о том, что они могут измениться "просто так", вне связей.

"Динамическая модель требований" - другой полюс: это реалистичный подход (ну ведь действительно нужно допускать флюидность требований), однако чересчур затратно.

Решение - итерационные модели и учёт "растительного жизненного цикла" требований.
Начинается всё с посева/зарождения: у кого-то в голове появляется идея "а неплохо бы, чтобы...". Затем идет самый трудоемкий процесс - выращивание: идея обрастает "мясом", уточнениями, ограничениями, примерами и т.д. и т.п.

Вершина жизни - зрелость: требование готово к реализации, зафиксировано, должным образом детализировано.
В идеальном мире оно таким бы осталось - вечно зрелым. Но увы, внешние и внутренние факторы заставляют его "увядать" - утрачивать актуальность, сразу или постепенно. Итог жизни - умирание: полная неактуальность требования.

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

Зачем же учитывать этот "жизненный цикл"? В первую очередь, чтобы выставлять приоритеты. Реализация более зрелых требований, постановка на паузу реализации "молодняка" и отказ от реализации увядающих и мертвых - путь к сокращению потерей. И чем масштабнее проект, тем больше экономия.

Еще нужно учитывать влияние требования на проект, - увядание "широко влияющего" требования (например, зависимость от библиотеки) приведет к росту затрат на перестройку. Здесь важно балансировать: нельзя изолировать требование, поэтому нужно балансировать и еще на старте ввода требования убеждаться, что риск преждевременной смерти ключевого требования низкий.

От меня: конечно, как и любая метафора, тема "созревания" требований и вообще аналогий с живой природой может показаться "weird". Тем не менее, вместе с минусами (неточность и неформальность) метафоры имеют и плюсы - они стимулируют "правополушарное" мышление и поиск нестандартных, спорных мест в теории. И след. раз, когда я буду переписывать требование или закрывать его за ненадобностью, я точно вспомню про эти "фрукты"))
https://www.litres.ru/author/uriy-dubrovskiy/

#книгаНедели
Еще одна книга (скорее мега-лонгрид) Дубровского "Идеальный ИТ-аналитик (Как нанять лучшего аналитика в команду)" - о процессе найма. Причем это взгляд с обеих сторон, интересный как РП / тимлиду / архитектору / HR, так и самому аналитику. Автор обстоятельно рассказывает о собеседовании (и подготовке к нему), о развитии нужных качеств, о месте аналитика в команде проекта и компании.
Лично я сам в последнее время наймом почти не занимаюсь, но пройтись по виртуальному собеседованию было интересно, даже с учетом того, что книга 2019 года.
Условно она делится на две части. Первая - это процесса поиска аналитика. Глава для нанимающей стороны. Автор использует модель "метапрограмм" - установок, по степени выраженности которых можно определить, соответствует ли кандидат нашим требованиям (стремление, внутренняя референция, процесс, процедуры, содержание). Далее - про техническое интервью: определение, сможем ли мы собрать с этим кандидатом нужный нам пазл. В структуре интервью - определение "правил игры", проверка знаний базовых понятий, умение решать технические задачи, владение технологиями бизнес-анализа, доменами, технологиями системного анализа, понимание рисков и умение выходить из проблемных ситуаций.
Вторая часть - это сборник конкретных вопросов и задач для интервью аналитиков, все с примерами, по каждому из представленных выше направлений: общие, вопросы по требованиям, по документированию, по архитектуре (от микросервисов до REST и SOA), по бизнес-процессам, интеграциям. Отдельные главы - по решению задач и владению технологиями и инструментами: сформулируйте ФТ к такому-то предмету, программе, определите требования по работе с исключительными ситуациями, определите минимальный перечень этапов и документов для ЖЦ разработки из взятого примера. Вопросов и примеров реально много.

В общем, не могу не рекомендовать, - книга уникальна и максимально ориентирована на практику.