Формулировка требований к продукту начинается с документов, которые нужны при его выводе на рынок (пресс-релиз и FAQ). Потом мы продолжаем работать над документами, которые приближают нас от пресс-релиза к реализации.

1Начинаем с пресс-релиза. Он должен простым языком описывать, что продукт делает, и почему он вообще существует — какую пользу он приносит, и какими свойствами он обладает. Максимально просто и максимально понятно. Это проясняет то, как продукт должен выглядеть со стороны.

2Потом FAQ. Тут мы отвечаем на вопросы, которые могут возникнуть у читателя при чтении пресс-релиза. Для чего, как и зачем его можно использовать. Вы должны поставить себя на место потенциального покупателя или уже пользователя продукта — и ответить на все их вопросы.

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

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

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

Источник: https://www.allthingsdistributed.com/2006/11/working_backwards.html

2Если мы делаем стартап — мы расхваливаем свою бизнес-модель.

#перечитываяклассику из давно опубликованного на тёмной стороне

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

Вывод №1. Как можно раньше выкатывайте первый вариант решения. Сколько бы мы пытались родить совершенный с самого начала вариант — на практике он всё равно окажется говном.

Вывод №2. Прежде чем усложнять или упрощать — сделайте хоть что-нибудь практическое.

Вывод №3. Разумный вариант — это результат упрощения.

Вывод №4. Если за четыре итерации мы не пришли к разумному решению задачи — значит, мы его не искали, а пережёвывали раз за разом одно и то же.

1Рассмотрим на примере коллцентра. Считаем, что обычное распределение тупых/умных обзвонщиков 80/20, клиентов заранее не готовых/готовых выполнить сложное целевое действие — тоже 80/20. Какая будет средняя конверсия в действие? В самом плохом случае — 0% (все готовые клиенты попадут на тупых обзвонщиков) с вероятностью 16% (20%*80%). Самый хороший — 20% (все готовые клиенты на умных обзвонщиков) с вероятностью 4% (20%*20%). Все остальное в среднем даст конверсию 4% (20%*20%) с вероятностью 80%. Усредненная конверсия получится около 3.3% (80%*4%+4%*20%).

2Какова стратегия коллцентра в случае стабильного количества обзвонов? Все время набирать новых кандидатов, чтобы найденными хорошими замещать старых тупых обзвонщиков. Через некоторое время процент хороших обзвонщиков превысит обычное распределение, и результаты существенно улучшатся вплоть до 20%.

3Готовы ли мы к масштабированию? Нет. Потому что нам надо будет срочно увеличивать количество новых обзвонщиков, а среди них опять будет 80/20 тупых на умных. Времени и ресурсов на найм и проверку в пять раз больше обзвонщиков, чем нужно для роста у нас наверняка не будет. В результате мы скатимся до средней конверсии в 3%.

4Как, например, можно с этим бороться? Если мы хотим получить сложное целевое действие, то, очевидно, что скрипт разговора состоит из нескольких частей — выяснение принципиального интереса, описание проблемы, нагнетание чувства срочной необходимости, предложение решения, снятие возражений и побуждение к выполнению действия. Первая часть о выяснении принципиального интереса — самая быстрая и формализуемая. Если мы разобьем наш коллцентр на две линии обзвона. На первичный обзвон мы будем сажать тупых с быстрым и простым скриптом. Они будут передавать 20% (как бы готовых) клиентов на вторую линию, где сидят умные. Предположим, что тупые обзвонщики, несмотря на простой скрипт, будет работать с точностью 50%, то есть давать false positive (передавать не готовых на вторую линию) и false negative (отсекать готовых). В результате на вторую линию перейдет только 10% (из 20%) готовых клиентов, которых там обработают умные обзвонщики. Конверсия в результате будет стабильных 10% при любом росте количества обзвонщиков, среди которых есть и тупые, и умные. Да, в 2 раза меньше, чем 20% идеальных, но в 3 раза больше, чем при масштабировании идеального коллцентра.

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

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

1Чем отличается реклама от пропаганды? Реклама говорит: «Пользуйся мной!». Пропаганда говорит: «Теперь это можно делать так».

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

Заинтересовался темой и собрал список моделей. У кого есть добавления, исправления, более хорошие примеры — велкам в комменты.

1Разные лицензии. Бесплатная лицензия для одних категорий пользователей и платная для других. Пример: MySQL.

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

3Продажа профессиональных услуг. Сам код распространяется бесплатно, но пользователи могут покупать обучение, техническую поддержку или консалтинг. Пример: Red Hat.

4Сертификация партнеров, самостоятельно оказывающих профессиональные услуги. Пример: Moodle.

5Продажа брендированного мерчандайзинга. Пример: Mozilla.

6Предоставление открытых программ как сервиса. По сути, плата за хостинг, заточенный под отслеживание обновлений, стабильность и масштабируемость использования. Пример: Gitlab, Wordpress.com.

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

8Предоставление сервиса, основанного в основном на открытом коде, но с добавлением собственного кода, дающего дополнительную ценность. Пример: Logz.io.

9Добровольные взносы пользователей. На поддержку разработки в общем или реализацию конкретных свойств в частности. Пример: GitHub недавно открыл такую возможность на своей платформе.

10Специальное лицензирование. Платное лицензирование отдельным компаниям для включения в свой коммерческий продукт. Пример: BSD в MacOS.

11Отложенная открытая лицензия. Новые версии становятся открытым кодом через некоторое время. Пример: MariaDB.

12Найти новую интересную работу, которую тебе предложат за доказанный опыт. В идеале еще и продолжить заниматься тем же самым. Пример: React, Angular.