Любой наблюдатель, который в тот момент влился бы в команду, решил бы, что именно так выглядит идеальное сотрудничество. Члены команды совместным трудом проделали отличную работу. Разработчики, дизайнеры, менеджеры по продукту и тестировщики – все они перебрались в комфортный конференц-зал и работали в атмосфере согласия друг с другом. Члены команды консультировались друг с другом по поводу ключевых решений, использовали множество современных agile-методов, были увлечены постоянной модернизацией рабочего процесса.
Проблема заключалась в следующем: команда никогда не представляла приложение клиентам. Члены команды поставили перед собой столь масштабную задачу – создание грандиозного приложения, призванного заменить существующие приложения конкурентов, – что никак не могли добраться до финиша. Цикличный подход был хорош для решения технических проблем, но он никогда не смог бы помочь найти решение, которое отвечало бы потребностям пользователя от начала до конца.
Когда семена сомнения, зароненные первоначальными исследованиями, начали прорастать, заинтересованные лица начали беспокоиться еще сильнее. Прибавьте к этому цену задержки: даже спустя два года команда все еще не могла представить сервис покупателям. Понятно, что у акционеров лопнуло терпение, и проект был закрыт. А ведь в течение долгого времени над проектом работали полтора десятка человек. Все их усилия, всё потраченное время – всё ушло впустую.
ОБУЧЕНИЕ НА ОШИБКАХ ЗАКРЫТОГО ПРОЕКТА
В следующем году некоторые сотрудники из этой команды были назначены на новый проект и поклялись исправить свои ошибки.
В ходе нового проекта команда дизайнеров создала совершенно другой механизм исследований. После первоначального цикла исследований, который принес знания, поставившие под вопрос стратегический план, команда дизайнеров с командой стратегов решили провести совместное недельное исследование ожиданий клиентов. Проектная группа хотела избежать проблемы, с которой она столкнулась ранее, сообщив о результатах, не вписывающихся в утвержденную концепцию. Члены команды хотели, чтобы лица, принимающие решения, увидели все своими глазами.
Это совместное исследование стало поворотным моментом в новом проекте. Оно позволило команде стратегов увидеть то, что раньше увидела проектная команда. Поработав вместе, члены обеих команд узнали больше, чем могли бы узнать при проведении исследования врозь. Кроме того, этот опыт позволил установить отношения сотрудничества между группами. Это сотрудничество продолжалось на протяжении всего проекта. Можно сказать, оно способствовало созданию новой команды.
Когда члены команды завершили исследование, они были преисполнены решимости избежать еще одной ошибки, проявившейся во время прошлого проекта: на этот раз они хотели представить проект клиентам как можно скорее. Поэтому, несмотря на то, что у них были амбициозные планы на продукт, который они, в конечном итоге, создали, они задались вопросом: «Какую самую минимальную вещь мы можем создать, чтобы выйти рынок через три месяца или раньше?» Чтобы ответить на данный вопрос, они привлекли в свою группу продавцов и трейдеров, которым предстояло работать с этим сервисом, а также членов инженерной команды, которым поручено было создать его. Этот конференц-зал сильно отличался от предыдущего. Он не был местом исключительно для инженеров или для команды по продукту. Здесь работала самодостаточная бизнес-команда. Эта команда в ходе серии совместных сеансов проектирования создала набросок сервиса, который намеревалась представить в его начальной стадии клиентам, вооруженным небольшим количеством программ. Со времени, когда они подтвердили, что сервис работает так, как и задумывалось, члены команды планировали привнести в программное обеспечение больше функциональных возможностей, которые позволили бы сервису расширяться в масштабах.
И это сработало. Команда запустила сервис в течение нескольких месяцев, получила одобрение со стороны рынка и смогла развивать продукт за счет выхода частых последующих версий.
ЗАКРЕПЛЕНИЕ ОПЫТА
Эта история представляет два важных результата. Первый – относительно поэтапной и цикличной разработки. Второй – командного сотрудничества и гибкости.
ПОЭТАПНОЕ VS ЦИКЛИЧНОГО
Поэтапная разработка начинается с грандиозного видения: вы смотрите в будущее, планируете что-то значительное, и делаете это своей целью. Затем вы дробите достижение цели на этапы и реализуете проект шаг за шагом. Представьте, что вы строите кирпичный дом. С точки зрения программного обеспечения, такой способ работы обладает некоторыми преимуществами. Работая с небольшими блоками, вы можете создать технически надежное программное обеспечение: каждый блок можно обособить и проверить, что позволяет создавать системы, которые будут стабильны и которые можно будет легко поддерживать и изменять с течением времени.