Что такое продуктовая разработка внешней командой и почему это не просто аутстаф или аутсорс
Куда ни глянь, все занимаются разработкой продуктов и цифровых сервисов (да, и мы тоже), но давайте по-честному разберемся: чем отличается продуктовая разработка от аутсорса и аутстафа, из каких составных частей собираются разные контракты на рынке заказной разработки, кто за что отвечает и что выгоднее для заказчика и команды.
Зачем нужна итеративно-инкрементальная модель, когда есть agile?
Наличие ТЗ свидетельствует о том, что клиент прорабатывал вопрос, у него есть идеи. Обсуждение ТЗ может быть полезным для команды и заказчика на старте, чтобы понять, что заказчик вообще хочет. Есть какие-то сложности в том, чтобы объяснить заказчику, что продукт будет развиваться, решения тестироваться и соответственно сам продукт будет меняться? Если да, то может, это не ваш клиент? Просто из контекста ясно, что мы проводим тесты и внедряем изменения, значит, ТЗ, где на старте все-все продумано, не подойдет априори никак, поскольку противоречит самой концепции работы над продуктом.
Если вы по Time&Material работает над продуктом заказчика и регулярно меняете исполнителей на нем, к которым у клиента есть доступ (то есть клиент знает, что спустя месяц у него другой дизайнер), то клиенту это не понравится, поскольку продукт должен делаться с хорошим погружением команды в вопросы заказчика. Вы сами менять постоянно дизайнеров и аналитиков и т.д. клиенту не будете, потому что от этого может пострадать и продукт, и отношения с клиентом, а разработка продукта - дорогое удовольствие, то есть если клиент платит хорошие деньги, настроен серьезно, работы надолго, к чему какие-то перемены, которые порождают риски?
Выходит, что при работе над продуктом по Time&Material команда будет постоянной, это разумные ожидания обеих сторон.
Про постоянную команду согласен (так и написано в статье)
Остальные соображения — как мне кажется — не относится к этому тексту. Т.е. — ок, это ваша позиция, но статья про другое )