Войти в систему
Войти с помощью соц. сетей:
В двадцатом веке организационная структура любого бизнеса представляла собой вертикаль, где каждый отдельный департамент выполнял отдельно поставленную задачу. И, надо признать, в прошлом система структурных подразделений имела смысл: маркетинговый отдел проводил исследования, готовил спецификации и передавал данные отделу разработки, который, изготовив продукт, отдавал его в отдел продаж, а тот уже запускал продукт в продажу и продавал, продавал, продавал. Финансовый отдел подсчитывал выручку. Системного администратора вызывали, когда кто-то из менеджеров забывал пароль от почты.
Подобная организация, выстроенная вдоль цепочек производства и выпуска одного продукта, выглядела логичной, когда все было просчитано, стабильно и когда цвет выпускаемого вами товара был черным. Это давало руководству полное представление о цикле разработки продукта, эффективности продаж и распределении ответственности внутри компании. И хотя организация, выстроенная вдоль продукта, имела явные преимущества с точки зрения основных производственных задач, она несла в себе колоссальные издержки. Она создавала замкнутую систему, которой недоставало комплексного подхода, где шла внутренняя конкуренция за клиента, а руководство оказывалось близоруким и не готовым к резким изменениям рыночной конъюнктуры. Это были компании, перевернутые с ног на голову – они ориентировались на продукт, а не на покупателя.
Но, к сожалению, на протяжении достаточно долгого времени подобная структура вполне себе функционировала. Дела шли не очень хорошо в том, что касалось взаимодействия с потребителями, но в целом бизнес жил и выживал. Однако нет ничего более страшного, чем посредственность, приносящая прибыль. Золотая послевоенная эра доминирования корпораций стала возможной именно потому, что клиенты вели себя относительно пассивно.
Наступили другие времена. В мире, где в центре системы находится клиент, структурные подразделения должны работать по-другому. О каком новом опыте взаимодействия с подписчиками может идти речь, если все менеджеры сидят тише воды, ниже травы? Как выбирать новые направления и разрабатывать новые продукты, как выходить на рынки и создавать новые бизнес-модели, если команда разделена глухими стенами?
Компании, избравшие подписную модель, работают по другим правилам. В следующей главе мы поговорим подробнее именно о них. И начнем с сердца компании – с дизайнеров и разработчиков, перед которыми стоит задача превратить отличный продукт в отличный сервис.
Со всеми компаниями, переходящими на модель работы по подписке – будь то разработчик, запустивший свой первый облачный сервис или медиаресурс, подтвердивший регистрацию первого пользователя, или торговая компания, увидевшая первое передвижение проданного товара, или производитель, получивший первые данные от установленного у заказчика оборудования, – происходит одинаково смешная штука. Они вдруг понимают, что могут наблюдать за действиями своих клиентов! Нет, правда, это впечатляет – видеть, как начинают меняться первые цифры на табло. Я сам помню это чувство – испытал его в Salesforce: нам сразу захотелось получить еще больше информации о пользователях, и это в корне изменило наш подход к принятию решений, распределению ресурсов и разработке новых сервисов. В общем-то, это изменило все.
У меня есть собственная теория о том, что многие открыли для себя новые принципы разработки продукта после того, как появился Gmail. Когда 1 апреля 2004 года в Gmail стала доступна возможность регистрации сторонних пользователей, на логотипе почтового сервиса красовалась надпись «beta». И даже когда число зарегистрированных адресов перевалило за несколько миллионов, сервис оставался в статусе бета-продукта – и был таковым на протяжении пяти лет, пока официально 7 июля 2009 года не завершил «тестовый» период. Почему этот самый период тянулся так долго и почему вдруг так внезапно «завершился»? Поверьте, в этом не было вины программистов – с их точки зрения, все давно было «завершено». Настоящая причина заключалась в том, что крупные компании из списка Fortune 500, уже использовавшие в работе Lotus Notes или Microsoft Exchange, очень хотели начать пользоваться и сервисом Gmail. Но их отделы закупки не позволяли приобретать продукт, официально находящийся в статусе «испытательного». Что сделали в Google, узнав об этом? Правильно – просто поменяли логотип.
Вот текст официального сообщение Google об окончании «тестового периода», опубликованное в корпоративном блоге компании 7 июля 2009 года (обратите особое внимание на последнее предложение):
Нас часто спрашивают, почему так много приложений Google постоянно находятся в стадии бета-тестирования? Например, на логотипе Gmail наклейка “beta” присутствует уже на протяжении более пяти лет. Мы понимаем, что подобная ситуация озадачивает некоторых наших пользователей, особенно тех, кто приравнивает статус “beta” к статусу продукта, не готового для выхода на большой рынок.
Пакет приложений Google Apps для корпоративных клиентов мы выпустили два года назад. Он предусматривает наличие соглашения о гарантированном уровне обслуживания, круглосуточную техническую поддержку семь дней в неделю – то есть отвечает всем условиям, а в некоторых случаях и превосходит схожие условия, принятые для так называемых полноценных продуктов без приставки “beta”. Более 1,75 миллиона корпоративных пользователей по всему миру уже используют в своей работе пакет приложений Google Apps, включая саму корпорацию Google. В то же время мы поняли, что сотрудников многих других крупных компаний, которые хотели бы использовать в работе наше программное обеспечение, смущает пометка “beta”, так как заставляет их сомневаться в полноценности и функциональности наших сервисов. В связи с этим мы приняли решение убрать эту пометку с логотипов всех высококлассных приложений, входящих в наш пакет.
Впрочем, те из вас, кому нравится пометка “beta”, могут вернуть прежний Gmail, выбрав соответствующие настройки в разделе “Labs”.
Нет, вы только вдумайтесь! Если пользователь заскучал по старому логотипу бета-версии, он может вернуть его с помощью настроек!
Потому что эта приставка из четырех букв – «бета» – не значит ровным счетом ничего.
Я считаю, что процитированный выше текст имеет эпохальное значение для всей цифровой индустрии, поскольку обозначает фундаментально новый подход к разработке современного программного обеспечения.
Появление Gmail ознаменовало рождение новой эпохи, когда обновленные версии приложений не выпускаются на рынок с помпой в какой-то определенный день – сами приложения находятся в состоянии постоянного, едва ли не ежедневного обновления. Что это значит? Ну, смотрите: изначально цель выпуска бета-версии состояла в том, чтобы предоставить пользователям продукт в стадии неполной готовности, собрать отзывы о продукте, а затем использовать полученную информацию для доведения продукта до совершенства и выпуска уже полноценной рабочей версии. В конечном счете в этом заключается ключевой аспект «гибкой модели» разработки программного обеспечения: вы даете возможность всем заинтересованным сторонам, включая пользователей, поучаствовать в процессе разработки программного продукта до появления финальной версии, чтобы выявить все возможные сценарии развития нештатных ситуаций – и в целом определить слабые места с точки зрения контроля качества. Руководство разработчиков Gmail решило расширить эти границы – и отказалось от последней части. В компании поняли: если перед их командой стоит задача создания живого, постоянно изменяющегося продукта, стóит привлекать пользователей в качестве инновационных партнеров на постоянной основе. А сервису – навсегда присвоить статус «бета».
Манифест гибкой методологии разработки программного обеспечения был принят группой разработчиков в ходе встречи на горнолыжном курорте в американской Юте в феврале 2001 года. Он состоит всего из четырех простых, но действенных принципов: пользователи и взаимодействие важнее процессов и инструментов; работоспособность продукта важнее исчерпывающих инструкций; результаты сотрудничества с заказчиком важнее согласования условий контракта; готовность вносить изменения важнее следования первоначальному плану разработки.
Эти принципы применимы к разработке любого сервиса с доступом по подписке. Инновации не возникают из ниоткуда – они появляются в результате развития определенной концепции на протяжении определенного периода. Резкие движения при работе над сервисом, взлеты и падения при разработке могут стать причиной выгорания и привести либо к нездоровым пикам производительности, либо к глубоким кризисам идей в команде разработчиков. Главная задача тут состоит в создании среды, питающей устойчивое развитие, когда у команды всегда хватает сил поддерживать темп работы над продуктом в постоянном и безостановочном режиме. Это – единственный способ оставаться гибкими и результативными.
Сегодня эти принципы – слышать клиента и не останавливаться в развитии – постепенно занимают основные позиции во всех секторах мировой экономики.
Войти с помощью соц. сетей: