Простой способ достижения компромисса

Sprint

Я сейчас читаю книгу “Sprint“. Я еще в процессе, поэтому это не ревью, больше впечатления и мысли по поводу.

Книга написана одним из сотрудников Google Ventures  – подразделения Google, которое инвестирует в стартапы. Она про то, как очень быстро можно проверить, будет ли работать идея. Для венчурных фондов это важно, они все-таки в стартапы деньги вкладывают. Поэтому хороший метод, который докажет, что идея перспективная – это очень нужная в хозяйстве вещь.

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

Основная идея

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

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

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

В качестве альтернатив авторы приводят:

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

Запуск MVP (Minimal Viable Product) и его итеративное улучшение. Этот метод немного получше, но тоже неидеален. Если минимальный продукт окажется построен на ошибочной главной идее, то потом никакими итерациями это исправить не получится. К тому же, не стоит путать итерации с дизайном.

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

Способ договориться

Я вам обещала простой способ про договориться. И этот способ – не Sprint, но в них есть общее зерно. А именно – вначале оцениваем, потом принимаем решение. Я как раз сегодня благодаря этой книге вспомнила про один случай на работе, когда мне это очень помогло.

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

Условия задачи

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

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

programmer

Решение

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

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

Шаг 1

Мы придумываем всевозможные критерии, которые имеют отношение к нашему “бизнесу” (даже косвенно), и договариваемся о том, насколько этот критерий применим к каждому варианту.

Например, блины испечь намного проще, чем торт, поэтому у торта ставим простоту 0.2, а у блинов – 0.8. Если даже тут мы с Васей не можем договориться, то просто берем среднее по мнению Васи и Лары.

Допустим, получилось как-то так:

decide_matrix_2

Шаг 2

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

Допустим, получилось так:

decision_matrix_3

Шаг 3

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

decide_matrix

Готово! Метод волшебной таблички решил за нас, что победили тортики.

Кстати, в нашем реальном случае, критериев у нас было 30 или 40. Из них были очевидно очень важные (успеем ли мы к сроку, который мы пообещали нашему директору) – там все ставили 100 баллов. Ну а в остальных местах – на вкус и цвет, так сказать. И еще мы договорились, что мои баллы имеют +10% бонуса. Потому, что делать все-таки мне.

Почему оно работает?

Во-первых, над списком критериев и их применимостью не надо спорить. Вася хочет критерий доставки? Добавляем. Лара хочет критерий простоты? Добавляем. Тут нет точки конфликта.

Во-вторых, поставить применимость каждому критерию тоже можно даже без консенсуса. Лара считает, что тортики печь офигеть как сложно (0), а Петя, что терпимо (0.4)? Окей, выводим среднее в 0.2. Опять нет точки конфликта – все услышаны, все учтены.

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

Ну и в-четвертых, с математикой и демократией сложно спорить. Каждый был услышан. Все по-честному.