Сегодня Grockit предлагает множество различных образовательных программ, но в начале Фарб следовал методологии бережливого производства. Grockit создала минимально рабочий продукт. Это был простой курс подготовки к тесту, который можно было пройти с помощью популярного веб-инструмента для конференц-связи WebEx. Фарб не стал создавать ни специального программного обеспечения, ни новой технологии. Он просто попытался донести свой новый подход к обучению до студентов через Интернет. Информация о новом виде частного обучения быстро распространялась, и через несколько месяцев преподавание онлайн уже приносило Фарбу приличный доход. Он зарабатывал от $10 000 до $15 000 в месяц. Но как и многие другие амбициозные предприниматели, Фарб создал свой MVP не только для того, чтобы зарабатывать на жизнь. Он хотел создать более эффективный, интерактивный метод обучения для студентов по всему миру. И благодаря первым успехам смог добиться финансирования от некоторых из лучших инвесторов в Кремниевой долине.
Когда я впервые встретился с Фарбом, его компания уже была на пути к успеху. Она привлекла венчурный капитал от инвесторов с хорошей репутацией, создала потрясающую команду и впечатляюще дебютировала на одном из знаменитых конкурсов стартапов Кремниевой долины.
Команда Фарба была чрезвычайно ориентирована на процесс и дисциплинированна. Она следовала самой строгой версии гибкой методологии разработки, которая называется Extreme Programming (она описана ниже), предложенной компанией из Сан-Франциско Pivotal Labs, с которой Grockit заключила партнерское соглашение. Первый продукт компании пресса назвала «прорывом».
Была только одна проблема: компания не видела большого притока клиентов. Пример Grockit очень показателен, потому что ее проблемы не были связаны с неудачной концепцией или недостатком дисциплины.
Следуя стандартным методам гибкой разработки, Grockit провела серию быстрых циклов итерации длительностью один месяц. Для каждого такого ежемесячного цикла Фарб расставлял приоритеты, создавая серию пользовательских историй – это метод также взят из методологии гибкой разработки. Вместо того чтобы разрабатывать спецификации для новой опции в технических терминах, Фарб описывал ее с точки зрения клиента. Это помогало разработчикам взглянуть на свою работу с позиций будущего пользователя.
Каждая опция была описана простыми словами, понятными всем – и тем, кто знаком с технологиями, и тем, кто не знаком. Кроме того, в соответствии со стандартной процедурой гибкой разработки Фарб мог в любой момент менять приоритеты. Узнав что-то новое о потребностях клиентов, он мог поменять местами задачи в плане разработки продукта. Единственное ограничение было в том, что Фарб не мог прервать выполнение задачи, если оно уже началось. К счастью, на выполнение задач уходило всего один-два дня.
Эту систему не зря называют гибкой разработкой: она позволяет быстро менять направление и чутко реагировать на новые бизнес-требования заказчика продукта (того, кто руководит процессом, в данном случае – Фарба).
Как чувствовала себя команда в конце каждого цикла? Она последовательно создавала новые опции. Она собирала обратную связь от клиентов в форме «историй» и интервью, которые показывали, что по крайней мере некоторым клиентам понравились новые опции. Те или иные данные всегда подтверждали интерес клиентов: возможно, росло общее количество пользователей, увеличивалось общее количество вопросов, на которые отвечали студенты, или росло количество повторных обращений.
Однако я видел, что Фарб и его команда не могут побороть сомнения. Вызван ли рост цифр их усилиями по развитию? Или это происходит благодаря другим факторам, например упоминаниям о Grockit в прессе? На встрече с членами команды я задал простой вопрос: «Откуда вы узнаете, что решения о приоритетах, которые принимает Фарб, правильны?» Члены команды ответили: «Это не в нашей компетенции. Фарб принимает решения, а мы их просто выполняем».
В тот момент Grockit была ориентирована только на один сегмент потребителей: абитуриентов бизнес-школ, которые готовятся к сдаче теста GMAT. Продукт компании позволял им участвовать в сеансах обучения онлайн вместе с другими людьми, которые готовятся к сдаче того же теста. Программа была достаточно эффективна: те, кто закончил курс обучения Grockit, получали значительно более высокие оценки, чем раньше. Но команда Grockit столкнулась с традиционными проблемами стартапа: как узнать, какие опции наиболее важны? Как сделать так, чтобы больше клиентов регистрировались и оплачивали наш сервис? Как сделать так, чтобы люди говорили о нашем продукте?
Я спросил Фарба: «Как вы узнаете, что принимаете правильные решения с точки зрения расстановки приоритетов?» Как и большинство основателей стартапов, он анализировал доступные данные и делал на их основании настолько адекватные предположения, насколько мог. Но это неизбежно приводило к неуверенности и сомнениям.
Фарб верил в свое видение целиком и полностью, но при этом начинал сомневаться в том, что его компания движется к реализации поставленной цели. Продукт улучшался каждый день, но Фарб хотел убедиться в том, что эти улучшения важны для клиентов. Это вызывает уважение, ведь многие другие новаторы держатся за свое первоначальное видение несмотря ни на что. Но Фарб был готов к «проверке реальностью».
Он всеми силами пытался поддержать веру своей команды в то, что Grockit обязательно добьется успеха. Он беспокоился, что команда утратит энтузиазм, если кто-то подумает, что человек, ведущий корабль, не знает, куда плыть. Но сам Фарб не знал, способна ли его команда создать истинную культуру обучения. В конце концов, это был важный аспект гибкой разработки: разработчики соглашаются адаптировать продукт к постоянно меняющимся требованиям бизнеса, но при этом не несут ответственности за стратегические решения.
Гибкая методология разработки довольно эффективна с точки зрения разработчиков. Она позволяет им сосредоточиться на разработке опций и на технических аспектах. Попытка ввести в этот процесс потребность учиться может снизить производительность. (Когда метод бережливого производства стали вводить на предприятиях, возникли похожие проблемы. Менеджеры привыкли учитывать коэффициент загрузки каждой машины. Предприятия были организованы так, чтобы машины работали с полной мощностью – и как можно дольше. С точки зрения загрузки отдельной машины это эффективно, но с точки зрения производительности всей фабрики это иногда крайне неэффективно. Как говорят в теории систем, при оптимизации одной части системы мы обязательно снижаем эффективность системы в целом.)
Фарб и его команда не понимали, что прогресс Grockit оценивается на основании «показателей тщеславия»: общее количество клиентов и общее количество вопросов, на которые получены ответы. Именно это заставляло его команду действовать: эти показатели создавали у команды ощущение движения вперед, хотя ее успехи все еще оставались весьма скромными. Интересно, как точно метод Фарба следовал этапам обучения по системе «экономичный стартап»: компания создала раннюю версию продукта и установила некоторые базовые показатели. Она делала относительно короткие итерации, и каждую из них оценивала в соответствии с тем, улучшает ли она показатели, отражающие активность пользователей.
Однако Grockit использовала не те показатели и на самом деле не развивалась. Фарба беспокоило, что компания не делает выводов из обратной связи от пользователей. В каждом цикле менялись показатели, на которых была сосредоточена его команда: в один месяц она рассматривала общие показатели использования, в другой – число зарегистрировавшихся пользователей, и т. д. Казалось, приоритеты меняются сами собой. Невозможно было установить ясные причинно-следственные связи. Правильно расставить приоритеты в такой ситуации очень сложно.
Фарб мог бы попросить своего аналитика изучить тот или иной вопрос. Например, когда мы предложили опцию X, повлияло ли это на поведение потребителей? Но это потребовало бы огромных затрат времени и сил. Когда именно была предложена опция X? Каким клиентам ее предложили? Изменили ли мы что-то еще в то же самое время? Могли ли повлиять какие-то сезонные факторы? Чтобы ответить на эти вопросы, потребовались бы огромные усилия и массивы данных. Ответ мог быть найден спустя недели после того, как был задан вопрос. А тем временем команда уже успела бы перейти к новым приоритетам и новым вопросам, требующим срочного решения.
По сравнению со многими другими стартапами команда Grockit обладала огромным преимуществом: она была чрезвычайно дисциплинированна. Такая команда может следовать неправильной методологии, но способна быстро переключить скорость, обнаружив ошибку. И самое главное: дисциплинированная команда может экспериментировать со своим собственным стилем работы и делать осмысленные выводы.
