Перед нами, друзья мои, вязанка сосисок диаграмма, на примере которой можно объяснить суть продуктового подхода. Диаграмма разбита на 3 ромба, соответствующих трем основным этапам жизни продуктовой задачи: 1) определение и проработка продуктовой проблемы; 2) нахождение и проработка идеи для решения проблемы; 3) выкатка решения проблемы и последующие разработки. При этом вязанка сосисок ромбы тут нарисованы не просто так - каждый из них символизирует, что на каждом этапе сперва нарастает неопределенность (ромб расширяется), а дальше мы с этой неопределенностью как-то работаем - и приходим в точку предельной ясности (ромб сходит на нет). А теперь посмотрим, как это работает на примере отдельных этапов: - Сперва мы должны разобраться с проблемой: понять, какие проблемы у нас в принципе есть (на схеме - Problem Discovery). При этом мы можем нарыть кучу всего - но за какую проблему надо будет браться, непонятно. Именно поэтому в этой точке неопределенность зашкаливает - и мы должны ее забороть, оценив каждую из проблем на массовость и критичность, детально проанализировать приоритетные - и остановиться на чем-то одном (Problem Definition). И в этой точке неопределенность ьудет уже нулевой, ведь мы знаем, какую проблему хотим решить. - Разобравшись с проблемой, мы начинаем генерить идеи для ее решения (Solution Discovery). Идей у нас может появиться много, часть идей будут откровенно бредовыми, часть - нереализуемыми, часть - вредными. Это и есть самая широкая точка ромба - точка максимальной неопределенности. Чтобы одолеть босса этого уровня, нам нужно проанализировать каждую из идей, оценить ее на адекватность и реалистичность, а уже после этого остановиться на решении, которое будет нам нравиться (Concept Validation). Это будет вторая точка определенности. - Дальше у нас идет детальный дизайн и разработка. Здесь выдерживается примерно тот же принцип: сперва мы разрабатываем наше решение и в какой-то момент находимся в состоянии полного хз, как это будет работать (максимальная неопределенность!) - но потом находим верное решение, выкатываем его на тестовую группу (точка предельной ясности), чтобы в следующую минуту понять, что оно почему-то не дает нужный эффект (максимальная неопределенность!), а значит - мы должны как-то докрутить наше решение, чтобы оно сработало лучше к моменту окончательного релиза (снова точка предельной ясности). И так мы двигаемся дальше, играя на баяне неопределенности и с каждой итерацией приближаясь к оптимальному определенному решению Тут есть пара важных оговорок: 1. Triple Diamond изначально завязан не на водопадные процессы (когда вы рисуете все макеты, потом делаете системный анализ, потом пускаете все в работу), но на постепенную одновременную работу всей командой. Именно поэтому в третий ромб заключен этакий бычий пузырь, который подразумевает совместную итеративную разработку - а сам этап носит интересное название Design&Development: в этот момент команда дизайна и продукта должна жить в обнимку с разработчиками, чтобы делать продукт вместе. Впрочем, если у вас в ходу водопад, то Triple Diamond от этого не становится менее актуальным - просто в его состав могут добавляться дополнительные звенья (ромбы) под каждый этап. 2. На конкретно этой схеме есть условные этапы Design&Development, Early Access Programme, Commercial Availability - я призываю не относиться к ним слишком серьезно, потому что в реальной жизни они могут быть сильно перемешаны между собой (выкатили что-то на широкую публику - собрали фидбек - выкатили обновление на узкую группу пользователей - потестировали…), но от этого суть третьего ромба не меняется - от состояния «я хз, сработает это или нет» мы приходим к идеальному варианту, обкатанному на аудитории. И мне кажется дико важным, что этот этап у дизайна и разработки - общий.