Чувствуй и реагируй. Как создавать продукты, нужные людям именно сейчас - Джош Сейден Страница 37

Когда члены команды завершили исследование, они были преисполнены решимости избежать еще одной ошибки, проявившейся во время прошлого проекта: на этот раз они хотели представить проект клиентам как можно скорее. Поэтому, несмотря на то, что у них были амбициозные планы на продукт, который они, в конечном итоге, создали, они задались вопросом: «Какую самую минимальную вещь мы можем создать, чтобы выйти рынок через три месяца или раньше?» Чтобы ответить на данный вопрос, они привлекли в свою группу продавцов и трейдеров, которым предстояло работать с этим сервисом, а также членов инженерной команды, которым поручено было создать его. Этот конференц-зал сильно отличался от предыдущего. Он не был местом исключительно для инженеров или для команды по продукту. Здесь работала самодостаточная бизнес-команда. Эта команда в ходе серии совместных сеансов проектирования создала набросок сервиса, который намеревалась представить в его начальной стадии клиентам, вооруженным небольшим количеством программ. Со времени, когда они подтвердили, что сервис работает так, как и задумывалось, члены команды планировали привнести в программное обеспечение больше функциональных возможностей, которые позволили бы сервису расширяться в масштабах.

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

ЗАКРЕПЛЕНИЕ ОПЫТА

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

ПОЭТАПНОЕ VS ЦИКЛИЧНОГО

Поэтапная разработка начинается с грандиозного видения: вы смотрите в будущее, планируете что-то значительное, и делаете это своей целью. Затем вы дробите достижение цели на этапы и реализуете проект шаг за шагом. Представьте, что вы строите кирпичный дом. С точки зрения программного обеспечения, такой способ работы обладает некоторыми преимуществами. Работая с небольшими блоками, вы можете создать технически надежное программное обеспечение: каждый блок можно обособить и проверить, что позволяет создавать системы, которые будут стабильны и которые можно будет легко поддерживать и изменять с течением времени.

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

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

СОВМЕСТНАЯ РАБОТА

Сотрудничество команды – это то, что делает цикличную разработку возможной. Такой вид работы подразумевает скромную оценку видения. Оно у вас есть, но вы должны быть готовы признать, что не уверены, что ваш план сработает. Вы можете настроить свою команду на получение обратной связи и принятие решений в ответ на нее. Чтобы это сработало, вы должны признать, что эти решения будут приниматься не единожды, а скорее всего, непрерывно, в ответ на каждый цикл.

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

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

Обретение силы многофункциональных команд

Не только цифровые команды открывают для себя способности многофункциональной организации.

В январе 2013 года Чип Бланкеншип, генеральный директор GE Appliances, собрал одну небольшую многофункциональную команду в одном помещении и бросил ей вызов – представить к выпуску новый высококлассный холодильник с двумя отделениями через год, при том, что где-то три месяца обычно нужны для разработки[66]. Более того, он хотел через три месяца получить рабочую модель. Бланкеншип был сторонником идеи бережливого стартапа и хотел понять, работают ли эти принципы при создании бытовой техники.

Единственный способ сделать это быстро – собрать команду вместе и заставить работать над одной задачей.

Члены команды начали продумывать, как успеть к сроку, и выявили ограничения в традиционном процессе. Они поняли: для того чтобы продвигаться в этом деле быстрее, им нужно создать непрерывный поток обратной связи от продавцов, дизайнеров, поставщиков материала и покупателей. В традиционной модели для проведения всех этих бесед могли бы потребоваться месяцы. Команда хотела сократить этот этап до нескольких дней или даже часов. Члены команды понимали, что им придется ужать временные рамки циклов, если они хотят справиться к сроку. И не только беседы должны протекать быстрее. Команда хотела генерировать быструю обратную связь с рынком, поэтому ей был необходим способ для привлечения клиентов. Наконец, команда понимала, что, по мере определения того, что работает, а что – нет, она должна быть