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

про адвоката-обвинителя на 47 минуте прям в точку. отличный доклад. Спасибо, Егор!

Очень понравился доклад

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

ПМ-ы рисуют домик с клиентом. Потом ПМ-ма дрючит директор за недостроенный домик, ну а ПМ капает на мозг программисту.

Почему актёр всегда за пределами системы? А если бизнес-задача выполняется по таймеру или другому внутреннему событию?

Господи сколько дополнительного времени уходит на эту «войну» с требованиями и как легко под борьбой за качеством скрывать желание работать помедленнее Настоящее качество рождается из совместного желания делать качественно

Сначала мне показалось, что у человека полная каша в голове. Потом некоторые моменты показались здравыми (трассировка требований, конкретика, фокус на том, что надо сделать, а не как технически). А потом встало все на свои места, выборка у докладчика небольная, ТЗ пишется больше для защиты, такая придирчивость оправдана (хотя человека жалко, нелегко в таких условиях работать). У ТЗ есть три основные сферы применения: получить оценку затрат, рисков и т д, убедиться, что делается именно то, что решает проблему, и собственно подстраховаться от заказчиков/исполнителей. Тут, очевидно, третий случай - самый неблагодарный. Серьезно, если приходится так работать, это выматывает. Именно такие ТЗ и получаются - с одной стороны, максимально размытые, с другой программисты максимально въедливые. Ситуация you win - I lose. Но многие работают в другой парадигме, когда и PM/PO, и тех лид/менеджер хотят максимальную пользу за фиксированное время, и тогда наступает эра разговора - вот примерно как в первом примере. I believe - потому что хорошо бы, но не за все деньги мира. Послушаю, что вы скажите, и мы договоримся на оптимальном варианте. А еще версии вот тут в URL, у нашего соседнего продукта так, вдруг тебе пригодится. Но вообще я тебе доверяю, скажи, что тут лучше будет. Нормальное такое начало разговора с архитектом или лидом, приглашение к обсуждению. Ок, это не будет в документации, но может спецификацию тогда вообще технарь напишет. Это так, к слову, показать другой тип взаимоотношений.

С таким уровнем занудства докладчик не ту специализацию в IT выбрал. И, судя по всему, ему по жизни не везло с продактами (. Ну и продактам с ним тоже не фартило )

Худший докладчик на этом канале)

3 пункт - повторюсь .. просто переведи на русский язык .. и все станет понятно .. не надо английский язык транскриптировать !!! не надо !!! надо переводить на РУССКИЕ слова и понятия !!!