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

Превращаем планирование в точную науку

Как определить вектор развития продукта и совместить его полезность и инновационность? Для того, чтобы наши новые разработки с большей вероятностью «попали в цель», было принято решение провести глубокое исследование и на основе его результатов запланировать новую версию. Определением стратегии развития Macroscop занимается product-менеджер компании, и вот по какому алгоритму действовал он:

1. Выявить все идеи. Их может быть много, очень много

Для того, чтобы найти все варианты новых функций, доработок и улучшений, product-менеджер Macroscop:

• общался с реальными пользователями продукта. Это были личные беседы с несколькими десятками людей на встречах или по skype, в ходе которых обсуждались их текущие потребности, идеи и проблемы;
• общался с технологическими лидерами отрасли на выставках, форумах и конференциях;
• общался с технической поддержкой и группой качества компании, чтобы понять их видение необходимых изменений и доработок на основе анализа проблем пользователей;
• проанализировал годовые цели разработчиков (каждый сотрудник компании формулирует в начале года свои личные цели);
• проанализировал около 10 тысяч оценок и комментариев к демо-версии Macroscop от тех, кто ее протестировал;
• проанализировал, какие модули видеоаналитики покупают чаще;
• проанализировал запросы на доработки ПО от крупных заказчиков;
• попросил менеджеров по продажам, пресейл-инженеров и специалистов по обучению партнеров составить свое видение необходимых доработок и разработок на основании их общения с партнерами в рамках своих направлений деятельности.

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

2. Взвесить каждую идею

Если бы мы были неограничены в ресурсах, мы бы реализовали все 130 идей. Но необходимо было выбрать конкретные задачи. Для этого мы взвесили каждую идею по 10 параметрам. Если не вдаваться в подробности, то все сводилось к 2 параметрам — инновационность и необходимость пользователям прямо сейчас.

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

3. Визуализировать распределение

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



Очевидно, что все 130 задач не реализуешь в рамках ближайших версий, но надо выбирать те, что находятся ближе к области (+?; +?). То есть идеальная задача – суперинновационная и необходимая пользователям прямо сейчас, та, за которую пользователи готовы уже сегодня заплатить деньги и пользоваться ей.

Мы разделили график на 3 зоны:

1 зона (выше красной линии) – это те идеи, которые надо реализовать обязательно. Они обладают одновременно высоким уровнем инновационности и высоким уровнем необходимости.

2 зона (между красной и зеленой линиями) – эти задачи решаем по возможности.

3 зона (ниже зеленой линии) — неинновационные и ненужные задачи (кстати, большая часть из этих 130 идей туда и попала). И мы их не делаем

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

Перевести идею в цель

Есть такая формула: цель = мечта + срок исполнения. И без четких сроков все наши планы целями не являлись. Ситуация усложнялась тем, что мы (как и многие разработчики) иногда грешили затягиванием внутренних сроков выхода версий, которые сами же себе устанавливали.

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

Павел Дуров говорил, что каждый месяц нужно выпускать какое-то определенное количество улучшений. В своем блоге он описывал ежемесячно 7 улучшений ВКонтакте: 7 улучшений ноября, 7 улучшений декабря и т.д.

Мы сочли позицию «Делай что хочешь, но выпускай 7 обновлений в месяц и ритмично развивай свой продукт» сильной и решили применить ее в Macroscop (естественно, адаптировав под нашу специфику).

Product-менеджер компании обсудил новую стратегию и срок 1 месяц с разработчиками и после долгих споров конструктивных обсуждений они договорились, что мы будем выпускать новую версию каждые 1,5 месяца.

Когда о сроке 1,5 месяца узнал технический директор, ответственный за тестирование новых версий продукта, он сказал, что это невозможно, так как сейчас мы каждую версию тестируем по 3 месяца. Потому что разработчики дописывают только новые функции и доработки, а они тестируют не только новинки, а ВЕСЬ ФУНКЦИОНАЛ с нуля. Версия, которая пришла от разработчиков – это черный ящик, который они должны проверить вдоль и поперек.

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

Итого получится, что каждые 1,5 месяца мы выпускаем версию, но пользователю уходит каждая вторая, протестированная версия. Чтобы понять, сколько улучшений мы должны выпускать каждые 1,5 месяца, мы проанализировали прежнюю скорость нашей разработки и получили все ту же цифру 7, которая в нашем случае включала: 1 завершенный шаг по инновациям (какой-то новый модуль видеоанализа или существенное улучшение текущего модуля) + 2 важных для пользователя функции или существенных улучшения + 4 прочих функции или улучшения.

Пользователь – главный эксперт

Еще один важный аспект, который мы ввели для повышения качества продукта — непосредственное общение разработчиков с пользователями. Раньше цепочка получения пожеланий от пользователей у нас была очень длинной: пользователь говорил что-то своему менеджеру – менеджер говорил это product-менеджеру – product-менеджер говорил это разработчикам, и, наконец, они разрабатывали. В итоге иногда получалось, что то, что сделали разработчики не совсем совпадало с тем, что было изначально нужно пользователям. И получалось так не по вине какого-то конкретного человека, а просто потому, что в цепочке было много звеньев, и часть информации на каждом таком звене терялась.

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

Все эти новшества мы разработали и ввели 2,5 месяца назад. Для того, чтобы понять, насколько точно мы сфокусировались и верно ли построили процесс разработки, должно пройти гораздо больше времени. Однако, согласно плана в конце сентября мы выпустили 1 новую внутреннюю версию, в которой реализовали 7 запланированных улучшений.