Blog

Юнит экономика

Полезные ссылки

Ultimate Guide to unit economics — Cleverism

Don’t Scale an Unprofitable Business — Toby Clarence-Smith

Терминология юнит экономики – https://khanin.info/blog/93

Блог Ханина – https://www.youtube.com/channel/UCOyUv3CQetbteA73rODD9Wg

Подборка на VC https://vc.ru/finance/48822-gayd-razobratsya-v-yunit-ekonomike-za-odin-den

September 12, 2021
Оценка объема рынка
Объем рынка – это количество денег которые потребители тратят или готовы потратить на удовлетворение своих потребностей в определенном сегменте.
- PAM – Potential Available Market. Все траты всех жителей земли за год на удовлетворения потребности. Например для кока коллы: все кто покупают напитки для удовлетворения жажды.
- TAM – Total Addressable Market. Объем целевого рынка. Траты клиентов, кому интересен мой вид продукта. Включая тех, кто не может себе позволить такую покупку. Для кока коллы: деньги клиентов, которые тратятся на удовлетворение жажды газировкой.
- SAM – Served Available Market. Доступный объем обслуживаемого рынка. Годовой объем денежных средств, которые тратятся на пользование моим продуктом и продуктами конкурентов.
- SOM – Serviceable & Obtainable Market. Реально достижимый объем рынка. Доля рынка моего бизнеса. Траты тех клиентов, кто пользуется моим продуктом + траты тех, кого я планирую привлечь.
Где брать информацию для PAM и TAM?
- Обзоры рынка
- Экспертные оценки в СМИ
- Данные Росстата
- Данные аналитических агенств. Gartner и Frost & Sullivan
- Рейтинговые агенства Standard & Poors, Moody’s, Fitch Ratings.
- Google AdWords, Яндекс.Wordstat
Где брать информацию для SAM?
- Отчеты на сайтах конкурентов
- В обзорах рынков Bloomberg, РБК
Где брать информацию для SОM?

Провести самостоятельный анализ.
- Выделить сегменты рынка для оценки.
- Количество конкурентов. Например из 2gis. Чем занимается.
- Средний чек. Звонишь узнаешь у конкурентов, анализируешь прайс листы.
- Количество заказов. Спросить работников, посмотреть номер заказа на чеке.
- Конверсии. Общий поток, кто заходит на сайт, проходит мимо, и сколько из них конвертируется.
Из этого считаем количество возможных заказов на рынке, количество денег и какой процент ты занимаешь.
October 22, 2019

Работа над продуктом/ продуктами

Критерии успеха продукта

1 – Наличие растущего рынка (самое главное).

2 – Команда. Команда должна быть крутой, сработанной и с взаимодополняющими компетенциями.

3 – Качество продукта и сам продукт.

Создание нового продукта

Шаг 0. Создаем команду из специалистов способных запустить продукт.

Знания и навыки необходимые для вывода нового продукта на рынок

Design Thinking
Маркетинг и методы анализа рынка
Подходы к анализу конкурентов
Проектное управление (гибкие методологии Scrum, Kanban)
Аналитика, продуктовые KPI
Сильные организационные навыки
Уверенные навыки фасилитации рабочих встреч
Начальные навыки активных продаж если есть в команде сильный продажник, если нет, то нужны сильнные навыки.
Use Cases
User Stories, JTBD
CJM
Желание поработать круглосуточно ближайшие пол года

Шаг 1. Анализ предметной области. Рынок, видение, стратегия, концепт.

Предварительный этап проработки идеи

Этап принятия решения ввязываемся или нет в активную проработку идеи (1 – 2 недели по паре часов в день; 2% работы над проектом)

Анализ, сбор информации о “мире”, предметной области. Откуда брать идеи о том, что делать? (2 – 3 дня с перерывами на протяжении недели, чтобы было время отвлечься и уложить информацию)
- Обзор прессы, отчетов венчурных фондов, новостных заметок.
- Обзор и анализ нормативно правовых документов в предметной области.
- Обзор мнения “экспертов”, “лидеров мнений”, просто громких чуваков в области или предметной области. Обзор и поиск трендов и моды в предметной области. Обзор тренд сеттеров. Подписка и мониторинг тематических групп в фейсбуке и телеграмм в предметной области.
- Обзор открытых маркетинговых исследований в области.
- Динамика развития области за последние 5-10 лет. Финансовые показатели области в целом.
- Определение основных “проблем” и “узких мест” для пользователей в предметной области.
- Анализ какие альтернативы решения есть сейчас. Как сейчас решают свои проблемы пользователи, включая офлайн решения и самые не очевидные и никак не связанные с IT.
- Анализ стартапов/ продуктов предметной области за рубежом и у нас. Даже далеких от первоначальной идеи просто в предметной области. Анализ объема инвестиций в стартапы, динамика развития, отчеты инвесторам, проверка динамики развития по систем сравнительного анализа конкурентов.
- Анализ трендов и посещаемости разделов и продуктов на наших ресурсах.
- Анализ трендов поисковых запросов
- Поиск знакомых из предметной области и сбор общего видения ситуации. Вопросы “на кухне” к учредителям или людям с опытом в предметной области, сфере бизнеса, о том, что они думают об идее.
- Опрос пользователей (пока можно просто окружения) как они решают свои проблемы в предметной области.
- Анализ конкурентной среды, свободности и занятости рынка Владивостока, Дальнего востока, Новосибирска, России. Продумываем теоретические варианты масштабирования, чтобы сразу понимать есть ли шанс масштабироваться. Если зайдем в область с кем будем конкурировать.
- Прикидываем объем рынка в людях, которые сталкиваются с обозначенными проблемами в предметной области. Пока достаточно поверхностно на основе выбранного рынка и ЦА регионов.
- Ищем развалившиеся/ закрывшиеся/ умирающие продукты в предметной области. Читаем, ищем инфу, почему не взлетели. Находим основателей и читаем их твиттер, фб, колонки, персональные сайты, интервью прессе и т.д. Можно просто списаться и узнать почему не взлетело и спросить советов и видения развития области.
- Если вдруг рынок свободен, “очевидная” идея не реализована и нет конкурентов, то скорее всего (99.9%) идея – говно. Найди почему!
Анализ готовности процессов в команде, проверка достаточности компетенций команды к работе над созданием нового продукта
- Общее понимание процесса работы каждой профессии в предметной области. Кто чем должен заниматься.
- Понимание и аналитика групповых динамик в существующей команде. Потянут ли они вообще большие проекты/ задачи. Или у них никогда не было опыта групповой работы над задачами.
- Анализ наличия нужных людей в команде, прикинуть сможешь ли ты сам закрыть недостающие компетенции, на что можно будет забить и что можно попробовать отдать на аутсорс договорившись с другими отделами, командами.
Формирование первоначального видения для продукта. (1 день)
- Описываем основные проблемы, болевые точки, чаяния пользователей, которые будем закрывать продуктом.
- Обозначаем основной рынок и перспективы масштабирования (есть, нет.). Объем рынка в людях.
- Обозначаем объем рынка в деньгах.
- Описываем политическую и юридическую ситуацию в регионе/ области. Насколько сильно гос. регулирование, “московское лобби”, связи и т.д.
- Определение с первоначальной идеей. Общее видение бизнес модели будущего продукта: B2B2C, C2B2C, B2C, (B2B – почти всегда не ввязываемся, так как это низко маржинальная история)
- Пинч идеи. Попробуйте рассказать идею “на кухне” и продать ее коллегам, менеджерам других отделов или просто знакомым друзьям. Слушайте критику и сомнения. Корректируйте доводы, собирайте еще информацию, проводи анализ, чтобы получилось переубедить.
- Обязательно попробуй “продать” видение и идею команде. Слушайте критику и сомнения. Корректируйте доводы, собирайте еще информацию, проводи анализ, чтобы получилось переубедить. Следи за эффектом “конформности” и “желания понравится” в команде. Скажет ли тебе команда прямо критику или просто забьет и подтвердит, что не скажешь лишь бы отстала/отстал.
Принятие решения о начала работ.
- “Загорелась” ли команда и так же верит в успех как и ты или все считают, что эта идея “говно” и “галлюцинации менеджера”.
- Анализируем все описанное выше и принимаем решение: “Прыжок веры” Тут только интуиция, после собранной инфы все еще хочется этим заниматься и осталась ли решимость и вера в успех. На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке.

Основной этап проработки продукта

Принятие решения будем ли упарываться в разработку или забьем. ( 2 недели, 1-2 месяца активной работы, если делать большие MVP (нужно время, чтобы накопить данные); 10% работы над проектом)

Проведение продуктовых исследований. Создание MVP без разработки
- Переформулируем проблемы, которые лежат в основе видения в гипотезы
- Прорабатываем качественные и количественные эксперименты по подтверждению/ опровержению гипотез
  - Customer Development. The Mom Test.
  - Опросы пользователей на наших ресурсах (главная ВЛ/Хаб, Дром, новости, офф)
  - Создание тем на форумах с ЦА, общение с пользователями в группах соц. сетей
  - Аналитика и сбор данных по поведению пользователей на наших ресурсах (схожие направления)
  - Создание MVP без разработки: фейковые кнопки, лендинги с предзаказом, ручная обработка заказов/услуг. Когда и какие гипотезы стоит проверять через MVP, а для чего это просто трата времени?
- Предпродажа и начальные договоренности с партнерами.
- Генерим и проверяем гипотезы по УТП
Корректировка видения продукта.
- Уточняем проблемы, которые есть у пользователей и будет решать продукт
- Фиксируем проверенные гипотезы с которыми будет строить бизнес модели
- Определяемся с ЦА, рынком
- Корректируем видение продукта
Конкурентный анализ
Набросок стратегии развития продукта, согласование с целями компании (как ты представляешь себе цели)
- SWOT анализ
- Стратегия голубого океана
- Operational Excellence, Customer Intimacy, Performance Superiority Strategies
- Product centred – Customer centred strategy (Long tail strategy)
Определение бизнес модели
- Подбор бизнес модели (Lean Bussiness Model Canvas, Ostervald Model Canvas)
- По выбранной бизнес модели просчитать юнит экономику, получить начальные метрики
- Просчитать или найти инфу по стоимости лида, сделки.
Каналы продвижения. Решаем откуда и за сколько будем брать трафик. Прогнозы сколько трафика откуда планируем привлечь.
- Условно бесплатные каналы для нас. Наши ресурсы.
- SEO
- Контекст и cpc, таргет
- Ну и остальные каналы
Фин анализ для бизнес модели
Анализ рисков
- Организационные – это риски, связанные с ошибками менеджмента компании, ее сотрудников; проблемами системы внутреннего контроля, плохо разработанными правилами работ, то есть риски, связанные с внутренней организацией работы компании или команды.
- Рыночные – это риски, связанные с нестабильностью экономической конъюнктуры: риск финансовых потерь из-за изменения цены, риск снижения спроса, неверно просчитанная бизнес модель.
- Юридические – это риски потерь, связанных с тем, что законодательство или не было учтено вообще, или изменилось пока делали проект; риск некорректно составленной документации, договоров, оферт и пр.
Корректировка стратегии, бизнес модели
Готовим документ в wiki:
- Background and strategic fit для компании, как соотносится с целями компании
- Видение продукта
- Исследования ЦА и их проблем. Customer Development, количественная аналитика.
- Анализ текущего состояния рынка
- Конкурентный анализ
- Сегментация аудиторий. Каналы продвижения. Откуда будем брать трафик на проект?
- Фин. анализ
- Основные продуктовые KPI и количественные прогнозы на основе данных. Прогнозируемые KPI для сравнения потом с фактическими.
Презентация видения и стратегии команде, обоснование для учредителей. Корректировка видения и стратегии продукта на основе фидбэка.
Принимаем решение будем ли упарываться в разработку. На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке.

Шаг 2. Вывод продукта на рынок

Планирование работ по созданию первой версии

Требования, прототипирование, оценка затрат по созданию. ( 1 неделя активной работы; 10% работы над проектом)

Сбор, анализ, постановка, описание требований для задач с командной разработки
- Выделение ролей системы
- Описание use cases для каждой роли
- Наброски эпиков, user stories(JTBD)
- Выделения критериев успеха: Макро и микро конверсии по историям.
- Создание интерактивного прототипа, wireframe
- Уточнение, нормальное проработка user stories
- Добавляем в план работы по:
  - Настройке аналитики и учету метрик
  - Деплою кода в прод, настройку инфраструктуры
  - Задачи необходимые для начального привлечения трафика.
    - SEO
    - Лендинги на которые будем гнать трафик
    - Рекламные виджеты на проектах
- Предпланирование и начальные эстимейты в SP с тех. лидом
- Составление графа зависимости историй
- Переписать/ доработать требования по фидбэку тех. лида
Выделение MVP продукта
- Проводим с командой MustDo, ShouldDo, CouldDo c пользовательскими историями. Выкидываем на ShouldDo, CouldDo большинство задач. С MustDo – это то, с чем будем запускаться. Это и есть наше MVP, которое мы выкатим на прод и будем показывать миру.
- Все что можно делать вручную – делаем вручную. Выдрачиваем только основной сценарий пользователя!
Привлечение партнеров, продажи. Составление договоров.
- Анализ договоров и оферт конкурентов. Представиться желающим подключиться и посмотреть как проходит процесс подключения у партнеров.
- По use cases составить набросок договора, оферты
- Активные продажи, переговоры, выезды к партнерам, обсуждение условий, нюансов, переделка договора
- Согласование договора, оферты с юристами компании
- Заключение первых договоров
Подготовка плана запуска продукта, офлайн часть
- План сбора фидбэка от пользователей (КЦ, телефоны, системы сбора фидбэка, почты, т.д.)
- Наброски инструкций, скриптов работ для внедрения
- План рекламной компании
- Доп. договоренности что будет покупать, отдавать на аутсорс на первом этапе.
Планирование этапов работ с командой
- Фиксируем, вспоминаем с командой Definition of Done. Для новых продуктов – это только прод в закрытом режиме!
- На iteration planning бьем эпики на задачи
  - Задачи на кодирование
  - Задачи под деплой и настройку окружения
  - Задачи под тестирование
  - Задачи под сбор аналитики и метрик
  - Задачи по оптимизации скорости работы системы
- Эстимейтим задачи с командой (planning poker)
- Составляем карту зависимостей задач
- Разбиваем на спринты, определяем параллельность работ и количество человек, которые могут одновременно работать над созданием продукта
- Получаем примерное время работы и время релиза. Умножаем на исторический фокус – фактор. Добавляем спринт на реал тайм тестирование и фиксы.
- По SP считаем бюджет фичи.
Принятие решения о начале работ. Старт разработки. Старт итерации.
- Смотрим на время разработки, бюджет разработки в деньгах – решаем будем делать или нет! Не дорого ли получается работа? На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке. Или еще уменьшить функционал.

Работы по созданию продукта

Мониторинг и контроль за разработкой. Как переложить его на процесс и тратить минимум времени?
- Спринты
- Epic Burndown Chart
- Переэстимейты перед каждым спринтом
- Самые рискованные, сложные, неизвестные вещи – вперед
- Дейли
- Ретро по корректировке процесса раз в 2 спринта.
Подготовка промо материалов, рисовка баннеров, виджетов
Настройка счетчиков аналитики
Составление, согласование, подписание документов:
- Договора
- Оферты

Правда жизни: Если тебе не стыдно за то, что ты выкатил пользователям – ты запустился слишком поздно!!! Говно и палки на этом этапе наше все

Запуск проекта, фаза слабоумие и отвага

Важно! При запуске проекта весть фидбэк пользователя только на менеджеров. Никаких прослоек в виде КЦ или клиент менеджеров. Все косяки пользователей и партнеров вручную должен решать запустивший проект менеджер.

Планерка по запуску
- Распределение ролей, кто за что отвечает
- Брейнсторм, что может пойти не так. Работа с рисками, risk management plan. Кто и как разруливает реализовавшиеся риски.
Мониторинг аналитики и показателей.
Разбор фидбэка пользователей. Решение проблем пользователей. Составление реестра предложений и фидбэка, откуда потом будем черпать идеи, что может быть не так.
Разбор фидбэка партнеров. Решение проблем партнеров. Составление реестра предложений и фидбэка, откуда потом будем черпать идеи, что может быть не так.
Перевод команды из работы по спринтам в режим херачим все что видим (назовем этот режим – Канбан)
Привлекаем всех кого можем на правку багов. Летит критичный фидбэк – кто не правит другую кричную багу, тот и правит этот фидбэк. Быстро, можно говнокодом. Оперативно разруливаем косяки, которые забыли и не учли при запуске в функционале, договорах, взаимодействии с пользователями/ партнерами.

Первые результаты после запуска проекта

Сравнение фактических KPI продукта с прогнозируемыми. Пытаемся понять почему мы не дотягиваем. Очень редко, что стреляет сразу Мы точно сперва не дотягиваем.
Составление реестра гипотез (HADI), почему не дотягиваем до KPI. Идеи берем из:
- Качественных источников: Фидбэки пользователей и партнеров, прямое общение с пользователями, NPS, вебвизор или наблюдение за тем как пользователи пользуются продуктом.
- Количественных данных по воронке продаж, аналитике, сравнение реальных KPI с прогнозируемыми.
Запускаем серии экспериментов по проверке гипотез. Фейковые кнопки, ручные фиксы, имитации с минимумом разработки. Как находим подтверждение в данных – уже пилим стабильную фичу. Смотри часть “Работа над фичей”

Шаг 3. Вывод продукта на стадию роста

Работа над конверсией основных сценариев/ воронок

CJM
Метрики воронок
АБ эксперименты

Успокаиваемся, когда начинаем видеть рост DAU, WAU. Убеждаемся, что все норм с удержание (retention) пользователей и они не “утекают”.

Привлечение пользователей

Аналитика каналов привлечения пользователей, стоимость привлечения пользователей, конверсии, Retentions, Assisted Conversions и роль канала в них…

Канал продвижения	Стоимость	Эффективность с точи зрения прямого привлечения трафика (1-5)	Для чего подходит лучше?Понятно, что в начале все каналы дают новых пользователей.	Как подготовить?	Метрики
Ссылка в левом меню на VL	Бесплатно	3	Довозвраты существующих, легкий способ найти полюбившийся продукт на ВЛ или ДВХабНовых пользователей можно получить чуть чуть в начале, если выделить ссылку	Согласовать с Егором установку ссылки и написать на SUPVL, чтобы ребята поставили.
Виджет на главной VL	Условно бесплатно. Тратим ресурсы компании на создание виджета.	3	Довозвраты существующих, легкий способ найти полюбившийся продукт на ВЛ или ДВХаб
Виджеты на ресурсах	Условно бесплатно. Тратим ресурсы компании на создание виджета. Ресурсы разработки, но небольшие	2	Узнаваемость и привлечение новых пользователей.Для довозвратов долго держать не получится, нужно приучать пользователей искать напрямую продукт.Для рекламы наших продуктов во Владивостоке и Хабаровске. При выходе на Россию можно заюзать Дром и Фарпост в других городах.	Согласовать вид виджета с Титус и рекламным отделом, чтобы не перебивать платную баннерную рекламу.Согласовать установку с владельцем продукта, разработать виджет, замерить CTR, utm метки	CTR виджетаМикро и макроконверсии с канала
Баннера	Условно бесплатно. Тратим ресурсы компании, что в целом дороже, чем просто деньги тратить. Ресурсы дизайна, но небольшие	1	Узнаваемость и привлечение новых пользователей.Для довозвратов нужно будет постоянно обновлять баннера и посылы.Для рекламы наших продуктов во Владивостоке и Хабаровске. При выходе на Россию можно заюзать Дром и Фарпост в других городах.	CTR баннераМикро и макроконверсии с канала
SEO	Условно бесплатно. Тратим ресурсы компании, что в целом дороже, чем просто деньги тратить	4. Долго, так как придется на протяжении полугода настраивать и следить за эффектом.	Довозвраты пользователей по брендовым запросам продукта.Привлечение новых, если ключевики не выкупаются агрессивно конкурентами
Google Adwords и Яндекс Директ	Платно, дорого. Но зато быстро получаем целевой трафик	5	Для привлечения новых платящих клиентов, когда точно определена макроконверсия на продукте. Покупка, подписка, просмотр телефона и т.д.Есть смысл подключать канал при хорошей (direct) конверсии и удержании. Когда продукт начал работать.	Согласовать бюджеты с Егором. Договориться с отделом интернет-маркетинга о запуске компании.Настроить аналитику по ключевым словам в Гугле и Яндексе: макро и микро конверсии, чтобы можно было корректировать кампании.Подключить Директ и AdWords к настроенным счетчикам	CTRПозиции словСтоимостиМикро и макроконверсии по ключевым словам и группам
MyTarget	Платно, дорого. Но зато быстро получаем целевой трафик	5	Согласовать бюджеты с Егором. Договориться с отделом интернет-маркетинга о запуске компании.
Наши группы в cоц. сетях	Бесплатно	2	Новые пользователи и больше для того, чтобы в общем узнали о продукте	Договориться с владельцами группы
Чужие группы в соц. сетях	Платно за деньги	3, если подобрать правильную тематическую группу	Новые пользователи и больше для того, чтобы в общем узнали о продукте
Новости	4	Новые пользователи и больше для того, чтобы в общем узнали о продуктеРазовое привлечение, либо нужно новости публиковать на постоянку, но нужны инфоповоды.
Посты на форумах	2	Новые пользователи и больше для того, чтобы в общем узнали о продукте
Youtube	?	Новые пользователи и больше для того, чтобы в общем узнали о продукте
Кросс-пиар с партнерами. Ролики в кинотеатрах, брендирование стадионов.	1	Чисто узнаваемость бренда, так как прямых переходов получишь не много.Постоянное фоновое напоминание о продукте
Growth Hacking техники	Много ресурсов и денег компании на разработку и эксперименты.	5
Участие в тематических встречах/ выставках/ конференциях…	Платно	1 – для пользователей4 – для партнеров
Почтовые рассылки	Условно бесплатно	3
BTL (Раздача листовок)	Платно	1
Баннерная офлайн реклама на щитах по городу	Платно, дорого	2
Реклама в лифтах (жилых домов, офисов)	Платно	3
Объявления на фарпосте в тематических разделах	Бесплатно. Виртуальный счет ушедший в минус на барахолке за деньги не считаем Но при фин. учете можем	2

Работа над фичей

Определение стадии ЖЦ продукта
Продуктовый анализ и исследования. Обоснование начала работ.
Сбор и анализ требований
Планирование этапов работ с командой
Принятие решения о начале работ. Старт разработки
Мониторинг и контроль. Как переложить его на процесс и тратить минимум времени?
Внедрение и запуск фичи
Мониторинг аналитики и показателей
Доработка? Как понять, что мы все сделали?

Pivot? Как понять, что мы все сделали и можно переводить на поддержку из активной разработки?

Выводы. Итоги. Ретроспектива по итерации

Перевод продукта/фичи на поддержку из активной разработки. Поддержка продуктов на стадии рост-зрелость.

Автоматизация бизнес – процессов, снижение затрат на поддержку.
Организация мониторинга основных KPI продукта, дашборды.
Передача операционных задач в отдел поддержки. Проверка документации и инструкций. Доработка инструментов поддержки по надобности. Все зависит от задач: активное привлечение и продажи можно передать в рекламу, поддержку оперативную пользователей и партнеров в КЦ, работу с партнерами клиент менеджерам. По загрузке отделов и возможности взять на себя доп. работы нужно договариваться с каждым из руководителей отделов отдельно. Обязательно организовать общую группу с коллегами для поддержки и ответов на оперативные вопросы. Если ты передаешь дела в другой отдел – еще пол года минимум вы будете отлаживать процессы и нужно активно помогать коллегам разобраться с новой работой.
Организация сбора фидбэка от внутренних заказчиков/ отдела поддержки.
Тушение пожаров.

Тушение пожаров

Идентификация источника проблемы
Действия по минимизации дискомфорта для пользователей и партнеров
Координация работ по фиксу проблемы
PostMortem анализ. Брейнсторм, что сделать чтобы не допустить повторения
Принимаем действия по недопущению повторения

February 7, 2019

Google AdWords заметки

Как создавать компании?

Повторяем структуру сайта. Разделы – это компании. Подразделы – группы. У компаний могут быть раздельные бюджеты, у групп общий бюджет.

Медиапланирование

Изучить сайт (посмотреть его структуру)
Определить и согласовать приоритетные направления.
Определить KPI (стоимость заявки/ звонка и т.д.)
Определить целевую аудиторию.
Выбрать таргетинги в рамках заданного бюджета.
Спрогнозировать количество трафика.
Спрогнозировать количество конверсий.

Подсказки по текстам объявлений

Использовать ключевое слово в тексте объявления
Указать цену, информацию о спец предложениях (бесплатная доставка, акции)
Подчеркнуть уникальность своей компании, товаров и предложений.
Призывы к действию
Максимально релевантные страницы
Минимум 3 варианта объявления.

Обзор типов соответствия

Тип соответствия	Специальный символ	Пример ключевого слова	Содержимое запросов, по которым могут показываться объявления	Примеры запросов
Широкое	Нет	женские туфли	Слова с опечатками, синонимы, связанные запросы и другие релевантные варианты.	купить дамские туфли женская одежда
Модификатор широкого соответствия	+ключевое слово	+женские +туфли	Все слова со знаком “+” (или их близкие варианты) в любом порядке. Другие слова могут стоять до или после отмеченных знаком “+”, а также между ними.	женские туфли и сумочки женская обувь туфли
Фразовое соответствие	“ключевое слово”	“женские туфли”	Заключенная в кавычки фраза (или ее близкие варианты), до или после которой могут стоять другие слова.	голубые женские туфли купить женские туфли женские туфли со скидкой
Точное соответствие	[ключевое слово]	[женские туфли]	Запросы, которые соответствуют заключенному в квадратные скобки или практически совпадают с ним по смыслу.	женские туфли дамские туфли туфли для женщин туфли женские

https://support.google.com/google-ads/answer/7478529?hl=ru&visit_id=636832113667843880-2135207219&rd=1

Варианты составления объявления

Вариант 1

Заголовок 1: Ключевое слово
Заголовок 2: УТП
URL: страница соответствующая ключевому слову
Описание: УТП + УТП + УТП + … + CTA
Видимый URL: части ключевого слова

Вариант 2

Заголовок 1: Часть ключевого слова
Заголовок 2: Вторая часть ключевого слова
URL: страница соответствующая ключевому слову
Описание: УТП + УТП + УТП + … + CTA
Видимый URL: части ключевого слова

Вариант 3

Заголовок 1: Часть ключевого слова
Заголовок 2: Вторая часть ключевого слова + УТП
URL: страница соответствующая ключевому слову
Описание: УТП + УТП + УТП + … + CTA
Видимый URL: части ключевого слова

January 16, 2019

Lean Analytics – конспект книги
Good Metric
- Comparative – being able to compare it to other time periods, groups of users or competitors.
- Understandable
- Ratio or Rate
  - Ratios are easier to act on
  - Ratios are inherently comparative
  - Ratios good for comparing factors that are somehow opposed, or for which there’s an inherent tension.
- Good metric change the way you behave: What will you do differently based on change of the metric?
January 22, 2018
Гипотезы о согласии

Гипотезы о согласии – это предположение о соответсвии случайно величины какому либо закону.

Общие критерии согласия – это критерии, которые применяются к гипотезе о согласии наблюдаемых результатов с любым предполагаемым распределением вероятностей.

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

Критерий согласия Хи-квадрат

Позволяет проверять как простую, так и сложную гипотезы о согласии.

1 этап. Группирование данных. Разбиваем область определения случайной величины на k непересекающихся интервалов. x₍₀₎,x₍₁₎,…,x_(k)

2 этап. Считаем количество наблюдений, которые попадают в каждый из интервалов. n_i

3 этап. Считаем частоту попадания в каждый из интервалов n_i/n

4 этап. Считаем теоретическую вероятность попадания в каждый из интервалов.

P_i(Θ)=F(x_(i),Θ)-F(x_(i-1),Θ)

December 25, 2017
R подсказки названий функций для анализа данных
1. Загрузка данных data<-read.csv(“/Users/crincum/Statistic/Data_Course1.csv”, sep=”;”,dec=”,”)
2. Номинальные данные в выборках (0 или 1), превращаем в факторы, чтобы R понимала, что это не обычные значения, а номинальные data$IsGeo <- as.factor(data$IsGeo)
Как подсчитать основные меры вариативности?
- min, max, mean, median
- quantile – расчет квартилей
- var (x) – несмещенная дисперсия, рассчитанная для n-1
- sd (x) или sqrt(var(x)) – среднеквадратичное отклонение
- names(sort(-table(x)))[1] – мода или Modus
- IQR(x) – Среднеквадратичное отклонение
- mad(x, center = mean(x)) – AAD среднее абсолютное отклонение
- mad(x) – MAD среднее медианное отклонение
Проверка на нормальность данных

Если судя по графику функции распределения – распределение признака похоже на нормальное, то можно провести тест Шапиро-Уилка чтобы убедиться в этом:

shapiro.test(rnorm(data$test))

shapiro.test(FC)

##

## Shapiro-Wilk normality test

##

## data: FC

## W = 0.68423, p-value = 9.549e-12

Значение p-value очень маленькое. Это значит, что тест на нормальность не пройден.

Если по результатам теста p-value > 0.05, это дает нам предполагать нормальное распределение.

Остается предположение о логнормальности данных. Для того, чтобы проверить эту теорию, возьмем логарифм переменной и проведем тест Шапиро-Уилка уже для него.

shapiro.test(rnorm(data$test))

или

logFC<-log(FC)

shapiro.test(logFC)

##

## Shapiro-Wilk normality test

##

## data: logFC

## W = 0.98479, p-value = 0.4715

Значение p-value резко возросло и теперь свидетельствует о нормальности данных. Это значит, что преобразование сработало и распределение переменной FC – логнормальное, так как логарифм логнормального распределения – нормальное распределение.

Построим график распределения количества организаций, после перевода в нормальное

plot(density(logFC), main = "Логарифм распределения значений", xlab = "Количество", ylab = "Частота", col = "red")

Он уже должен больше напоминать нормальный.

Построение графиков плотности и распределения

plot(ecdf(dataCourse1$AddressCount))

plot(density(test,adjust=2))
December 2, 2017
Что делать с неопределенными ответами (Да, нет, не знаю)
Как кодировать неопределенные ответы?
1. Если они неинформативны, то их можно кодировать как пропущенные. Отбрасывать, заменять на функцию от соседних и т.д.\
2. Если они важны,
  - Если шкала порядковая, то”затрудняюсь ответить” кодируем самым большим числом. Например, вопрос о счастье. Оцените насколько вы счастливы от 1 – несчастен до 9 – счастлив. 10 – затрудняюсь ответить. Важно! Что при этом меняется тип шкалы, она становиться не порядковой, а номинальной. 10 выпадает из порядковой логики и оставляет качественно что то другое.
  - Если есть проблемы с вопросом. Т.е. больше половины респондентов затруднились ответить на вопрос. Это сигнализирует о проблемах с вопросом. Либо плохо сформулирован вопрос, либо люди не имеют мнения.
  - Если речь идет о затруднительных темах. Или не хотят рассуждать вслух.
  - Возможно есть проблема с работой интервьюиера. Например новый интервьюир может не дожидаться пока люди подумают и сформулируют мнение, а сразу невнятные “я не знаю”, записывают в неопределенный ответ.
November 26, 2017
Определение необходимого объема выборки
Как понять какой объем выборки будет достаточным для того, чтобы делать выводы о всей генеральной совокупности.

Возьмем формулу предельной ошибки выборки и выведем из нее формулу объема выборки.

Пример с расчетом среднего чека во всех заведениях Москвы.

Мы хотим узнать сколько в среднем стоит поесть в Москве.

N = 5802 заведения. Размер генеральной совокупности

s²= 549093,84. Несмещенная дисперсия. Выборочная дисперсия – это оценка теоретической дисперсии распределения, рассчитанная на основе данных выборки относительно среднего значения в выборки. Дисперсия – мера отклонения случайной величины от ее математического ожидания. Математическое ожидание – среднее значение, которое принимает случайная величина (функция случайной величины).

$\Delta_{\overline{X}}$ = 100 рублей. Предельная ошибка.

Мы знаем, что $\overline{X}$ = 956 рублей. Средний чек для заведений из выборки.

Подсчитаем вероятности для

p₁ = 95%

p₂ = 99%

p₃ = 99,9%

Работа с пропущенными наблюдениями

Каковы причины?
1. Вопрос задан не корректно
2. Фальсификация опросных данных.
3. Иногда люди отказываются отвечать на наши вопросы.
Что делать с пропущенными данными?

1. Исключить пропущенные наблюдения. Но это приведет к потере информации.

2. Заменить пропущенные наблюдения.

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

Всего опросили 636 человек и 359 отказались отвечать.

$\overline{X}$ = 32 594 рубля, среднее значение

t_0,5 = 30 000 рублей, медиана.

Регион Возраст Доход

142 69 20 000

142 32 46 000

142 67 18 000

142 39 8 000

142 69 19 000

142 65 19 000
1. Построим гистограмму и дальше будем замещать пропущенные значения по очереди средним, медианой и т.д., чтобы поспосмотреть, что будет происходить с графиком.
- Если заменять пропущенные значения среднем, то если пропущенных данных много, есть шанс все испортить, так как (если есть выбросы), то за счет такого замещения они усилятся и на гистограмме будет ничего не понятно.
- Замещение медианой тоже дает фигню.
- Правильно заменять любыми случайными числами, как то связанными с выборкой. Например, находя пропущенные данные брать ближайших соседей, совершать какую то функцию над ними (например, среднее арифметическое) и заполнять пропущенное значение.
- Если данные позволяют, то можно исключить эти данные.
November 26, 2017
Выборки в анализе данных
Зачем вообще нужна выборка?
1. Иначе будет очень дорого опрашивать всех.
2. Многие данные полностью просто не доступны.
Какие бывают выборки?
1. Простая случайная. Обычный рэндом.
2. Механическая. Выбираем один случайный элемент и с определенным шагом начинаем выбирать элементы.
3. Стратифицированная. Мы знаем что то про генеральную совокупность. Мы делим ее на страты и случайным образом выбираем из каждой страты. Например, мужчины и женщины.
4. Гнездовая (кластерная). Например, группируем районы города на кластеры по важным нам свойствам и случайно опрашиваем не все районы, а представителей каждого кластера.
Неслучайные выборки

Все неслучайный выборки не репрезентативны, но иногда других способов получить данные нет.
1. Метод “снежного кома”. Незаменимы для исследования экспертов или для исследования труднодоступных групп. Мы находим одного и он дает нам контакты следующих людей и т.д. Часто запускают несколько таких комков.
2. Квотная.
Ошибки выборки

N – объем генеральной совокупности

n – объем выборки

Далее мы считаем среднее по выборке ( $\overline{X}$ ) и среднее по генеральной совокупности (μ).

Разница между среднем значением показателя в выборочной и генеральной совокупности и будет называться Ошибкой выборки.

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

Коэффициент доверия Стьюдента (t).

Он зависит от вероятности, с которой определяется предельная ошибка выборки.

Для вероятности p = 95%, t = 1,96

Пример, все кафе Москвы

Мы знаем средний чек в этих заведениях и хотим на основе выборки в 294 заведения из 5802 заведений подсчитать средний чек в генеральной совокупности.

N = 5802 заведения. Размер генеральной совокупности

n = 294 заведений. Размер выборки.

$\overline{X}$ = 989 рублей. Средний чек для заведений из выборки.

s²= 461504.5432. Несмещенная дисперсия. Выборочная дисперсия – это оценка теоретической дисперсии распределения, рассчитанная на основе данных выборки относительно среднего значения в выборки. Дисперсия – мера отклонения случайной величины от ее математического ожидания. Математическое ожидание – среднее значение, которое принимает случайная величина (функция случайной величины).

p = 95%. Вероятность с которой мы хотим подсчитать средний чек в заведении на основе выборки.

t = 1.96. Коэффициент доверия Стьюдента для 95% вероятности.

$\Delta_{\overline{X}}$ = 75.66 рублей. Предельная ошибка, рассчитанная по формуле выше.

Доверительный интервал

Доверительный интервал – это интервал, в который попадает неизвестный параметр (например, средний чек для заведений Москвы) с заданной вероятностью. Вероятность можно определять с помощью коэффициента доверия Стьюдента.

Левая граница – это среднее по выборки минус предельная ошибка. А для правой границы доверительного интервала – среднее по выборке плюс предельная ошибка.

$\overline{X} - \Delta_{\overline{X}} < \mu < \overline{X} + \Delta_{\overline{X}}$

Пример доверительного интервала для среднего чека по всей генеральной совокупности получился 913.34 < μ < 1064.66 рублей. А для всей генеральной совокупности истинный средний чек равен μ_N = 956 рублей. Он попадает в наш 95% доверительный интервал.
November 26, 2017
Видение, миссия и стратегия
Формирование видения для бизнеса, компании, продукта, отдела и т.д.

Видение можно формировать самостоятельно или совместно с командой. Шаги будут те же.

Шаг 1. Определить для чего я буду формировать видение. Для команды, отдела, компании, продукта.

Шаг 2. Выбрать горизонт планирования (3-5-7 лет). Лучше не брать очень большой.

Шаг 3 Выписать свои успехи и достижения. Этот шаг полезен для того, чтобы осознать, что ты сможешь замахнуться на многое.

Шаг 4 Написать первую версию Видения

Как можно точнее, что будет за продукт, как им будут пользоваться, сколько человек в команде, с кем будете работать…

Шаг 5 Перечитать, дополнить и отложить работу над видением на 2-3 дня

Шаг 6 Через 2-3 дня посмотреть на написанное без эмоционального переживания. Доработать и переписать.

Шаг 7 Поделиться своим видением со значимыми для Вас людьми, чтобы получить обратную связь, доработать и усилить.

Шаг 8 Презентовать видение бизнеса команде, коллегам, партнерам.

Миссия компании

Миссия – это смысл существования этого бизнеса, организации, компании.

Нужно ответить на вопросы:
- Кто мы?
- Что мы делаем?
- Для кого мы это делаем?
- Ради чего мы это делаем?
SWOT анализ

Проанализировать где я сейчас нахожусь относительно себя и рынка.
- S – Сильные стороны компании
- W – Слабые стороны
- O – Возможности, которые предоставляет рынок
- T – Угрозы, которые могут случиться на рынке
После анализа всех 4х составляющих можно получить стратегию. В пересечении возможностей (трендов) и своих сильных сторон можно сформировать несколько стратегий.
- Начать с заполнения сильных и слабых сторон. Может оказаться, что одна и также вещь может быть как силой, так и слабостью.
- В возможностях рынка, нужно смотреть именно какие возможности есть прямо сейчас на рынке.
- Угрозы, которые могут помешать в достижении своих целей.
- Дальше нужно сопоставить и внимательно проанализировать сильные стороны и возможности рынка. “Пересечения” помогут увидеть и сформулировать стратегию развития бизнеса, продукта, команды.
Цель и план действий

1. С видения и стратегии главное спуститься на уровень цели, которую необходимо оцифровать в конкретный KPI.
- Период
- Конкретный результат по SMART
- Реализуема и актуальна для компании
2. Составить план действий для достижения цели, через анализ сильных сторон и барьеров.
- Какие есть у меня сильные стороны ресурсы, чтобы достичь эту цель?
  - Составить план действий: Что мне нужно сделать чтобы усилить мои сильные стороны и воспользоваться ресурсами?
- Какие могут быть барьеры, что может повлиять или может не хватить для достижения цели?
  - Составить план действий: Что мне нужно сделать, чтобы устанить барьеры и препятствия, что сделать чтобы предотвратить негативные последствия.
3. Сгруппировать действия по категориям. Например, часть действий будет касаться персонала; часть маркетинга; продаж; организации компании.

В итоге получится Видение, Миссия, Цели и дейтсвия по достижению целей.

Из большого многообразия полученных действий нужно выбрать 3-4 глобальных события, которые должны произойти через 3 месяца, 6 месяцев, 8ми, 12ти, чтобы поставить вехи для сверки с тем идем ли мы по выбранной стратегии или “что то пошло не так”:)
November 21, 2017
Графики для неметрических шкал

Pie Chart

Если нужно понять соотношение признаков

Не использовать для порядковых шкал

Горизонтальная столбиковая диаграмма

Когда нужно понять популярность и определить лидеров

Вертикальная столбиковая диаграмма

Используется для порядковых шкал

В Швеции мода 8, России 5, Албании 10.

Как показать совместные распределения признаков?

3. Если одна шкала номинальная, а другая – интервальная, то информативен ящик с усами.

Визуализация совместных распределений

November 12, 2017
Графический анализ (box plot или коробчатая диаграмма) и диаграмма рассеяния

Ящик с усами, или коробчатая диаграмма (англ. box-and-whiskers diagram or plot, box plot) — это график, который используется в описательной статистике для компактного изображения распределения вероятностей.

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

Примеры графиков для разных данных

Боксплот не показывает смесь выборки.

November 12, 2017
Графический анализ данных (гистограммы)
Квартет Энскомба — четыре набора числовых данных, у которых простые статистический свойства очень похожи, но их графики существенно отличаются.

Методы графического анализа данных

1 метод – Эмпирическая функция распределения

Эмпирическая функция распределения выборочный аналог функции распределения, который мы можем построить по имеющейся у нас выборке. Функция распределения показывает вероятность попадания случайной величины в интервал от -∞ до x.

F_ξ(x) = P{ξ ≤ x}, x∈R

Пример как подсчитать:

Дано количество кликов по фирме в день
1. Стоим вариационный ряд, Упорядочиваем по возрастанию
2. Считаем для каждого значения количество наблюдений, которые меньше или равны текущему.
2 метод – Гистограммы

Гистограмма – это геометрическое изображение эмпирической функции плотности вероятности некоторой случайной величины, построенное по выборке.

Как построить гистограмму?
1. Поделить область значений на k равных интегралов
2. Подсчитать количество наблюдений в каждом интервале
4. Чтобы получить функцию плотности с интегралом площади под графиком равным 1, высчитаем высоту столбцов по формуле ниже
Как правильно выбрать количество интервалов?

1 метод. Метод Стёрджесса (для определния количетсва интервалов)

k = 1 + [log₂n]

2 метод. (для определния количетсва интервалов)

k = [√n]

3 метод. Метод Скотта(для определния ширины интервалов)

Рассчитан на нормальность данных, так как использует среднее квадратичное отклонение.

4 метода. Фридмана – Диакониса

Испольует межквартильный размах и не рассчитан на нормальность данных.

Примеры гистограмм на больших выборках

Без выбросов хорошо работают Скотт и Диаконис. Первые два метода, ломаются и дают очень небольшое количество интервалов. Из за чего теряют в информативности.

Если брать выборки с выбросами, то нормально работает только метод Фридмана – Диакониса.

Гистограммы плохо работают на небольшом объеме данных. Мы не можем сказать какие у нас данные: нормальные, логнормальные, экспоненциальные, есть или нет выбросов.

Как интерпретировать результаты гистограмм?

Для нахождения смесей выборки.
November 12, 2017
Меры и типы переменных: что и где применимо?

Диаграмма переменных распределенных по количеству данных, которые они несут.

November 6, 2017
Как оценить по выборке генеральную совокупность? (Меры вариативности признака в генеральной совокупности)
Насколько сильно отклоняются от среднего те значения, которые на него не похожи.

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

1. Размах

Расстояние между двумя крайними значениями.

Размах = (Max – Min)

2. Дисперсия

Дисперсия – мера разброса значений случайной величины (функции случайной величины) относительно её математического ожидания.

Учитывает каждый из объектов. Суммируем квадраты всех отклонений от среднего.

Из минусов, мы получаем большое отклонение от шкалы исследования из за квадрата.

‾X‾ – среднее значение выборки или генеральной совокупности.

Несмещенная дисперсия

Выборочная дисперсия – это оценка теоретической дисперсии распределения, рассчитанная на основе данных выборки относительно среднего значения в выборки.

, где Mη – математическое ожидание, p_i – вероятность выпадения i-ой грани кубика (1/6), x_i – случайная величина соответствующая i элементарному исходу, Dη – дисперсия случайной величины.

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

3. СКО – Среднеквадратичное отклонение

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

Минусы: чувствительно к выбросам

4. AAD – среднее абсолютное отклонение

5. MAD – медианное абсолютное отклонение

Примеры с изменение средних и разбросов зарплат

6. Межквартильный размах
- Позволяет оценить разброс между типичными значениями
- менее чувствителен к выбросам
- позволяет оценить разброс на порядковых шкалах
November 6, 2017
Как оценить по выборке генеральную совокупность? (Меры центральной тенденции)
Чтобы оценить по выборочным данным генеральную совокупность,

нам нужно знать следующие вещи, чтобы описать распределение характеристики в генеральной совокупности объектов:

1. Где находятся типичные значения характеристики. => Меры среднего

2. То, насколько эти значения разрознены, насколько они не одинаковые => Меры разброса (вариативности)

Как подсчитать меры среднего?

1. Среднее арифметическое

Подходит для нормальных распределений, где нет выдающихся значений.

2. Рассчитать усечённые статистики

Пример: есть компания, где зарплаты распределены с 15 000 до 50 000 руб. Среднее арифметическое = 23 000 руб. И тут появляется работник, которому начинают платить 150 000 руб. Среднее арифметическое станет в районе = 33 000 руб, со стороны это может дать сигнал, что в компании люди стали получать больше, но на самом деле это не так.

Если есть выбросы и распределение “Паранормальное”, то мы можем рассчитать усеченные статистики. Тоже арифметическое среднее, но мы отбросим самый маленький и самый большой результаты. Так делают в спорте, когда судьи оценивают, две крайние оценки отбрасывают при расчете.

3. Робастные статистики

Тоже вариант расчета для паранормальных распределений с выбросами. Это статистики, которые сами по себе не чувствительны к выбросам.

3.1 Моду – это самое распространенное значение

Мода незаменима для номинальных распределений, на непрерывных, дискретных и порядковых она дает не самые лучшие результаты. Если посмотреть на выборку зарплат, то единственное значение, которое встречается 2 раза – это 15 000 руб. Это и есть Мода.

Мода подходит для бимодальных распределений. Например, когда есть данные по расходу бензина в городе (для пробок) и на трассе (тогда распределение будет выглядеть именно так). Или когда есть средний бал ЕГЭ в российских школах и есть 2 типа школ: обычные и специальные и в подготовке детей в обоих школах большой разрыв.

Такое распределение говорит о том, что есть какие то группы, которые возможно есть смысл рассматривать отдельно.

3.2 Медиана (подкласс робастных статистик)

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

Пример на зарплатах в компании:

Для значений с выбросом: 12000 15000 15000 16000 20000 25000 27000 28000 30000 50000 150000
- Мода = 15000
- Медиана = 25000
- Среднее = 35272
Итого, если есть выбросы, то лучше использовать Усеченные или робастные статистики.
November 5, 2017
Типы данных в анализе данных и вычисление выборочной квантили

Номинальные – содержат меньше всего информации, принадлежность объектов к определенной группе. Мужчины, женщины; совы, жаворонки;

Порядковые – тоже содержит принадлежность к группе, но кроме того определено и отношение порядка между значениями. Насколько вы счастливы по шкале от 1 до 9.

Дискретные (интервальные) – и отношение к группе и порядок, но еще цифры означают сами себя и кроме порядка у нас определено расстояние между значениями. Не просто 2 < 5, но еще и 2 меньше 5 ровно на 3. И 4 меньше 7 ровно на те же 3.

Непрерывные – дни, часы, секунды, рубли, копейки миллионы.

Выборка

Допустим у нас есть случайная величина ξ (кси) и у нее есть некоторый закон распределения ξ = F_ξ(x). Мы работаем не со случайной величиной, а с некоторым набором реализации данной случайной величины.

Наблюдения X₁,…,X_n должны удовлетворять следующим правилам, чтобы предотвратить смесь выборки (типа смесь выборки очень плохо).

1. Независимы друг от друга

2. Одинаково распределены

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

Выборка – это некоторый конечный набор реализации случайной величины, которой мы извлекаем из некоторой генеральной совокупности.

Порядковая статистика (больше одинаковых терминов богу терминов) –

Используется для получения выборочных квантилей – значение, которая имеющая у нас случайная величина не превосходит с заданной вероятностью α.

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

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

1. Упорядочиваем нашу выборку X₍₁₎< X₍₂₎< X₍₃₎< … < X_(n). Строим вариационный ряд.

2. Берем выборочную квантиль, как порядковую статистику, где номер порядковой статистики определяется как целая часть от произведения нужной нам вероятности на объем выборки. t_α = X_([α*n]), где α – заданная вероятность, n – объем выборки.

Пример

Есть некая выборка кликов по фирме в день и мы хотим подсчитать больше какого количества кликов получит данная фирма с вероятностью 90%?

1. Мы упорядочиваем выборку, т.е. строим вариационный ряд.

2. В этом случае нам нужна 10% выборочная квантиль. α = 0,9 => 1- α = 0,1

3. Так как объем выборки у нас равен n = 22 и нам нужны 10%, то мы получаем, что нам нужна вторая порядковая статистика [(1 – α)*n] = [0,1*22] = [2,2] = 2

4. Вторая порядковая статистика t_0,1 = X₍₂₎ = 214

5. По имеющейся у нас выборке, данная фирма получит больше 214 в день с вероятностью 90%

October 29, 2017
Распределения случайных величин

Когда вы работаете со случайными величинами всегда нужно знать к какому распределению они принадлежат.

Равномерное непрерывное распределение

Экспоненциальное непрерывное распределение

Экспоне́нта — показательная функция $f(x)=\exp(x)=e^{x}$ , где $e$ — число Эйлера $(e\approx 2,718)$ .

Пример:

Нормальные непрерывные распределения

Коэффициент сдвига (μ) – то, насколько центр сдвинут по оси Х.

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

Логонормальные непрерывные распределения

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

Задачка

Если данные распределены логнормально со значениями 5 (коэф. сдвига) и 1 (коэф. масштаба). Какова вероятность, что страничка компании получит количество кликов в интервале от 150 до 200?

Если сперва значения прологорифмировать, то получим ту же самую цифру

Дискретные величины

Распределение Бернулли

значения 0 или 1. Подбрасывание монетки.

Математическое ожидание (для случайной величины распределенной по закону Бернулли) равно просто вероятности успеха. Mξ = p

Дисперсия (для случайной величины распределенной по закону Бернулли) Dξ = pq = p(1-p); q – вероятность неудачи.

Пример: Подбрасывание монетки, CTR баннера.

Биномиальное распределение

Мы проводим n испытаний и в каждом конкретном случае работаем с величиной распределенной по закону Бернулли.

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

Пример:

Успеет ли девушка из колл центра, которая совершает до обеда 30 звонков, дозвониться до 25 фирм? Если вероятность дозвона по статистике P = 0,53; объем выборки n = 30 звонков. P {ξ ≥ 25} -?

Для решения нужно подсчитать значение функции вероятности для значений p25, p26, p27, p28, p29, p30 и сложить их вместе

Итого: шансов у девушки очень мало дозвониться до 25 или более фирм из 30ти попыток.

October 29, 2017
Основы теории вероятностей (терминология)

Терминология

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

Элементарный исход (ω, “омега”) – это любой возможный исход случайного эксперимента. Пример: выпадение какой либо грани.

Пространство элементарных исходов (ω, “омега”) – множество всех возможных элементарных исходов эксперимента.

Ω = {ω₁,ω₂,ω₃,ω₄,ω₅,ω₆}

Случайное событие – подмножество пространства элементарных исходов случайного эксперимента. Пример: в случае с кубиком, нас интересует выпадение четного количества очков.

Случайная величина (ξ, “кси”) – функция, ставящая в соответствие каждому элементарному исходу некоторое число из множества (в общем случае) действительных чисел. Пример: Если кубик имеет не пронумерованные, а цветные грани, то мы каждой грани назначаем некоторый вес (действительное число) и это позволяет перейти к оперированию числами.

ξ: Ω → R

Вероятность (P) – это мера, которая выражает возможность данного события по отношению к другим исходам.

m – объем пространства элементарных исходов

A – случайное событие эксперимента

k – объем множества элементарных исходов

P (A) = k / A

Пример: выпадения четного количества очков на кубике пространства элементарных исходов объема 6. Множество элементарных исходов, которое соответсвует интересующему нас случайному событию – 3.

Статистическая вероятность

Что делать, если мы не можем четко определить ни пространство элементарный исходов, ни множество элементарных исходов, которое соответствует интересующему нас случайному событию? Проводим некоторое количество экспериментов.

A – некоторое случайное событие. Которое нас интересует как результат эксперимента, которое может произойти, либо не произойти.

n – количество экспериментов. Выборка реализации случайного эксперимента.

n_{A –}количество удачных экспериментов

Частота выпадения A и называется статистической вероятностью.

P* (A) = n_A/ n

Чем больше количество экспериментов, тем точнее статистическая вероятность оценивает некоторую истинную вероятность события, которая в общем случае нам неизвестна.

Свойства вероятности

Первое свойство вероятности

Вероятность несуществующего события равно нулю

P (Ø) = 0

P – вероятность

Ø – несуществующее событие

Второе свойство вероятности

P (Ā) = 1 – P(A)

A – некоторое событие

Ā – обратное событие

Третье свойство вероятности

Если событие A вложено в B, либо входит в B, то вероятность возникновения A меньше, чем вероятность возникновения события BЕсли A ⊃ B, то P(A) ≤ P(B)

Следствие третьего свойства

Четвертое свойство вероятности

Вероятность любого события, всегда находится между 0 и 1

0 ≤ P(A) ≤ 1

Пятое свой свойство вероятности

P(A∪B) = P(A) + P(B) – P(A∩B)

Свойство независимых событий

Свойства A и B называются независимыми, если вероятность их совместного события равна произведению вероятностей их событий по отдельности.

P(AB) = P(A)P(B)

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

Характеристики случайных величин

Случайная величина – функция, перевода из множества элементарных исходов в множество действительных чисел.

Непрерывные случайные величины – переводят пространство элементарных исходов во множество действительных чисел.

Пример: Время до какого то события, до прибытия транспорта на остановку.

Дискретные случайные величины – переводят пространство элементарных исходов в некоторое конечное, либо, в общем случае, счетное множество. Пример: подбрасывание игрального кубика. Переводит из пространства элементарных исходов в 6ть граний, в числовое пространство от 1 до 6ти.

Функция распределения вероятностей

Функция распределения – это вероятность попадания случайной величины в интервал от -∞ до x

F_ξ(x) = P{ξ≤x}, x ∈ R

Свойства функции распределения

Функция плотности

Используется для непрерывных случайных величин. Показывает нам частоту с которой случайная величина принимает те или иные значения

Свойство функции плотности

Площадь под функцией всегда равна единице. Интеграл по всей области значения всегда равен единице.

Функция вероятности

(для дискретных случайных величин)

P{ξ = x_k} = p_k

Квантиль

Квантиль – это значение, которое случайная величина не превышает с какой то заданной вероятностью.

t_α = F^-1(α)

Чаще всего квантили считают для значений 0,25; 0,5; 0,75 – это квартили.

Математическое ожидание и дисперсия

Математическое ожидание – среднее значение, которое принимает случайная величина (функция случайной величины).

Дисперсия – это мера отклонения случайной величины от ее математического ожидания

October 29, 2017

Основы управленческого и финансового учета

Основная задача финансового учета – предоставление информации для принятия решений. Управленческий учет.

Принципы финансового учета

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

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

Дебиторская задолженность – это задолженность клиента после того, как я выполнила обязательства (засчитала себе выручку), но клиент денег не перевел за оказанную услугу.
Кредиторская задолженность – клиент перевел мне 1 000 000 рублей, но я не отгрузила товар (не исполнила обязательств) и не вернула обратно 1 000 000 рублей.

Три основных формы отчетности

Отчет о финансовых результатах
Отчет о движении денежных средств
Баланс

Отчет о финансовых результатах

Еще называется Форма №2 РСБУ, Отчет о прибылях и убытках (ОПиУ), Отчет о доходах и расходах, Statement of Earnings, Profit and Loss statement (P&L, PNL), Income statement.

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

Прибыль = Выручка – Расходы
Рентабельность = Прибыль/ Выручку

Форма отчета о прибылях и убытках
+	Выручка
–	Операционные (текущие) расходы
	EBITDA
–	Амортизация
–	Проценты по займам
	Прибыль до налогообложения
–	Налоги
	Чистая прибыль

Как подсчитать выручку?

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

Для построения прогноза выручки и нахождения боттелнека нужно определиться с воронкой продаж.

Принципы классификации операционных расходов

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

Подсчет валовой прибыли и анализ эффективности направлений бизнеса

Прямые расходы – можно четко понять к какому направлению бизнеса мы их относим (контракт/ проект/ проектная команда или менеджер / единица продукции).
Косвенные расходы – расходы направленные на все направления нашего бизнеса и мы не можем их разделить на проект1, проект2 или контракт1, контракт2. (ЗП бухгалтера, аренда офиса)

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

Главный критерий оценки проектов/ продуктов – ВАЛОВАЯ ПРИБЫЛЬ = выручка проекта/продукта – прямые расходы (проекта/продукта).

Расчет маржинальности бизнеса для составления прогнозов и вычисления точки безубыточности

Переменные расходы – изменяются с изменением объема производства или объемом оказанных услуг. (СМСки на транзакцию, эквайринг платежной системы, …)
Постоянные расходы – не изменяются с изменением объемов производства или объема оказанных услуг. Внутри одного операционного цикла не меняются. (Фиксированная часть ЗП, Освещение, Аренда, …)

Точка безубыточности (ТБУ) – объем выручки, который покрывает все операционные расходы. Прибыль в ТБУ равна нулю.

Чтобы рассчитать ТБУ необходимо знать:

Маржинальность бизнеса (Gross Margin)
Размер постоянных расходов

EBITDA

Если не возникает оборотного капитала (Запасов, Дебиторской задолженности, Кредиторской задолженности), то EBITDA = OCF (Operating Cash Flow) – операционный денежный поток.

October 22, 2017

Подходы к организации требований
Product Backlog

Product Backlog – список фич, которые команда планирует реализовать.

Состоит из:
- Пользовательских историй (User Stories)
- Багов (Bugs)
- Рабочих задач (Work Task) – например, “настроить билд окружение”, “поднять тестовый сервер”,
- Исследовательских задач (Knowledge Tasks) – например, найти и разобраться как работает js библиотека отрисовки графиков.
Story Maps

Используется для визуализации бэклога. Группировка историй из бэклога в функциональные категории для визуализации. Позволяет выделить наиболее важные/ полезные / в которых основная ценность для пользователя фичи (core features) в верхней части карты. Что позволяет релизить сперва основной функционал, а все “рюшки” и “прыгающие пони” можно будет добавить после.
August 13, 2017
Управление требованиями в Agile
Плюшки управления требованиями в гибких методологиях разработки в том, что изменения требований максимально приветствуются на любой стадии разработки проекта (=фичи). Инструменты управления требованиями в Agile (сбор, анализ, приоритезация, верификация) заточены под постоянное внесение изменений в требования к продукту, прототипирование и быстрое внедрение на прод для получения фидбэка.
Предполагается, что с первого раза невозможно “угадать” потребности пользователей поэтому нужно уметь быстро доставлять фичи на прод (для проверки концепций) и быстро модифицировать функциональность не зарываясь при этом в техническом долге.

Терминология:
1. Проект – процесс по созданию продукта (=фича).
  - Имеет четкое начало и конец, т.е. ограничение по времени. Время выполнения проекта может быть хоть один день, хоть два года. У нас чаще всего – это “пока не сделаем” или “не устанем делать”, но вот такой у нас time management:).
  - Ограниченный функционал (функционал может уточнятся/ изменяться на каждой фазе (=итерации) проекта).
2. Продукт – некий функционал, который доступен пользователю.
1. Бизнес требования

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

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

Бизнес требования (Устав проекта по PMI, Project Vision)

Для чего: бизнес требования выводятся непосредственно “заказчиком” продукта, в нашем случае это учредители компании или менеджер. Бизнес требования это некое видение продукта (=фичи), концепция (которая конечно может и будет корректироваться после релиза продукта). Некая идея, почему мы вообще собираемся вбухать время, силы и деньги в текущий проект. А так же очень общее направление работы для команды продукта куда развивать проект.
- Обоснование проекта. Зачем нужен проект. Желательно по SMART (Specific, Measurable, Attainable, Relevant, Time-related – https://en.wikipedia.org/wiki/SMART_criteria). Полезно иметь некую цель, чтобы можно было постфактум проанализировать что в итоге получилось сделать, что пошло не так и какие предположения были не верны в начале. Такой подход позволяет давольно быстро набирать опыт и накапливать экспертные знания.
- Возможные альтернативные цели проекта. В случае, если проект “забуксует” в одном из направлений всегда можно будет переключится на альтернативное.
Бизнес правила (Ограничения проекта по PMI)
- Privacy Policies (Пример: обработка и хранение персональных данных )
- Brand Uniformity requirement (Пример: Единый стиль оформления VL.ru, из за несоблюдения этого правила каждый новый дизайнер рисует новый вид влрушечки и в итоге у нас вакханалия в проектах)
- Government Regulation (Пример: ограничения на рекламу табака, хранение паспортных данных)
- …
2. Пользовательские требования

Пользовательские требования это требования конечных пользователей продукта (End Users) к разрабатываемому продукту.

Инструменты для представления требований Agile:

Use Case (Use Case Diagram)

Концепт был разработан в 1982 Иваром Якобсоном и значительно популяризирован Алистером Коберном. Способ определения, уточнения и организации деталий задачи.
Элементы :
- Название пользовательского сценария
- Актеры (роли)
- Цель
- Триггеры – то что позволяет сценарию начаться. Например: нажатие кнопки.
- Предусловия (pre-conditions) – условия, которые должны быть выполнены перед тем, как случится условие
- Постусловия (post-conditions)
- Основной сценарий – “Sunny Day” scenario. Сценарий когда все идет “как надо”.
- Альтернативные сценарии
- Исключения
- Параметры (qualities).
Литература:
- Use Case Examples – Effective Samples and Tips
- Use case definition – ссылки на подробные описания
- Алистер Коберн – Современные методы описания функциональных требований
Wireframes (mockups)

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

Литература
- A Beginner’s Guide to Wireframing
- Examples of wireframes on Tumblr
- Мы используем Wireframe Sketcher.
Story Boards

В нашем случае (мое мнение) очень избыточная практика. Обычно используется для презентации проекта заказчикам или для генерации идей. Визуализирует прохождение по “sunny day” сценарию.

User Stories (Story Maps)

Простой способ для представления требований к системе. Благодаря определенной форме все требования приводятся к единому формату. Их легко писать, легко читать, легко оценивать и прериотизировать.

Формат описания: Как ______, я хочу ____, для того чтобы _____ .

Как ________ роль для кого применяется это требование “кто?” (пример: авторизованный пользователь; модератор; менеджер билетов онлайн; бухгалтер)_____________,
Я хочу _______ задача или функция которую хотят сделать “что?” (пример: видеть список идущих сегодня фильмов в порядке популярности; ) ___________,
Для того чтобы _______ указываем цель, зачем эта пользовательская история вообще нужна “зачем?” (пример: я могу быстро выбрать куда сходить в кино)________________________.

Story #1 Как водитель с загоревшейся лампочкой я хочу просмотреть все ближайшие заправки, чтобы найти более удобную в данный момент.Epic: Как водитель с загоревшейся лампочкой бензина я хочу быстро найти ближайшую хорошую заправку, чтобы заправиться качественным бензином.

Story #2 Как водитель с загоревшейся лампочкой я хочу видеть стоимость и марку бензина рядом с названием заправки, чтобы выбрать дешевый и качественный бензин.

Проверка качества написанной истории (Bill Wake)

INVEST
- Independent (Независимая) – нужно следить, чтобы истории были независимы друг от друга, чтобы можно было реализовать каждую отдельно от остальных. Это позволяет выкинуть любую историю из спринта или изменить порядок выполнения историй.
- Negotiable (Обсуждаемая) – должна быть достаточно общей, чтобы команда могла предлагать реализации, подходы и решения.
- Valuable (Полезная) – должна добавлять ценность проекту, чтобы команда не делала всякой бесполезной фигни.
- Estimable (Оцененная) – должна быть возможность оценить сколько реализация займет времени. Если нельзя сказать за сколько история будет реализована, значит это скорее всего не история, а эпик (Epic). И его можно побить на меньшие истории, которые уже можно оценить.
- Small (Компактная) – даже если мы смогли оценить историю в 3 месяца, это не значит, что она маленькая. Небольшие куски значимого функционала легче оценивать, деплоить и быстрее собирается фидбэк.
- Testable (Тестируемая) – обычно покрывается приемочными тестами.
Epic – большой кусок функционала, который невозможно сделать за относительно короткий период времени (например неделю). Обычно появляются вначале разработки фичи, дальше дробится на истории.

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

Testable / Definition of Done / Acceptance Tests

Приемочные тесты служат для проверки, что требования выполняются и для проверки адекватности пользовательской истории. Критерии приемки (acceptance criteria) пишутся на основе пользовательских историй и служат для уточнения требований к системе.
Пользовательская история #1: Как пользователь, я хочу ввести данные моей банковской карты (Visa или MasterCard), чтобы оплатить билеты удобным способом.

Критерии приемки (Acceptance Criteria):
1. Оплата может производится карточкой Visa
2. Оплата может производится карточкой Master Card
3. При вводе номера карты, тип карты должен вычисляться автоматически
4. Пользователь должен видеть только поля соответсвующие выбранному методу оплаты
Приемочные тесты для критерия приемки #1 (Acceptance Tests):
- Ввести данные карты Visa в поля ввода
- Ввести 3ds код
- Подтверждение, что оплата поступила
- и т.д.
3. Функциональные требования

Behaviour that product should do or support. Поведение, которое продукт должен выполнять и поддерживать. https://en.wikipedia.org/wiki/Functional_requirement

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

Information Flow Diagram (http://myyee.tripod.com/cs457/dfd.htm)

4. Не функциональные требования (Сорт продукта, управление качеством по PMI)

“How well” a product must perform. Как хорошо продукт должен выглядеть и функционировать. Доп. требования к функциональным требованиям. Функциональные требования – что должен делать продукт, не функциональные – как хорошо продукт должен это делать.
- Accuracy Requirements – точность вычислений, параметров, сенсоров. Пример: вычисляя сумму мы должны округлять до N знаков запятой,
- Dependability Requirements – система логирования изменений при редактировании событий на Афише.
- Security Requirements
- Usability Requirements
- Efficiency Requirements – приложение, навигатор по городу не должно жрать батарейку и должно позволять использовать навигатор N часов без подзарядки (Space, Time, Power, Resource ).
- Performance Requirements – response time, hitrate
- Maintainability Requirements – требования к расширяемости превоначального функционала.
5. Дополнительные требования

External Interface Requirements – если продукт является частью большой системы, то требования к внешним интерфейсам позволяют обозначить как продукт взаимодействует с другими системами. Например: Продукт “Продажа билетов в кино на kino.vl.ru”, является частью системы в которую входят сервера кинотеатров и театров, платежные системы, биллинг барахолки, тикет система VL.ru, конечные пользователи, операторы call центра и так далее. (Примеры инструментов для описания: Data Flow Diagram, System context diagram)

Physical Setting Requirements – Считывания штрих кода на билетах для приложения контроллер должно быть возможно в темных подвальных клубах со стробоскопами, громкой музыкой и нестабильной связью.

Development Constraints – технологии, конвенции, стандарты и процесс. Например: мы используем фреймворк Symfony2 для разработки новых продуктов.

6. Управление качеством требований

Вопросы, которые можно задать для выявления разных уровней требований

If you want to elicit business requirements
- What problem are you trying to solve?
- What’s the motivation for solving this problem?
- What would a highly successful solution do for you?
- What’s a successful solution worth?
- Who could influence this project?
- Who could be influenced by this project?
- Are there any related projects to this one?
- Which activities should be included in the scope?
- Could there be any unintended consequences of the new system?
If you want to to elicit business rules
- What policies must the product conform to?
If you want to elicit user requirements
- What goals could this product help you accomplish?
- What problems do you expect this product to solve?
- What words would you use to describe the product?
- What aspect of the product excites you?
- What aspects are most/least valuable to the users?
If you want to elicit non-functional requirements…
- What qualities (e.g., efficiency, security, reliability, etc.) are critical for the specific parts of the product?
If you want to elicit external interfaces features…
- What events must the product respond to?
- Can you describe the environment in which the product will be used? If you want to reveal exception conditions…
- Would anyone ever want to …?
- Could … ever occur?
- What should happen if …?
If you want to reveal more constraints…
- What is most important to you about the product?
- How would you judge whether the product is a success?
- How should the product be different from the way things are done now?
- Is there anything else we should be asking you?
If you want to dig to reveal assumptions, rationale, real needs…
- Please could you help me to understand why …? ○ e.g., why something applies, is relevant, is really required, is high priority, is the way it is, etc.
Признаки качественных требований
- Correct – пользовательские истории должны описывать тот функционал, который нужен.
- Complete – должны быть учтены все необходимые требования. Для проверки удобно использовать Story Maps
- Clear – историю легко понять и она имеет только одну интерпретацию. Для проверки требований используется Requirements Technical Review and Repair или Wireframes.
- Consistent – требования не должны противоречить друг другу.
- Verifiable – должны быть тестируемы и проверяемы с достижимой целью.
- Feasible – история должна быть возможна для реализации доступными команде технологиями, инструментами и навыками.
- Traceable – только необходимый и достаточный код будет написан для каждой истории и функционал будет протестирован.
- Manageable – каждый элемент требований (пользовательские истории) может быть изменен не влияя на другие элементы. Не достижимо, но стоит стремиться. Решение: треччить зависимости пользовательских историй.
- Simple – без ненужных деталей реализации и не перегружены предлагаемыми решениями проблемы. Пользовательские истории служат для определения “что” за фичу нужно реализовать, но не “как” она должна быть реализована.
Слова для выявления неопределенности в формулировке требований:
- Количество. Пример: Как пользователь, я хочу купить билет, чтобы сходить в кино. Вопросы: один пользователь может купить только один билет?
- До / после / следующий. Пример: “как пользователь я могу удалить последний комментарий, чтобы…” -> “как пользователь я могу удалить последний созданный мною комментарий, …”
- Все / никто
- И / или. Пример: Как модератор, я хочу иметь возможность удалить комментарий и заблокировать пользователя, чтобы комментарии не соответствующего содержания не появлялись на сайте. Вопрос: это два отдельных действия? или при удалении нужно блочить пользователя.
- Оба / каждый
Литература по теме управления требованиями:
- Creating a lean, mean requirements machine from Atlassian
- Four techniques for defining project scope
- Business Requirements vs. Functional Requirements
- Agile PMO – сравнение гибких и классических методологий
- Ambiguous-Requirements-Checklist.pdf – пример чеклиста для требований на анлийском, из которого можно получить представление как пишутся требования.
- Информационный стиль в написании текстов – сайт Ильяхова, он больше заточен под продающие тексты, но идею и принципы оттуда можно почерпнуть. И, на сколько я знаю – это лучшее, что есть на русском.
August 13, 2017
Что такое дизайн спринты?
Есть два источника по которым я разбиралась, что такое дизайн спринт: Фреймворк разработанный в Стенфорде (курсы на курсере) и его адаптация под разработку стартапов в Google (гайды гугла и курс на udacity).

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

Для каких ситуаций подходит?
Решения непонятных, нетривиальных задач, когда нужно выйти за рамки, так как “застопорились”, непонятно как и что делать. Например, есть проблема: “Падает посещаемость и непонятно в чем причина и как исправить” или “Стопор в разработке стратегии продукта, не понятно куда идти, какую фичу, направление делать” или “Нет хороших интерфейсных решений, все тупят ничего нормального предложить не могут”.

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

Для каждого из этапов привлекаются конечные пользователи продукта и экспертов из области по определенным правилам.

Какие варианты дизайн спринтов бывают
(в английском под словом дизайн подразумевается не только рисование интерфейсов, а вообще создание чего либо):
- Дизайн спринт по проблемным сценариям – нахождение и выделение проблем и потребностей пользователей в определенной области. В результате получаются знания рынка, бизнес задач, конкурентов, пользователей, свежий взгляд на текущий продукт, проблемы пользователей и их потребности. И, как результат набор стратегических фич согласованных и понятных всем участникам. Ну и эффект “владения идеей”, все этой стратегией болеют, так как сами придумывали и вырабатывали фичи и верят в них.
- Мотивационный дизайн спринт – до того как реализовывать какое то сложно решение можно провести спринт по “имитации” продукта удовлетворяющего пользовательские потребности и проверить какое решение будет действительно полезно конечному пользователю. Не интерфейсная его часть, а именно концепт решения. Тупой пример из учебника: Мы поняли, что у пользователя очень шумная машина. И придумали, что его спасет супер громкая магнитола. Имитируем решение и получаем кучу инсайтов, что это не удобно и возможно идеи, что лучше сделать звукоизоляцию.
- Юзабили спринт – генерация прототипа интерфейсов и подтверждение, что конкретное наше интерфейсное решение пользователям удобно, полезно и с помощью него они могут решить проблему.
- Архитектурный дизайн спринт – для тех. команды для разработки сложных систем, когда в одного рискованно принимать какие то базовые решения. Тоже обязательно представитель от бизнеса, чтобы можно было задавать вопросы о том что и как работает в мире. Это уже для супер сложных систем в которых переделка стоит дорого.
Как проходит дизайн спринт?
За основу дизайн спринтов взята модель из design thinking (что то отдаленно напоминающее наш ТРИЗ – теория решения изобретательских задач).
Делится на несколько этапов (в разных источниках могут быть разные примеры, в некоторых источниках 6 этапов) В общих чертах этапы следующие:
1. Изучить/понять, определить/обозначить
2. Нагенерить разнообразных идей (брейнсторминг)
3. Решить/ выбрать
4. Запрототипировать, визуализировать
5. Проверить, протестировать, провалидировать
1. Изучить

На этом этапе задача команды разнообразных специалистов как можно больше понять о текущей ситуации, о проблеме, контексте, решаемой задачи. Очень важно именно разнообразие опыта работы в области, поэтому в этом совещании должны участвовать представители бизнеса, технологий, UX, аналитиков, маркетологов. На этом этапе важно привлекать пользователей и экспертов. Обмениваться знаниями. Для этого есть список упражнений с четкими инструкциями, который позволяет лучше понять друг друга, услышать и объяснить. Попытаться переформулировать или уточнить проблему. На этом этапе важно не перескакивать к решению. На собственном опыте могу сказать, что это очень сложно услышав или осознав крутую “проблему пользователя” не придумывать для нее решение. Все идеи на этом этапе записываются и визуализируются в определенном формате, чтобы к ним можно было всегда вернуться. Конкретные варианты как это сделать есть в гайдах по дизайн спринтам.

2. Нагенерить разнообразных идей (брейнсторминг)

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

3. Решить/ выбрать

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

4. Запрототипировать

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

5. Проверка

Все варианты тестирования. Если речь идет о потребностях пользователей по которым мы строим стратегию, то это могут быть дополнительный исследования рынка. Или создание опроса, или создание прототипа для тестирования или MVP.

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

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

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

Есть варианты когда весь спринт укладывается в один день.

Так как метод используется для решения именно нетривиальных или сложных задач и принятие сложных решений, то речь идет о задачах выработки стратегических фич, например. В обычном режиме принятие таких решений группой специалистов может занимать до полугода. В сравнении с этими масштабами – пять дней дизайн спринта выглядят отличной альтернативной. К тому же дальше, с результатами этого метода начинают работать по lean startup подходу, что позволяет минимизировать риски. Т.е. смысла “рассусоливать” и до последнего искать единое верное решение – нет, так как бизнес процессы использующих этот подход контор заточены под быструю просейку и опробацию идей на рынке.

То что гайдбук выпустил гугл и “распиарил” его, не значит, что подход плохой и не стоит его использовать. Только все нужно делать к месту и с умом.

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

2. Очень важен опыт и навыки ведущего.

2.1 Любые групповые активности чреваты возможными конфликтами и неэффективностями. Для этого важно, чтобы ведущий обладал знаниями и опытом управления групповыми динамиками. Пример: из за нераспределенных ролей в команде два человека (тех. лид и руководитель отдела продаж, например) начинают “спорить о скобочках” (о какой то тупой фигне) и в итоге, если у ведущего недостаточно опыта и знаний все совещание превращается в холливор и выяснение кто круче. Часть этих проблем решается гайдлайнами в методичке гугла, но это просто подсказка как проводить совещания, а опять же, не серебряная пуля.

2.2 Ведущий должен быть максимально не аффилирован с группой. Из моего опыта проведения ретроспектив и коллективных совещаний, я поняла, что очень сложно (если ты ведущий) не продавливать свое мнение, а помогать группе приходить к консенсусу. Я вообще решила, что для меня это невозможно. Ведущим должен быть человек со стороны, интерес которого только в том, чтобы команда пришла к решению – это мое мнение, мне кажется это должно быть так.

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

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

5. Культура и структура организации должна быть заточена под принятие решений командой и команда должна быть. Поэтому этот метод в первую очередь позиционируется для стартапов, которые еще не успели нарастить мощный бюрократический аппарат “принятия решений”. Если сейчас в какой нибудь большой корпорации со сложившейся историей 15ть человек проведут дизайн спринт и примут какие то даже хорошие решения, все это может запросто быть похоронено на местах. Так как генерация решений и их внедрение и реализация – не одно и то же.

Итого:
Дизайн спринт – это просто супер умное название для специфически структурированного формата группового брейнсторминга.
Чтобы эта штука заработала и были позитивные результаты ее должен проводить опытный ведущий (фасилитатор), который сможет организовать группу. Т.е. есть у ведущего должен быть минимально необходимый порог знаний и навыков о том как проводить групповые совещания вообще, чтобы успешно воспользоваться “методичкой”.
Это всего лишь один из методов проведения групповых совещений, самые лучше результаты он дает в комбинации с подходами: бизнес моделирования рынков, итерационной проверки идей, гибкой организации и т.д.
У Стэнфорда более сложный и общий вариант, для решения любых задач. У Гугла упрощенный вариант более заточенный под стартапы и вывод новых продуктов на рынок.

Чем отличается от обычного брейнсторминга и почему все так с ним бегают.
“Методичка гугла” – это очень хорошее практическое пособие по проведению групповых совещаний нацеленных именно на создание и опробирование решений в IT. До дизайн спринтов все эти теории были и практические упражнения, некоторые не новые, но гугл первый собрал их в таком доступном, понятном и готовом для применения виде с практическими указаниями и рекомендациями. А так же завязал и адаптировал под специфический процесс разработки продуктов в IT, что тоже не мало и не очень тривиально.

Источники и что почитать посмотреть на тему:
https://en.wikipedia.org/wiki/Design_sprint
http://blog.udacity.com/2015/07/introducing-googles-design-sprint-process-in-product-design-new-course.html
https://developers.google.com/design-sprint/
https://www.coursera.org/learn/uva-darden-running-design-sprints
August 13, 2017
Структура “Технического задания” к сайтам
Техническое задание
1. Статус документа – дисклеймер, что данный документ и его приложения аннулируют все предыдущие документы и договоренности касательно структуры и функциональности сайта, его сервисов и страниц.
2. Используемые термины и условные обозначения: Модуль, Сервис, Визуальные редактор, Объекты данных и т.д
3. Требования проекта – Система управления сайтом (CMS), Возможности системы, Хранение паролей и т.д.
4. Технические требования – Требования к выдерживаемым нагрузкам, К программному и аппаратному обеспечению сервера, Языковые версии, Браузеры, Разрешения экранов,…
5. Структура сайта
  1. В каком меню располагается
  2. Глубина вложенности
  3. Используемый шаблон
6. Общие правила вывода страниц
  1. Механика меню
  2. Ограничение доступа
  3. Постраничная навигация
  4. Формат цены
  5. …
7. Общие элементы сайта
  1. Описание меню
  2. Обратная навигация
  3. Контактный телефон
  4. Блок счетчиков
  5. Блок копирайтов владельцев сайта
  6. Форма авторизации/регистрации
  7. Блок корзины
  8. Баннер на внутренней стороне
  9. …
8. Страница проекта
  1. Шаблон
  2. Текстовое описание
  3. Объекты данных
    
    Название
    
    Тип поля
    
    Обязательное/ не обязательное
    
    Откуда берутся
November 20, 2016

Регион	Возраст	Доход
142	69	20 000
142	32	46 000
142	67	18 000
142	39	8 000
142	69	19 000
142	65	19 000

Blog

Полезные ссылки

Где брать информацию для PAM и TAM?

Где брать информацию для SAM?

Где брать информацию для SОM?

Создание нового продукта

Шаг 0. Создаем команду из специалистов способных запустить продукт.

Знания и навыки необходимые для вывода нового продукта на рынок

Шаг 1. Анализ предметной области. Рынок, видение, стратегия, концепт.

Предварительный этап проработки идеи

Основной этап проработки продукта

Шаг 2. Вывод продукта на рынок

Планирование работ по созданию первой версии

Работы по созданию продукта

Запуск проекта, фаза слабоумие и отвага

Первые результаты после запуска проекта

Шаг 3. Вывод продукта на стадию роста

Работа над конверсией основных сценариев/ воронок

Привлечение пользователей

Работа над фичей

Pivot? Как понять, что мы все сделали и можно переводить на поддержку из активной разработки?

Перевод продукта/фичи на поддержку из активной разработки. Поддержка продуктов на стадии рост-зрелость.

Тушение пожаров

Как создавать компании?

Медиапланирование

Подсказки по текстам объявлений

Обзор типов соответствия

Варианты составления объявления

Вариант 1

Вариант 2

Вариант 3

Good Metric

Критерий согласия Хи-квадрат

Как подсчитать основные меры вариативности?

Проверка на нормальность данных

Построение графиков плотности и распределения

Пример с расчетом среднего чека во всех заведениях Москвы.

Работа с пропущенными наблюдениями

Каковы причины?

Что делать с пропущенными данными?

Зачем вообще нужна выборка?

Какие бывают выборки?

Неслучайные выборки

Ошибки выборки

Коэффициент доверия Стьюдента (t).

Пример, все кафе Москвы

Доверительный интервал

Формирование видения для бизнеса, компании, продукта, отдела и т.д.

Миссия компании

SWOT анализ

Цель и план действий

Pie Chart

Горизонтальная столбиковая диаграмма

Вертикальная столбиковая диаграмма

Как показать совместные распределения признаков?

Визуализация совместных распределений

Методы графического анализа данных

1 метод – Эмпирическая функция распределения

2 метод – Гистограммы

Как построить гистограмму?

Как правильно выбрать количество интервалов?

Примеры гистограмм на больших выборках

Как интерпретировать результаты гистограмм?

1. Размах

2. Дисперсия

Несмещенная дисперсия

3. СКО – Среднеквадратичное отклонение

4. AAD – среднее абсолютное отклонение

5. MAD – медианное абсолютное отклонение

Примеры с изменение средних и разбросов зарплат

6. Межквартильный размах

Чтобы оценить по выборочным данным генеральную совокупность,

Как подсчитать меры среднего?

1. Среднее арифметическое

2. Рассчитать усечённые статистики

3. Робастные статистики

3.1 Моду – это самое распространенное значение

3.2 Медиана (подкласс робастных статистик)

Пример на зарплатах в компании:

Выборка