«Современные методологии создания цифровых продуктов на примере страховой медицины»

Для чего применяется Agile:

• это методика для ускорения вывода продукта на рынок;
• для управления изменениями в приоритетах;
• для улучшения взаимодействия между подразделениями IT и бизнеса.

На площадке ДЕЛОВОЙ ЭКСПЕРТ была организована мастерская в формате практикума по изучению гибкого подхода в создании продуктов Agile.
Участниками мастерской стали представители крупнейших страховщиков ДМС, представители лечебных учреждений и приглашенные эксперты.

Мастер-класс провели эксперты:

• Agile, Lean Kanban - Марина Арефьева, сертифицированный тренер, Agile-коуч с опытом работы в Яндексе и МТС.
• Кроссфункциональные коммуникации - Галина Сартан, владелец консалтинговой компании "Katarsis Business Group", экс-Директор Корпоративного университета СК Allianz РОСНО, бизнес-тренер, консультант по работе с командами.

В ходе мастерской Марина Арефьева продемонстрировала суть Agile с помощью погружения участников в ситуацию реальных рабочих групп по созданию цифровых продуктов.
Ниже подробно о том, что рассказала марина об Agile, и описание тренинга.

Содержание мастерской.

О тренере и методе. «Я учу компании переходить на гибкий подход к созданию продуктов - Agile. Есть множество адаптаций метода под разные сферы бизнеса. Agile может применяться в медицине. Agile-проекты в медицине мне известны с 2007 года - я участвовала в проекте - это было Британское Министерство Здравоохранения. Также в медицинском софте есть много аспектов, которые можно делать с применением Agile. Возможен также способ организации персонала в медицинских учреждениях. Применяется Agile и в науке. Проекты по созданию самоуправляемых автомобилей организуются с помощью этого метода.
Везде, где надо улучшить контролируемость эксперимента, удобно делать изменения маленькими циклами в формате организации Agile.
Существует мировой опыт. В Нидерландах и Англии государственные органы, практически все министерства, перешли на Agile».
Комментарии ДЕЛОВОГО ЭКСПЕРТА: и в нашей стране этот метод применяется на разных управленческих уровнях. Дмитрий Песков, в одном из интервью Радио «Комсомольская правда», выразил суть метода «…у Стругацких в «Понедельник начинается в субботу» есть такой эпизод, когда у одного из героев спрашивают: эта задача не имеет решения, - он говорит: я знаю, что она не имеет решения, я хочу знать, как ее решать. И мы, используя самые последние наработки в области менеджмента, того, что называется подходом Эджайл, позволяя себе ошибаться, но, быстро обрабатывая эти ошибки, делая их дешевыми, ищем это решение». (25.05.2016 https://www.ugra.kp.ru/radio/26533/3550221/)
«Необходимое условие для появления Agile в компании это переход, сначала в экспериментальном формате, от функциональной структуры, к кроссфункциональным командам, реально вовлеченным в процесс. Из отдельных сотрудников отделов компании, в которых, например, есть две тысячи программистов, три тысячи аналитиков, отдел маркетинга, продаж формируются команды. Им выделяется отдельное помещение, и они на сто процентов заняты одним продуктом.
Современная тенденция: стремление к безубыточности и быстроте реализации. Что достижимо путем Agile. Для примера, сегодня на открытый рынок пошел корпоративный университет МТС. Это не значит, что он перестал быть корпоративным университетом. Он решил зарабатывать деньги и не быть расходной статьей в компании».

Для чего нужен Agile. «Когда традиционные подходы уже не работают, нужно вытащить компанию из убытков, выйти на другой рынок, когда поджимают сроки, тогда компании ищут новые формы организации работы. Для этого бизнесы внедряют Agile. А потом действительно становятся гибкими.
Функциональные структуры корпораций, зачастую, не могут быстро реагировать на вызовы времени. Это цифровизация, о которой сегодня много говорят на разных уровнях, и скорость изменения событий и процессов. Реальность сегодняшнего рынка требует создавать новые продукты очень быстро - это основа жизнеспособности бизнесов. Agile привносит в корпорации мир стартапов, мир скорости, мир проб, ошибок и снова проб. Это создание маленьких кластеров, где люди быстро делают от прототипов до продуктов и начинают приносить пользу компании.
Сегодня уже существуют успешные способы организации работы, которые позволяют создавать продукты очень быстро. Например, Хакатон - это место где люди прорабатывают продукт от бизнес идеи до полной технической реализации. Такое возможно за трое суток, с организацией помещения для сна, где люди работают с перерывами на отдых. За это время команды способны сделать минимальную жизнеспособную версию продукта. А в крупной корпорации можно делать это два года, просто потому, что у сотрудников десять разных проектов. Это и отличает организацию с помощью Agile от корпоративной организационной структуры.

Если нужно чтобы вашим продуктом люди начали пользоваться уже через месяц, то вам не до того, чтобы писать красивые словесные описания: в этом приложении должны быть такие окна, по нажатию на кнопку номер такой-то должно быть то-то. Вы делаете очень просто. Для того чтобы IT-специалисты создали этот продукт, вы делаете его прототип. Этого прототипа, зачастую бывает достаточно для квалифицированных программистов, чтобы восстановить всю ИТ-инфраструктуру, требуемую для реализации.
Я занимаюсь не столько IT-проектами, сколько тем, что размываю границы между бизнесом и IT. IT-специалистам я помогаю понимать бизнес, экономику, прибыль, выручку. Бизнес подразделения я обучаю созданию цифровых продуктов своими руками в пределах компетенций.

Теоретическая часть мастерской.
Об Agile: идея продукта и команда. В ходе мастерской на выработку идеи продукта давалось пять минут. Также быстро в реальной жизни рождается идея реального продукта у топ менеджера компании. Она возникает из какой-то незакрытой горячей темы. Когда нужно сделать быстро, то обычно невозможно делать продукт параллельно со ста другими вещами. Из подразделений компании выделяется команда. В этой команде обязательно есть менеджер продукта. Он, как настоящий мини генеральный директор этой команды, определяет все остальные условия и решает, в пределах своих возможностей, все проблемы. Он защищает свою команду от внешних воздействий, чтобы она могла заниматься творчеством.
Кросс функциональность команды означает, что в этой команде есть все необходимые специалисты, чтобы достигнуть поставленной цели.
Все, что есть у команды - это рабочие столы, офисные принадлежности, зарплата. Больше нет руководителей, которые говорят, эти два часа ты делаешь это, а эти два часа - это, а еще есть документ, на него ты должен поставить свою визу и т.д.
А что же тогда должна делать команда, которая предоставлена сама себе? Она должна создавать продукт и стремиться вывести его на плановые показатели по экономическим параметрам: выручка, прибыль. Если это бесплатный продукт - это количество пользователей. Естественно, что руководитель продукта несет ответственность за PNL - расчет о прибылях и издержках. В этот PNL включают все: аренду офиса - ту часть, которая занята этой командой, уборщицу, кофе машину т.д. Как если бы это была отдельная компания.

Условия организации agile-команд. Для того чтобы Agile существовал, и чтобы люди, зачастую спонтанно сформированные в команду, смогли добиться эффективности, существует большое количество Фреймворков. Это слово не переводиться, а просто транслитерируется с английского. Это условия труда. Например, для некоего языка программирования существует специальная среда, в которой можно писать программы. Нельзя же программировать просто в блокнотике. Так же и для Agile создается специальная среда.
Самое главное для участников agile-команды - это бизнес ценность, которую они создают. А Фреймворки - это способы ее достижения. Это касается Scrum, Kanban, и тысячи разных инструментов и практик. Можно даже медитировать, если это помогает достичь нужной цели.
Про организацию места работы. Реальная работа команды происходит в рабочих помещениях. А красивая обстановка с гамаками, или расслабленная атмосфера офиса - некие декорации, с которыми связывают организацию рабочего пространства в Agile, нужны только для переключения.

Роль руководителя компании в успешности agile-команд. Agile это самоорганизация. Назначается ответственный человек, руководитель команды. Ему даются инструменты, ставятся цели на год или месяц, с контролем каждый месяц или каждую неделю. И во внутренний процесс уже нельзя вмешиваться. Обычно это называется самодостаточность. Но это не совсем верно. Agile-команды не могут существовать без остальной части корпораций: без бухгалтерии, без финансов, без всего остального, что существует в компаниях. При этом нет смысла включать внутрь этих команд операционную деятельность. Иначе они начнут заключать кучу договоров, сопровождать себя бухгалтерией, и не будут делать продукт.
В Agile-команды выделяются обычно именно специалисты - создатели ценности: бизнес-подразделения, продажи, маркетинг, дизайнеры и т.д.

Цели, стоящие перед agile-командами. Для чего существуют все бизнесы - для того чтобы приносить прибыль своим учредителям/акционерам.
Есть только два типа бизнеса, которые на это не нацелены. Это нон-профит - не приносящие прибыли, и лоу-профит - низко прибыльные бизнесы, социальные. Все остальные существуют, чтобы приносить прибыль. Люди, объединяющиеся в команду - должны понимать, что цель - это заработать деньги.

Agile это управляемый цейтнот. Одно из препятствий для Agile - авторитарный руководитель компании. Если она преодолено, то ничто не мешает команде креативить.
Главное, что требуется от внешнего руководителя - ставить команду в жесткие временные рамки. Если задача стоит, что нужно что-то не пойми когда, то ни какой Agile не нужен. Работайте себе спокойно, создавайте себе спокойно все эти документы, все продумывайте, прописывайте.
Скорость создания продуктов в Agile не означает, что люди должны жить «двадцать четыре-на-семь» на работе. Это значит, что они выходят на пик производительности, который могут поддержать долго - три-пять-семь лет. Команда должна не только создать продукт за месяц, но и работать вместе минимум от полутора лет. Т.к. это короткие циклы создания продукта, то через месяц это будет продукт с минимальным количеством функций. Для его дальнейшего развития понадобятся еще функции.

Ценности команды. Чтобы команды могли долго существовать, появляются ценности, которые ее участники должны разделять: открытость, прозрачность и т.д. Эти ценности общечеловеческие. Они особенно сильно актуализируются, когда люди в одном и том же коллективе работают постоянно, почти как в школьном классе. Каждый участник должен понимать, что в его команде нет людей, которые орут, поливают друг друга грязью, могут украсть телефон, поэтому его надо запирать в сумке.
Это нормы, которые не позволяют сойти с пути. Важна именно среднесрочная и долгосрочная производительность команды. Например, ценности не позволят прямо сегодня выжаться, заставить всех остаться до полуночи, а потом люди будут обижены и будут работать хуже.
Как и на каком этапе определяются ценности. Например, в компании уже есть сформированные команды, цели поставлены, время определено. Но команды пока еще не знают, как их достигнуть. Главное в данном случае, задать темп, в котором создается что-то быстро. Ни знание кто какие ценности разделяет, ни красивая обстановка не помогут. На протяжении работы те, кто не вписался - сами отсеиваются. Команда собирается в правильно подобранный коллектив и делает работу. Еженедельные занятия с agile-коучем не нужны, т.к. здесь нет особых рекомендаций. Но все участники должны быть достаточно профессиональны в своей части разработки продукта. Т.о. целеустремленность и темп деятельности - те условия, которые формируют ценности участников команды и, в конечном итоге, ее состав.

Философия, которую исповедуют люди, приходящие к Agile, сродни религиозной философии. Люди на первом этапе просто верят в то, что это комфортная среда для творчества. На определенной стадии зрелости это перерастает в культуру, в желание людей действительно делать и создавать ценное для пользователей. Особенно это проявляется, когда мы сделали что-то, от чего пошли огромные положительные отзывы пользователей с благодарностью.

Что хотят потребители. Наша самая большая проблема, когда мы делаем продукт, основываясь на своих ощущениях. Особенно это касается экспертов рынка. У нас у всех узкая специализация. А у наших пользователей она немножко другая.
Как ни странно, оказывается те функции, от которых в восторге пользователи, это не те функции, которые кажутся нам таковыми в нашей голове. Потому, что основное правило при создании цифровых продуктов - мы не репрезентативны. Все мы с вами вместе и каждый из нас по отдельности думаем только о себе. И о других, но на примере себя.
Это касается, к примеру, формата продукта, того, каким он должен быть. Сегодня мобильными приложениями пользуется почти все. Очень мало тех, кто пользуется более чем десятью мобильными приложениями каждый день. У кого-то на главном экране их шестнадцать и пользуются ими каждый день. Чем моложе будет ваша аудитория, тем больше будет у нее приложений, и специализаций этих приложений в телефоне. И в связи с этим, у нашей аудитории будет отказ от компьютеров, как таковых.
Или у вас проблема - болит зуб. И все ваши попытки будут в первую очередь направлены на создание идеального страхового продукта, который решит эту проблему услугой ДМС в стоматологии. У человека, у которого в семье рак, почти все идеи будут витать вокруг этой проблемы. Наши мысли искажены нашим предыдущим опытом. Поэтому, самое главное сейчас, относительно глобальной выборки ваших миллионов пользователей, это искажения. Вы - какая-то часть этой выборки, но не самая обычная («отягощенная» опытом). То есть, если у вашего приложения более десяти пользователей, каждый конкретный человек будет не похож на типичный средний размытый портрет потребителя.

Как подбираются команды. Концепция «Ноева ковчега». Из каждого функционального отдела берется по одному, иногда по два человека и создается кросс функциональная команда.

Руководитель в Agile. Нельзя связывать Agile и отсутствие руководителей. В Agile всегда есть человек, который отвечает за продукт. И есть человек - скрам-мастер, который отвечает за то, чтобы команда эффективно двигалась к достижению цели. Все что нам нужно, это как можно быстрее достигнуть поставленных целей.
Зачем нужен приходящий или постоянный agile-коуч в компаниях. Когда есть проблема, зачастую на уровне топ менеджмента, когда команда не может выделить одно конкретное дело, которое нужно сделать команде для достижения цели, или все пытаются делать все и это не получается, или получается, но за несколько лет.
Сегодня вы сели, сконцентрировались и нарисовали прототип. Очень многие в компаниях доходят до стадии рисования прототипа, даже имея профессиональных дизайнеров, через три шесть месяцев после мысли о том, что им надо что-то сделать. Для начала они думают о том, что им надо было бы начать проект. Что бы начать проект люди ищут денег. Что бы деньги получить, надо что-то показать. Так просто денег никто не даст. В разных компаниях это происходит по-разному. Первая мысль, которая возникает у менеджеров проектов - нам надо сделать какую-то штуку, нам надо обосновать бюджет на ее изготовление. Под «получением денег» здесь подразумевается бюрократическая активность, связанная с обоснованием бюджета. Agile этот подход переворачивает. Сначала создается команда, иногда инициативная исследовательская группа, которая должна потратить как можно меньше рабочего времени. Иногда речь идет об одном двух рабочих днях. Она проверяет, нужно ли под этот проект выделять деньги. Сначала вы не готовите всю проектную документацию, чтобы посчитать, сколько нужно программистов, тестировщиков и т.д. А вы идете от цели.
Основа Agile - не говорить людям о способе достижения задачи, но ставить конкретные бизнес и экономические цели. Например, одна из задач Яндекс-браузера звучала так: пользователи уже пришли на страницу, и нужно было добиться, чтобы кнопка «скачать» нажималась пользователями в три раза больше. И как этого добиться, не сказано.

Agile-коуч. Чтобы настроить команду, коуч размывает границы между IT- и бизнес специалистами. Например, обучает представителей бизнес подразделений понимать, как создаются прототипы. Т.о. помогает им включаться в саму разработку цифрового продукта. Так же с IT-подразделениями. Коуч говорит о том, что надо не просто думать, как красиво сделать кнопочки, а нужно, чтобы почти каждое движение пользователя приводило к увеличению дохода компании.
Есть такая цитата: «само по себе software или программа ничего не стоят», т.к. не приносят денег. Тем более, сейчас уже почти не бывает платных приложений. А вот то, что вы в ней делаете - это то, что нужно, чтобы заработать деньги.
Естественно, нельзя обвесить все платными подписками, но баланс нужно соблюдать. И у каждого в команде должно быть понимание, что задача команды - достигнуть намеченной цифры. Лучше всего работает именно денежная цифра - выручка, прибыль. На бесплатных приложениях прекрасно работает количество аудитории. Все остальные метрики, особенно, если их много, практически не работают на то, чтобы подвигнуть команду быстро делать продукт. Руководителю нужно выбрать одну такую метрику, достижение которой измеримо и сложно подделываемо.
Если у команды не получается ставить цели, подключается аgile-коуч или просто бизнес тренер. Команда получает консультацию, ставит цель, начинает осуществлять действия по ее достижению. Потом опять достигает точки остановки. Например, прототип нарисовали хорошо, а программу выпустить не получается. Тогда на помощь приходит коуч. А еще лучше, если коуч находится рядом с командой, пока она учиться работать сама. Как ребенок, который не может ходить сам с момента рождения. Не все понимают, что когда людей объединили в группу, то они не смогут сразу эффективно работать.
Agile тренеров зовут тогда, когда команду нужно создать, помочь ей выработать свой собственный стиль работы, наладить ее таким образом, чтобы она не теряла времени на разных издержках. Иногда нужно сделать аудит - это исследование командных процессов, перестройки внутри участников команды, или, когда нужно сделать продукт, который вы не знаете, как делать, не знаете, как исследовать пользователей, и т.д.
Agile-коуч помогает решать проблемы на пути к безубыточности и потом к сверхприбыли.

Когда Agile не нужен. Когда руководитель не хочет чтобы подчиненные занимались самоорганизацией или старается работать за подчиненных.
Видели ли вы команды с играющим тренером? Тренер обычно помогает команде продумать стратегию. Он остается в раздевалке, и заменяет игроков, в крайнем случае. Обычно он значительно старше игроков. У него уже плохо с рефлексами, но хорошо с опытом и расчетом, со стратегией. Особенно это касается детской сборной. Человек тридцатилетнего возраста не будет бегать с подростками, и играть в футбол. У нас в работе чаще всего бывает все абсолютно наоборот. У нас руководитель пытается впрячься в работу вместе с командой и сделать всю работу, если не за подчиненных, то, как минимум, точно знать, кто что должен делать, кто сколько раз вышел покурить и т.д. Agile с таким руководителем будет недостижим. Разрешением конфликтов, медиацией между командой и руководителем занимаются agile-коучи. Но это почти бесполезно. Авторитарный руководитель задушит любую инициативу. Поэтому команда должна строиться под руководителя».

Практическая часть тренинга. «Что мы будем делать: создавать прототип цифрового продукта и показывать его потенциальным пользователям.
Есть четыре команды. Вы сидите за четырьмя столами. Каждый стол будет создавать свой цифровой продукт. И между собой мы все одна большая компания, в рамках сегодняшнего занятия. Я буду ваш генеральный директор. Я попросила вас выйти на новый рынок. Нужно создать цифровые продукты. Пока не понятно, какие проекты будут успешными. Это надо проверить. Каждая команда создаст свой продукт.
Все что нужно: карандаши, резинки, фломастеры, бумага. Сначала вам нужно будет создать макет своего цифрового продукта на бумаге. После чего, вы превратите его в интерактивный прототип, используя смартфон: то, что можно кликнуть, как будто это настоящее приложение в телефоне. Это делается с помощью специального приложения (POP) в ваших смартфонах».
Каждой команде будет нужно собрать из фотографий бумажных прототипов настоящий интерактивный прототип, который можно будет кликать на смартфоне. Самое главное ради чего все это задумывается - это показать прототип нашим потенциальным потребителям. Для этого нужно будет провести интервью на улице.
Важно не уйти в отрисовку идеально красивых картинок.
Создать прототип и опросить потенциальных пользователей вполне возможно, даже не имея опыта анкетирования и рисования. Нужно представить себе, что у вас как будто бы готовый продукт и нарисовать много экранов: прямоугольник - окошко, кнопки и т.д.
Нужно рисовать быстро. Главное, донести до ваших потребителей мысль, какая информация будет у вас на экране, и какие действия они могут сделать. Например - кнопки «далее» и «назад». Писать чертежным шрифтом - печатным и разборчивым. Красиво вырисовывать не надо. В дальнейшем, если продукт получится, то сделать красиво вы успеете.
Начинаем с того, что в каждой команде должен быть выбран один человек, который будет менеджером этого продукта. Все остальные становятся участниками этой исследовательской команды. Так же бывает во многих компаниях, применяющих Agile. Есть команды, которые исследуют, какие новые продукты можно сделать. Параллельно с ними есть команда, которая эти прототипы - макеты - превращает в реальность и подгружает их в Play Market, App Store и т.д. Часто между этими командами размываются границы.
Сейчас у нас здесь нет команды разработки, но это сейчас и не нужно. Мы будем собирать прототип. Ваша задача представить максимально-подробный макет с точки зрения пользователя. Чтобы было понятно, на какие кнопки он кликает, что у него есть на экране. Чтобы ваши пользователи на улице посмотрели на это, покликали, дали отзывы.
Выберите минимум двух человек на каждую команду, чтобы показывать потенциальным пользователям на вашем телефоне макеты на улице. Важная инструкция - показывать макеты только тем людям, которых можно оценить как нормальных. Каждой команде достаточно собрать прототип на двух смартфонах. Потом по трое брать интервью у потенциальных пользователей.
Пять минут дается на выбор идеи продукта и менеджера продукта, того - кто будет главным и будет решать все споры в процессе. Можно в режиме лифтовой презентации: расскажите команде об идее - за тридцать секунд (по пути в лифте).
Ваша бизнес-цель - это прибыль. Цель продукта - что можно представить в вашей сфере для клиентов».

Следующий этап - цель пользователя. «Представьте себе, что у пользователя возникла какая-то цель. Эту цель нужно описать. Какую цель он сможет реализовать в вашем приложении - один сценарий. Дальше - когда у него возникла потребность, какие действия он совершит в вашем приложении. Сегодня наша мастерская не рассматривает потребности пользователя. Мы собрались здесь специально для погружения в мир создания продукта с помощью Agile. Обычно этот тренинг идет в комплекте с другими последующими тренингами, когда вы уже более подробно разрабатываете потребности пользователя.
Сегодня мы допустим, что цели пользователя нам известны. Их уже выяснили маркетологи. Вам это тоже известно и вы эксперты в этой области.
Когда вы все поняли, о чем будет ваше приложение, самое время, перечислить список тех действий, который пользователь будет в нем совершать. Например, если ваш пользователь сможет вызывать врача с помощью вашего приложения, то логично, что там будет поиск врачей по параметрам, инициация диалога с врачом. Если пользователь собирается купить какой-то продукт, то там будут какие-то действия, которые приводят к этому. Например, зайти в личный кабинет. Это называется шаги пользователя.
Для реализации цели в приложении у вас будет много шагов. Каждый из этих шагов будет отдельным экраном в приложении».

Шаги пользователя. «Ваш пользователь открывает приложение или авторизуется, и это первый шаг пользователя. Каждый шаг это отдельный экран и одновременно, заголовок на вашем экране. Посмотрите на количество людей в вашей команде, если шагов будет больше, чем членов команды, то кому-то из вас придется рисовать два экрана. Постарайтесь не переборщить, чтобы ваш пользователь не очень сильно утруждался. Больше шести шагов редко кто выдерживает. Поэтому сегодняшняя команда рассчитана на шесть человек. И шестым экраном, пользователь должен получить то, что он желает - достижение цели - саму услугу.
Каждый участник команды выберет шаг (экран) за который он будет ответственным и будет его рисовать. Шесть шагов - 15 минут.
Что должен содержать экран. Ваш идеальный экран состоит из заголовка, который отражает, на каком шаге человек сейчас находиться, что происходит на экране. Контент внутри должен максимально показывать, что примерно происходит в приложении. Сейчас в мобильных приложениях используется схема - на каждом шагу вы должны предложить человеку логический шаг «далее», «далее» и где-то на пятом шестом шагу «готово». Учтите, что кнопка «вперед» - жизненно важна, чтобы вы получили прибыль, как и кнопка назад, - для того чтобы вы так же получили прибыль, если человек ошибся и захотел что-то исправить. Желательно в прототипе, который вы сегодня сделаете, сделать эти бумажные кнопки «вперед/назад» достаточно большими. Потому, что вы нарисуете экран размером листа А4. Дальше, вы будете его фотографировать, и они будут пропорционально уменьшаться до экрана вашего смартфона в четыре-шесть раз. Соответственно, кнопки в пропорциях должны быть достаточно большими, чтобы потом на экране вашего смартфона их можно было разглядеть и нажать.
Если вы решите куда-то переходить, то у вас должна быть соответствующая страничка, куда пользователь должен попасть.
После того, как каждый из вас стал ответственным за один шаг, можно начать рисовать экраны. Не нужно делать много интерактивных опций, например, типа выбор из всплывающего списка и т.д. Для макета, делайте, как будто бы пользователь выбрал. Т.к. это не настоящее приложение. Это иллюстрация, к тому, что примерно он должен видеть на экране.
На каждом шаге должно быть что-то похожее на реальное приложение, но не старайтесь сделать слишком интерактивное.
Через 15 минут у каждого участника должен появиться свой экран».

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

Customer Development interview. Результаты. После проведения интервью пользователей на улице было организовано обсуждение.
«Мы все с вами не можем знать оптимального результата и не можем все проработать до мелочей. И вместо того, чтобы брать много времени на подробную проработку, можно сделать не очень подробно, потом прийти к нашим пользователям, и они нам на нашем быстро сделанном прототипе укажут наши недоработки.
Одной из команд сказали, что хорошо бы, что бы было «спасибо за регистрацию», были замечания по поводу непонятных аббревиатур. Были отзывы: «все удобно», «где я могу это купить». Что это значит? То, что вы подтвердили, что прототип сделан хорошо. Если бы это был настоящий проект, то можно было бы отдавать этот прототип в разработку. Вы создали минимальный жизнеспособный продукт - MVP.
Вы нарисовали, показали его пользователям - они в восторге. Теперь за две-четыре недели можно разработать. Более того, по этим прототипам программисты могут гораздо лучше вообразить, чем по текстовым описаниям, структуру базы данных и все, что они требуют в техническом задании. Этой информации достаточно для квалифицированных старших программистов, чтобы восстановить всю ИТ-инфраструктуру, требуемую для реализации. И вероятность ошибки снижается: того, что они не учтут в каком-то поле. Все потому, что они видят визуальное представление конечного результата.
Когда наши пользователи сказали что все отлично - это означает, что эту вещь можно отдавать в реализацию, а самим делать следующую вещь. У нас ведь в прототипе был только один путь, а в реальных приложениях обычно их больше чем один. Но, вместо того чтобы делать пятьсот вещей, проще сделать мини приложение с одним простым путем, а потом добавлять. Пример - Банк Тинькофф - использует эти подходы. Они были сначала совсем простенькие, потом добавилась ипотека, потом еще много чего. Недавно они выпустили мобильные сим-карты. Они постоянно что-то добавляют. Бывает, что такая скорость создает технически неудобства: недоступность серверов на некоторое время и т.д. Но сегодня пользователи готовы прощать вам мелкие ошибки. Agile против перфекционизма, против детальной проработки и за короткий цикл обратной связи. Сделали не срезу весь огромный продукт, а небольшой продукт, проверили на пользователях, отдали в разработку, пошли делать другой. Маленькие продукты делать дешевле, проще. В том числе, потому что вы можете их все целиком понять, вместить себе в голову, чем большой продукт».

Впечатления от общения с респондентами. Все участники, проводившие интервью отметили положительную реакцию опрашиваемых. Людям было интересно. Они сами начинали предлагать идеи. Некоторые респонденты сначала боялись, что им что-то предложат покупать. Но эксперты подобрали нужные формулировки и все получилось.
Тренер прокомментировала: «Такое интервью труднее проводить в городах, где нет метро и низкая концентрация людей. Но и там можно найти скопление людей: рынки, кинотеатры. Этот метод применим в разных сферах деятельности. Например, можно делать приложение для путешественников.
Статистическая оправданность этого метода начинается от двухсот исследованных людей. Это значение выведено скорее эмпирически. От двадцати респондентов начинает, в принципе, работать теория больших чисел. Сегодня удалось опросить трех-четырех человек по одному прототипу. То, что всем понравилось - это скорее повезло. Существует такое понятие как когорта - это поведенческая группа, у которой есть общие признаки. Но таких групп может быть много. Вы, скорее всего, просто попали на трех-четырех человек из одной когорты, которой все нравится, которая является вашей целевой аудиторией. Мы все не репрезентативны. Информации от трех-четырех респондентов не достаточно, чтобы мы узнали все о миллионах наших потенциальных пользователей. Чтобы повысить вероятность охвата разных когорт и сделать более точный анализ, нужно опросить как можно больше людей. Информацию по интервью можно считать достаточной и проведение интервью следует остановить тогда, когда от последующих интервью вы не получаете новой информации. Часто статистически, это как раз оказывается на пороге в двести проинтервьюированных».

Фотоотчет: