Как разделить процессы дискавери и разработки в продуктовой команде. | Рауф Еникеев, Авито

• В видео обсуждается процесс дискавери, который был хаотичным и несистемным в компании Авито.  

• Проблемы включали непредсказуемость результатов, резиновую спринту, непредсказуемость результатов и низкую прозрачность.  

• Команда Авито решила переосмыслить процесс дискавери и создать его на основе дизайн-мышления и касд.  

• Был создан дабл даймонд, который позволяет генерировать набор вариантов решения проблем и выбирать оптимальное решение.  

• В итоге был сформирован отдельный дискавери-бэклок, за который отвечает команда дискавери во главе с продактом.  

• Команда продукта внедрила систему дискавери, основанную на крам-методологии, в свою работу.  

• Система включает в себя спринты, род-мэпы, биг пикчи и другие артефакты.  

• Система дискавери повысила предсказуемость процесса изучения проблем и решений, улучшила линкование целей и решений, а также прозрачность работы команды.  

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

• Важно работать с проблемами, а не только с решениями, и не полагаться только на опыт и драйв.  

• Рекомендуется проводить однодневные переосмысления и ретроспективы, чтобы сменить обстановку и расставить приоритеты.  

• Привлечение разработчиков к исследованиям помогает упростить переход между дискавери и разработкой.  

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

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

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

• Обсуждается, что в команде может быть разделение на процессы разработки и доставки, и что разработка может активно участвовать в процессе доставки.  

• Упоминается, что если команда небольшая, она может делать и то, и другое.  

• Обсуждается, как решать проблему между командами разработки и доставки, когда они не могут найти ресурс.  

• Упоминается, что команда может привлекать разработку для решения проблем или использовать дизайнера или аналитика для помощи в процессе разработки.  

• Упоминается, что дема - это процесс, в котором разработка должна челленджить команду доставки, чтобы понять, как и почему они делают то, что делают.  

• Обсуждается, что разработка также должна оценивать потенциальные решения и задачи, которые они берут в процессе доставки, на основе их потенциальной реализации и результатов.