Crincum's Blog

Category: Конспекты лекций

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

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

    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

     

  • Оценка объема рынка

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

    •  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. Чем занимается.
    • Средний чек. Звонишь узнаешь у конкурентов, анализируешь прайс листы.
    • Количество заказов. Спросить работников, посмотреть номер заказа на чеке.
    • Конверсии. Общий поток, кто заходит на сайт, проходит мимо, и сколько из них конвертируется.

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

  • Google AdWords заметки

    Google AdWords заметки

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

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

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

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

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

    • Использовать ключевое слово в тексте объявления
    • Указать цену, информацию о спец предложениях (бесплатная доставка, акции)
    • Подчеркнуть уникальность своей компании, товаров и предложений.
    • Призывы к действию
    • Максимально релевантные страницы
    • Минимум 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: части ключевого слова

  • Lean Analytics – конспект книги

    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?
  • Гипотезы о согласии

    Гипотезы о согласии

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

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

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

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

    Позволяет проверять как простую, так и сложную гипотезы о согласии.
    1 этап. Группирование данных. Разбиваем область определения случайной величины на k непересекающихся интервалов. x(0),x(1),…,x(k)
    2 этап. Считаем количество наблюдений, которые попадают в каждый из интервалов. ni
    3 этап. Считаем частоту попадания в каждый из интервалов ni/n
    4 этап. Считаем теоретическую вероятность попадания в каждый из интервалов.
    Pi(Θ)=F(x(i),Θ)-F(x(i-1),Θ)

  • R подсказки названий функций для анализа данных

    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))
  • Что делать с неопределенными ответами (Да, нет, не знаю)

    Что делать с неопределенными ответами (Да, нет, не знаю)

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

    1. Если они неинформативны, то их можно кодировать как пропущенные. Отбрасывать, заменять на функцию от соседних и т.д.\
    2. Если они важны,
      • Если шкала порядковая, то”затрудняюсь ответить” кодируем самым большим числом. Например, вопрос о счастье. Оцените насколько вы счастливы от 1 – несчастен до 9 – счастлив. 10 – затрудняюсь ответить. Важно! Что при этом меняется тип шкалы, она становиться не порядковой, а номинальной. 10 выпадает из порядковой логики и оставляет качественно что то другое.
      • Если есть проблемы с вопросом. Т.е. больше половины респондентов затруднились ответить на вопрос. Это сигнализирует о проблемах с вопросом. Либо плохо сформулирован вопрос, либо люди не имеют мнения.
      • Если речь идет о затруднительных темах. Или не хотят рассуждать вслух.
      • Возможно есть проблема с работой интервьюиера. Например новый интервьюир может не дожидаться пока люди подумают и сформулируют мнение, а сразу невнятные “я не знаю”, записывают в неопределенный ответ.

  • Определение необходимого объема выборки

    Определение необходимого объема выборки

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

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

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

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

    N = 5802 заведения. Размер генеральной совокупности
    s2= 549093,84. Несмещенная дисперсия. Выборочная дисперсия – это оценка теоретической дисперсии распределения, рассчитанная на основе данных выборки относительно среднего значения в выборки. Дисперсия – мера отклонения случайной величины от ее математического ожидания. Математическое ожидание – среднее значение, которое принимает случайная величина (функция случайной величины).
    \Delta_{\overline{X}} = 100 рублей. Предельная ошибка.
    Мы знаем, что \overline{X} = 956 рублей. Средний чек для заведений из выборки.
    Подсчитаем вероятности для
    p1 = 95%
    p2 = 99%
    p3 = 99,9%

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

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

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

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

    1. Исключить пропущенные наблюдения. Но это приведет к потере информации.
    2. Заменить пропущенные наблюдения.
    Пример как можно заменить пропущенные наблюдения на примере данных социологического опроса о возрасте и доходе населения.
    Всего опросили 636 человек и 359 отказались отвечать.
    \overline{X} = 32 594 рубля, среднее значение
    t0,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. Построим гистограмму и дальше будем замещать пропущенные значения по очереди средним, медианой и т.д., чтобы поспосмотреть, что будет происходить с графиком.

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

    Видение, миссия и стратегия

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

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

    Шаг 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ти, чтобы поставить вехи для сверки с тем идем ли мы по выбранной стратегии или “что то пошло не так”:)

  • Графики для неметрических шкал

    Графики для неметрических шкал

    Pie Chart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

  • Графический анализ данных (гистограммы)

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

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

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

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

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

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

    Дано количество кликов по фирме в день

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

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

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

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

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

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

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

    k = 1 + [log2n]

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

    k = [√n]

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

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

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

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

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

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

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

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

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

    Для нахождения смесей выборки.

     

  • Как оценить по выборке генеральную совокупность? (Меры вариативности признака в генеральной совокупности)

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

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

    1. Размах

    Расстояние между двумя крайними значениями.
    Размах = (Max – Min)

    2. Дисперсия

    Дисперсия – мера разброса значений случайной величины (функции случайной величины) относительно её математического ожидания.  
    Учитывает каждый из объектов. Суммируем квадраты всех отклонений от среднего.
    Из минусов, мы получаем большое отклонение от шкалы исследования из за квадрата.
    ‾X‾ – среднее значение выборки или генеральной совокупности.

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

    Выборочная дисперсия – это оценка теоретической дисперсии распределения, рассчитанная на основе данных выборки относительно среднего значения в выборки.
    , где  Mη – математическое ожидание, pi – вероятность выпадения i-ой грани кубика (1/6), xi – случайная величина соответствующая i элементарному исходу, Dη – дисперсия случайной величины.
    На графиках видно, что даже на маленьких выборках несмещенная дисперсия сразу дает значения близкие к истинной дисперсии. Тогда как смещенная дает хорошие результаты только на больших выборках.

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

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

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

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

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

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

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

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

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

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

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

    • Принцип начисления – выручкой мы признаем факт исполнения обязательств перед клиентом, а не сумму денег пришедшую от клиента.
    • Принцип соответствия – затратами признаем те расходы, которые были направлены на получение выручки, т.е. на исполнение обязательств перед клиентом.
    • Дебиторская задолженность – это задолженность клиента после того, как я выполнила обязательства (засчитала себе выручку), но клиент денег не перевел за оказанную услугу.
    • Кредиторская задолженность – клиент перевел мне 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) – операционный денежный поток.

     

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

    Product Backlog

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

    Состоит из:

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

    Story Maps

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

  • Управление требованиями в Agile

    Управление требованиями в 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).


    Литература:

    Wireframes (mockups)

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


    Литература

    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 – без ненужных деталей реализации и не перегружены предлагаемыми решениями проблемы. Пользовательские истории служат для определения “что” за фичу нужно реализовать, но не “как” она должна быть реализована.

    Слова для выявления неопределенности в формулировке требований:

    • Количество. Пример: Как пользователь, я хочу купить билет, чтобы сходить в кино. Вопросы: один пользователь может купить только один билет?
    • До / после / следующий. Пример: “как пользователь я могу удалить последний комментарий, чтобы…” -> “как пользователь я могу удалить последний созданный мною комментарий, …”
    • Все / никто
    • И / или. Пример: Как модератор, я хочу иметь возможность удалить комментарий и заблокировать пользователя, чтобы комментарии не соответствующего содержания не появлялись на сайте. Вопрос: это два отдельных действия? или при удалении нужно блочить пользователя.
    • Оба / каждый

    Литература по теме управления требованиями:

  • Структура “Технического задания” к сайтам

    Техническое задание

    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. Объекты данных
        1. Название
        2. Тип поля
        3. Обязательное/ не обязательное
        4. Откуда берутся