============ FALCON ============
Вместо реквайрментс написать десижн?
============ FALCON ============
Те жк яйца, только вид сбоку по мне
============ FALCON ============
Более того, требования как раз таки говорят разработчику что ему не надо решать что пилить. За него это уже продумали и требуют выполнения)
Denis
в продуктовой разработке нет требований, есть идеи работающие и неработающие, проверенные и непроверенные
Denis
чтобы в разработку шли только проверенные идеи — user stories — придумали dual-track agile
============ FALCON ============
в продуктовой разработке нет требований, есть идеи работающие и неработающие, проверенные и непроверенные
Смотря для кого. Разработчику не сможете придти и сказать реализуй идею
Denis
я приходил
============ FALCON ============
Сеньор вас ткнет просто в картинку такую
============ FALCON ============
============ FALCON ============
И отправит дорабатывать вашу идею
Denis
э
============ FALCON ============
😁
Denis
вы продолжаете спорить с моим опытом в гипотетическом простанстве?
Nail’
вы можете хоть обпредъявляться в духе «продукт должен зарабатывать не менее 1млн долларов в месяц через полгода после выпуска на рынок»
Это не отменяет наличия требований. Другой вопрос - их претворение в жизнь. Не путаем. Вопрос ведь был в наличии или отсутствии требований к продукту
============ FALCON ============
Я как раз перевожу в практическую плоскость)
Nail’
я тоже так думал 10 лет назад, когда на фотках был тоже в костюме
Денис, по крайней мере мы к тебе приближаемся)))
Nail’
Щепотка позитива в чат
============ FALCON ============
Я уже переррс, ибо на картинке аллея, а может наоборот недорос))
Denis
я приходил
Я в общем-то согласен с тем, что вы пишите. Не расскажите как сделать, что бы разработчик мог приходить с идеей? Вы же не зря написали про dual track - так вот разработчик в другом track относительно продуктовой работы, не понятно откуда у них могут быть хорошие идеи. У нас такое бывает, но я может пару случаев припомню всего.
Denis
Про заказчиков и требования - согласен. Это какой-то чисто post СССР дискурс. Люди продукт делают, а у них заказчики какие-то вместо пользователей и требования вместо продуктовых гипотез.
Denis
вопрос, делают ли люди продукт?
А если не продукт, то что же мы делаем? Проект? =) Вот и приплыли, все то о чем мой теска пишет. Цель заменяем реализацией с порога.
Dmitry
А если не продукт, то что же мы делаем? Проект? =) Вот и приплыли, все то о чем мой теска пишет. Цель заменяем реализацией с порога.
так и я про это. разве не может быть целью "сделать проект", "выполнить требования" и т.д. я здесь не про смысл, а про реальную жизнь
Denis
в заказной и внутренней разработке при создании систем и решений могут вполне существовать «требования», хотя местами это мешает хорошей работе в продуктовой разработке при создании продуктов для открытого рынка большинство здоровых компаний понимают, что у них не требования, а идеи
Nail’
Ок, проверили, дальше?
Nail’
Работает
Denis
Работает
передаём в производство, например
Nail’
Производству как понять, как сделать?
Nail’
Идеи - согласен для создания прототипа
Denis
вот упрощённая модель
Denis
Denis
во многих хороших компаниях любой человек может добавлять идеи в бэклог идей продукта
У нас в беклог попадают проверенные идеи, как вы и писали. Невалидированные в другом треке. То есть задача это добавить идею в беклог на изучение другим людям из другого по сути процесса (у них там аналитка / юзер интервью и так далее).
Denis
Производству как понять, как сделать?
вы хотите, чтобы я вам пересказал, как работают user story или как?
============ FALCON ============
Чем такой подход отличается от разработки по гипотезам?
============ FALCON ============
На первый взгляд dual-track каша из lean startup, customer development и многого другого) но это на мой взгляд
Denis
Чем такой подход отличается от разработки по гипотезам?
У нас что-то близкое к Lean. До тестирования гипотезы, если вы помните есть предварительная проверка через аналитику, user интервью, прототипы. Если идея worth to test то тут уже другой track работает, делается MVP. Если MVP взлетел, то он итерируется.
============ FALCON ============
Mvp или poc?
Denis
MVP
Denis
я напомню, что бывает MVP без кода
Denis
мы это прототипами называем
============ FALCON ============
Что то новое узнал сегодня Спасибо)
Denis
Синди Альварез предлагает несколько видов MVP: - MVP для предварительного заказа - Клиентообразующиий MVP - MVP типа «Консьерж» - MVP типа «Волшебник страны Оз» - MVP для одновариантного использования - MVP типа «Чужой продукт» https://www.ozon.ru/context/detail/id/34432645/
Denis
Нам больше всего нравится «Консьерж»
============ FALCON ============
👍
============ FALCON ============
По сути получается дискавери фаза уменьшает неопределенность
Denis
конечно
Nail’
вы хотите, чтобы я вам пересказал, как работают user story или как?
Нет, я хочу сказать, user story по сути и есть требование. Написано в другой форме, да. Но по итогам рождаются задачи для доработки продукта. И для проверки идеи тоже нужно сформулировать требования, чтобы получить MVP. Все об одном и том же.
Denis
охх
============ FALCON ============
Две команды параллельно Одна тестит гипотезы, другая валидированные гипотезы пилит?
Что вы скажете на то, что дискавери фаза смахивает на антипаттерн специального спринта? К примеру некоторые команды юзают харденинг спринт, а в этом случае спринт дискавери спринт
Андрей
Нет, я хочу сказать, user story по сути и есть требование. Написано в другой форме, да. Но по итогам рождаются задачи для доработки продукта. И для проверки идеи тоже нужно сформулировать требования, чтобы получить MVP. Все об одном и том же.
Нет. User story не является требованием. Другое дело, что в мире десятки тысяч людей сидят и записывают требования в формате «как Вася Пупкин я хочу», и думают, что пишут user stories. Ну так это не первый и не последний карго-культ.
Алекс
Аналитик должен доработать User story так, что было понятно что делать разработчику - например
Андрей
Алекс
Agile
Андрей
Agile
Ты это всерьёз или ты приводишь пример косяка? я туплю 🙂
Алекс
Пример услышанного косяка
Андрей
Пример услышанного косяка
Фффффух! 🙂 Отпустило )))
Nail’
Нет. User story не является требованием. Другое дело, что в мире десятки тысяч людей сидят и записывают требования в формате «как Вася Пупкин я хочу», и думают, что пишут user stories. Ну так это не первый и не последний карго-культ.
Дайте, пожалуйста, ссыль на определение user story, которое является тру. Потому как ещё раз освежив память и пройдясь по первым ссылкам в гугл, все же фигурирует слово - требование в основе определения. Взять ту же Википедию, хотя сейчас меня, похоже, закидают тухлыми яйцами) https://ru.m.wikipedia.org/wiki/Пользовательские_истории
Yuriy
Википедия по Agile пролетает 😄
Yuriy
там ссылок на Скрамгайд нет?)
Nail’
Интересно ж, посмотрел перевод книги Паттона)
Nail’
Перевод скрам гайда
Nail’
Или это тоже не то? Надо читать на английском?)
Андрей
Или это тоже не то? Надо читать на английском?)
Да, НАДО, потому что там нет ни хера про требования. Там вот так написано: "The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product."
Андрей
Даже перевод от членов коммьюнити страдает косяками 🙁
Nail’
Nail’
Тоже не?
Nail’
С английским прям близко не дружу..
Nail’
Заранее прошу прощения, если задаю глупые вопросы
Artem
99% случаев переводится как требование, но видимо коллеги намекают на то, что здесь это надо переводить как потребность, ну или у коллег есть какое-то свое "авторское" виденье
Андрей
Заранее прошу прощения, если задаю глупые вопросы
Не глупые, Наиль. Глупых вопросов вообще нет. Но да - термин "требование" нагружен отрицательными смыслами, от которых я точно хочу дистанцироваться (Денис, скорее всего, тоже). Один из параметров дистанцирования он уже обозначил - верификация/валидация. Есть и другие.