{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Блог Антона Липатова: заметки с тегом product management",
    "_rss_description": "Блог Антона Липатов про продакт-менеджмент, аналитику, визуалиазацию данных и разное",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/anton-lipatov.ru\/tags\/product-management\/",
    "feed_url": "https:\/\/anton-lipatov.ru\/tags\/product-management\/json\/",
    "icon": "https:\/\/anton-lipatov.ru\/user\/userpic@2x.jpg?1622202245",
    "author": {
        "name": "Антон Липатов",
        "url": "https:\/\/anton-lipatov.ru\/",
        "avatar": "https:\/\/anton-lipatov.ru\/user\/userpic@2x.jpg?1622202245"
    },
    "items": [
        {
            "id": "46",
            "url": "https:\/\/anton-lipatov.ru\/all\/strategiya-i-biznes-model-101-opredeleniya-i-freymvorki\/",
            "title": "Стратегия и бизнес-модель 101: определения и фреймворки",
            "content_html": "<p>📚 Самое простое определение: <b>стратегия<\/b> рассказывает, какие действия компания предпримет, чтобы прийти к намеченным целям. Это описание обычно <b>недетализировано<\/b> и рассчитано на <b>длительный период<\/b>.<\/p>\n<p>📚 <b>Бизнес-модель<\/b> показывает, <b>как<\/b> именно компания будет работать и зарабатывать деньги.<\/p>\n<p>Можно сказать, что стратегия — это выбор среди множества возможных бизнес-моделей наиболее подходящей для достижения целей.<\/p>\n<p>☝️ Например, достичь одной и той же цели — стать лидером на рынке создания веб-сайтов можно за счет разных бизнес-моделей:<\/p>\n<p>— открыть агентство кастомной разработки;<br \/>\n— открыть агентство low-code разработки;<br \/>\n— выпустить свой конструктор сайтов;<br \/>\n— запустить платформу, которая свяжет клиентов и разработчиков.<\/p>\n<p>Стратегия компании — выбрать одну из предложенных.<\/p>\n<h2>Как задать цели?<\/h2>\n<p>Классический <b>продуктовый<\/b> подход:<\/p>\n<p>— определить отраслевое видение — как будет выглядеть мир будущего;<br \/>\n— определить видение компании — какое место компания займет в мире будущего, какие будет выпускать продукты или оказывать услуги, на кого они будут рассчитаны;<br \/>\n— зафиксировать цели — с учетом видения компании задать метрики<\/p>\n<p>☝️ Упрощенный пример Airbnb, которая стартовала как сервис по аренде спальных мест:<\/p>\n<p>— отраслевое видение: путешественники будут готовы останавливаться не только в отелях, но и арендовать спальное место из соображений бюджета;<br \/>\n— видение компании: компания станет первым онлайн-сервисом, позволяющим арендовать спальное место;<br \/>\n— цель: X заказов в год к Y году.<\/p>\n<h2>Фреймворки стратегий<\/h2>\n<h3>Конкурентная стратегия Майкла Портера<\/h3>\n<p>🏆 Ряд работ и фреймворков при рассмотрении стратегии на первое место ставят вопрос о конкуренции. Мэтр маркетинга и менеджмента Майкл Портер (Michael Porter) сформулировал классический подход к конкурентным стратегиям. Он выделил два измерения — узкий и широкий рынок, преимущества в затратах и продукте и составил такую таблицу.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled-1.png\" width=\"851\" height=\"447\" alt=\"\" \/>\n<\/div>\n<ol start=\"1\">\n<li>Лидерство в издержках и фокус на издержках — производство продукта с минимальной себестоимостью для захвата рынка.<\/li>\n<li>Дифференциация — отстройка от конкурентов за счет уникальных свойств продукта.<\/li>\n<li>Фокус на дифференциации — ориентир на узкую аудиторию, для которой твой продукт будет лучшим.<\/li>\n<\/ol>\n<p>☝️ Есть мнение, что стратегии минимизации издержек в принципе не существует, поскольку сокращение издержек — это важная ежедневная работа компаний. Ей невозможно пренебрегать, если даже в вашей стратегии фокус смещен на другую область.<\/p>\n<p>Сейчас этот базовый фреймворк представляется не слишком подробным и применимым.<\/p>\n<h3>7 сил стратегии Хелмера Хамилтона<\/h3>\n<p>Фреймворк разработал Хелмер Хамилтон (Helmer Hamilton) — 7 powers. По его мнению, успешный бизнес должен обладать хотя бы одной из следующих “сил” для победы над конкурентами:<\/p>\n<ol start=\"1\">\n<li>🔍 Эффект масштаба (scale economies). Стратегия основана на сокращении издержек с ростом масштабов бизнеса. Возможные действия: собственное производство, сокращение цепочек поставок, монополия в продажах своих продуктов. Примеры — собственные торговые марки розничных сетей, исключение дилеров и дистрибьюторов в сбыте компьютеров.<\/li>\n<li>🕸️ Эффект сети (network economies). Чем больше пользователей у вашего продукта, тем больше выгода его использования новыми пользователями. Подходит для различных платформ, рейтинговых продуктов — чем больше контента, сгенерированного пользователями: отзывов\/элементов информации, — тем ценнее.<\/li>\n<li>🤴 Отстройка от конкурентов (counter-positioning). Концентрация на одном узком сегменте, в котором ты будешь превосходить конкурентов, т. к. они не смогут сделать его у себя таким же эффективным из-за присутствия у них прочих сегментов. Пример — концентрация на ассортименте джинс (Bonobos) или обуви (Zapier), что не смогут повторить ритейлеры с широким ассортиментом.<\/li>\n<li>🧀 Высокие затраты на переключение (switching cost). Начавшим использовать твой продукт пользователям будет невыгодно переключаться на новый продукт, поскольку это приведет к большим затратам. Пример — Amazon Kindle, интегрированный с Amazon.<\/li>\n<li>™️ Бренд (branding). Создание доверия бренду для долгосрочного сотрудничества с клиентами.<\/li>\n<li>🦹‍♂️ Нечестное преимущество (cornered resource). У компании есть эксклюзивный доступ к ресурсу, которого нет у конкурентов: сырью, патентам, поставщикам.<\/li>\n<li>⚙️ Преимущество в процессе (process power). Создание уникального процесса, который не смогут скопировать конкуренты.<\/li>\n<\/ol>\n<p>☝️ Это интересный подход, но он представляется скорее достаточным, чем необходимым. То есть, иметь одну из сил — хорошо, но если у тебя ее нет, это не означает, что бизнес не может существовать.<\/p>\n<h3>Эрик Рис. Lean Startup<\/h3>\n<p>Эрик Рис (Eric Reese) сформулировал необходимые компоненты стратегии для стартапов в простой формуле. Для успешного развития стартапу нужно проверить две гипотезы<\/p>\n<p>— ❤️ гипотезу ценности — доставляет ли ценность предлагаемый продукт, готовы ли его покупать.<br \/>\n— 📊 гипотезу роста — как будет расти продукт. Например, за счет платных каналов привлечения, вирусного распространения или сетевого эффекта (чем больше людей пользуются продуктом, тем больше в него приходит новых пользователей).<\/p>\n<p>Хотя формула очень простая, необходимо помнить о том, что гипотезы ценности и роста должны обязательно учитывать состояние рынка и конкуренции (например, 5 сил Портера).<\/p>\n<h2>Бизнес-модели<\/h2>\n<h3>Business Model Canvas<\/h3>\n<p>🗺️ Теперь переходим к более “подробным» бизнес-моделям. Разложить бизнес на 9 составляющих в шаблоне Business Model Canvas предложил в 2005 году А. Остервайлдер (Alexander Osterwalder). Это простой шаблон подходит, как для нового бизнеса, так и для описания уже действующего. Бизнес-блоки:<\/p>\n<p>— Ресурсы и действия: партнеры, активности, ресурсы<br \/>\n— Ценностное предложение<br \/>\n— Клиенты: сегменты , каналы, отношения с клиентами<br \/>\n— Финансы: доходы и расходы<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled-(1)-1.png\" width=\"1920\" height=\"1358\" alt=\"\" \/>\n<\/div>\n<h3>Бизнес-модель компании Strategy Partners<\/h3>\n<p>Модель, которую впервые увидел в презентации Strategy Partners. Компоненты бизнес-модели:<\/p>\n<p>— ❤️ Создает ли компания ценность (Create). Вообще кому-нибудь нужно ваше решение или пользователи довольны уже текущими поставщиками.<br \/>\n— 💰 Может ли ее монетизировать (Capture). Например, email-клиенты очень сложно монетизировать.<br \/>\n— 💂‍♂️ Как долго эта ценность будет держаться, имеется ли контроль над внешней средой (Control). Насколько просто скопировать ваши процессы, получить такие же ресурсы и запустить аналогичный бизнес. Например, у Telegram за счет огромной абонентской базы такая защита есть.<br \/>\n— 💵 Критические компетенции. Сколько нужно проинвестировать?<\/p>\n<p>Эти параметры соотносятся с количественными показателями бизнеса: выручка, прибыль, время и затраты соответственно.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled-(2)-1.png\" width=\"614\" height=\"326\" alt=\"\" \/>\n<\/div>\n<h2>Маркетинговая стратегия<\/h2>\n<p>Иногда маркетинговая стратегия используется как синоним стратегии компании в целом. Если посмотреть на Business Model Canvas, можно увидеть, что многие блоки — это традиционно маркетинговые компоненты: ценностное предложение, потребители, каналы.<\/p>\n<p>Известна следующая распространенная структура маркетинговой стратегии, которая объединяет фреймворки STP Филиппа Котлера (Philip Kotler) и 4-9P<\/p>\n<p>— Цели бизнеса и маркетинга. Цели маркетинга могут лежать в плоскостях:<\/p>\n<ul>\n<li>Оптимизация воронки (funnel): действия, направленные на пользователей в стадиях осведомленность (awareness), интерес (interest), триал (trial), покупка (purchase);<\/li>\n<li>Привлечение новых пользователей или повторные покупки (acquisition & retention);<\/li>\n<li>Увеличение выручки за счет доли конкурентов или расширения границ рынка.<\/li>\n<\/ul>\n<p>— STP (segmentation, targeting, positioning): сегментация, позиционирование, таргетинг.<br \/>\n— 4P — product, placement, promotion, price —  расширяемое по желанию до 7P (people, process, physical evidence) и 9P (public relations, personal sellings).<\/p>\n",
            "date_published": "2023-04-05T19:48:35+03:00",
            "date_modified": "2023-04-18T14:52:30+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/Untitled-1.png",
            "_date_published_rfc2822": "Wed, 05 Apr 2023 19:48:35 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "46",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled-1.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled-(1)-1.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled-(2)-1.png"
                ]
            }
        },
        {
            "id": "40",
            "url": "https:\/\/anton-lipatov.ru\/all\/kratkiy-pereskaz-soderzhanie-rezyume-robert-fitcpatrik-sprosi-ma\/",
            "title": "КНИГИ. Фитцпатрик Роберт — Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут",
            "content_html": "<p>😜 Роберт Фитцпатрик в конце книги сам ее суммировал :) В книге отвратительная структура. У меня будет подлиннее и по-другому. У Роберта нет таких сформулированных правил.<\/p>\n<p>Эта книга о том, как проводить интервью в рамках подхода customer development. Что стоит сделать 1️⃣ перед началом разговора, 2️⃣ во время разговора и 3️⃣ после разговора. И какие есть 4️⃣ признаки того, что что-то пошло не так.<\/p>\n<p>👨‍🏭 Книга не дает универсальную формулу успешного успеха и не претендует на философские обобщения. Это больше набор ремесленных приемов.<\/p>\n<p>👵 Говорят, книга устарела. По мне — не устарела, а пошла в народ и выписанные в ней истины уже кажутся прописными.<\/p>\n<hr \/>\n<h2>1️⃣ Перед началом разговора<\/h2>\n<h3>Правило 1. Если этого не было сделано раньше, выберите четкий клиентский сегмент, представителей которого вы сможете найти<\/h3>\n<p>🥺 Если вы получили 10 противоположных ответов от 10 респондентов, то скорее всего вы неверно определили сегмент и спрашиваете всех подряд.<\/p>\n<p>Сегментация поможет получить ответы, которые потом удастся увязать между собой. Для каждого сегмента определите группы в нем, которые <b>мотивированы больше других<\/b> использовать ваш продукт.<\/p>\n<p>Далее — ищи места, где находятся представители целевой аудитории.<\/p>\n<p>Далее — выбирай контакты. Приоритет отдаем тем, кто может принести максимальный доход, с кем легко установить контакт или кто поможет развить бизнес. Как найти собеседника:<\/p>\n<p>— холодное общение, в том числе в linkedin;<\/p>\n<p>— говорите с людьми об их проблемах;<\/p>\n<p>— организовывать полуформальные отраслевые события;<\/p>\n<p>— стать оратором в выбранной области;<\/p>\n<p>— вести блог, посвященный отрасли;<\/p>\n<p>— отраслевые консультанты, университеты, инвесторы<\/p>\n<p>🛑 Распространные ошибки с ЦА:<\/p>\n<p>— Вы выбираете <b>слишком широкий сегмент<\/b> и общаетесь со всеми подряд.<\/p>\n<p>— У вас несколько клиентских сегментов, и вы <b>упускаете из виду<\/b> те, что не следовало бы оставлять без внимания.<\/p>\n<p>— Вы работаете в секторе B2B со сложным процессом продаж и <b>не учли некоторых заинтересованных участников<\/b> этого процесса.<\/p>\n<h3>Правило 2. Вместе с вашей командой сформулируйте три основные цели сбора информации<\/h3>\n<p>Всегда перед интервью стоит понимать, ответы на три каких важнейших три вопроса вы хотите получить. <b>Если не знаешь, что хочешь узнать в итоге разговора, то не стоит вообще начинать разговор<\/b>.<\/p>\n<p>Если вы НЕ ЗАДАЕТЕ важные вопросы, значит вы тратите время, пусть даже ваши вопросы хороши. Важные вопросы — ответы на которые могут до основания <b>разрушить вашу текущую картину реальности<\/b>. Вовремя выявленные риски — это отлично, они вам сэкономят время и деньги.<\/p>\n<p>Идеи для вопросов — твои гипотезы: если бизнес потерпит неудачу, что вероятнее всего станет причиной этого? Что необходимо, чтобы бизнес оказался исключительно успешным?<\/p>\n<p>Подумайте, что больше всего заботит ваших собеседников.<\/p>\n<p>🛑 Важно помнить, что помимо принятия пользователями (будет ли PMF), есть риски продукта (можно ли создать продукт). То есть вы правильно определите желания аудитории (перемещаться по городу без пробок), но физически не сможете это реализовать.<\/p>\n<h3>Правило 3. Продумайте идеальный сценарий очередных шагов и обязательств<\/h3>\n<p>Если по итогам встречи по продукту или его продаже вы не знаете, что будет происходить дальше, значит встреча бесполезная. Хорошо выводить собеседника на обязательства:<\/p>\n<p>— <b>время<\/b>: согласованы дата вследующей встречи;<\/p>\n<p>— <b>репутация<\/b>: вас знакомят с коллегами, ЛПР;<\/p>\n<p>— <b>финансовые<\/b>: протокол о намерениях, оплата;<\/p>\n<h3>Правило 4. Если на вопросы, которые вы хотите задать, можно ответить с помощью «кабинетного исследования», сначала проведите такое исследование<\/h3>\n<p>Например, посмотри профиль компании или человека в интернете.<\/p>\n<h3>Правило 5. Правильно договоритесь о встрече<\/h3>\n<p>🛑 Следует избегать крайностей: формализма или приглашения выпить чашку кофе без намеков.<\/p>\n<p>👍 Предлагаемая схема — ВФСЗП:<\/p>\n<p>— Видение — хочу решить проблему в отрасли для того, чтобы...;<\/p>\n<p>— Формирование — что вы ждете от общения, на каком этапе находитесь. Упомянуть, что ничего не собираетесь продавать;<\/p>\n<p>— Слабости — стороны, в которых собеседник может помочь вам;<\/p>\n<p>— Значимость — покажите значимость собеседника;<\/p>\n<p>— Просьба — попросите его о помощи.<\/p>\n<p>Порядок может быть иным.<\/p>\n<blockquote>\n<blockquote>\n<p><i>Привет, Пит!<\/i><br \/>\n<i>Я пытаюсь снизить бремя арендных платежей за мебель и помещения для молодых компаний (видение). Мы начали над этим работать совсем недавно, и пока нам нечего предложить, но мы хотим быть уверены в том, что создаем полезный продукт (формулировка).<\/i><br \/>\n<i>Пока что я рассматривал эту проблему только с позиций арендатора, и мне сложно понять точку зрения арендодателя (слабость). Вы очень помогли бы мне, поскольку у вас есть опыт предоставления в аренду офисной мебели (значимость).<\/i><br \/>\n<i>Найдется ли у вас время для беседы в ближайшие две недели?» (Просьба.)<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<h2>2️⃣ Во время разговора<\/h2>\n<h3>Правило 6. Не становись бутылочным горлышком<\/h3>\n<p>🛑 Плохая идея — <b>ходить на интервью в одиночку<\/b>. Ты станешь таким образом бутылочным горлышком, будешь субъективно трактовать идеи и станешь неоспоримым авторитетом. Лучше брать на разные интервью разных участников команды. Лучше всего — 2 человека.<\/p>\n<h3>Правило 7. Прежде чем переходить к сути, осмотритесь<\/h3>\n<p>Прежде чем задать важный вопрос стоит «осмотреться» — <b>вообще насколько тема актуальна для собеседника<\/b>. В ряде случаев — это и так понятно; например, если это уже зафиксировано в теме вашей встречи.<\/p>\n<p>Но если это не так, то будет глупо спрашивать об отношении к раздевалкам в спортзале того, кто в спортзал не ходит. Разговорить и выявить реальное отношение помогут вопросы:<\/p>\n<p>— <i>«Насколько серьезно ты относишься...?»<\/i><br \/>\n— <i>«Ты зарабатываешь на этом деньги?»<\/i><br \/>\n— <i>«Ты пытался заработать на этом больше?»<\/i><br \/>\n— <i>«Сколько времени ты тратишь на это еженедельно?»<\/i><br \/>\n— <i>«Есть ли у тебя важные устремления, связанные с ним?»<\/i><br \/>\n— <i>«Какими инструментами и сервисами ты пользуешься в работе с ним?»<\/i><br \/>\n— <i>«Что ты уже сделал для его улучшения?»<\/i><br \/>\n— <i>«Каковы три важных аспекта, которые ты пытаешься исправить или улучшить сейчас?»<\/i><\/p>\n<h3>Правило 8. Задавайте правильные вопросы, которые пройдут «Тест для мамы»<\/h3>\n<p>«Тест для мамы» — это набор из трех правил, которых стоит придерживаться в интервью с клиентами:<\/p>\n<p>— Говорите о жизни собеседника, а <b>НЕ о вашей идее<\/b>.<\/p>\n<p>— Спрашивайте <b>о КОНКРЕТНЫХ СЛУЧАЯХ<\/b>, которые происходили в прошлом («Как вы поступили, когда столкнулись в последний раз с этой проблемой»), а не о взглядах или мнениях на перспективу.<\/p>\n<p>— <b>МЕНЬШЕ ГОВОРИТЕ<\/b>, больше слушайте.<\/p>\n<p>🛑 Примеры <b>плохих вопросов<\/b> (гипотетические или связаны с вашим продуктом):<br \/>\n— <i>«Как вам кажется, это хорошая идея?»<\/i><br \/>\n— <i>«Вы купили бы продукт, который выполняет задачу Х?»<\/i><br \/>\n— <i>«Сколько вы заплатили бы за Х?»<\/i><br \/>\n— <i>«Заплатили бы вы Х долларов за продукт, который выполняет задачу Y?»<\/i><\/p>\n<p>👍 Примеры хороших и отличных вопросов (не относятся к вашему конкретному продукту)<br \/>\n— <i>«Какими функциями должен обладать продукт вашей мечты?»<\/i><br \/>\n— <i>«Почему вас это беспокоит?»<\/i><br \/>\n— <i>«Каковы последствия этой ситуации?»<\/i><br \/>\n— <i>«Расскажите мне поподробнее, что произошло в последний раз?»<\/i><br \/>\n— <i>«Расскажите мне поподробнее, каков алгоритм вашей работы».<\/i><br \/>\n— <i>«Как вы решаете эту проблему сейчас?»<\/i><br \/>\n— <i>«Что еще вы пытались сделать?»<\/i><br \/>\n— <i>«Кто будет финансировать покупку?»<\/i><br \/>\n— <i>«С кем еще мне следует переговорить?»<\/i><br \/>\n— <i>«Есть ли еще вопросы, которые мне следовало бы задать?»<\/i><\/p>\n<h3>Правило 9. Уклоняйтесь от комплиментов, сдерживайте болтовню, докапывайтесь до сути.<\/h3>\n<p>В разговоре не стоит давать лишние поводы для ложной информации. Они и так будут стараться вылезать наружу. Ложная информация — это:<\/p>\n<p>— <b>Комплименты<\/b>. Не добивайся одобрения, не напрашивайся на комплименты, а в случае их оглашения — вежливо уходи от них.<\/p>\n<p>— <b>Болтовня<\/b>. Общие фразы — «я обычно», «я всегда», гипотетические рассуждения — «я могу», «я мог бы» , разговоры о будущем — «я, пожалуй, сделаю это». Правильно — спрашивайте о реальных конкретных случаях.<\/p>\n<p>Не стоит  задавать вопросы типа «Вы когда-нибудь делали...», «Как обычно вы поступаете...»? Если только это не прелюдия для последующего уточнения: «Вы когда-нибудь делали...»? «Как вы поступили в последний раз?»<\/p>\n<p>— <b>Клиентские идеи<\/b>. Стоит фиксировать не решение, которое предлагает собеседник, а реальную проблему, на которое это решение направлено. Тут помогут вопросы:<br \/>\n— <i>«Зачем она вам нужна?»<\/i><br \/>\n— <i>«Какие действия вы сможете выполнять с ее помощью?»<\/i><br \/>\n— <i>«Как вы справляетесь без нее?»<\/i><br \/>\n— <i>«Как вам кажется, мы должны добавить эту функцию незамедлительно или это можно сделать попозже?»<\/i><br \/>\n— <i>«Как она впишется в вашу текущую работу?»<\/i><br \/>\n— <i>«Расскажите мне об этом поподробнее»<\/i><\/p>\n<h3>Правило 10. Делайте заметки<\/h3>\n<p>Заметки потом помогут при анализе с командой. Важно <b>записывать дословно<\/b>. Роберт предлагает использовать свою систему обозначений.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/knigi-fitcpatrik-robert-sprosi-mamu-kak-obschatsya-s-klientami-i.png\" width=\"819\" height=\"431\" alt=\"\" \/>\n<\/div>\n<h3>Правило 11. Добивайтесь твердых обязательств и фиксируйте очередные шаги<\/h3>\n<h2>3️⃣ После разговора<\/h2>\n<h3>Правило 11. Проанализируйте свои записи и важные реплики, прозвучавшие из уст клиента, вместе с вашей командой<\/h3>\n<h3>Правило 12. Перенесите записи в информационную систему, если ей пользуетесь<\/h3>\n<h3>Правило 13. Внесите коррективы в ваши предположения и планы<\/h3>\n<p>После анализа каждого интервью полезно формально задать команде вопрос — <b>Что изменилось в нашем представлении о рынке по его итогам?<\/b>. Какие вопросы сработали, какие нет? Как стоит это учесть в последующих интервью: скорректировать сегмент, заменить вопросы и т. п.<\/p>\n<h2>4️⃣ Признаки того, что вы действуете «для галочки»<\/h2>\n<p>— вы говорите больше, чем ваши собеседники;<\/p>\n<p>— они говорят вам комплименты и хвалят вашу идею;<\/p>\n<p>— рассказав им о своей идее, вы не знаете, куда двигаться дальше;<\/p>\n<p>— вы не делаете записи;<\/p>\n<p>— вы не проанализировали записи вместе с командой;<\/p>\n<p>— получив неожиданный ответ, вы не пересмотрели свою идею;<\/p>\n<p>— ни один из вопросов, которые вы задали, не приводил вас в ужас;<\/p>\n<p>— вам не до конца понятно, ответ на какой «большой вопрос» вы пытаетесь получить.<\/p>\n",
            "date_published": "2021-09-07T19:00:00+03:00",
            "date_modified": "2021-09-15T13:16:59+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/knigi-fitcpatrik-robert-sprosi-mamu-kak-obschatsya-s-klientami-i.png",
            "_date_published_rfc2822": "Tue, 07 Sep 2021 19:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "40",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/knigi-fitcpatrik-robert-sprosi-mamu-kak-obschatsya-s-klientami-i.png"
                ]
            }
        },
        {
            "id": "36",
            "url": "https:\/\/anton-lipatov.ru\/all\/tonkosti-unit-ekonomiki\/",
            "title": "Юнит-экономика: что потеряно в переводе и как считать",
            "content_html": "<p><i> Содержание за 15 секунд<\/i>:<br \/>\n<i>1. Содержание терминов unit-экономики разное в разных компаниях. Прочитав эту статью, вы поймете общий принцип расчетов, и сможете распространить на любой проект.<\/i><br \/>\n<i>2. Нормальный файл для расчета по <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1BRkUs4UInWWK2Etm_70vaFiqCBaMjktNitXEsbRbSXc\/\">ссылке<\/a>.  <\/i><\/p>\n<p>🖖 Говорят, что термин Unit-экономика и принцип ее расчета был предложен в России Ильей Красинским. Как по мне, это адаптация простых формул университетского курса про постоянные и переменные издержки, точку безубыточности или более сложного финансового анализа, к метрикам и реалиям цифрового мира. В том числе к метрикам мобильных приложений.<\/p>\n<p>Что-то революционное? — Нет. Ближе к современному бизнесу? — Наверное.<\/p>\n<p>🤑 В чем хорош подход? Он подсвечивает те метрики, от которых зависит успех бизнеса. Анализ чувствительности результата к ним покажет, какая из метрик больше влияет на прибыль.<\/p>\n<p>👺 Но как обычную экономику за пределами бухучета все считают по-своему, так и unit-экономика оказалась у каждого своя. Это нормально, потому что бизнес-модели у всех разные: у кого-то пользователи и месячная подписка, у кого-то интернет-магазин с потоком заказов и т. п. Масла в огонь подливает разница в понятиях финансового учета в России и США и то, что эти понятия плохо состыковываются с уже закрепившимися финансовыми понятиями в digital.<\/p>\n<p>😞 Первая боль — это беда с терминами. В пределах одного инструмента могут быть использованы разные названия одного параметра. Например, сначала вы называете покупателей Buyers, а потом Customer, а потом в аббревиатурах еще используете Paying User (ARPPU, Average Revenue Per Paying User). Revenue повсеместно мешается с Margin повсеместно.<\/p>\n<p>⌛ Вторая боль — время. Ряд величин зависят от периода, на котором они измеряются, и не стоит их считать в разные периоды: постоянные затраты за месяц, а регулярность покупок — за всю жизнь.<\/p>\n<p>💸 Третья боль — учет затрат, которые у нас принято относить к постоянным: зарплата менеджмента, продуктовых команд. Те деньги, объем которых не зависит напрямую от объема продаж. Про них часто забывают или учитывают в себестоимости, как переменные издержки. Так делать не стоит, они не зависят напрямую от объема продаж, цены.<\/p>\n<p>👨‍🏫 Четвертая боль — обилие материала по теме с призывом разобраться за 15 минут. В разных источниках отличаются термины и определения, и сложно установить правду. Поэтому лучше включать свою логику. С ней, по крайней мере, будет понятно, как перейти в систему координат очередного автора.<\/p>\n<p>Вот одна из трактовок. Она не единственно верная.<\/p>\n<h2>Термины<\/h2>\n<p>👨 <b>Users<\/b> — пользователи. Сколько вообще есть у вас зарегистрированных пользователей за период.<\/p>\n<p>➡️ <b>Коэффициент C1<\/b>. Коэффициент конверсии из пользователей в покупатели.<\/p>\n<p>🤑 <b>Customers<\/b>, или <b>Buyers, <\/b>Paying Users** — покупатели (Customers = Users × C1). Нам нужны именно уникальные покупатели, число людей.<\/p>\n<p>💵 <b>Average Price<\/b> — средний чек (Revenue \/ Buyers). Эту метрику можно разбить далее на число товаров в корзине (icount) и среднюю стоимость (iprice) для того, чтобы отслеживать, как изменение этих параметров влияет на прибыль.<\/p>\n<p>💸 <b>COGS (Cost of Good Sold)<\/b> — это затраты на проданные товары, что-то вроде себестоимости. Их можно разбить:<\/p>\n<ul>\n<li>📌 COGS, % — затраты, которые зависят от цены продажи и относятся к единице продукции. Например, комиссия за электронную транзакцию, если она считается как процент к базе;<\/li>\n<li>🧱COGS, vc  — переменные затраты, которые не зависят от цены продажи, но относятся к единице продукции. Например, себестоимость сырья;<\/li>\n<li>1️⃣ 1sCOGS — дополнительные затраты на осуществление первой (и последующих) покупок. Например, купон на скидку для новых клиентов. Эти затраты не зависят ни от цены, но относятся к единице продукции.<\/li>\n<li>💻 COGS, fix — затраты, относимые к постоянным. Они не зависят ни от цены, ни от объема продаж. Например, расходы на продуктовую команду.<\/li>\n<\/ul>\n<blockquote>\n<blockquote>\n<p>Часто постоянные затраты при расчетах unit-экономики относят к переменным, относя их к прогнозной базе привлеченных пользователей. Однако в этом случае становится некорректным анализ чувствительности — изменения прибыли в зависимости от числа пользователей. Т. к. изменение числа пользователей приведет к другому значению постоянных издержек, приведенных к единице продукции.<\/p>\n<\/blockquote>\n<\/blockquote>\n<p>💲 <b>Payments per 1 Buyer или APC (Average Payment Count)<\/b> —  число платежей, которые в среднем делает покупатель за период.<\/p>\n<p>💰 <b>Revenue<\/b> — выручка. Это то, сколько денег мы получили до вычета наших расходов (Revenue = Customers x Average Price x APC)<\/p>\n<p>💳 <b>AC (Acquisition Costs)<\/b> — стоимость привлечения, то есть маркетинговый бюджет на привлечение новых пользователей.<\/p>\n<p>❤️ <b>CPA (Cost Per Acquisition)<\/b> или <b>CPU (Cost Per User)<\/b> — стоимость привлечения одного пользователя (CPA = AC \/ Users).<\/p>\n<p>👍 <b>CM (Contribution Margin)<\/b> — маржинальная\/валовая прибыль. Ее как раз и считаем, и на ее основании оцениваем эффективность модели.<\/p>\n<h2>Как посчитать Прибыль?<\/h2>\n<p>Очевидно, что CM — это разница между Revenue и затратами. Формула для выручки была выше. Из чего складываются затраты:<\/p>\n<ul>\n<li>📌 COGS,% × Customers × Average Price × APC — затраты, которые мы несем с каждой единицей продукции и которые зависят от цены;<\/li>\n<li>🧱 COGS, vc × Customers × APC — затраты, которые мы несем с каждой единицей продукции;<\/li>\n<li>1️⃣ 1sCOGS × Customers — затраты, которые мы несем с каждым пользователем при первой покупке;<\/li>\n<li>💻 COGS, fix — просто постоянные затраты. Важно, что COGS, fix стоит брать за тот же период, за который рассчитывается APC.<\/li>\n<li>CPA × Users — затраты на привлечение, которые привяжем к пользователям.<\/li>\n<\/ul>\n<p>В итоге получаем:<\/p>\n<p>👍 CM = <span style=\"color:green;\">Customers × Average Price × APC <\/span>  —  <span style=\"color:red;\">(COGS,% × Customers × Average Price × APC + COGS,vc × Customers × APC + 1sCOGS × Customers + COGS,fix + CPA × Users)<\/span> (1)<\/p>\n<p>или<\/p>\n<p>👍 CM = Users × (<span style=\"color:green;\">C1 × (APC × (Average Price × (1 — COGS,%) — COGS,vc) — 1sCOGS)<\/span> — CPA) — COGS,fix (2)<\/p>\n<p><span style=\"color:green;\">зеленым<\/span> — то, что удается заработать c одного пользователя, назовем эту цифру прибыль с пользователя (<b>AMPU<\/b> — Average Margin Per User).<\/p>\n<p>Какой вывод напрашивается: объем — король. В пределе бесконечное число пользователей при положительном AMPU может покрыть любые постоянные затраты. В жизни это, конечно, не так, поскольку с ростом базы пользователей увеличивается CPA; увеличивается штат продаж и поддержки, то есть COGS, fix.<\/p>\n<h2>Пример<\/h2>\n<p>У нас есть интернет-магазин со следующими показателями, отнесенными к одному месяцу. То есть в случае с APC предполагаем, что клиент успевает купить указанное число раз в течение месяца.<\/p>\n<ul>\n<li>👨 Users = 20 000<\/li>\n<\/ul>\n<ul>\n<li>➡️ С1 = 2,15%<\/li>\n<\/ul>\n<ul>\n<li>💵 Average Price = 2 000 руб.<\/li>\n<\/ul>\n<ul>\n<li>💲  APC = 1,6<\/li>\n<\/ul>\n<ul>\n<li>📌 COGS,% = 10% от цены на налоги и эквайринг<\/li>\n<\/ul>\n<ul>\n<li>🧱 COGS,vc = 900 руб.<\/li>\n<\/ul>\n<ul>\n<li>1️⃣ 1sCOGS = 50 руб.<\/li>\n<\/ul>\n<ul>\n<li>💻 COGS, fix = 300 000 руб. на зарплату персоналу<\/li>\n<\/ul>\n<ul>\n<li>💳 AC = 250 000 руб.<\/li>\n<\/ul>\n<p>Подставляем в формулу<br \/>\n👍 CM = 20 000 × (2,15% × <span style=\"color:green;\">(1,6 × (2 000 × (1 — 0,1) — 900) — 50) — 12,5) <\/span> — <span style=\"color:blue;\">300 000<\/span> = 347 700 — 300 000 = 47 700 руб.<\/p>\n<p>AMPU, то есть, сколько мы зарабатываем с одного пользователя с учетом всех затрат, кроме постоянных и затрат на привлечение:<br \/>\nAMPU = 2,15% × (1,6 × (2 000 × (1 — 0,1) — 900) — 50) = 29,89 руб.<\/p>\n<p>AMPU (29,89) больше CPA (12,5 руб.), поэтому дальнейшее повышения числа пользователей при условии сохранения прежнего уровня постоянных затрат приведет к росту прибыли.<\/p>\n<p>Проведем анализ чувствительности — как изменится CM, если изменить входные данные.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-whatif.png\" width=\"625\" height=\"193\" alt=\"\" \/>\n<\/div>\n<p>Сильнее всего в этом примере влияет Average Price. Так, ее снижение на 20% обрушивает экономику проекта к уровню — минус 200 тыс. руб. Практически не влияет изменение дополнительных затрат на совершение первой покупки — 1sCOGS.<\/p>\n<p>Во всех ли примерах изменение Average Price будет оказывать наибольшее влияние, а изменение 1sCOGS — наименьшее? Нет. Все зависит от соотношения величин самих параметров.<\/p>\n<h2>Что влияет на Прибыль?<\/h2>\n<p>Вернемся к начальной формуле (1), заменив Customers = Users × C1:<\/p>\n<p>👍 CM = <span style=\"color:green;\">Users × C1 × Average Price × APC <\/span>  —  <span style=\"color:red;\">(COGS,% × Users × C1 × Average Price × APC + COGS,vc × Users × C1 × APC + 1sCOGS × Users × C1 + COGS,fix + CPA × Users)<\/span> (3)<\/p>\n<p>Как быстро понять, прибыльный у нас проект или нет? Очевидно, что через сравнение выручки и затрат. В случае CM = 0 выручка равна затратам. Давайте разделим обе части на Revenue = Users × C1 × Average Price × APC и обозначим CM1 = CM\/Revenue. Тогда из (3) получим:<\/p>\n<p>👍 CM1 = 1 — COGS, % — COGS,vc \/ Average Price — 1sCOGS \/ (Average Price × APC) — COGS,fix \/ Revenue — CPA \/ (Average Price × APC × C1) (4)<\/p>\n<p>Каждое из слагаемых в правой части «откусывает» от нашей выручки свою долю, уменьшая прибыль. Не только каждое из слагаемых должно быть меньше единицы, но и сумма слагаемых с отрицательным знаком для положительной прибыли должна быть меньше единицы.<\/p>\n<p>Перепишем (4) в виде (5):<\/p>\n<p>CM1 = 1 — E — D — C — B — A (5),<br \/>\nгде A-E соответствующие коэффициенты. Например, A = CPA \/ (Average Price × APC × C1).<\/p>\n<p>Подставив числа, получим, что наши затраты «съедают» 97% выручки. Действительно, CM \/ Revenue у нас равно 3,5%. При этом половина — это 🧱 COGS, vc<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-unit-coefficient.png\" width=\"281\" height=\"135\" alt=\"\" \/>\n<\/div>\n<p>Если вы знаете коэффициенты A-E, вы знаете, на чем вы теряете больше всего.<\/p>\n<h2>Калькулятор юнит-экономики<\/h2>\n<p>Калькулятор юнит-экономики, повторяющий расчет, описанный в статье, — <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1BRkUs4UInWWK2Etm_70vaFiqCBaMjktNitXEsbRbSXc\/.\">https:\/\/docs.google.com\/spreadsheets\/d\/1BRkUs4UInWWK2Etm_70vaFiqCBaMjktNitXEsbRbSXc\/.<\/a> Чтобы задать свои параметры, скопируйте его к себе на Google Drive.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-unit-calc.png\" width=\"1143\" height=\"830\" alt=\"\" \/>\n<\/div>\n<h2>Это все. А дальше?<\/h2>\n<p>А дальше — усиление расчетов unit-экономики благодаря когоротному анализу и применению метода к разным временным периодам. Когороты, действительно, дают лучшее представление, что происходит с бизнесом, и где надо срочно чинить.<\/p>\n",
            "date_published": "2021-04-27T20:52:53+03:00",
            "date_modified": "2021-07-04T18:21:29+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/lipatov-whatif.png",
            "_date_published_rfc2822": "Tue, 27 Apr 2021 20:52:53 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "36",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-whatif.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-unit-coefficient.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-unit-calc.png"
                ]
            }
        },
        {
            "id": "47",
            "url": "https:\/\/anton-lipatov.ru\/all\/knigi-demarko-tom-deadline-roman-ob-upravlenii-proektami\/",
            "title": "КНИГИ. ДеМарко Том — Deadline. Роман об управлении проектами",
            "content_html": "<p><b>1. Безопасность и перемены. <\/b><br \/>\nПеремены открывают большие возможности, но для их рассмотрения человек должен чувствовать себя в безопасности.<\/p>\n<ol start=\"1\">\n<li>Если человек не чувствует, что находится в безопасности, он будет противиться переменам.<\/li>\n<li>Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).<\/li>\n<li>Неуверенность заставляет человека избегать риска.<\/li>\n<li>Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.<\/li>\n<li>Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.<\/li>\n<\/ol>\n<p><b>2. Отрицательная мотивация<\/b><br \/>\nОтрицательная мотивация работает в малых объемах.<\/p>\n<ol start=\"1\">\n<li>Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.<\/li>\n<li>Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.<\/li>\n<li>Более того, если люди не справятся, вам придется выполнить свои обещания.<\/li>\n<\/ol>\n<p><b>3. Части тела, необходимые для управления проектами<\/b><\/p>\n<ol start=\"1\">\n<li>Для руководства нужны сердце, нутро, душа и нюх.<\/li>\n<li>Так что:<br \/>\n• руководить надо сердцем;<br \/>\n• чувствовать нутром;<br \/>\n• вкладывать в команду и проект душу;<br \/>\n• иметь нюх на всякую ерунду и бессмыслицу.<\/li>\n<\/ol>\n<p><b>4. Главнокомандующий на поле битвы, как метафора управления проектами<\/b>.<br \/>\nК началу сражения работа главнокомандующего уже закончена.<br \/>\nСобеседование и прием на работу.<\/p>\n<ol start=\"1\">\n<li>Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).<\/li>\n<li>Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.<\/li>\n<li>Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.<\/li>\n<li>Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.<\/li>\n<li>Больше слушайте, меньше говорите.<\/li>\n<li>И все это сработает еще лучше, если вы слегка подтасуете колоду.<\/li>\n<\/ol>\n<p><b>5. Повышение производительности<\/b><\/p>\n<ol start=\"1\">\n<li>Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.<\/li>\n<li>Повышение производительности — результат долгосрочных усилий.<\/li>\n<li>Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко».<\/li>\n<\/ol>\n<p><b>Управление рисками<\/b><\/p>\n<ol start=\"1\">\n<li>Чтобы управлять проектом, достаточно управлять его рисками.<\/li>\n<li>Создайте список рисков для каждого проекта.<\/li>\n<li>Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.<\/li>\n<li>Оцените вероятность возникновения и стоимость каждого риска.<\/li>\n<li>Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.<\/li>\n<li>Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.<\/li>\n<li>Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.<\/li>\n<\/ol>\n<p><b>6. Играй в защите<\/b><\/p>\n<ol start=\"1\">\n<li>Сокращайте потери.<\/li>\n<li>Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.<\/li>\n<li>Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.<\/li>\n<li>Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.<\/li>\n<li>Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.<\/li>\n<li>Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.<\/li>\n<li>День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.<\/li>\n<\/ol>\n<p><b>7. Моделирование процесса разработки<\/b><\/p>\n<ol start=\"1\">\n<li>Моделируйте свои предположения и догадки о том, как пойдет процесс работы.<\/li>\n<li>Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.<\/li>\n<li>Предсказывайте результаты работы с помощью модели.<\/li>\n<li>Сравнивайте результаты, полученные а процессе моделирования, с реальными.<\/li>\n<\/ol>\n<p><b>8. Извращенная политика<\/b><\/p>\n<ol start=\"1\">\n<li>В любой момент нужно быть готовым отказаться от работы и попросить расчет…<\/li>\n<li>…однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.<\/li>\n<li>Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.<\/li>\n<li>Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.<\/li>\n<li>Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.<\/li>\n<li>Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.<\/li>\n<\/ol>\n<p><b>9. Сбор метрических данных<\/b><\/p>\n<ol start=\"1\">\n<li>Определяйте размер каждого проекта.<\/li>\n<li>Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.<\/li>\n<li>Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).<\/li>\n<li>Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.<\/li>\n<li>Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.<\/li>\n<li>Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.<\/li>\n<li>Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.<\/li>\n<li>Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.<\/li>\n<\/ol>\n<p><b>Процесс разработки и его улучшение<\/b><\/p>\n<ol start=\"1\">\n<li>Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.<\/li>\n<li>Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.<\/li>\n<li>Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.<\/li>\n<li>Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.<\/li>\n<li>Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.<\/li>\n<li>Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.<\/li>\n<li>Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).<\/li>\n<\/ol>\n<p><b>10. Делать работу по-другому<\/b><\/p>\n<ol start=\"1\">\n<li>Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.<\/li>\n<li>Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.<\/li>\n<li>Проекты с высокой производительностью требуют гораздо больше времени на проектирование.<\/li>\n<\/ol>\n<p><b>11. Что дает давление сверху<\/b><\/p>\n<ol start=\"1\">\n<li>Люди не начнут быстрее соображать, если руководство будет давить на них.<\/li>\n<li>Чем больше сверхурочной работы, тем ниже производительность.<\/li>\n<li>Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.<\/li>\n<li>Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.<\/li>\n<li>Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.<\/li>\n<\/ol>\n<p><b>12. Сердитый начальник<\/b><\/p>\n<ol start=\"1\">\n<li>Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.<\/li>\n<li>Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?<\/li>\n<li>Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).<\/li>\n<\/ol>\n<p><b>13. Туманные спецификации<\/b><\/p>\n<ol start=\"1\">\n<li>Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.<\/li>\n<li>Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.<\/li>\n<li>Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.<\/li>\n<\/ol>\n<p><b>14. Конфликт<\/b><\/p>\n<ol start=\"1\">\n<li>Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.<\/li>\n<li>Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.<\/li>\n<li>В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.<\/li>\n<li>Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.<\/li>\n<li>Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.<\/li>\n<li>Тяжело договариваться. Гораздо легче выступать посредником.<\/li>\n<li>Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.<\/li>\n<li>Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.<\/li>\n<\/ol>\n<p><b>15. Кто такой катализатор проекта<\/b><\/p>\n<ol start=\"1\">\n<li>Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.<\/li>\n<li>Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.<\/li>\n<li>Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»<\/li>\n<\/ol>\n<p><b>16. Человеку свойственно ошибаться<\/b><\/p>\n<ol start=\"1\">\n<li>Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.<\/li>\n<\/ol>\n<p><b>17. О персонале<\/b><\/p>\n<ol start=\"1\">\n<li>Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).<\/li>\n<li>Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.<\/li>\n<li>Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.<\/li>\n<li>В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).<\/li>\n<li>Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!<\/li>\n<\/ol>\n<p><b>18. Проблемы социологии<\/b><\/p>\n<ol start=\"1\">\n<li>Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.<\/li>\n<li>Каждому проекту нужна какая-то церемония или ритуал.<\/li>\n<li>С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.<\/li>\n<li>Защищайте людей от оскорблений и ругани Начальства.<\/li>\n<li>Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.<\/li>\n<li>Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)<\/li>\n<\/ol>\n<p><b>19. О патологической политике (еще раз)<\/b><\/p>\n<ol start=\"1\">\n<li>Эту патологию невозможно вылечить снизу.<\/li>\n<li>Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.<\/li>\n<li>Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.<\/li>\n<li>Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.<\/li>\n<\/ol>\n<p><b>20. Злоба и скупость<\/b><\/p>\n<ol start=\"1\">\n<li>Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.<\/li>\n<li>Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.<\/li>\n<li>Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.<\/li>\n<\/ol>\n<p><b>21. Основы здравого смысла<\/b><\/p>\n<ol start=\"1\">\n<li>У проекта должно быть два срока сдачи — запланированный и желаемый.<\/li>\n<li>Эти сроки должны быть разными.<\/li>\n<\/ol>\n",
            "date_published": "2021-04-20T18:05:54+03:00",
            "date_modified": "2023-04-20T18:06:36+03:00",
            "_date_published_rfc2822": "Tue, 20 Apr 2021 18:05:54 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "47",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "41",
            "url": "https:\/\/anton-lipatov.ru\/all\/intervyu-v-ramkah-custdev\/",
            "title": "Интервью в рамках Custdev",
            "content_html": "<h2>1. Общие правила<\/h2>\n<h3>Правило 1. «Почему? \/ почему это так важно?»<\/h3>\n<p>Задаем эти вопросыо тех пор, пока не поймем эмоцию или исходный мотив. Ни в коем случае не пропускаем промежуточные фразы<\/p>\n<h3>Правило 2. Проблемные и решенческие интервью отличаются<\/h3>\n<p>Интервью бывают <b>проблемными (ПИ)<\/b>, в которых мы изучаем боли и потребности респондентов, и <b>решенческими (РИ)<\/b>, в которых мы подтверждаем, что наши решения справляются с потребностями респондентов.<\/p>\n<p>РИ проводим на стадиях:<\/p>\n<p>— MVP на коленке (презентация\/чат-бот и т. п.)<br \/>\n— полноценного MVP<br \/>\n— схемы монетизации<br \/>\n— в повседневной работе над развитием продукта<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/image-7.png\" width=\"804\" height=\"454\" alt=\"\" \/>\n<\/div>\n<p>Проверка по РИ важна как при создании продукта, так и при его дальнейшем развитии для того. Она помогает сэкономить деньги и время (тратим 2 недели и 100 тыс. рублей вместо миллионов и месяцев):<br \/>\n— Срок запуска MVP — 6-12 месяцев;<br \/>\n— Ненужные фичи несут в себе минорные баги, на исправление которых уйдут сотни тысяч и миллионы рублей.<\/p>\n<p>Почему возникают риски после того, как проведены проблемные интервью.<br \/>\n— изначально неверно трактовали боли и потребности;<br \/>\n— не передали знания в MVP (потеряли по пути).<\/p>\n<h3>Правило 3. Особенности B2B<\/h3>\n<p>В интервью B2B стоит понимать, с кем проводить интервью. Если бенефициар только ЛПР — можно ограничиться только им. Если пользователи — то с пользователями и питчинг ЛПР, чтобы тот был в курсе.<\/p>\n<p>Важно проговорить, что вы можете влиять на продукт, но вы не сможете сделать абсолютно все, что попросит вас сделать клиент.<\/p>\n<p>Вопросы Скрипт Димы Думика:<\/p>\n<blockquote>\n<blockquote>\n<p>— <i>Опишите, пожалуйста, вашу роль и зону ответственности?<\/i> Проверяем, действительно ли человек, которого мы интервьюируем является ЛПРом<br \/>\n— <i>А кто в вашей компании отвечает за... ? Кто влияет на решения ЛПРа (ЛВР)<\/i> Если перед вами не ЛПР.<\/p>\n<\/blockquote>\n<\/blockquote>\n<h3>Правило 4. Избегаем ошибок<\/h3>\n<p>Ошибки по <a href=\"https:\/\/anton-lipatov.ru\/all\/kratkiy-pereskaz-soderzhanie-rezyume-robert-fitcpatrik-sprosi-ma\/\">Фитцатрику<\/a>:<\/p>\n<p><nohtml>1.<\/nohtml> Вопросы про будущее (Заплатишь ли ты, если мы это сделаем).<\/p>\n<p><nohtml>2.<\/nohtml> Обобщение (часто, обычно, всегда).<\/p>\n<p><nohtml>3.<\/nohtml> Комплименты неискренние. Интервьюируемые хотят отблагодарить интервьюэра.<\/p>\n<p><nohtml>4.<\/nohtml> Интервьюировать в одиночку.<\/p>\n<h2>2. Что спрашивать на проблемных интервью (ПИ)<\/h2>\n<p>ПИ проводятся на первом этапе: ищем сегмент с болью,  формируем и подтверждаем гипотезы по болям и бенефитам, которые есть у пользователей.<\/p>\n<p>Вопросы могут быть разные, важно понять:<\/p>\n<p><b><nohtml>1.<\/nohtml> Существует ли потребность в принципе?<\/b><\/p>\n<blockquote>\n<blockquote>\n<p>—<i>Наверно, у вас накапливается большое число тасков. Вам приходится периодически «чистить» канбан-доску?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<p><b><nohtml>2.<\/nohtml> Как сейчас?<\/b><\/p>\n<blockquote>\n<blockquote>\n<p>—<i>Вспомните последний раз, когда это делали — как вы это делали?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>—<i>С какими сложностями столкнулись?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>—<i>Вы делаете только так или есть еще варианты?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<p><b><nohtml>3.<\/nohtml> Затраты на потребность<\/b><\/p>\n<p>Тут спрашиваем: как часто возникает, сколько на этот тратите времени\/денег.<\/p>\n<blockquote>\n<blockquote>\n<p><i>Часто ли этим занимаетесь?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p><i>Сколько на это уходит времени\/денег?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<p><b><nohtml>4.<\/nohtml> Эмоции, зависимость от потребности<\/b><\/p>\n<p>Спрашиваем, нравится ли текущий способ. Что является идеалом<\/p>\n<blockquote>\n<blockquote>\n<p>— <i>Какую эмоцию вы испытывали в этот момент?<\/i> Если человек закрыт, приводим собственный опыт или подсказываем: «Это было ужасно? Это было неприятно?»<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Оцените эмоцию по 10-балльной шкале. Что для вас 10-ка? <\/i> Это нужно, чтобы не наслаивать свою оценку на кастомера. Если боль выше 7-ки, мы с ней работаем, если ниже — скорее, не работаем (если у вас продукт в сфере массового B2C, тогда работаем). <b>Важно<\/b> ответы разных респондентов стоит привести к одной шкале. В восточной Европе люди относятся более скептично, поэтому, «если не громят, то это уже круто».<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Что вообще доставляет вам неудобство при решении потребности? С чем приходится справляться каждый день? <\/i>Вопрос, который заходит в «кэш» собеседника и достаёт его боли. Когда ты говоришь с человеком впервые, он либо говорит, что всё нормально, либо называет 2−3 боли. В процессе интервью потом вскроются и другие, поэтому не стоит ждать от этого вопроса слишком многого сразу.<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Что будет, если вы не будете это делать \/ не сможете решить потребность?<\/i> Проверяем, сильна ли потребность<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Что для вас успех? Как поймете, что вы решили свою потребность классно? Что мешает достигать этого успеха?<\/i> В b2b так можно выявить OKR\/KPI\/цели, которые поставил руководитель.<\/p>\n<\/blockquote>\n<\/blockquote>\n<h2>3. Что спрашивать на решенческих интервью (РИ)<\/h2>\n<p>На РИ мы показываем на коленке собранный MVP или презентацию.<\/p>\n<p><b><nohtml>1.<\/nohtml> Обязательно обновляем информацию о потребностях и болях клиента<\/b><\/p>\n<p>Это нужно для того, чтобы был верный контекст последующего разговора.<\/p>\n<p><b><nohtml>2.<\/nohtml> Показываем решение (презентацию, лендинг), не питчим.<\/b><\/p>\n<p>Просим дать обратную связь и думать вслух. Тут приходится сначала выводить на обратную связь (что ты об этом думаешь, что о том). Через 5 минут собеседник уже сам втягивается и сам начинать давать обратную связь. Как правило, больше всего обращают внимание на то, что не нравится и что очень нравится.<\/p>\n<p><b><nohtml>3.<\/nohtml> Получаем оценку<\/b><\/p>\n<blockquote>\n<blockquote>\n<p>— <i>Почему решили воспользоваться? Почему не воспользовались?<\/i> Если речь про MVP или фичу.<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>А покажите, как достигли своих целей? Как сделать это (нужные JTBD)?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Какие сильные стороны?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Какие слабые стороны?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Сравните с конкурентами: в чем выигрывает, в чем проигрывает?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Решает ли вашу потребность?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<p><b><nohtml>4.<\/nohtml> Проверяем монетизацию<\/b><\/p>\n<blockquote>\n<blockquote>\n<p>— <i>Сколько вы готовы заплатить?<\/i> Способы определения: <b>лесенка<\/b> (называем самую большую цену, называешь самую маленькую и постепенно приходишь к психологически комфортному уровню для клиента), <b>доля от затрат<\/b> (Есть мнение, что b2b готовы заплатить за решение проблемы 5-20% от экономии затрат при решении этой проблемы; т. е. если автоматический постинг постов экономить 10 тыс. рублей в месяц, комфортная цена сервиса — 500-2000 руб.)<\/p>\n<\/blockquote>\n<\/blockquote>\n<p>— <i>Готовы ли купить сейчас? Почему да или нет?<\/i><\/p>\n<p><b><nohtml>5.<\/nohtml> Выжимаем выгоду для себя<\/b><\/p>\n<blockquote>\n<blockquote>\n<p>— <i>Продайте мне, как будто перед вами лучший друг\/коллега<\/i> Эти фразы можно использовать в коммуникации, они будут лучше всего продавать.<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>— <i>Готовы купить или подписать соглашение о намерениях?<\/i> Если дело не в деньгах, просим заплатить социально — рассказать коллегам\/друзьям.<\/p>\n<\/blockquote>\n<\/blockquote>\n<h2>4. Устанавливаем контакт с респондентом<\/h2>\n<p>Если человек тебя не знает, у него включается <b>барьер<\/b> — лимбическая система квалификации «свой\/чужой»:<\/p>\n<p>— исходит ли от тебя угроза;<\/p>\n<p>— ты победитель или неудачник;<\/p>\n<p>— ты союзник или враг<\/p>\n<p>Если ты не преодолел этот барьер в течение первых минут, потом интервью можно не продолжать. Как растопить лед:<\/p>\n<p><nohtml>1.<\/nohtml> Улыбнись (зеркальные нейроны застявят собеседника тоже улыбаться)<\/p>\n<p><nohtml>2.<\/nohtml> Сделай искренний комплимент. Именно искренний<\/p>\n<p><nohtml>3.<\/nohtml> Продемонстрируй формат, что в ходе разговора будут эмоции<\/p>\n<blockquote>\n<blockquote>\n<p>—<i>Привет, я буду задавать тебе странные вопросы про эмоции. Я не хочу тобой манипулировать, я не психолог, я не залезу тебе в голову. Но я не понимаю, что ты чувствовал, когда.. Чтобы это понять, буду задавать вопросы, что ты чувствовал. Почему это болело?<\/i><\/p>\n<\/blockquote>\n<\/blockquote>\n<p>Подтверди своим примером и добавь, что будет здорово, если собеседник будет рассказывать то же самое.<\/p>\n<p><nohtml>4.<\/nohtml> Подготовься — узнай темы, которые важные собеседнику, случаи из его жизни. Вплети их в первые минуты разговора.<\/p>\n<p><nohtml>5.<\/nohtml> Поза — открытые руки и больше жестикулируй.<\/p>\n<p><nohtml>6.<\/nohtml> Сделай небольшую ошибку — урони ручку, пролей кофе.<\/p>\n<p><nohtml>7.<\/nohtml> Возвращай подтверждение получения: «ага, понял», «перефразирование».<\/p>\n<p><nohtml>8.<\/nohtml> Подчеркни что-то общее между вами<\/p>\n<p><nohtml>9.<\/nohtml> Если ничего не помогает, можно попробовать вывести на отрительные чувства — фрустировать. Например, дать невыполнимую задачу.<\/p>\n<p><nohtml>10.<\/nohtml> На встречу одевайся чуть хуже, чем ожидаешь придет респондент.<\/p>\n<h2>5. Сигналы<\/h2>\n<p>— Если в первой презентации готовы купить 40% (8 респондентов из 20), это хорошо.<\/p>\n<p>— Когда продукт уже есть — если 40% отвечают, насколько они будут разочарованы, если не смогут больше пользоваться продуктом, то это тоже хорошо.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/image-8.png\" width=\"284\" height=\"116\" alt=\"\" \/>\n<\/div>\n<h2>См. также<\/h2>\n<p>Книга по кастдеву. Иван Замесин <a href=\"https:\/\/zamesin.me\/books\/custdev\/intro\">https:\/\/zamesin.me\/books\/custdev\/intro<\/a><\/p>\n<p>Решенческие интервью: как проверить ценность продуктовой идеи. Иван Замесин <a href=\"https:\/\/www.youtube.com\/watch?v=1qBcKODd6YE\">https:\/\/www.youtube.com\/watch?v=1qBcKODd6YE<\/a><\/p>\n",
            "date_published": "2021-02-26T19:14:00+03:00",
            "date_modified": "2021-09-15T13:16:20+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/image-7.png",
            "_date_published_rfc2822": "Fri, 26 Feb 2021 19:14:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "41",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/image-7.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/image-8.png"
                ]
            }
        },
        {
            "id": "30",
            "url": "https:\/\/anton-lipatov.ru\/all\/knigi-maksim-ilyahov-yasno-ponyatno-konspekt\/",
            "title": "КНИГИ. Ильяхов Максим — Ясно, понятно. Конспект",
            "content_html": "<p>Если вы правы и вас не поняли, то не важно, что вы правы. «Инструменты ясности» помогают донести мысль. Таким инструментом может стать история, поддерживающая мысль, или антипример.<\/p>\n<p>Инструменты ясности — опасное оружие. Ясный текст кажется нам правдимым и полезным. При этом нет никакой связи между ясностью для читателя (или собеседника) и справедливостью, пользой.<\/p>\n<p>Коротко — не значит ясно. Мусор выбрасывайте из текста. Инструменты ясности — добавляйте. Есть много примеров лонгридов, которые читают до конца, потому что они интересные или полезные. Краткий пересказ «Ясно, понятно» не отражает всей широты.<\/p>\n<p>Даже если вы напишете «ясный текст», он может не заинтересовать читателя и усилия будут потрачены впустую. Чтобы повысить ваши шансы, знайте своего читателя и:<\/p>\n<ul>\n<li>учитывайте его <b>контекст<\/b>: что он знает о теме, что с ним происходит, в каких обстоятельствах он встретится с вашим текстом (разговором);<\/li>\n<\/ul>\n<ul>\n<li><b>заинтересуйте<\/b> читателя пользой от прочтения, развлечением. Покажите, что вы знаете, зачем ему нужен этот текст;<\/li>\n<\/ul>\n<ul>\n<li>уберите туман и мусор из <b>текста<\/b>;<\/li>\n<\/ul>\n<ul>\n<li>поработайте над <b>подачей<\/b>, дайте возможность быстро понять основные тезисы и прочитать по-диагонали.<\/li>\n<\/ul>\n<h2>Контекст<\/h2>\n<p>Ваш текст одни прочитают, другие — нет. Один и тот же текст человек может прочитать или не прочитать текст в зависимости от своего контекста.<\/p>\n<div class=\"e2-text-table\">\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\">\n<tr>\n<td>✔️ Да, прочитал<\/td>\n<td>❌ Нет, не прочитал<\/td>\n<\/tr>\n<tr>\n<td>Утром в выходные<\/td>\n<td>Днем в будни<\/td>\n<\/tr>\n<tr>\n<td>В посте друга в социальной сети<\/td>\n<td>В рекламном сообщении<\/td>\n<\/tr>\n<tr>\n<td>Читатель разделяет точку зрения автора<\/td>\n<td style=\"text-align: right\">Читатель ее не разделяет<\/td>\n<\/tr>\n<\/table>\n<\/div>\n<p>На что стоит обращать внимание:<\/p>\n<ul>\n<li>удачное ли выбрано <b>место и время<\/b>. Подходит ли TikTok для текстов банка, уместно ли обращаться с рекламным предложением к людям на улице; пользователь ищет статью об ожогах для реферата или оказания первой медицинской помощи;<\/li>\n<\/ul>\n<ul>\n<li>что <b>происходит в мире<\/b>. Не попадет ли текст в опалу из-за того, что автор проигнорировал важное событие;<\/li>\n<\/ul>\n<ul>\n<li>какие уже сложились отношения с говорящим. Выясните, нет ли у читателя <b>предубеждений<\/b> вроде того, что все финансисты воры или риелторы делают деньги из воздуха.<\/li>\n<\/ul>\n<ul>\n<li>попадает ли внешний вид текста или сообщения в <b>ожидание<\/b> читателя: молодым нравится верстка TheVillage, пожилым — дизайн Комсомольской правды.<\/li>\n<\/ul>\n<p>Невыгодный контекст можно исправить:<\/p>\n<ul>\n<li>прямо и с пониманием озвучьте позицию собеседника («Вы думаете, что я хочу вам продать этот пылесос любой ценой...»);<\/li>\n<\/ul>\n<ul>\n<li>нарисуйте образ общего врага («Вы правы, торговые агенты обычно так поступают. Для них нет ничего святого»);<\/li>\n<\/ul>\n<ul>\n<li>при этом сохраняйте спокойствие;<\/li>\n<\/ul>\n<ul>\n<li>сошлитесь, что это ваш личный опыт, позиция и т. п.;<\/li>\n<\/ul>\n<ul>\n<li>напишите, для какого уровня подготовки текст, чтобы эксперты не ругали за то, что в статье для новичков тема освещена неглубоко.<\/li>\n<\/ul>\n<h2>Интерес<\/h2>\n<h3>Как привлечь<\/h3>\n<p>Мы заблуждаемся насчет того, что наш текст прочитают в любом случае. Это заблуждение идет из школы, где учитель обязательно читает работы учеников, а во главу угла ставится грамотность. В жизни все по-другому, и нужно бороться за время читателя, вызывать у него интерес. Даже неграмотный текст может быть интересным.<\/p>\n<p>Человеку интересен он сам, и ему не интересен автор. Если он найдет в статье отражение себя, пользу для себя, развлечение для себя интерес появится.<\/p>\n<blockquote>\n<p>Самый простой способ привлечь внимание — написать простым языком, зачем читать пришел.<\/p>\n<\/blockquote>\n<h3>Точка зрения<\/h3>\n<p>Споры о правоте — эффективный магнит для привлечения внимания. Нам нравится получать подтверждения своей правоте и нас очень сложно переубедить.<\/p>\n<p>Как переубеждать:<\/p>\n<ul>\n<li>определить спорную часть картины мира;<\/li>\n<\/ul>\n<ul>\n<li>показать правоту читателя при определенных условиях и показать другие условия, в которых все иначе;<\/li>\n<\/ul>\n<ul>\n<li>фокус на том, как перейти из исходного состояния в желаемое нами.<\/li>\n<\/ul>\n<h3>Полезное действие. Решить проблему<\/h3>\n<p>Если полезное действие «прагматическое» и рациональное, то должны совпасть три фактора:<\/p>\n<ul>\n<li>читатель знает о существовании проблемы (болит в груди);<\/li>\n<\/ul>\n<ul>\n<li>читатель считает ее важной (да, это может быть сердце);<\/li>\n<\/ul>\n<ul>\n<li>читатель готов ее решать (уже не хочу откладывать, пора лечить).<\/li>\n<\/ul>\n<p>✔️ В заголовок стоит добавлять детали решения, почему именно оно полезно:<\/p>\n<ul>\n<li>рассказать детали решения («Как снизить температуру процессора во время игр до 40 ºC с помощью пассивного охлаждения»);<\/li>\n<\/ul>\n<ul>\n<li>показать, что это быстро или полно («Пять привычек, которые помогают быстрее худеть, лучше спать и быть более энергичным»);<\/li>\n<\/ul>\n<ul>\n<li>показать, что инструкция, гайд, чек-лист;<\/li>\n<\/ul>\n<ul>\n<li>обозначение целевой аудитории («Предпринимателям на УСН: что изменится в налогообложении из-за пандемии»).<\/li>\n<\/ul>\n<p>❌ Ошибки:<\/p>\n<ul>\n<li>казенный, неродной для читателя язык («Нормы учета в 2020 году»); так читатель не говорит;<\/li>\n<\/ul>\n<ul>\n<li>слишком общая тема («Как экономить» -> Как экономить на транспорте в Москве, если вы студент);<\/li>\n<\/ul>\n<ul>\n<li>незнание читателя и неверное его отражение в статье.<\/li>\n<\/ul>\n<h3>Полезное действие. Стать более значимым и любимым<\/h3>\n<p>Читателю может быть интересно все, что обещает ему приобрести лучшее положение в обществе: курсы, советы, мероприятия, подборки.<\/p>\n<p>Важную роль играет чувство принадлежности: к городу, профессии, социальной группе.<\/p>\n<p>Хороший текст при этом еще и <b>выполнит обещание<\/b>.<\/p>\n<p>Человеку НЕ интересен автор или кто-либо другой. Он хочет узнавать себя, свои проблемы<\/p>\n<h3>Полезное действие. Эмоции<\/h3>\n<p>Заголовки, вызывающие эмоции, работают:<\/p>\n<ul>\n<li>любопытство («Врачи раскрыли самый действенный способ профилактики COVID-19, это...», заголовки со мнимой важностью);<\/li>\n<li>гнев («Платите налоги, если хотите ...»);<\/li>\n<\/ul>\n<p>При этом сам текст может преследовать совершенно другие цели, чем обещано в заголовке. И в ряде случаев это нормально, что читатель только прочитал заголовок.<\/p>\n<h2>Текст<\/h2>\n<h3>Создавайте картинку<\/h3>\n<p>Текст не информирует, он должен помочь читателю разобраться, понять взаимосвязи между предметами и явлениями. Лучше всего взаимосвязи понятны, если у читателя перед глазами всплывет <b>история, связный рассказ<\/b>, в которых есть что-то делающие персонажи.<\/p>\n<blockquote>\n<p>❌ Встроенная в камеру эмуляция пленки позволяет ускорить некоторые этапы обработки, а в отдельных ситуациях даже отказаться от обработки как таковой.<\/p>\n<\/blockquote>\n<blockquote>\n<p>✔️ Раньше у фотографа было несколько этапов работы: снять картинку, загрузить на компьютер и обработать — настроить цвет, яркость и резкость. Теперь камера следит за этим сама: фотограф просто делает снимки и сразу выгружает их в интернет.<\/p>\n<\/blockquote>\n<h3>Абстракции, примеры, антипримеры<\/h3>\n<p>Абстракции стоит сопровождать примерами. Люди лучше понимают, запоминают и применяют на практике знания из примеров, чем из абстраций.<\/p>\n<blockquote>\n<p>❌ Не подписывайте документы, не читая.<\/p>\n<\/blockquote>\n<blockquote>\n<p>✔️ Не подписывайте документы, не читая. Если за вами очередь, скажите сотруднику банка, что вы не подписываете документы, не читая. Спросите, как это лучше организовать, чтобы никого не задерживать. Иван в прошлом году подписал документ и попал на миллионы рублей.<\/p>\n<\/blockquote>\n<p>Нюансы использования <b>примеров<\/b>:<\/p>\n<ul>\n<li>писать текст можно не от темы, а от примера;<\/li>\n<\/ul>\n<ul>\n<li>если к мысли нет примера, эта мысль не нужна;<\/li>\n<\/ul>\n<ul>\n<li>но и примеры не оставлять без обобщения, иначе непонятно, что пример иллюстрирует;<\/li>\n<\/ul>\n<ul>\n<li>примеры не стоит делать слишком детальными;<\/li>\n<\/ul>\n<ul>\n<li>лучше придерживаться одного примера, постепенно его развивая по ходу повествования;<\/li>\n<\/ul>\n<ul>\n<li>пример не должен быть неожиданным и экстравагантным; его обстоятельства должны быть понятными читателю.<\/li>\n<\/ul>\n<ul>\n<li>в ряде случаев примера недостаточно, если у читателя другая позиция, привычка, стиль поведения. В этом случае становитесь на сторону читателя, показывайте, что знаете и разделяете его точку зрения; после этого учите, как правильно.<\/li>\n<\/ul>\n<p>Используйте антипримеры в связке <b>Тезис — Пример — Антипример<\/b>. Читатель лучше поймет и запомнит из-за описанных негативных последствий.<\/p>\n<blockquote>\n<p>ТЕЗИС Чтобы при записи звука не было гулкости и отражений, комнату нужно акустически подготовить.<\/p>\n<\/blockquote>\n<blockquote>\n<p>ПРИМЕР Самый простой способ — обставить ее мягкой мебелью, повесить тяжелые бархатные шторы и закрепить на стенах поролоновые звукопоглотители («пирамидки»).<\/p>\n<\/blockquote>\n<blockquote>\n<p>АНТИПРИМЕР Лотки из-под яиц в качестве поглотителей не годятся: из-за своей формы они поглощают лишь крохотный диапазон частот. Прикрепить их к стенам так же сложно, как и акустический поролон, а звук в результате будет малопригоден для профессиональной работы.<\/p>\n<\/blockquote>\n<h3>Не наезжайте на читателя<\/h3>\n<p>Чтобы ни случилось, читатель не должен быть выставлен виноватым.<\/p>\n<blockquote>\n<p>У вас могут быть обоснованные причины не следовать нашим советам. Мы это принимаем. Вы по-своему правы. В любом случае мы на вашей стороне.<\/p>\n<\/blockquote>\n<p>Есть способ распределения эмоций через местоимения:<\/p>\n<ul>\n<li>вы — для хорошего;<\/li>\n<\/ul>\n<ul>\n<li>он(и) — для плохого;<\/li>\n<\/ul>\n<ul>\n<li>мы — в спорных моментах;<\/li>\n<\/ul>\n<blockquote>\n<p>✔️Если <b>вы<\/b> так сделаете, <b>читатель<\/b> с большей вероятностью поймет вашу мысль и будет рад последовать за вами, <b>ваша<\/b> коммуникация состоится. А когда <b>автор<\/b> заходит немного сверху, <b>читатель<\/b> скорее отвернется от него, начнет защищаться. Поэтому, когда <b>мы<\/b> пишем статью, нам полезно оценить общую тональность: не создаем ли <b>мы<\/b> случайно враждебной тональности?<\/p>\n<\/blockquote>\n<p>Не нужно обращаться сверху, придумывать группы для разделения на своих и чужих («хорошие редакторы»), давать отрицательную оценку (ее лучше смягчить).<\/p>\n<h3>Как рассказать банальный совет<\/h3>\n<p>Если по ходу статьи нужно дать банальный совет, то его лучше преподносить с обратной стороны — почему читатели не делают то, что советуют (тратят больше денег с кредитки, чем могут себе позволить).<\/p>\n<ul>\n<li>Есть проблема<\/li>\n<\/ul>\n<ul>\n<li>Все знают о решении в теории<\/li>\n<\/ul>\n<ul>\n<li>Мало кто делает на практике (почему, что мешает?)<\/li>\n<\/ul>\n<h3>Подлежащее и сказуемое<\/h3>\n<p>Хорошая структура фразы — это активный залог в формате «Человек + делает + так» («Субъект + действие + уточнение»). Но не всегда стоит вводить ненужные субъекты<\/p>\n<p>✔️Дома построены. Новоселы получат первые ключи...<\/p>\n<p>❌Строители сдали дома (Тут строители лишние, т. к. статья не про них).<\/p>\n<h3>Как давать факты<\/h3>\n<p>Порой чистые факты не работают, т. к. непонятны. Их можно изложить более удачно, если:<\/p>\n<ul>\n<li>привести сравнение для того, чтобы читатель понял, много это или мало;<\/li>\n<\/ul>\n<ul>\n<li>описать ситуацию, в которой тот или иной факт станет значимым (чувствительность у камеры ночью);<\/li>\n<\/ul>\n<ul>\n<li>округлить до ясности (0,23 — четверть и т. п.).<\/li>\n<\/ul>\n<h3>Коротко<\/h3>\n<ul>\n<li>Не отрывайте субъект от действия. Уточнения, нюансы можно вынести в отдельную фразу.<\/li>\n<\/ul>\n<blockquote>\n<blockquote>\n<p>❌ Если вы ИП на ЕСХН, УСН, ЕНВД или патенте, то в большинстве случаев вы не обязаны вести бухучет (п. 1 ст. 2 ч. 6 Федерального закона от 06.12.2011 №402-ФЗ), но это тем не менее не значит, что вы можете не выставлять счета и не хранить акты выполненных работ.<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<blockquote>\n<p>✔️ ИП могут не вести бухгалтерский учет, но хранить акты и выставлять счета всё же нужно. Это касается предпринимателей на ЕСХН, УСН, ЕНВД или патенте. Право не вести бухучет закреплено в п. 1 ст. 2 ч. 6 Федерального закона от 06.12.2011 №402-ФЗ.<\/p>\n<\/blockquote>\n<\/blockquote>\n<ul>\n<li>К перечислению лучше добавлять обобщающую мысль:<\/li>\n<\/ul>\n<blockquote>\n<blockquote>\n<p>✔️ В Росреестр возьмите все документы на квартиру:<\/p>\n<\/blockquote>\n<\/blockquote>\n<ul>\n<li>Метафоры нужно уметь использовать.<\/li>\n<\/ul>\n<h3>Сюжет<\/h3>\n<p>Сюжет работает на привлечение внимания читателя. При этом одно и то же событие можно трактовать совершенно по-разному изменив сюжеты. Компоненты сюжета помогают втянуть читателя:<\/p>\n<ul>\n<li>герои — протагонист и антагонист; добрый и злой; симпатичный и мерзкий;<\/li>\n<\/ul>\n<ul>\n<li>конфликт — у героев противоположные интересы; они действуют друг против друга, чтобы эти интересы реализовать;<\/li>\n<\/ul>\n<ul>\n<li>разрешение — хороший побеждает плохого;<\/li>\n<\/ul>\n<ul>\n<li>трансформация героя — протагонист побеждает благодаря внутренним изменениям, росту, взрослению, преодолению себя;<\/li>\n<\/ul>\n<ul>\n<li>обстоятельства — всё разворачивается в понятных нам декорациях или по понятным законам. «Звездные войны» происходят в далекой галактике, но по земным правилам: есть империя, повстанцы, а космические бои ничем не отличаются от воздушных.<\/li>\n<\/ul>\n<h3>Схема текста<\/h3>\n<ul>\n<li>Контекст и интерес: проверяем, хочет ли читатель нас слушать, и какие примеры, сюжеты подобрать.<\/li>\n<\/ul>\n<ul>\n<li>Введение в ситуацию.<\/li>\n<\/ul>\n<ul>\n<li>Тезис, основная мысль.<\/li>\n<\/ul>\n<ul>\n<li>Примеры и антипримеры.<\/li>\n<\/ul>\n<ul>\n<li>Доказательства<\/li>\n<\/ul>\n<h2>Подача<\/h2>\n<p><i>В книге дан разбор плохих и хороших визуальных примеров, лучше обращаться к ней. Нет смысла переносить в конспект<\/i><\/p>\n<p>Инструменты визуального повествования облегчают понимание текста, при диагональном прочтении читатель получит больше информации, а именно:<\/p>\n<ul>\n<li>о чём здесь;<\/li>\n<\/ul>\n<ul>\n<li>какова главная мысль;<\/li>\n<\/ul>\n<ul>\n<li>полезно ли это изучить;<\/li>\n<\/ul>\n<ul>\n<li>если полезно — с чего начать;<\/li>\n<\/ul>\n<ul>\n<li>что изучить в первую очередь, если на текст мало времени.<\/li>\n<\/ul>\n<p>Этого можно добиться, если использовать:<\/p>\n<ul>\n<li>заголовки и подзаголовки — делайте простыми. Можно добавлять информативности для того, чтобы читатель понял, читать ему этот раздел или нет;<\/li>\n<\/ul>\n<ul>\n<li>перечни;<\/li>\n<\/ul>\n<ul>\n<li>модульная структура статьи;<\/li>\n<\/ul>\n<ul>\n<li>анкеты, микроформаты, рейтинги — доносите мысль в разных разделах текста по одному шаблону.<\/li>\n<\/ul>\n<ul>\n<li>плашки-шпаргалки, дающие краткие тезисы раздела или всей статьи (Если у тебя мало времени, прочитай только меня);<\/li>\n<\/ul>\n<ul>\n<li>текстовые иллюстрации (примеры и диалоги);<\/li>\n<\/ul>\n<ul>\n<li>иллюстрации фотографиями (людей, мест, предметов, коллажи) и видеороликами. Иллюстрация отличается от картинки тем, что поддерживает ту или иную мысль, высказанную автором.<\/li>\n<\/ul>\n<ul>\n<li>иллюстрации скриншотами и документами;<\/li>\n<\/ul>\n<ul>\n<li>иллюстрации схемами и схематичными рисунками.<\/li>\n<\/ul>\n",
            "date_published": "2021-01-18T21:45:33+03:00",
            "date_modified": "2021-05-28T15:28:56+03:00",
            "_date_published_rfc2822": "Mon, 18 Jan 2021 21:45:33 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "30",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "44",
            "url": "https:\/\/anton-lipatov.ru\/all\/knigi-til-piter-masters-bleyk-ot-0-k-1-kak-sozdat-startap-kotory\/",
            "title": "КНИГИ. Тиль Питер, Мастерс Блейк  — От 0 к 1: Как создать стартап, который изменит будущее",
            "content_html": "<p>Книга начинается с фразы «Каждое событие в бизнесе происходит лишь однажды». Ты можешь скопировать любую модель, но при этом ты переходишь от 1 к 2 (горизонтальный прогресс, глобализация) и большим цифрам. При этом идейно интересно перейти от 0 к 1 (технология).<\/p>\n<p>Сильными провайдерами технологий являются стартапы, т. к. в них работает больше одного человека и они не закрепощены корпоративными стандартами.<\/p>\n<p>Стартап — максимальная по числу группа людей, которую вы сможете заразить своей идеей создания нового, лучшего будущего.<\/p>\n<h3>Уроки кризиса доткомов<\/h3>\n<p>В 1999 году PayPal уже имела продукт по пересылке денег для владельцев карманных компьютеров PamPilot. Их почти ни у кого не было, но у всех была электронная почта. Это было плохое решение, но заставило задуматься о пересылке просто электронных денег.<\/p>\n<p>Компания успела привлечь деньги до кризиса доткомов, при этом модель привлечения была — раздача по 10 долл. каждому новому пользователю.<\/p>\n<p>Уроки кризиса доткомов:<\/p>\n<ol start=\"1\">\n<li>Осторожность в прогнозах<\/li>\n<li>Действовать гибко<\/li>\n<li>Развиваться в ходе конкуренции — работайте с уже созревшими клиентами<\/li>\n<li>Думайте о продукте, а не о продажах.<\/li>\n<\/ol>\n<h3>Монополия и конкуренция<\/h3>\n<p>Любая компания с достаточной точностью работает либо в формате монополии, либо в условиях совершенной конкуренции. Их сложно различить, поскольку обе стороны лгут: монополисты придумывают себе конкурентов, а конкурирующие слишком оптимистично определяют свою долю, определяя свою долю на пересечении сегментов.<\/p>\n<p>Монополия — это состояние, характерное для любого успешного бизнеса. В этом случае у компании остаются деньги для стратегических и социальных инициатив. Конкуренция — это отсутствие прибыли и развитие в стесненных условиях. Людям свойственно конкурировать, но это не лучшая стратегия.<\/p>\n<p>Что отличает монополию:<\/p>\n<ol start=\"1\">\n<li>Собственная технология, которую сложно повторить. Хорошо, если она в 10 раз лучше, чем у конкурентов. Это вопрос технологии, но не только. Преимуществом может быть ассортимент или дизайн.<\/li>\n<li>Сетевой эффект. Каждый новый пользователь приводит несколько новых. Успешный сетевой бизнес редко запускают выпускники MBA, поскольку начальный сегмент бывает очень узким (у Facebook это были сокурсники Цукерберга).<\/li>\n<li>Эффект масштаба. Монополия становится сильнее. Хороший стартап должен предусмотреть возможность наращивания масштаба уже в первой версии продукта<\/li>\n<li>Бренд. Но начинать с него опасно, лучше поработать над продуктом.<\/li>\n<\/ol>\n<h3>Целевая аудитория<\/h3>\n<p>На старте необходимо отличать малую аудиторию от незначительной. Аудитория владельцев PalmPilot была незначительной и не имела шансов на масштабирование. Идеальная ЦА — небольшая группа людей, обслуживание которой занимается ни слишком много конкурентов, либо и вовсе никто.<\/p>\n<p>Авторы предостерегают от выпуска на рынок «бомб» — первых версий решений, которые компания потом дорабатывает.<\/p>\n<p>Гораздо выгоднее быть тем, кто делает завершающий ход — выходит на рынок с прорывной технологией.<\/p>\n<h3>Настроение<\/h3>\n<p>Важно настроение. Авторы раскладывают на отношение (пессимизм\/оптимизм) и определенность\/неопределенность<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled.png\" width=\"358\" height=\"309\" alt=\"\" \/>\n<\/div>\n<h3>Закон степеней<\/h3>\n<p>Мы живем в мире, в котором правит закон степеней (*Сложные проценты — восьмое чудо света по Эйнштейну).* Венчурные фонды зарабатывают очень большие деньги на очень маленьком числе компаний. Диверсификация тут — не лучшая модель.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled-(1).png\" width=\"384\" height=\"248\" alt=\"\" \/>\n<\/div>\n<h3>Секреты<\/h3>\n<p>С точки зрения доступности информации выделяются:<\/p>\n<p>— общепринятые истины (легко узнать)<br \/>\n— секреты (трудно узнать)<br \/>\n— тайны (невозможно узнать)<\/p>\n<p>Раскрывать секреты — ключ к успеху. Но их никто не ищет, поскольку социум уничтожает веру в секреты, вторая тенденция — избегание риска, третья — самоудовлетворенность; плюс однообразие. Это позиция — в мире уже все есть.<\/p>\n<p>Есть два вида секретов:<\/p>\n<p>— секреты мира природы<br \/>\n— секреты человеческой натуры (то, что люди сами о себе не знают и скрывают)<\/p>\n<p>Их стоит искать там, где никто не ищет. Например, *в области питания, в которой догмы были заложены 30-40 лет назад под действием лоббистов.*<\/p>\n<h3>Фундаменты<\/h3>\n<p>Закон Тиля: стартап, где наделали ошибок с самого начала, невозможно исправить.<\/p>\n<p>Где могут быть ошибки:<\/p>\n<ol start=\"1\">\n<li>Характеры сооснователей<\/li>\n<li>Отсутствие структуры: собственность (кто владеет акциями компании), управление (кто рулит в ежедневного режиме), контроль (кто принимает решения, связанные с бизнесом — совет директоров, 3-5 человек)<\/li>\n<li>Сотрудники только на фуллтайм и с полной вовлеченностью<\/li>\n<li>Слишком большая зарплата руководителя<\/li>\n<li>Замена зарплаты на долю в стартапе<\/li>\n<\/ol>\n<h3>Кадры<\/h3>\n<ol start=\"1\">\n<li>Удобный офис и гибкий график не сделают команду. Набирай вовлеченных и заинтересованных людей.<\/li>\n<li>Стартап должен заставить своих сотрудников быть максимально похожими друг на друга<\/li>\n<li>Внутри компании каждый сотрудник должен резко отличаться от других своей работой (ответственность за что-то одно).<\/li>\n<\/ol>\n<h3>Продажи<\/h3>\n<p>Чистая прибыль за весь период сотрудничества с клиентом должна быть выше средней цены привлечения нового клиента.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/Untitled-(2).png\" width=\"728\" height=\"229\" alt=\"\" \/>\n<\/div>\n<p>В мертвой зоне могут использоваться гибридные и нестандартные подходы к решению вопроса.<\/p>\n<p>В дистрибуции также действует закон больших чисел — обычно идеально работает только один канал дистрибуции, который приносит наибольшую выгоду.<\/p>\n<h3>Человек и машина<\/h3>\n<p>Человек и машина — это взаимодополняющие элементы. Именно в этом направлении бизнес должен искать секреты.<\/p>\n<h3>Почему многие стартапы прогорают?<\/h3>\n<p>Потому что не могут ответить на один из вопросов.<\/p>\n<ol start=\"1\">\n<li>Вопрос о технологиях. <i>Способны ли вы создать прорывную технологию, а не вносить мелкие дополнения в уже существующую? (в 10 раз лучше, чем у конкурентов)<\/i><\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Вопрос о времени. <i>Подходящий ли сейчас момент начинать задуманный вами бизнес?<\/i><\/li>\n<\/ol>\n<ol start=\"3\">\n<li>Вопрос о монополии. <i>Вы начинаете с захвата большой доли на маленьком рынке?<\/i><\/li>\n<\/ol>\n<ol start=\"4\">\n<li>Вопрос о людях. <i>У вас достойная команда?<\/i><\/li>\n<\/ol>\n<ol start=\"5\">\n<li>Вопрос о продажах. <i>У вас есть возможность не только создать, но и продать ваш продукт?<\/i><\/li>\n<\/ol>\n<ol start=\"6\">\n<li>Вопрос о долгожительстве. <i>Сможете ли вы сохранить свои позиции на рынке через 10 лет? А через 20?<\/i><\/li>\n<\/ol>\n<ol start=\"7\">\n<li>Вопрос об открытии. <i>Нашли ли вы свой уникальный шанс, не замеченный остальными?<\/i><\/li>\n<\/ol>\n<h3>Парадокс основателя<\/h3>\n<p>Заключается в том, что основатели по распределению сильно негативных и сильно положительных качеств отличаются от других, для которых справедливо нормальное распределение с пиком в среднем значении. У основателей наоборот — максимумы на крайних значениях.<\/p>\n",
            "date_published": "2020-11-08T21:21:41+03:00",
            "date_modified": "2021-11-08T11:23:54+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/Untitled.png",
            "_date_published_rfc2822": "Sun, 08 Nov 2020 21:21:41 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "44",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled-(1).png",
                    "https:\/\/anton-lipatov.ru\/pictures\/Untitled-(2).png"
                ]
            }
        },
        {
            "id": "35",
            "url": "https:\/\/anton-lipatov.ru\/all\/prioritizaciya-zadach-istoriy\/",
            "title": "Приоритизация задач, историй",
            "content_html": "<h2>Общее про фреймворки проиритизации<\/h2>\n<p>🙄 Фреймворки приоритизации помогают. Они задают общие правила игры для команды и <b>снижают напряженность из-за субъективных решений<\/b>. Иногда и помогают зарабатывать :)<\/p>\n<p>🤣 Но можно работать и без фреймворков, если команда не может договориться. Или каждая оценка получается неоправданно дорогой.<\/p>\n<p>😡 Общие проблемы фреймворков:<br \/>\n— Субъективность оценок<br \/>\n— Сложность получения оценки требуемых ресурсов<br \/>\n— Взаимное влияние фичей и необходимость переоценки<\/p>\n<p>👨‍🦲👨‍🦲👨‍🦲 Фреймворков много разных. Похожи они в том, что приоритет определяется важностью гипотезы\/импактом и ресурсами на ее выполнение.<\/p>\n<p>💡 И самое интересное. Фреймворки из трех, четырех, пяти букв обещают в названии, что для принятия решения будет достаточно такого же числа факторов: <b>PIE<\/b>, <b>BUC<\/b>, <b>ICE<\/b> — 3 фактора; <b>RICE<\/b>, <b>RACE<\/b>, <b>REAN<\/b> — 4 и т. д.<\/p>\n<p>💡Однако, как потом выясняется, для оценки каждого из факторов нужно учесть еще кучу «подфакторов», чтобы дать точную оценку. Например, при оценка влияния Impact в <b>RICE<\/b> может быть сложена из оценки частоты использования фичи или ее уникальности для продукта; оценка простоты Ease — из простоты технической реализации и простоты согласования со стейкхолдерами.<\/p>\n<p>💡В этом смысле «правильный фреймворк» — сразу выписать однозначно все метрики для своего бизнеса и идти по ним. Как Hotwire или PXL.<\/p>\n<p>🤴 Особое внимание стоит уделить отличному от других подходу KANO.<\/p>\n<h2>Фреймворки приоритизации<\/h2>\n<h3><nohtml>1.<\/nohtml>«Риск допущения + Важность»<\/h3>\n<p>Мы закрываем первыми такие истории, которые позволяют проверить наиболее рисковые допущения и которые одновременно мы считаем важными для пользователей. Таким образом для каждой истории мы ставим оценку от 1 до 5 или 10 по двум критериям:<\/p>\n<p>✔️насколько велик риск допущения, которое связано с историей. Риск допущения — это насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным<\/p>\n<blockquote>\n<p>📝 Например, мы делаем систему хранения и обмена фотографиями. У нас осталось непроверенным допущение, что люди пожилого возраста будут пользоваться нашим облачным фотохранилищем. Мы рассчитываем на эту аудиторию, поэтому истории, в которой пользователь может использовать номер пенсионного удостоверения для скидки, дадим 10 баллов по допущениям<\/p>\n<\/blockquote>\n<p>✔️насколько важна задача с точки зрения бизнеса, пользователей.<\/p>\n<p>Суммируя две оценки получаем одно число. Чем оно выше, тем быстрее истории уходит в разработку.<\/p>\n<h3><nohtml>2.<\/nohtml> BUC (Business, Users, Costs)<\/h3>\n<p>Метод <b>BUC<\/b> также дает одну оценку.  Она складывается из трех факторов, которые оцифровываются по любой шкале (1-5, 1-10):<br \/>\n✔️ выгоды бизнеса: рост выручки, упрощение процессов, привлечение новых пользователей;<br \/>\n✔️ выгоды пользователей: удобство использования, дополнительный функционал;<br \/>\n✔️ затраты: насколько сложно историю закрыть.<\/p>\n<p>В результате число получается сложением выгод и вычитанием затрат.<\/p>\n<h3><nohtml>3.<\/nohtml> MOSCOW (Must, Should, Could, Would)<\/h3>\n<p>Этот метод впервые начали применять в 1994 году в Oracle.<\/p>\n<p>Истории распределяются по четырем корзинам:<br \/>\n✔️ обязательно нужно сделать. Если историю не закрыть, последствия могут быть значимыми негативными.<br \/>\n✔️ следует сделать. Не самые важные требования, но которые стоит закрыть после обязательных.<br \/>\n✔️ могли бы сделать. Желательные требования, которые сделаем, если останутся ресурсы.<br \/>\n✔️ можем и не делать. Требования зафиксированы, но можно их отложить на следующий спринт, поскольку они не повлияют серьезным образом на бизнес или пользователей.<\/p>\n<h3><nohtml>4.<\/nohtml> RICE (ICE)<\/h3>\n<p>RICE — пожалуй, один из самых популярных фреймворков приоритизации.<\/p>\n<p>Критерии:<br \/>\n✔️ <b>Reach<\/b> (охват) — сколько пользователей охватывает гипотеза. Узкое место, что охваты приходится считать или оценивать. Это дополнительные деньги. Плюс охваты постоянно меняются — стоит договориться о периодах, на которые эти данные будут фиксироваться.<br \/>\n✔️ <b>Impact<\/b> (влияние) — как реализация истории повлияет на охватный сегмент (слабо-сильно). При выборе и оценке влияния удобно разложить «вклад» на составляющие.<\/p>\n<blockquote>\n<p>📝 Примеры:<br \/>\n— является ли эта фича уникальной (можно ли решить пользовательскую историю сейчас иначе)?<br \/>\n— как часто будет использоваться?<\/p>\n<\/blockquote>\n<p>✔️ <b>Confidence<\/b> (уверенность в результате). Значение уверенности можно определять: мнением PM, мнением HiPPO, групповой экспертизой, данными аналитики, опросом пользователей.<\/p>\n<blockquote>\n<p>📝Можно договориться о шкале, например:<br \/>\n—  сам придумал 5%<br \/>\n— команда согласна 10%<br \/>\n— есть запросы от пользователей, данные аналитики 30%<br \/>\n— опрос, кастдев 50%<br \/>\n— был успешный MVP или AБ-тест на другом продукте 70%<\/p>\n<\/blockquote>\n<p>✔️ <b>Effort<\/b> (усилия). Проблема с оценкой усилий связана с тем, что это дорого и не всегда точно.<\/p>\n<p>Конечная формула — в числителе производение R*I*C, в знаменателе — E.<\/p>\n<p>Во фреймворке <b>ICE<\/b> все то же самое, кроме того, что не учитывается охват, а Effort может быть заменен обратной величиной Ease (простота). Финальную оценку получают перемножают трех множителей: I*C*E.<\/p>\n<h3><nohtml>5.<\/nohtml> ⚡ HotWire, PXL<\/h3>\n<p>В компании HotWire есть своя шкала оценок. В ней 10 факторов, по каждому из которых оценка 0 или 1. Приоритет определяется простой суммой факторов. Факторы на 2015 год:<br \/>\n✔️ Влияет ли основную метрику (1 — новые бронирования на сайте\/в приложении; 0 — любая другая вторичная метрика)<br \/>\n✔️ Что оптимизируем (1 — относится к результатам поиска или процессу биллинга)<br \/>\n✔️ Место (1 — если выше «fold», т. е. в верхней части страницы)<br \/>\n✔️ Охват (1 — распространяется на 100% всех пользователей)<br \/>\n✔️ Новизна (1 — новое на сайте; 0 — изменение существующих элементов)<br \/>\n✔️ Показало себя у конкурентов (1 — да, например, у Booking или Expedia)<br \/>\n✔️ Влияет на 2 или более улучшителя конверсии — conversion vein (1 -да). Примеры улучшителей конверсии: отображение цен и скидок, стимулирующие элементы (осталось часов до закрытия выгодного предложения), снижение затрат на регистрацию (гостевой логин), повышение доверия за счет логотипов систем безопасной оплаты<br \/>\n✔️ Относится к стратегической цели компании (1 — да)<br \/>\n✔️ Мобильность (1 — изменяется элемент мобильного приложения и\/или повышает вероятность установки приложения)<br \/>\n✔️ Непрозрачные продажи (Opaque sales). Это специальная метрика HotWire, который продает не конкретные отели, а отель определенного класса. Пользователь узнает отель уже после оплаты, но при этом обычно получает хорошую скидку (1 — относится к метрике непрозрачных продаж)<\/p>\n<p>Подробнее про систему HotWire<br \/>\n<a href=\"https:\/\/blog.optimizely.com\/2015\/05\/05\/how-to-prioritize-ab-testing-ideas\/\">https:\/\/blog.optimizely.com\/2015\/05\/05\/how-to-prioritize-ab-testing-ideas\/<\/a><br \/>\n<a href=\"https:\/\/www.navistone.com\/blog\/increase-your-online-sales-by-15-with-a\/b-experiments\">https:\/\/www.navistone.com\/blog\/increase-your-online-sales-by-15-with-a\/b-experiments<\/a><\/p>\n<p>По аналогичной схеме конкретных вопросов построен более поздний фреймворк <b>PXL<\/b>. Отличие заключается в наборе параметров и в том, что оценка может быть как бинарной, так и не бинарной. Подробнее про систему PXL:<br \/>\n<a href=\"https:\/\/cxl.com\/blog\/better-way-prioritize-ab-tests\/\">https:\/\/cxl.com\/blog\/better-way-prioritize-ab-tests\/<\/a><\/p>\n<h3><nohtml>6.<\/nohtml> REAN, RACE<\/h3>\n<p>Модель REAN разработана Стивом Джексоном (Steve Jackson) из компании Cult of Analytics. Она больше подходит для планирования маркетинговых активностей. В ней используются характерные стадии воронки:<br \/>\n✔️ охват (<b>Reach<\/b>),<br \/>\n✔️ вовлечение (<b>Engage<\/b>),<br \/>\n✔️ активация или целевая конверсия (<b>Activate<\/b>),<br \/>\n✔️ повторные покупки (<b>Nurture<\/b>).<\/p>\n<p>RACE — почти брат-близнец <b>REAN<\/b> с той разницей, что в <b>RACE<\/b> активация относится к денежным показателям (в REAN — это могут быть просто конверсии или коэффициент конверсии). Эта модель — из The Smart Insights.<\/p>\n<h3><nohtml>7.<\/nohtml> PIE<\/h3>\n<p>Фреймворк от <b>Криса Говарда<\/b> (Chris Goward), основателя WiderFunnel. Автор предлагает его использовать для приоритизации действий и гипотез.<br \/>\n✔️ <b>Potential<\/b> — насколько серьезным будет улучшение, насколько улучшиться релевантная метрика. Приоритет будет отдаваться таким действиям, которые кардинально меняют метрику. Вопросы, ответы на которые помогут оценить потенциал гипотезы:<\/p>\n<blockquote>\n<p>— Подтверждена ли гипотеза данными?<br \/>\n— Подтверждена ли гипотеза обратной связью от пользователей?<\/p>\n<\/blockquote>\n<p>✔️ <b>Importance<\/b> — насколько это повлияет на общую метрику. Если речь идет об оптимизации сайта приоритет будет у тех страниц, через которые проходит максимум трафика, приводящего к целевому действию. Вопросы:<\/p>\n<blockquote>\n<p>— Повлияет ли главную метрику?<br \/>\n— Были ли раньше релевантные экспертименты и какие их результаты?<\/p>\n<\/blockquote>\n<p>✔️ <b>Ease<\/b> — простота реализации<\/p>\n<blockquote>\n<p>— Насколько легко проверить?<br \/>\n— Насколько простым будет согласование со стейкхолдерами?<\/p>\n<\/blockquote>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-pie-sample.png\" width=\"735\" height=\"461\" alt=\"Пример приоритизации по PIE\" \/>\n<div class=\"e2-text-caption\"><i>Приоритизация по PIE, источник: WiderFunnel<\/i><\/div>\n<\/div>\n<h3><nohtml>8.<\/nohtml> <b>KANO<\/b><\/h3>\n<p>Фреймворк <b>KANO<\/b> назван в честь автора — Нориаки Кано (Noriaki Kano). Он основан на предположении, что в любом продукте есть 3 типа функций и отношений клиентов к ним:<br \/>\n✔️ Mandatory quality — обязательные свойства. В отеле обязательно должна быть кровать. В ресторане — официант для обслуживания гостей.<br \/>\n✔️ Desired quality — свойство, способное повлиять на оценку клиентов (как в положительную, так и отрицательную сторону). Это, например, площадь номера отеля: чем больше, тем лучше за прежнюю цену. Или скорость загрузки мобильного приложения.<br \/>\n✔️ Delightful quality — свойства, которые определяют положительную оценку, но если их не будет — ничего страшного. В номере отеля посетителя могут ждать приятные сюрпризы. Ресторан подает бесплатные снеки.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-kano.jpeg\" width=\"700\" height=\"530\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><i>Влияние функций разных типов на клиента, <a href=\"https:\/\/medium.com\/@reinaldocamargo\/product-backlog-prioritization-technique-kano-model-63bc5d28a1fe\">источник<\/a> <\/i><\/div>\n<\/div>\n<p>Интересно, что:<\/p>\n<ol start=\"1\">\n<li>Большая часть затрат на создание продукта связана с обязательными свойствами. В то время как на удовлетворенность способны сильно повлиять обычно дешевые «фишки».<\/li>\n<li>Но «фишки» быстро скатываются в первую корзину обязательных свойств, поскольку к ним пользователи быстро привыкают.<\/li>\n<\/ol>\n<p>Как понять, к какой категории относится то или иное свойство? Для этого стоит задать два противоположных вопроса (прямой и обратный) с вариантами ответа.<\/p>\n<blockquote>\n<p>📝Как вы отнесетесь к бесплатной бутылке воды в вашем номере?<br \/>\n— [x] Хотелось бы (Like)<br \/>\n— Так всегда бывает (Expect)<br \/>\n— Нейтрально (Neutral)<br \/>\n— Без этого не проживу (Live with)<br \/>\n— Мне бы это не понравилось (Dislike)<\/p>\n<\/blockquote>\n<blockquote>\n<p>📝Как вы отнесетесь к тому, что в вашем номере НЕ БУДЕТ бесплатной бутылки воды?<br \/>\n—  Хотелось бы<br \/>\n— [x] Так всегда бывает<br \/>\n— Нейтрально<br \/>\n— Без этого не проживу<br \/>\n— Мне бы это не понравилось.<\/p>\n<\/blockquote>\n<p>На основании ответов по таблице соответствия можно понять суть свойства.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/anton-lipatov.ru\/pictures\/lipatov-kano-table.png\" width=\"700\" height=\"316\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><i>Приоритизация KANO по итогам опроса, <a href=\"https:\/\/medium.com\/@reinaldocamargo\/product-backlog-prioritization-technique-kano-model-63bc5d28a1fe\">источник<\/a> <\/i><\/div>\n<\/div>\n<p>В нашем случае (прямой — Like, обратный — Expect) — это функция из третьей корзины, которую никто особо не ждет, но которая повысит удовлетворенность.<\/p>\n<p>💡 Если у продукта несколько пользователей, то тип оценивается по паре ответов, которая встречала в опросе наиболее часто.<\/p>\n",
            "date_published": "2020-03-19T19:59:24+03:00",
            "date_modified": "2021-05-28T15:32:30+03:00",
            "image": "https:\/\/anton-lipatov.ru\/pictures\/lipatov-pie-sample.png",
            "_date_published_rfc2822": "Thu, 19 Mar 2020 19:59:24 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "35",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-pie-sample.png",
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-kano.jpeg",
                    "https:\/\/anton-lipatov.ru\/pictures\/lipatov-kano-table.png"
                ]
            }
        },
        {
            "id": "32",
            "url": "https:\/\/anton-lipatov.ru\/all\/lean-startup-eric-ries\/",
            "title": "КНИГИ. Риз Эрик — Бизнес с нуля. Конспект",
            "content_html": "<p>Традиционно российские редакторы постарались с названием. В русском варианте оно желтоватое и не отражает сути книги. По ходу встречается «экономичный» стартап. Это все странно, ведь в русском языке уже прочно устоялся аналог «lean» — бережливый.<\/p>\n<p>Функции бизнеса и маркетинга в цифровых решениях также важны, как и техническая составляющая. Если стартап провалился, не стоит искать причину только в технических проблемах, как это было в 90-е и начале века.<\/p>\n<h2>1. Принципы lean startup (LS)<\/h2>\n<p>Пять основных принципов LS:<br \/>\n— подход LS можно применять в любом бизнесе;<br \/>\n— стартапу нужен не только продукт, но и менеджмент;<br \/>\n— для развития бизнеса стоит постоянно проводить эксперименты, чтобы проверять на практике свое видение;<br \/>\n— в основе LS лежит самая быстрая возможная обратная связь от потребителей; задача бизнеса заключается в постоянном производстве цикла «создать-оценить-научиться»: превращать идеи в продукты или их части, узнавать мнение потребителей, принимать решение о сохранении вектора или необходимости «виража»;<br \/>\n— новая отчетность, которая позволяет оценить каждый из экспериментов и бизнес в целом.<\/p>\n<h2>2. ВИДЕНИЕ<\/h2>\n<p>Если качество производство определяется способностью компании выпускать качественные товары, то в системе LS — способностью быстро получать подтверждение фактами. То есть очень быстро проводить эксперименты и узнавать реакцию пользователей. Нет смысла детально прорабатывать план на старте — он строится на слишком большом числе допущений. Об этом говорит и само определение стартапа<\/p>\n<blockquote>\n<p><i>«Стартап — вновь созданная организация, которая занимается разработкой новых товаров или услуг <b>в условиях чрезвычайной неопределенности<\/b>»<\/i>.<\/p>\n<\/blockquote>\n<p>Экспериментировать нужно со всем — страницей промо-сайта, новым функционалом, маркетинговыми коммуникациями. Разделяете на тестовую и контрольную группы, задаете метрики и потом их сравниваете.<\/p>\n<p>Видение компании можно сделать очень простым, всего из двух частей: гипотеза ценности и гипотеза роста. Первая отвечает на вопрос «Почему люди захотят пользоваться решением?», вторая — «Как будет расти база клиентов?»<\/p>\n<p>В компании Kodak гипотезы проверяют четырьмя вопросами:<br \/>\n— Признают ли потребители, что у них есть проблема, которую мы пытаемся решить?<br \/>\n— Если предложить им решение этой проблемы, готовы ли они за него платить?<br \/>\n— Станут ли они платить именно нам?<br \/>\n— Можем ли мы предложить решение?<br \/>\nОшибка компаний в том, что они сразу переходят к четвертому вопросу, игнорируя остальные. Все их можно проверить экспериментами.<\/p>\n<blockquote>\n<p>? <i>Пример. Прачечная VLS в Индии. На улицах компания разместила пикапы со стиральными машинами, чтобы проверить, готовы ли жители отдавать белье в стирку и платить за это. Само белье компания отвозила сначала на базу. Они выяснили, что люди готовы платить за стирку и в два раза больше за глажку. Итогом стал продукт — мобильные киоски с энергосберегающей стиральной машиной, сушилкой и удлинителем.<\/i><\/p>\n<\/blockquote>\n<h2>3. ПРАКТИКА<\/h2>\n<p>В цикле «создать — оценить — научиться» сначала проверяются самые рискованные допущения плана, то, от чего зависит все остальное. Такие допущения называют «прыжками веры». Они могут быть сформулированы с помощью аналогов и антианалогов, так они более понятны для инвесторов:<\/p>\n<blockquote>\n<p>? <i>Аналог. В прошлом технологии А удалось завоевать рынок Б благодаря функции С. У нас есть новая технология А2, которая позволит нам завоевать рынок Б2, потому что у нас тоже есть атрибут С.<\/i> При уже существующем аналоге Sony Walkman разработчики iPod уже знали, что люди готовы слушать музыку в наушниках в публичных местах.<br \/>\n? <i>Антианалог.<\/i> Разработчики iPod видели пример сайта Napster, что люди не хотели платить за музыку. Поэтому им пришлось разработать свою модель монетизации.<\/p>\n<\/blockquote>\n<h3>MVP<\/h3>\n<p>Для проверки допущений, или прыжков веры создается минимально рабочий\/жизнеспособный продукт (Minimal viable product, MVP) — его стоит запустить как можно раньше. Главная задача первого этапа — определить, приводят ли усилия по разработке продукта к желаемым результатам.<\/p>\n<p>MVP не должен быть идеальным: он ориентирован на ранних последователей, для которых некоторые функции окажутся избыточными, они не смогут их оценить и вы потеряете деньги и время на разработке. Не стоит беспокоиться и о низком качестве, поскольку это тестовая версия, а основную всегда можно выпустить под другим брендом.<\/p>\n<p>Варианты MVP:<br \/>\n— ручная работа (Groupon сначала публиковал предложения на сайте и отсылал купоны вручную по почте);<br \/>\n— видеопрезентация (Dropbox);<br \/>\n— MVP для одного клиента (Food on table — сервис по созданию меню и списка покупок с наиболее выгодными ценами — начинал с того, что руководители работали с одним клиентом, анализируя его боли и пожелания)<\/p>\n<h3>Учет инноваций<\/h3>\n<p>Проблема этапа после MVP — ясно понять причины состояния стартапа. Это важно не только в случаях плохих показателей, но и когда дела идут хорошо.<\/p>\n<blockquote>\n<p>? <i>Например, продуктом пользуются все больше пользователей и он приносит больше денег. Однако на вопрос, что послужило причиной этого роста, владельцы продукта часто отвечают: мы сделали много изменений в прошлом месяце, они сработали. Необходима более точная оценка каждого действия.<\/i><\/p>\n<\/blockquote>\n<p>Инвесторы часто требуют финансовые прогнозы. Эти прогнозы не имеют особого смысла в условиях сильной неопределенности. Совместно с подсчетом базовых финансовых показателей нужно <b>учитывать инновации<\/b> — эффективность каждого изменения.<\/p>\n<p><b>Учета инноваций<\/b> основывается на двух принципах:<br \/>\n— проводить эксперименты последовательно, чтобы разделять их результаты;<br \/>\n— использовать когортный анализ — обобщать данные пользователей определенной версии продукта и отделять их от данных пользователей других групп, пришедших на другую версию продукта.<\/p>\n<p>Для успешного учета инноваций стоит:<br \/>\n— правильно настроить метрики. Стоит опасаться «показателей тщеславия» — абсолютных величин, которые имеют у стартапов роста по экспоненте с определенного момента. Большее число платящих пользователей — это хорошо, но если доля таких пользователей в общем объеме сокращается, это говорит о проблемах продукта;<br \/>\n— сделать отчеты максимально понятными для всех;<br \/>\n— обеспечить доверие сотрудникам отчетам;<br \/>\n— настроить процесс разработки пользовательских историй:<\/p>\n<blockquote>\n<p>— история может находиться на одной из стадий канбан: исходные данные, создание, завершение (техническое), проверка. При этом каждый список канбан должен хранить ограниченное число задач для соблюдения правила независимого тестирования историй (не более трех одновременно);<br \/>\n— ни одна пользовательская история не считается завершенной до тех пор, пока не получено подтверждение фактами.<\/p>\n<\/blockquote>\n<h2>4. ВИРАЖ<\/h2>\n<p>Если стартап не работает или застрял в «долине живых мертвецов» (улучшения есть, но они очень незначительные, не соответствуют вкладываемым усилиям, <b>главное<\/b> — не соответствуют прогнозным показателям по числу пользователей, выручке и т. п.), то стоит задуматься о вираже — изменении одного или нескольких параметров проекта.<\/p>\n<blockquote>\n<p>«Вираж — это стратегическая гипотеза»<\/p>\n<\/blockquote>\n<p>На вираж сложно решиться:<br \/>\n— «показатели тщеславия» могут вводить в заблуждение, что все хорошо — база пользователей растет, они активируют продукт;<br \/>\n— невозможно оценить текущее состояние, потому что в проект не были заложены ожидаемые показатели;<br \/>\n— вираж — это фиксация того, что прежде проект развивался по ошибочному пути.<\/p>\n<p>Встречи с повесткой по виражу компании стоит проводить периодически. На эти встречи приглашайте разработчиков и высшее руководство.<\/p>\n<p>Большинство сделавших вираж сожалеют, что не сделали его раньше.<\/p>\n<p>Виды виражей:<br \/>\n— увеличение: вывод опции продукта в отдельный продукт;<br \/>\n— уменьшение: продукт становится одной из опций многофункционального продукта;<br \/>\n— сегмента потребителей: переориентировка на новую целевую аудиторию;<br \/>\n— потребности клиентов: переориентация на новые проблемы целевой аудитории;<br \/>\n— платформы: переход от приложения к платформе (набору приложений) и обратно;<br \/>\n— бизнес-архитектуры: переход от продаж высокомаржинальных продуктов для узкой аудитории к низкомаржинальным продуктам большой аудитории и наборот;<br \/>\n— способа монетизации: например, отказ от агрессивной мотивации в пользу большей ценности для клиента;<br \/>\n— механизма роста: переход между разными механизмами роста — вирусным, липким, оплаченным;<br \/>\n— канала сбыта;<br \/>\n— технологии: как правило, низкорисковые виражи с целью повышения эффективности работы стартапа.<\/p>\n<h2>5. РАБОТА СТАРТАПА<\/h2>\n<p>Сама простая формула для перехода к формату бережливого производства: какие наши действия приводят к росту ценности, какие приводят к потерям.<\/p>\n<h3>Поток единичных изделий<\/h3>\n<p>Подход <b>потока единичных изделий<\/b> — перевод по произодственному циклу продуктов по одному, а не партиями.<\/p>\n<blockquote>\n<p>? <i>Пример. Допустим, вам нужно подготовить к отправке 100 конвертов: наклеить марку, написать адрес, вложить письмо с печатью. Разумный подход — сначала поставить печати на всех письмах, потом вложить все в конверты и т. п. Специализация должна сократить затраты. Это работает в условиях определенности. В условиях неопределенности по-другому: письмо может не влезть в конверт и об этом мы узнаем только после простановки печати на всех. Кроме того, при специализации постоянно присутствует большой объем незавершенного производства.<\/i><\/p>\n<\/blockquote>\n<blockquote>\n<p>? <i>Пример. Вам как инженеру-конструктору нужно сделать 30 отдельных рабочих чертежей. Подход больших партий — самостоятельно составить все чертежи и отдать на проверку. Он нехорош тем, что коллеги будут потом постоянно отвлекать с вопросами. Лучше выдавать чертежи по одному или смысловыми группами.<\/i><\/p>\n<\/blockquote>\n<p>В случае со стартапом поток единичных изделий гарантирует минимальные затраты в случае, если продукт окажется не нужен людям. Это относится в том числе и к поставке программного обеспечения крупными релизами — лучше мелкие постоянные изменения.<\/p>\n<h3>Модель роста<\/h3>\n<p>У стартапа должна быть модель роста — устойчивого привлечения новых пользователей.<\/p>\n<p>У хороших стартапов работает правило:<\/p>\n<blockquote>\n<p><i>Новые клиенты приходят благодаря действиям клиентов, которые пришли раньше.<\/i><\/p>\n<\/blockquote>\n<p>Это выражается в четырех направлениях:<br \/>\n— сарафанное радио: текущие клиенты рассказывают друзьям о сервисе;<br \/>\n— побочный эффект: пользователи продвигают стартап, не подозревая об этом. Если вы носите модную одежду, вы привлекаете интерес других людей; отправляя деньги кому-то через PayPal вы ему сообщаете о том, что пользуетесь этим сервисом;<br \/>\n— реклама: прибыль от действующих пользователей позволяет давать рекламу для привлечения новых пользователей; считается, что на рекламу стоит тратить именно прибыль от уже действующей части продукта;<br \/>\n— повторные покупки\/повторное обращение.<\/p>\n<p>Есть три механизма роста:<br \/>\n— механизм «липкого» роста: расчет на то, что пользователи будут приносить деньги на протяжении длительного периода времени. Если коэффициент роста выше коэффициента потерь потребителей, значит все ок.<\/p>\n<blockquote>\n<p>?<i>Примеры таких стартапов — сайт по продаже коллекционных товаров, IT-продукт по подписке.<\/i><\/p>\n<\/blockquote>\n<p>— механизм «вирусного» роста. Вирусный коэффициент показывает эффективность: если он равен одному, каждый клиент за определенный период приведет одного друга. Часто монетизация таких продуктов основывается на рекламе, чтобы не брать деньги с пользователей и тем самым не снижать значение коэффициента.<\/p>\n<blockquote>\n<p>?<i>Примеры таких стартапов — Tupperware, Hotmail (подпись — заведите бесплатную почту).<\/i><\/p>\n<\/blockquote>\n<p>— механизм оплаченного роста. Покупка новых пользователей за счет рекламных действий и продаж.<\/p>\n<p>Каждый механизм роста <b>требует своего набора метрик для отслеживания эффективности работы<\/b>. Вирусные метрики бесполезны в модели липкого роста и наоборот. Конечно, у компании могут параллельно работать все механизмы. Однако лучше сосредоточиться на одном и правильно его измерять.<\/p>\n<h3>Адаптивность<\/h3>\n<p>Хорошая способность стартапа — адаптироваться к условиям, то есть корректировать процессы и действия в соответствии с текущей ситуацией.<\/p>\n<blockquote>\n<p>? <i>В компании Эрика IMVU сначала не думали о программе обучения новых сотрудников. Однако ее разработали и получили отличные результаты.<\/i><\/p>\n<\/blockquote>\n<p>В этом помогает метод «Пяти почему?» С его помощью вы выйдете на истинную причину проблемы.<\/p>\n<blockquote>\n<p>? <i>Пример 5 почему?<\/i><\/p>\n<\/blockquote>\n<p><i>В новой версии оказалась отключена одна из опций. Почему? Потому что возникли неполадки на одном из серверов.<\/i><\/p>\n<blockquote>\n<p>Почему возникли неполадки на сервере? Потому что какая-то из подсистем использовалась неправильно.\/\/<br \/>\nПочему она использовалась неправильно? Работавший с ней разработчик не знал, как это нужно делать.\/\/<br \/>\nПочему он этого не знал? Потому что его не обучили.\/\/<br \/>\nПочему его не обучили? Его руководитель не считает нужным обучать новых сотрудников, потому что он сам и члены его команды «очень заняты».\/\/<\/p>\n<\/blockquote>\n<p>Зная причины на каждой из стадий можно рационально распределить ресурсы для их «починки».<\/p>\n<p>Метод 5 почему не должен перерастать в метод пяти обвинений. Для этого на встрече должны присутствовать все, кого касается проблема. Полезно назначить специалиста по пяти почему.<\/p>\n<p>Этот метод плохо подходит для решения хронических и глобальных проблем.<\/p>\n",
            "date_published": "2020-01-25T12:15:00+03:00",
            "date_modified": "2021-05-28T15:34:02+03:00",
            "_date_published_rfc2822": "Sat, 25 Jan 2020 12:15:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "32",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "27",
            "url": "https:\/\/anton-lipatov.ru\/all\/pm101\/",
            "title": "Product Management 101",
            "content_html": "<p>В университетах США есть традиция нумеровать курсы в пределах направления. Номер 101 — так часто обозначают вводный курс для новичков.<\/p>\n<p>В статье перечислю перечислил то, из чего состоит управление продуктом (PM). Этот список не может быть одним общепринятым и полным. Воспринимайте его как набор терминов, отправную точку для дальнейшего исследования.<\/p>\n<p><a href=\"\/all\/pm101\/#plc\">Часть 1. Жизненный цикл продукта (PLC)<\/a><br \/>\n<a href=\"\/all\/pm101#ideas\">Часть 2. Идеи (Ideas & User Needs)<\/a><br \/>\n<a href=\"\/all\/pm101#competitors\">Часть 3. Анализ конкурентов и рынка (Competitors & Market analysis)<\/a><br \/>\n<a href=\"\/all\/pm101#custdev\">Часть 4. Развитие на клиентах (Customer Development)<\/a><br \/>\n<a href=\"\/all\/pm101#mvp\">Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)<\/a><br \/>\n<a href=\"\/all\/pm101#conceptualizing\">Часть 6. Моделирование (Conceptualizing)<\/a><br \/>\n<a href=\"\/all\/pm101#metrics\">Часть 7. Метрики (Metrics)<\/a><\/p>\n<p>По тексту есть ссылки на отдельные методы, подходы, фреймворки.<\/p>\n<p>Даны термины на английском языке. Раньше я не любил включать иностранные слова в русскую речь. Но дело в том, что англоязычные эквиваленты как раз общеприняты. Если вы скажете user story, epic то и вы поймете, о чем речь, и ваш собеседник тоже. Русские эквиваленты (истории пользователей, эпики) не так однозначно понимаемы.<\/p>\n<p><br\/><\/p>\n<p><a name=\"plc\"><\/a><\/p>\n<h2>Часть 1. Жизненный цикл продукта (PLC)<\/h2>\n<h3>Жизненный цикл продукта (Product Life Cycle, PLC)<\/h3>\n<p>PLC часто представлен как последовательность 4-х стадий. Каждая из стадий отличается своими особенностями с точки зрения развития продукта и его маркетинга.<\/p>\n<p><nohtml>1.<\/nohtml> Внедрение на рынок (Introduction): продвижение среди инноваторов, проверка конкурентных преимуществ, работа в минус.<\/p>\n<p><nohtml>2.<\/nohtml> Рост (Growth): рост за счет притока новых бесплатных пользователей, увеличение маржинальности, увеличение рекламных бюджетов и их ориентация на более широкую аудиторию.<\/p>\n<p><nohtml>3.<\/nohtml> Зрелость (Maturity): сокращение прироста, отстройка от конкурентов, рост стоимости новых потребителей.<\/p>\n<p><nohtml>4.<\/nohtml> Спад (Decline): сокращение продаж, прекращение работы или переход в нишевой сегмент.<\/p>\n<h3>Процесс разработки продукта (New Product Development, NPD)<\/h3>\n<p>NPD включает 7 стадий.<\/p>\n<p><nohtml>1.<\/nohtml> Задумка (Conceive). Это исследовательский этап, на котором собираются проблемы пользователей, а также идеи по их решению.<\/p>\n<p><nohtml>2.<\/nohtml> План (Plan \/ Research). Проводится исследование рынка и конкурентов, определяются гипотезы по параметру продукта, проводятся интервью пользователей.<\/p>\n<p><nohtml>3.<\/nohtml> Разработка (Develop \/ Execute). Записываются требования к продукту, таймлайн, пишутся user stories и технические спецификации. Итогом становится минимально жизнеспособный продукт (Minimal Viable Product, MVP).<\/p>\n<p><nohtml>4.<\/nohtml> Валидация (Iterate \/ Qualify \/ Validate). MVP проверяется на реальных пользователях и получение обратной связи от них. Разработка версии для бета- и альфа-тестирования.<\/p>\n<p><nohtml>5.<\/nohtml> Запуск (Launch). Разрабатывается стратегия Go-To-Market (GTM), объединяющая усилия разных служб (маркетинг, продажи, PR, финансисты, юристы) по представлению продукта пользователям.<\/p>\n<p><nohtml>6.<\/nohtml> Продажи (Steady State \/ Deliver \/ Post Launch). Продукт дорабатывается в соответствии с обратной связью пользователей, выводы делаются на основании метрик; работа маркетинга и продаж.<\/p>\n<p><nohtml>7.<\/nohtml> Maintain OR Kill \/ Retire. Принятие решение на основании данных о дальнейшей поддержке или закрытии продукта.<br \/>\n<br\/><br \/>\n<a name=\"ideas\"><\/a><\/p>\n<h2>Часть 2. Идеи (Ideas & User Needs)<\/h2>\n<h3>Сбор идей<\/h3>\n<p>Сбор идей происходит на разных стадиях развития продукта: в момент планирования, создания MVP, поддержки уже готового продукта. Распространенные источники идей собраны в аббревиатуру <b>EMUC<\/b> (Employees, Metrics, Users, Clients), то есть сотрудники, показатели, пользователи, клиенты.<\/p>\n<blockquote>\n<p>?Отличие пользователей от клиентов в том, что пользователи непосредственно работают с продуктами (например, SMM-менеджер с агрегатором статистики), а клиент оплачивает использование продукта (руководитель отдела маркетинга). У этих двух категорий могут быть разные оценки продукта и идеи по улучшению.<\/p>\n<\/blockquote>\n<h3>Оценка идеи<\/h3>\n<p>Не все идеи достойны того, чтобы быть принятыми в работу. При анализе идеи полезно задать вопросы:<br \/>\n— А это на самом деле проблема?<br \/>\n— Не будет ли негативных побочных эффектов?<br \/>\n— Действительно ли идея решит потребность пользователя?<\/p>\n<h3>Оценка идеи 2<\/h3>\n<p>Альтернативный и дополняющий подход состоит в том, что хорошая идея приводит к одному или нескольким позитивным результатам:<br \/>\n— Рост числа пользователей<br \/>\n— Рост удовлетворенности пользователей<br \/>\n— Усиление бренда<\/p>\n<p><br\/><br \/>\n<a name=\"competitors\"><\/a><\/p>\n<h2>Часть 3. Анализ конкурентов и рынка (Competitors & Market analysis)<\/h2>\n<h3>Оценка рынка<\/h3>\n<p>Оценка рынка не обязательно должна быть точной, но хорошая оценка верно отражает порядок, а самое главное — динамику.<\/p>\n<p>Объем рынка, на который выводится продукт, можно оценивать «сверху» (Top Down) и «снизу» (Bottom Up).<\/p>\n<p>Оценка сверху отталкивается от расчета возможного спроса, емкости.<\/p>\n<blockquote>\n<p>?<i>Пример. Для оценки рынка мужской обуви в РФ можно идти от того, что мужчины составляют треть населения страны (50 млн чел.) и покупают новую пару раз в год — 50 млн пар обуви в год. Дальше можно уточнять по демографии, виду продукции и т. п.<\/i><\/p>\n<\/blockquote>\n<p>Оценку снизу получают суммированием известных показателей участников рынка.<\/p>\n<blockquote>\n<p>?<i>Если в России работают пять производителей мужской обуви, каждый производит по 10 млн пар в год, то при условии нулевой внешней торговли и нулевых складских запасов получается та же оценка — 50 млн пар в год.<\/i><\/p>\n<\/blockquote>\n<h3>Поиск конкурентов<\/h3>\n<p>Если у вашего продукта нет конкурентов, то это признак того, что:<br \/>\n— нет спроса на продукт или сервис,<br \/>\n— анализ проведен недостаточно хорошо и вы искали только прямых конкурентов и забыли про косвенных, потенциальных и конкурентов с «продуктами-заменителями»;<br \/>\n— вы нашли свой голубой океан ?.<\/p>\n<p>Кроме прямых (предлагают схожий продукт) на рынке могут быть следующие группы конкурентов:<br \/>\n— <b>косвенные<\/b>. Их продукт решает те же проблемы пользователей, но иным способом и\/или для иной целевой аудитории;<br \/>\n— <b>потенциальные<\/b>. Работают с вашей целевой аудиторией, но решают другие проблемы... пока;<br \/>\n— конкуренты с <b>продуктами-заменителями<\/b>. Решают те же проблемы, но иным способом.<\/p>\n<blockquote>\n<p>?<i>Для нового сервиса каршеринга прямыми конкурентами будут Яндекс Драйв, Делимобиль; косвенными — службы такси, доставки городского транспорта.<\/i><\/p>\n<\/blockquote>\n<h3>Оценка конкурентов<\/h3>\n<p>Один из возможных подходов к оценке компаний-конкурентов:<\/p>\n<p>— насколько хороша продуктовая команда;<br \/>\n— число пользователей;<br \/>\n— качество дизайна (в широком смысле, включая UX);<br \/>\n— бренд;<br \/>\n— скорость изменений.<\/p>\n<p>По каждому параметру конкуренту присваивают оценку. Шкала может быть какой угодно (от 0 до 5, от 0 до 10 и т.д). Итоговая оценка — это сумма оценок по пяти параметрам.<\/p>\n<h3>Таблица свойств (Feature Table)<\/h3>\n<p>По аналогии с оценкой конкурентов оценивают их продукты. Это делают с помощью таблицы свойств (Feature Table). В таблице принято откладывать по горизонтали сравниваемые компании, по вертикали — сравниваемые свойства. На основании сравнения, задав веса свойствам можно получить суммарную оценку продуктов конкурентов.<br \/>\n<br\/><br \/>\n<a name=\"custdev\"><\/a><\/p>\n<h2>Часть 4. Развитие на клиентах (Customer Development)<\/h2>\n<p>Концепцию <b>Customer Development<\/b> предложил Стив Бланк (S. Blank). Это подход к построению продукта, в соответствии с которым от клиентов и пользователей постоянно получается обратная связь: идеи, гипотезы, пожелания. Акцент именно на постоянном характере обратной связи.<\/p>\n<p>В этом фреймворке разработка продукта, а скорее уже процесс создание стартапа на основе продукта, состоит из четырех циклов:<br \/>\n<nohtml>1.<\/nohtml> Исследование (Customer Discovery). Определить целевую аудиторию и понять важность решаемой задачи для них. Разработать сценарий MVP<br \/>\n<nohtml>2.<\/nohtml> Подтверждение (Customer Validation). Построение стандартного процесса продаж и первые продажи ранним адептам. Если модель не подтверждается деньгами, то возможен возврат на предыдущую стадию Исследования.<br \/>\n<nohtml>3.<\/nohtml> Создание (Customer Creation). Расширение бизнеса за счет увеличения рекламы, действия реферальных программ.<br \/>\n<nohtml>4.<\/nohtml> Построение (Company Building). Создание формализованной компании.<\/p>\n<h3>Виды интервью<\/h3>\n<p>Разделение на виды очень условно. В пределах одного интервью могут быть вопросы разного характера. Интервью до выпуска продукта (pre-product) серьезно отличаются от интервью после выпуска (post-product).<\/p>\n<p><nohtml>1.<\/nohtml>Исследовательское (Exploratory). Наиболее свободное по форме интервью: открытые вопросы для того, чтобы понять боли, контекст использования продукта, конкурирующие продукты и технологии и уйти с интервью с новыми идеями.<\/p>\n<p><nohtml>2.<\/nohtml> Подтверждающее (Validation). Целью является подтверждение или опровержение гипотезы. В ходе интервью нужно стараться объективно понять особенности поведения респондента, не подталкивая его к желаемому ответу. Озвучить решение проблемы можно в завершении, также важно получить объективную оценку.<\/p>\n<p><nohtml>3.<\/nohtml> Оценка удовлетворенности (Satisfaction oriented). В чем продукт хорош, а в чем плох.<\/p>\n<p><nohtml>4.<\/nohtml> Эффективность (Efficiency interview). Здесь обратная связь используется для изменения продукта с целью повышения выбранных показателей эффективности (с точки зрения бизнеса, клиентов)<br \/>\n<br\/><br \/>\n<a name=\"mvp\"><\/a><\/p>\n<h2>Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)<\/h2>\n<p>Термин <b>MVP<\/b> (Minimal Viable Product, MVP) был предложен Эриком Ризом (E.Ries) во фреймворке Lean Startup. MVP — это такая версия продукта, которая позволяет собрать максимальный объем данных от пользователей при минимальных затратах.<\/p>\n<blockquote>\n<p>?Хорошая практика: за один MVP тестировать один функционал. Если одновременно тестируете несколько функционалов, нужно понимать, как эти тесты могут повлиять друг на друга.<\/p>\n<\/blockquote>\n<p>Подготовка MVP состоит из семи шагов:<\/p>\n<h3>Шаг 1. Определить, в чем состоит боль\/потребность потребителей.<\/h3>\n<h3>Шаг 2. Зафиксировать принятые допущения.<\/h3>\n<p>Допущения удобно фиксировать в формате «Продукт будет успешен при условии, что... ». Например, «...при условии, что у моих потенциальных клиентов есть потребность x, за которую они готовы заплатить z, и при этом нет сильных альтернатив».<\/p>\n<p>Допущения ранжируют по <b>степени влияния на продукт<\/b>, то есть, насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным. Обычно самое рисковое допущение — предположение о наличии потребности у потенциального клиента.<\/p>\n<p>Второй измерение для ранжирования — сложность проверки допущения.<\/p>\n<p>На основании комбинации риск-сложность определяют приоритет проверки допущений через MVP:<br \/>\n— Большой риск — Маленькие затраты<br \/>\n— Большой риск — Большие затраты<br \/>\n— Маленький риск — Маленькие затраты<br \/>\n— Маленький риск — Большие затраты (обычно не проверяют)<\/p>\n<h3>Шаг 3. Сформулировать гипотезы.<\/h3>\n<p>Для проверки в MVP допущения должны быть переведены на язык гипотез. Гипотеза — это письменно зафиксированное утверждение, которое можно подтвердить или опровергнуть результатами теста. Варианты формулировки гипотез (от худшего к лучшему):<\/p>\n<p>a. Мы думаем, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).<br \/>\nb. Если мы (действие), то это приведет к тому, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).<br \/>\nс. Мы думаем, что (пользователь цель) имеют (боль, потребность), потому что (причина). Если мы (действие), это приведет к тому, что метрика (ожидаемое состояние).<\/p>\n<p>Во всех случаях причины лучше описывать в терминах болей и потребностей; хуже — в терминах ценностей и преимуществ.<\/p>\n<h3>Шаг 4. Зафиксировать минимальный порог успеха (Minimal Criteria for Success, MCS).<\/h3>\n<p>10% результатов экспериментов носят однозначно бинарный характер: мы провели эксперимент и наша гипотеза однозначно подтвердилась или однозначно не подтвердилась.<\/p>\n<p>В 90% случаев результат где-то посередине, поэтому нужно фиксировать MCS — рубеж, по достижению которого гипотеза будет считаться принятой.<\/p>\n<p>Этот рубеж опирается на одну или несколько метрик. Как правило, в качестве MCS стараются выбирать такую точку, начиная с которой потенциальный доход превышает ожидаемые затраты на разработку.<\/p>\n<p>Метрикой может быть процент пользователей, выполнивших действие, или соответствующих определенным условиям (провели в приложении столько-то времени, просмотрели столько-то страниц).<\/p>\n<h3>Шаг 5. Выбрать тип MVP-эксперимента.<\/h3>\n<p>Протестировать интерес пользователей в цифровой среде можно разными способами.<\/p>\n<p>— Email-анонс. Разослать письма с анонсом нового функционала и собрать обратную связь<br \/>\n— Кнопка (Shadow Button). Разместить на сайте кнопку для доступа к новому функционалу и отслеживать клики. Клики могут переводить на страницу «Скоро».<br \/>\n— 404 \/ Скоро (Coming soon). При интересе пользователя и переходе пользователя на страницу нового функционала показывать сообщение о скором создании раздела.<\/p>\n<blockquote>\n<p>? Так часто делает Amazon.<\/p>\n<\/blockquote>\n<p>— Видео (Explainer video). В видео рассказать о новом функционале и выгодах для пользователя.<\/p>\n<blockquote>\n<p>? Так стартовал Dropbox.<\/p>\n<\/blockquote>\n<p>— Лендинг (Landing page). Аналогично видео, но рассказать о преимуществах функционала на отдельной странице.<br \/>\n— Консьерж (Concierge service). В случае интереса пользователя прикрепленный менеджер помогает пользователю выполнить те действия, которые потом будут реализованы в функционале.<br \/>\n— Частичный MVP (Piecemeal). Часть функциональности MVP закрывается с помощью существующих сервисов автоматизации, таких как Google Docs, Zapier и проч.<br \/>\n— Волшебник Изумрудного города (Wizard of Oz). Продукт притворяется, в то время как все действия новой функциональности выполняются вручную.<\/p>\n<p><a href=\"\/all\/mvp\">Типы MVP-экспериментов — подробное описание<\/a>  (скоро)<\/p>\n<h3>Шаг 6. Провести MVP-эксперимент.<\/h3>\n<h3>Шаг 7. Подвести итоги и сделать выводы.<\/h3>\n<p>MVP возвращают численные результаты. Для этого в начале допущения переводили в форму гипотез. На их основании данных PM принимают решение о том, стоит ли делать тот или иной функционал.<\/p>\n<blockquote>\n<p>?Хорошая практика: дополнить численные результаты качественными данными из интервью. Чтобы понять, почему пользователи сделали так, а не по-другому.<\/p>\n<\/blockquote>\n<p><br\/><br \/>\n<a name=\"conceptualizing\"><\/a><\/p>\n<h2>Часть 6. Моделирование (Conceptualizing)<\/h2>\n<p>Тут все несложно. Самое главное — принято различать три уровня моделей. Их лучше не путать.<\/p>\n<p>Схема (Wireframe) — схематический рисунок, в котором картинки обозначаются перечеркнутыми прямоугольниками, рыбный текст, показано существование и размещение блоков. По мере обсуждения функционала команды уточняют схемы. Схемы обычно делает PM.<\/p>\n<p>Как составить схему:<br \/>\n— нарисовать браузер;<br \/>\n— в браузере нарисовать лого и основное навигационное меню;<br \/>\n— понять цель страницы;<br \/>\n— выписать сценарии, которые пользователи проходят на странице;<br \/>\n— добавить на страницу элементы.<\/p>\n<p>Мокап (Mockup) — схема в цвете. В мокапе уже фиксируются места элементов и добавляются элементы дизайна. Точность мокапа выше, чем у схемы.<\/p>\n<p>Прототип (Prototype) — модель, цель которой показать, как пользователь будет взаимодействовать с продуктом. Это самая точная модель, после согласования идет на разработку.<\/p>\n<blockquote>\n<p>?Взаимодействие с продуктом может быть показано уже на схеме.<\/p>\n<\/blockquote>\n<p><br\/><br \/>\n<a name=\"metrics\"><\/a><\/p>\n<h2>Часть 7. Метрики (Metrics)<\/h2>\n<p>Метрики показывают, что происходит с продуктом, они свидетельствуют о достижении целей, а также дают базу для проведения экспериментов. Важные метрики входят в число KPI (Key Performance Indicator).<\/p>\n<p>Метрики принято разделять:<\/p>\n<p>— Метрики роста (Growth&Activation). Они показывают рост вашего продукта.<br \/>\nПримеры: число новых пользователей, их структура по источнику трафика, число активаций (пользователей, которые не только установили приложение, но и зарегистрировались и выполнили определенные действия).<\/p>\n<p>— Метрики удержания (Retention). Показывают, как часто пользователи возвращаются к продукту.<br \/>\nПримеры: число пользователей ежедневно использующих продукт, восстановленные пользователи (не использовали некоторое время, но вернулись)<\/p>\n<p>— Метрики вовлечения (Engagement). Показывают, насколько пользователи привязаны к продукту.<br \/>\nПримеры: среднее число визитов, проведенное время, страниц за сессию, число написанных постов или социальных действий.<\/p>\n<p>— Метрики счастья (Happiness). Показывают удовлетворенность пользователей<br \/>\nПримеры: NPS, число жалоб, рейтинг в сторах.<\/p>\n<p>— Денежные метрики (Revenue). Показывают, сколько продукт зарабатывает.<br \/>\nПримеры: LTV, стоимость привлечения новых пользователей, месячный постоянный доход (Monthly recurring revenue, MRR), годовой постоянный доход (Annual recurring revenue, ARR)<\/p>\n<p>Метрики бывают:<br \/>\n— Исследовательские метрики (Exploratory). Показывают специфическую информацию, важную в определенный момент времени. Например, это метрики, связанные с экспериментами (стоимость привлечения и уровень вовлеченности в определенный раздел продукта). Список исследовательских метрик гибкий, он периодически обновляется.<br \/>\n— Отчетные метрики (Reporting). Стабильный список глобальных метрик, по которым из месяца в месяца оценивается динамика продукта.<\/p>\n<blockquote>\n<p>? Хорошие отчетные метрики:<br \/>\n— понятны, однозначны;<br \/>\n— <b>представляют собой относительную или среднюю величину<\/b>, не абсолютны (пользователи за день, процент довольных пользователей и т. п.);<br \/>\n— не взаимосвязаны между собой (нет смысла одновременно мерить число визитов за день и за месяц);<br \/>\n— учитывают внешние факторы и их можно улучшить (бесполезно работать над длительностью сессии, если у характерного пользователя есть только 2 часа в день на работу с продуктом)<br \/>\n— относятся к «причинным» метрикам, реже следствиям. Причинная метрика — баланс калорий за день, следственная — изменение веса.<\/p>\n<\/blockquote>\n<p>По фреймворку HEART работа над созданием метрик выглядит следующим образом:<br \/>\n— определяете, что хотите измерить. Например, денежные метрики (обычно одна из групп того или иного фреймворка);<br \/>\n— определяете цель, чего конкретно хотите добиться.  Например, увеличить выручку и продавать больше;<br \/>\n— определяете сигналы; по сигналам можно определить, что цели достигаются. Увеличение числа заказов и рост выручки;<br \/>\n— определяете метрику. Метрика показывает, как измерить сигнал. Среднее число заказов в день на пользователя, средняя выручка за день.<\/p>\n<blockquote>\n<p>? Пример: составить метрику, связанную с удовлетворенностью пользователей.<br \/>\n— Цель: обеспечить максимальную удовлетворенность от продукта и сервиса;<br \/>\n— Сигналы: рейтинг в сторе, оценки NPS.<br \/>\n— Метрики: динамика NPS к предыдущему месяцу; число оценок 10 при опросе NPS.<\/p>\n<\/blockquote>\n<p><br\/><\/p>\n<h2>Часть 8. Создание продукта<\/h2>\n<h3>Пирамида продукта<\/h3>\n<p>Части пирамиды продукта:<br \/>\n— Глобальное видение отрасли (Global vision) — живая картинка будущего отрасли;<br \/>\n— Видение компании (Company Vision) — место компании в будущем отрасли с учетом глобального видения;<br \/>\n— Цели (Goals) — видение компании, описанное метриками;<br \/>\n— Инициативы (Initiatives) — крупные направления, которые помогут достичь намеченных целей;<br \/>\n— Элементы бэклога (Product Backlog Items): Релизы (Releases) \/ Эпики (Epics) \/ Фичи (Features) \/ Темы (Themes) \/ Пользовательские истории (User Stories \/ Tasks) \/ Баги (Bugs). В описании Scrum задачи, связанные с разработкой продукта, называются элементами бэклога. Такой подход позволяет каждой команде по-своему создавать свою структуру задач и направлений. У кого-то это только эпики и истории, у кого-то релизы, фичи и истории. Однако большинство команд используют пользовательские истории.<\/p>\n<p><a href=\"\/all\/kak-pisat-polzovatelskie-istorii-user-stories\/\">Как писать User Stories<\/a><\/p>\n<h3>Спецификации<\/h3>\n<p>Спецификации пишут на крупные задачи (эпики). Их пишут простым языком, чтобы любой сотрудник мог понять их суть. Состав спецификации:<\/p>\n<ol start=\"1\">\n<li>Введение. Во введении указывают:<br \/>\n- — какие фичи входят в эпик и почему решено их реализовать;<br \/>\n- — на какие метрики повлияют изменения;<br \/>\n- — ссылки на дополнительные документы;<br \/>\n- — согласование эпика с планом маркетинга, юридические тербования;<br \/>\n- — схемы.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Требования к продукту (Product requirements). Какие изменения должны произойти в продукте, чтобы эпик считался успешным.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li>Требования к дизайну (Design requirements). Специфические ограничения по дизайну: использование гайдов, UI-китов и т. п.<\/li>\n<\/ol>\n<ol start=\"4\">\n<li>Требования к разработке (Engineer requirements). Что должно быть сделано с точки зрения бэкенда и фронтэнда.<\/li>\n<\/ol>\n<h3>Оценки<\/h3>\n<p>Оценки в IT сложно давать, поскольку каждая новая задача уникальна. Из SCRUM пришел подход, связанный с оценкой в условных и абстрактных единицах — очках (story point).<\/p>\n<p>На покере планирования (planning poker) команда присваивает пользовательским историям оценку в очках. Со временем команда понимает, сколько очков она способна в среднем закрыть за один спринт. Допустим, вы знаете «скорость» разработки. С этим знанием вы сможете более уверенно набирать задачи на спринт в пределах этого объема, и у вас будет большая уверенность, что они будут выполнены.<\/p>\n<h3>Приоритеты<\/h3>\n<p>Некоторые способы расставить приоритеты пользовательским историям\/фичам\/эпиками.<\/p>\n<p><nohtml>1.<\/nohtml> <b>«Допущения + Важность»<\/b><br \/>\nМетод похож на описанный <a href=\"all\/pm101#mvp\">в разделе про MVP <\/a> способ расставить приоритеты допущениям. А именно мы закрываем первыми такие истории, которые позволяют проверить наиболее рисковые допущения и которые одновременно мы считаем важными для пользователей. Таким образом для каждой истории мы ставим оценку от 1 до 5 или 10 по критериям:<\/p>\n<p>— насколько велик риск допущения, которое связано с историей. Напомню, что риск допущения — это насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным<\/p>\n<blockquote>\n<p>? <i>У нас осталось непроверенным допущение, что люди пожилого возраста будут пользоваться нашим облачным фотохранилищем. Мы рассчитываем на эту аудиторию, поэтому истории, в которой пользователь может использовать номер пенсионного удостоверения для скидки, дадим 10 баллов по допущениям<\/i><\/p>\n<\/blockquote>\n<p>— насколько важна задача с точки зрения бизнеса, пользователей.<\/p>\n<p>Суммируя две оценки получаем одно число. Чем оно выше, тем быстрее истории уходит в разработку.<\/p>\n<p><nohtml>2.<\/nohtml> <b>BUC (Business, Users, Costs)<\/b><br \/>\nМетод также дает одну оценку. Она складыается из трех факторов, которые оцифровываются по любой шкале (1-5, 1-10):<br \/>\n— выгоды бизнеса: рост выручки, упрощение процессов, привлечение новых пользователей;<br \/>\n— выгоды пользователей: удобство использования, дополнительный функционал;<br \/>\n— затраты: насколько сложно историю закрыть.<\/p>\n<p>В результате число получается сложением выгод и вычитанием затрат.<\/p>\n<p><nohtml>3. <\/nohtml><b>MOSCOW (Must, Should, Could, Would)<\/b><br \/>\nЭтот метод впервые начали применять в 1994 году в Oracle. Истории распределяются по четырем корзинам:<\/p>\n<ul>\n<li>обязательно нужно сделать. Если историю не закрыть, последствия могут быть значимыми негативными.<\/li>\n<li>следует сделать. Не самые важные требования, но которые стоит закрыть после обязательных.<\/li>\n<li>могли бы сделать. Желательные требования, которые сделаем, если останутся ресурсы.<\/li>\n<li>можем и не делать. Требования зафиксированы, но можно их отложить на следующий спринт, поскольку они не повлияют серьезным образом на бизнес или пользователей.<\/li>\n<\/ul>\n",
            "date_published": "2020-01-17T15:20:05+03:00",
            "date_modified": "2021-05-28T15:34:56+03:00",
            "_date_published_rfc2822": "Fri, 17 Jan 2020 15:20:05 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "27",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "31",
            "url": "https:\/\/anton-lipatov.ru\/all\/kak-pisat-polzovatelskie-istorii-user-stories\/",
            "title": "Как писать пользовательские истории  (User Stories, US)",
            "content_html": "<p>Пользовательские истории — это краткие задачи, которые собираются в эпики. На самом деле правильная формулировка US гарантия хорошего результата.<\/p>\n<p>Хороший формат для описания истории —  Three Cs, который предложил Рон Джеффрис (Ron Jeffries) в 2001 году.<\/p>\n<p><b>Как Y (субъект: пользователь, администратор, клиент), я хочу Y (требуемое изменение), чтобы Z (польза или работа с болью).<\/b><\/p>\n<blockquote>\n<p>? <i> Как пользователь, я хочу прикладывать фото к комментариям, чтобы быстро делиться ими с друзьями.<\/i><\/p>\n<\/blockquote>\n<p>Пользу или боль стоит прописывать именно с точки зрения пользы и боли.<\/p>\n<blockquote>\n<p>? <i>Пример<\/i><br \/>\n❌ <i>«Как пользователь соцсети я хочу, чтобы мне напоминали о заполненной и неоформленной корзине, чтобы я мог убрать товары из корзины или подтвердить заказ». <\/i><br \/>\nТут проблема в том, что часть после «чтобы» не объясняет ценность для клиента. Вместо ценности мы описали ожидаемое поведение после того, как функционал будет доступен пользователю.<br \/>\n✔️ <i>Как пользователь соцсети я хочу, чтобы мне напоминали о заполненной и неоформленной корзине, чтобы я не забыл про важный заказ<\/i>.<br \/>\nДополнительно можно добить ожидаемой метрикой:<br \/>\n✔️ <i>Это позволит увеличить на 20% закрытие заказов среди тех, которые не были закрыты в течение 3 часов с момента создания<\/i>.<\/p>\n<\/blockquote>\n<p>К каждой истории стоит прописывать критерии приемки (<b>Acceptance Criteria<\/b>): что должно быть сделано, чтобы считать историю отработанной удачно. Одновременно критерии подсказывают, как тестировать выполнение работ по истории.<\/p>\n<blockquote>\n<p><i>— появляется всплывающее окно для загрузки фото<\/i><br \/>\n<i>— сообщение об ошибке, если файл не проходит по расширению или размеру<\/i><\/p>\n<\/blockquote>\n<p>Фреймворк для составления историй — I.N.V.E.S.T.<\/p>\n<p>— Независимая (Independent) — история не должна зависеть от других, иначе сложно их будет приоритизировать.<br \/>\n— Неточная (Negotiable) — описание допускает разные варианты реализации на усмотрение команды.<br \/>\n— Ценная (Valuable) — запрашиваемые действия будут полезными для пользователей, клиентов.<br \/>\n— Оцениваемая (Estimable) — работы по истории могут быть оценены.<br \/>\n— Небольшая (Small) — для ее реализации хватит спринта.<br \/>\n— Тестируемая (Testable) — можно провести тестирование выполненных работ.<\/p>\n",
            "date_published": "2019-01-19T22:16:00+03:00",
            "date_modified": "2021-05-28T15:36:22+03:00",
            "_date_published_rfc2822": "Sat, 19 Jan 2019 22:16:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "31",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "34",
            "url": "https:\/\/anton-lipatov.ru\/all\/sazerlend-dzheff-scrum-revolyucionny-metod-upravleniya-proektami\/",
            "title": "КНИГИ. Сазерленд Джефф — Scrum. Революционный метод управления проектами. Конспект",
            "content_html": "<p>Слабости каскадного метода:<\/p>\n<ol start=\"1\">\n<li>Слепое планирование. Разумно планировать, но не слепо следовать плану.<\/li>\n<li>Работа без самоанализа. Всегда стоит следить за ходом работать и выявлять, что может быть сделано лучше.<\/li>\n<li>Отложенное нахождение ошибок. Ошибки выявляются на финальной стадии, много времени уделяется ведению документации, хотя продукт должен быть важнее процессов.<\/li>\n<\/ol>\n<p>Scrum основывается на принципе PDCA и некоторых других принципах. Основные предпосылки.<\/p>\n<ol start=\"1\">\n<li>Сомнение смерти подобно. Наблюдать, ориентироваться, решать, действовать. Определите, где вы находитесь, осознайте имеющиеся варианты, сделайте выбор и действуйте!<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Искать ответы вокруг себя. Сложные адаптивные системы следуют нескольким простым правилам, ориентируясь на окружающую среду.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li>Великие коллективы. Многофункциональные, автономные, свободные в принятии решений команды с установкой на совершенствование своих возможностей.<\/li>\n<\/ol>\n<ol start=\"4\">\n<li>Не гадать. Планировать, действовать, проверять, корректировать. Планируйте то, что собираетесь выполнить. Сделайте. Проверьте, соответствует ли это тому, что вы хотели. Корректируйте на основании выявленных ошибок и изменяйте методы работы. Повторяйте цикл регулярно и добивайтесь непрерывного улучшения системы.<\/li>\n<\/ol>\n<ol start=\"5\">\n<li>Сюхари. Осваивайте приемы, движения и правила. Овладев ими, придумывайте свои приемы и движения. Добившись высокого мастерства, откажитесь от правил и просто будьте. Когда все выученное усвоено, решения принимаются автоматически.<\/li>\n<\/ol>\n<h2>Команда<\/h2>\n<ol start=\"1\">\n<li>Ориентирована на поиск совершенства.<\/li>\n<li>Автономна — самоорганизуется и самоуправляется.<\/li>\n<li>Многофункциональна. При этом должности и звания ничего не значат.<\/li>\n<li>Малочисленна. Правило 7 плюс-минус 2.<\/li>\n<li>В команде нет обвинений, нужно искать вредные системы и недостатки в них.<\/li>\n<li>Ориентированы на амбициозные цели.<\/li>\n<\/ol>\n<h2>Время<\/h2>\n<ol start=\"1\">\n<li>Работа спринтами (один спринт — 1-4 недели). В конце каждого спринта обязательно что-то должно быть показано.<\/li>\n<li>Оценка объема работы и прогнозирование.<\/li>\n<li>Ежедневные собрания «на ходу» с тремя вопросами: что делал вчера? что делаешь сегодня? какие есть препятствия?<\/li>\n<li>Информационная насыщенность ускоряет работу.<\/li>\n<\/ol>\n<h2>Потери<\/h2>\n<ol start=\"1\">\n<li>Потери — это преступление. Есть три вида потерь<\/li>\n<\/ol>\n<ul>\n<li>мури — из-за неблагоразумного обращения с ресурсами (помогает избегать планирование);<\/li>\n<li>мура — из-за неравномерного обращения с ресурсами (действовать)<\/li>\n<li>муда — любые процессы, связанные с производственным процессом (проверять).<\/li>\n<\/ul>\n<p>Ключевые виды потерь:<\/p>\n<ul>\n<li>потери, связанные с нанесением ущерба имуществу;<\/li>\n<li>потери из-за неправильного выполнения задания с первого раза. Потери на исправление гигантские.<\/li>\n<li>потери от чрезмерного усердия. Напряженный труд порождает еще больше работы. По кривой Максвелла максимальная производительность в scrum достигается при 30-40 часовой рабочей неделе. У каскадной модели пик несколько правее;<\/li>\n<li>эмоциональные потери, связанные с завышенными ожиданиями. Не браться за все сразу, быть однозадачным. Потери на переключение между пятью проектами — 75%. Сделанное наполовину — не сделанное никогда, поэтому лучше довести одно прежде чем браться за другое.<\/li>\n<\/ul>\n<h2>Планирование<\/h2>\n<p>Проекты несут в себе неопределенность. Стоит планировать определенные вещи, а не неопределенные.<\/p>\n<p>При планировании поможет оценка в относительных единицах: породах собак, числах фибоначчи. Оценки можно получать в ходе «покера планирования», когда все сотрудники оценивают задачу. Важна анонимность для избегания эффекта ореола. Правила покера:<\/p>\n<ul>\n<li>Все оценивают задачу, карточки открываются одновременно. Если расхождения в пределах двух карточек, берется среднее (5, две 8, 13 — 6,6).<\/li>\n<li>Если расхождения большие сотрудники с минимальной и максимальной оценкой объясняют свою позицию. После этого проводится еще один раунд покера.<\/li>\n<\/ul>\n<h2>Истории вместо задач<\/h2>\n<p>Формулировка задачи предполагает, что в ней уже заложен путь ее решения и в ней не хватает информации для решения. Вместо задачи стоит писать клиентские истории.<\/p>\n<blockquote>\n<p><i>Пример. Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.<\/i><br \/>\n<i>Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.<\/i><\/p>\n<\/blockquote>\n<p>Удобно составлять задачи \/ истории \/ эпики должны по принципу INVEST<br \/>\n<a href=\"http:\/\/anton-lipatov.ru\/all\/kak-pisat-polzovatelskie-istorii-user-stories\/\" target=\"_blank\">Подробнее. Как писать User Stories<\/a><\/p>\n<p>Повысить динамику производительности можно, ответив на три вопроса:<\/p>\n<ol start=\"1\">\n<li>Можем ли мы начать делать что-то иначе, чтобы еще ускорить темпы?<\/li>\n<li>Можем мы вычеркнуть что-то из списка заданий? Распределить часть заданий по разным группам?<\/li>\n<li>Может, найдем что-то, что мы могли бы не делать? Можем мы каким-то образом уменьшить объем работ?<\/li>\n<\/ol>\n<h2>Счастье<\/h2>\n<p>Счастье делает нас более производительными и приводит к успеху в любой сфере нашей жизни.<\/p>\n<p>В scrum показатели счастья — качество завершения спринта, число завершенных задач.<\/p>\n<p>А также по завершении спринта каждый участник команды отвечает на вопросы:<\/p>\n<ol start=\"1\">\n<li>Оцените свою роль в компании по шкале от одного до пяти.<\/li>\n<li>Оцените компанию в целом по той же шкале.<\/li>\n<li>Почему вы так считаете.<\/li>\n<li>Назовите вещь, которая может сделать вас счастливее в следующем спринте.<\/li>\n<\/ol>\n<p>Важный фактор для счастья — открытость и доступность, что в том числе выражается в использовании канбан-досок.<\/p>\n<p>Есть опасность излишней самоудовлетворенности и самонадеянности — «пузыря счастья». Поэтому полезно иметь роль «мудрого шута», который будет задавать неприятные вопросы или говорить неудобную правду. «Счастье» должно быть не только своевременным, но и с прицелом на будущее.<\/p>\n<h2>Приоритеты<\/h2>\n<p>Концепция продукта — это пересечение на диаграмме Виенна трех сфер — Что мы можем предложить? Что вы можете продать? Чем вам интересно заниматься?<\/p>\n<p>Приоритеты бэклога:<br \/>\n— имеют самое большое значение для хода работ над проектом;<br \/>\n— важнее всего для заказчика или будущего потребителя;<br \/>\n— принесут максимальный доход;<br \/>\n— проще всего осуществить.<\/p>\n<p>Стоит помнить, что 80% успеха продукта заложены в его 20% возможностей. То, что казалось вам нужным в самом начале, никогда не бывает тем, что вам нужно на самом деле. Стоит создавать только то, что имеет или создает ценность для клиента.<\/p>\n<p>В методологии скрам предусмотрено три роли:<br \/>\n— владелец продукта — ведет и пополняет бэклог, расставляет приоритеты (что делать). Он должен знать продукт и рынок, самостоятельно принимать решения, быть доступным для команды, нести ответственность за полезность продукта.<br \/>\n— скрам-команда;<br \/>\n— скрам-мастер — методологическое обеспечение работы (как делать).<\/p>\n<h2>Быстрый старт в скраме<\/h2>\n<ol start=\"1\">\n<li>Определить владельца продукта.<\/li>\n<li>Определить команду — 3-9 человек.<\/li>\n<li>Выбрать скрам-мастера.<\/li>\n<li>Сделать бэклог продукт (список всех требований). Существует только один бэклог.<\/li>\n<li>Оценить и проиритизировать истории бэклога.<\/li>\n<li>Распланировать спринт с учетом «динамики производительности». Добавлять новые задания в спринт нельзя.<\/li>\n<li>Работа должна быть видимой (скрам-доска). Стоит сделать диаграмму выгорания задач (число закрытых баллов в задачах по дням спринта).<\/li>\n<li>Ежедневные собрания на ходу.<\/li>\n<li>Обзор спринта. Команда рассказывает, что сделано за спринт и демонстрирует готовые асти продукта. На обзоре присутствуют все роли и любые стейкхолдеры. Демонстрируется только то, что окончательно готово.<\/li>\n<li>Рестроспективное собрание. Команда обсуждает, что прошло хорошо, что можно сделать лучше и что можно изменить немедленно.<\/li>\n<li>Начало следующего спринта.<\/li>\n<\/ol>\n",
            "date_published": "2018-10-05T14:24:00+03:00",
            "date_modified": "2021-05-28T15:37:09+03:00",
            "_date_published_rfc2822": "Fri, 05 Oct 2018 14:24:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "34",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 3794,
    "_e2_ua_string": "E2 (v3794; Aegea)"
}