Набросал коротенькую статью о том, как сэкономить на подборе респондентов и не потерять в качестве.

Чёт накатило

Алан Купер придумал прекрасный способ улучшать продукты. Так почему же сейчас он так непопулярен? Ответ, на самом деле, прост: люди не очень умные.

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

И ещё немного про проектную документацию. Теперь - нарратив, последовательное изложение. Плюсы, минусы и даже настоящее исследование с аналитикой.

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

В общем, ловите пост про проблемы продуктов, методологию USM и то, как она влияет на функциональную архитектуру продукта.
Про проблемы продуктов, методологию USM и то, как она влияет на функциональную архитектуру продукта.

И ещё немного про архитектуру, теперь - про информационную. Такой "трамплин" для погружения в область.

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

И знаете, я упрощаю. Удаляю сложные термины и формулировки. Привожу банальные и тошнотворные примеры. Лучше я изложу свою идею на 70%, но её поймут, чем на все 100 - но аудитория не отдуплит, о чём это я толкую.

Но иногда это надоедает. Как сейчас, например.

Мы делаем клёвый проект с Олегом Нестеровым и Адой Солвич. На нём нарабатывает крутые скиллы Евгения Шамрай. К нему даже приложил лапку Вадим Митякин. А Артём Фенелонов вообще стал тем, кто в принципе сделал возможным наше общее сотрудничество.

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

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

Олег, идейный вдохновитель и автор проекта, как-то сказал, что бывают вещи, которые ты просто должен сделать. Что если ты их не сделаешь, то не сделает никто.

В общем, я делаю. Вот ссылка.

Несколько лет назад у меня был довольно забавный период.

Волевым решением я тогда отказался от участия в развитии вороха стартапов, успев к тому времени поработать в некотором их количестве. Однако "сарафан" продолжал работать и ко мне периодически приходили за помощью молодые и не очень ребята, которые хотели запустить очередной убер-космолёт. Я им вежливо отказывал в сотрудничестве, и тогда часть из них просто платила мне за разовую консультацию. Тогда я брал ту документацию, которая у них к этому времени была, изучал её и несколько часов мы общались.

Больше половины уходило расстроенными: мы выясняли, что стартап нежизнеспособен. Чаще всего не билась математика: один раз даже был случай, когда ребята, вылизав финмодель (!) и посчитав "точную" юнит-экономику, просто забыли, что после определённого (небольшого) порога запросы к гугл-картам становятся платными.

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

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

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

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

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

Немного оффтопа ещё никому не повредило

Вот сейчас будет грустно.

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

То есть наш сервис ещё не умеет принимать оплату и доставка у нас не автоматизирована, а мы уже за каждую сотую покупку ачивки раздаём и турнирную таблицы покупателей имплементируем.

Но опасность такого подхода даже не в том, что он может запросто похоронить ваш проект. Самое страшное, что он может сделать это незаметно.

Синдром Преждевременной Геймификации - это такие Царь-Грабли продуктовой разработки.

Разбираем на цитаты