Вадим Митякин написал об индустрии создания цифровых продуктов — первая глава будущей книги о продюсерском подходе.

Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.

Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.

Типы проектов:
1. Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.
2. Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях.
3. Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.

Слабые специалисты не вытянут проект типа «мозги». Если крутые будут делать слишком простые проекты, разработка будет слишком дорогой, а специалисты потеряют мотивацию и покинут компанию.

Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.

Бизнес-модели:
1. Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента.
2. Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.

«Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама».

«Настоящее проектирование в руках профессионалов — это инструмент, который даёт возможность точно целиться в бизнес-цели проекта и дальше решительно действовать. Оно сокращает бюджет и сроки проекта: вместо поисков в темноте наугад проектирование как фары автомобиля освещает дорогу, по которой движется проектная команда. Проектированию предшествует этап анализа бизнес-задачи клиента. Если задачи не сформулированы, то проектирование не даст результата. Также оно связывает разных участников экосистемы».

https://mityakin.ru/paranoid-method-book-1

Командообразование

В итоге, Саша Мемус провел с нами всего два занятия в этом семестре, и все его внимание было посвящено сплочению ребят внутри команды.

В том числе для этого мы прошли тесты на определение наших типов личности и сильных сторон: чтобы сопоставить сильные и слабые стороны внутри команды и распределить роли так, чтобы мы могли перекрыть слабые стороны друг друга.

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

Внутри команды мы поделились на несколько ролей: менеджер, аналитик и дизайнер (нас как раз было трое). Аналитик мог пользоваться только браузером, дизайнер мог искать референсы и рисовать прототипы, менеджер не мог делать ничего кроме как говорить и координировать.

Итак, менеджер в течении одной минуты получает задание от другой команды. Ему необходимо понять какую проблему будет решать его команда.
После чего даётся десять минут на то, чтобы провести поиск проблемы, найти несколько фактов на которых будет строишься решение, найти референсы и нарисовать прототип решения. По истечении времени менеджер презентует всем результат работы.

С каждой новой итерацией мы менялись ролями внутри команды и брифами с другими командами. Чтобы мы не расплавлялись Саша закручивал гайки: сначала на работу отвели 7 минут, потом урезали речь менеджера на защите до 3 предложений, а в самом конце от начала работы до презентации прошло всего три минуты.

Конечно, мало кто смог сразу продать идею заказчику, сначала все споткнулись на том, что не следили за временем, и дорисовывались все в последнюю секунду, многие говорили непоследовательно, забывали назвать какой-то из пунктов обязательных для презентации, например, показать референсы; очень часто забывали выполнить какое-либо из условий. Но совсем страшным грехом было, если команда говорила несуществующие факты, чтобы набить себе цену — с врунами никто никогда работать не будет, их репутация портится молниеносно.

Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Провели работу наш ошибками над тем, что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах.

О чем вообще ты говоришь, женщина?
А вот о чём:
— У нас есть период онбординга нового члена команды, за который он выравнивается с командой на этом безопасном плато.
— Есть система обучения: разные форматы и подходы, которые помогают научиться писать тексты
(рассказывали на VC и давали примеры домашек)
— А есть критерии качества текстов и типографики — каждый может свою работу проверить, а до командного ревью она доходит уже без ошибок по этим чеклистам.

Спустя год, нам было над чем поразмыслить.

И вот что работает хорошо:

1. Рассказывать новичку о чеклистах — о том как надо, а как не надо писать текст, до первых задач смысла нет. Критерии не четкие как, например, в типографике, поэтому понятия «Краткость», «Человечность» тоже размыты.
Их не измеришь, а значит, теория до первого опыта неприменима. Рассказывать стоит уже в первых задачах, на примере уже написанного текста и с личным разбором. Показывать и объяснять, что плохо или хорошо и почему.

2. Сильно помогает предварительная UX-аналитика и интервью c ЦА. Портреты и характеристики пользователей помогают писать в правильном тоне и с единым уровнем детализации сложных понятий.

Грубо говоря — пишем как для офлайнового предпринимателя в продукте валютного контроля, или как для разбирающегося relations-менеджера в KYC-продукте.

3. Свежий взгляд на текст — как не парадоксально, это сильно помогает и об этом нельзя забывать. Утро вечера мудренее: написали тексты, ушли домой, а утром ещё раз просмотрели и сразу заметили грубые ошибки.

4. Ролевые игры 🙂
Практика, которую мы применяли в обучении UX-исследователей, работает и в обучении дизайнеров UX-текстам. Устраивает исследователь для дизайнера на его задачах. Многим новичкам помогает, так как они не понимают о пользователе ничего, включая реакции и потребности на конкретном шаге конкретного процесса.


А вот что у нас не работает или приносит несущественную пользу:

1. Домашки на выдуманной задаче не работают — дизайнер не в контексте продукта, без понимания пользователя и без ответственности за результат.
— Нужно объяснять почему что-то хорошо или плохо на конкретном рабочем примере.

2. Лекции, статьи, книги, командные разборы — работают на поддержание и рост, но не в начале наработки скила.
— Нужна индивидуальная работа и разборы текстов с экспертом из команды.

3. Мудборды по UX-текстам: сложно находить специально, человеку без опыта сложно понять, что хорошо, а что плохо.
— Мудборд нужно делать общекомандным и обязательно нужно разбирать и оставлять комменты о том что и почему в конкретном примере хорошо и плохо.

4. Главред — это зло, когда не умеешь им пользоваться. Сколько не говори о рейтинге и о том, что не надо на него смотреть и доводить свой текст до 8 и выше, люди в это выдрачивание всё равно скатываются.

— А на самом деле надо переписать его другими словами и смыслами. Главред хорошо использовать как лакмусовую бумажку, которая показывает и тюкает вас в лоб в том, что плохо.

5. Дрочить один и тот же текст — плохо. Чем дольше над ним сидишь и выдавливаешь из себя, тем более убогим он получится.


Ну вот и всё. Удачи вам с microcopy

Ура! Переходим к поиску решения!

На этом долгий процесс описания нашего исследования закончен, самое время перейти к описанию решения, к которому мы пришли.
Но сначала пару слов о проведенном исследовании.

Я так подробно описывал процесс работы полевиков, потому что в этом и есть вся суть блока исследования — как можно глубже прокопать проблематику, максимально вникнуть в боль наших пользователей, понять в чем причина их бед.

И если делать определённый вывод, то можно сказать, что полевиков в целом все устраивает. Да, им иногда не очень удобно переключаться между бумагой и телефоном, в некоторых методах много мороки с обработкой данных — но при этом, их работа никогда не превращается в рутину, потому что люди приходят на проект и не занимаются этой работой на постоянной основе: если ты пришёл на месяц, то тебе, в целом, все равно, что за инструменты у тебя в руках, главное, что работа сделана, деньги получены и даже удовлетворение от того, что в результате твоей работы мир стал чуточку лучше, присутствует.

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

На каждом проекте методологи испытывают боль от того, что полевые исследования проходят по тем же технологиям, что и двадцать лет назад.

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

На наблюдениях, казалось бы, методологи получают готовый проект, который сразу можно анализировать, но сам процесс сбора информации (3 часа в полях) и дальнейшая её обработка (2 часа за компом) занимает немало времени у полевиков, при том, что они делают, в целом, бессмысленную работу: переименовывают каждую фотографию определенным образом, вставляют её в проект, который воссоздают по своим бумажным записям.

И если говорить про решение, то нам предстояло понять, возможно ли перевести эти методы в электронный вид, а если возможно, то в какой формат? Приложение, десктоп, веб сервис, а может проблема вообще не в сборе данных и её нужно решать на уровень выше? Или уже существуют технологии, которые позволят вовсе отказаться от полевиков?

По умолчанию

Что это такое
Эксперименты и исследования говорят, что наличие варианта по умолчанию увеличивает вероятность его выбора. Получается, с помощью этого эффекта дизайнеры могут управлять выбором пользователя.

Почему это работает?
Так уж вышло, что наш мозг по своей природе очень ленивый. Каждый раз сталкиваясь с выбором, он напрягается. Для минимизации усилий он более склонен к выбору по умолчанию.

Пример
Если вы делаете сайт благотворительного фонда, поставьте на главной странице форму пожертвования с 50-100 рублями по умолчанию: пользователь все еще сможет ввести любую сумму, но процент людей, пожертвоваших сумму по умолчанию, значительно вырастет.

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

Инсайты + конкуренты

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

С юду действительно много пересечений, в частности они уже давно перешли на модель обратного аукциона, о которой я писал в самом начале (https://t.me/bukhtiyar/88). Поэтому многие процессы связанные с автоматизацией у них уже обкатаны и налажены.

Было интересно погружаться в процессы конкурентов, не один раз я восклицал — блин, это то что нам нужно! Поражался насколько схожи кейсы.
Да, правда говорят, что все уже придумано до нас. Но главное, это решить бизнес задачу, не так ли? А вот по бизнес метрикам все может быть не так однозначно, и в дальнейшем наши гениальные идеи не раз отвергались ребятами из профиру.

Давайте сравним юду и профиру.

Итак, я решил зарегистрироваться в профиру и юду в качестве дизайнера-фрилансера, давайте посмотрим, что из этого получилось (и не получилось).

В профиру для регистрации необходимо пройти порядка 24 экранов и приготовить весь необходимый пакет документов, как при устройстве на реальную работу. В итоге регистрация затягивается и может занять до 7 дней, так как все данные проверяются вручную администратором.

И что бы вы думали?
У меня не получилось зарегистрироваться! Так как для регистрации в роли дизайнера необходим диплом о высшем образовании, карл! Я на свою работу устроился без диплома, потому что дизайнеру не нужен диплом! А знаете почему в профиру он нужен? Потому что по иерархии дизайн относится к IT сфере, куда в том числе входят и программисты, которым действительно важно иметь высшее образование, а правила для всей категории вакансий в сфере IT одинаковые, вот и получается, что дизайнеру нужен диплом.

Что же в случае с регистрацией в юду, то там совершенно противоположная ситуация — пускают всех подряд, можно войти просто через соцсети, сразу есть доступ ко всем заказам. Ко всему прочему тебе дают безлимит заявок на сутки. В итоге отозваться на заказ можно спустя 5 минут после того как ты решил стать спецом (при том, что даже не нужно скачивать отдельное приложение — все собрано в одном месте).

Глобально, это две совершенно разные системы построения бизнеса — с одной стороны профиру с их трудной регистрацией, которая отсеивает случайных людей и пускает только тех кто строго соответствует их правилам, с другой стороны гибкий юду с низким порогом входа, но без особых гарантий и с вероятностью нарваться на неквалифицированного спеца.

Очевидно, что истина где-то посередине.