Уроки от Pixar: Зачем ПО-разработчикам быть сценаристами?

Большинство людей при упоминании студии Pixar сразу вспоминают «В поисках Немо» или «Историю игрушек». Мало кто знает, что эта студия уже почти тридцать лет производит программное обеспечение для мирового кинематографа, которое оживляет истории на большом экране.

Мне повезло работать в качестве главного инженера в команде разработчиков ПО в Pixar.
Пока я работал в студии, при разработке новой серии программных решений под названием Presto мы использовали техники и подходы, которые обычно практикуются в кинопроизводстве. И вот чему я там научился.

Концепции кинопроизводства в ПО

В Pixar часто повторяют: «Самое главное — хорошая история». Это и есть основная причина успеха студии. Все фильмы в Pixar начинаются со сценарного отдела, где разрабатывается начальный сценарий, рисуются раскадровки, определяется вид фильма (раскадровка выглядит как огромный деревянный планшет, на котором крепятся карточки 4х6 дюймов с рисунками от руки). Эта история потом и перейдёт к исполнительной команде до выпуска в производство.
Во многом разработка программного продукта похожа на создание истории. Никого не удивляет, что современные agile-процессы собирают информацию от пользователей, чтобы понять их требования к программе. Мы немного переработали этот подход и в группе разработчиков ПО создали настоящий сценарный отдел. Этот отдел отвечал за разработку рабочих процессов, осуществляемых в новом ПО и за то, чтобы в виде стандартной раскадровки донести до конечных пользователей функции нового ПО. Раскадровка передавалась конечным пользователям (то есть художникам) в привычном для них виде и структуре, что позволяло им с легкостью общаться с отделом разработки на их языке. Также у нас была «сценарная комната», на стенах которой и находились раскадровочные планшеты, что позволяло в одном месте продемонстрировать функции нового приложения.
Конечно, такой подход нельзя копировать на все остальные программные проекты, но ключевой момент здесь – это разговор с пользователями и использование техник, которые они понимают. Поскольку очевидно, что при написании программного обеспечения необходимо выслушать мнение этих пользователей, мы решили пойти ещё дальше и включили одного из пользователей в нашу группу разработки.
Мы попытались найти тех художников, кто в настоящий момент не занят в проекте, и тех, кто был заинтересован в усовершенствовании студийного ПО. Эти художники помогли бы нам определить рабочие задачи и пользовательский интерфейс на основе своего опыта работы с существующим ПО. Например, одной из наших задач была поддержка процесса артикуляции персонажей, поэтому на начальном этапе к нам присоединился инженер по артикуляции. Он ежедневно использовал наше ПО для артикуляции моделей Базз и Вуди, посещал наши собрания для выделения основных функций и определения недостающих опций.
Такой поток входящей информации от пользователя-эксперта давал нам уверенность, что мы разрабатываем продукт, который решит повседневные проблемы пользователей. Ещё одно преимущество заключается в том, что такие художники затем могли стать евангелистами для продукта среди своих коллег.

Процесс общения

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

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

Отношения «Режиссёр-Продюсер»

Между тем, как делаются фильмы и тем, как делаются программы, есть одно фундаментальное различие. В кинопроизводстве вы имеете дело с режиссёром, ответственным за творческое содержание ленты, и продюсером, ответственным за финансовые, кадровые и экономические вопросы. Этих людей объединяет общее дело, но постоянно раздирают конфликты.
Когда я работал над «Суперсемейкой», во время обсуждения о необходимости большего финансирования для улучшения визуальных эффектов продюсер Джон Уолкер сказал режиссеру Брэду Бёрду, что он просто хочет довести проект до финиша. На что режиссёр ответил, что он хочет, чтобы проект дошёл до финиша чемпионом.

В мире программного обеспечения обычно только один человек несёт ответственность за сборку финального продукта; часто это продакт-менеджер или владелец продукта. Есть инженеры и дизайнеры, ответственные за внешний вид и юзабилити продукта, но они редко вмешиваются в решения продакт-менеджера.
Во время работы в Pixar мы экспериментировали с моделью отношений «Режиссёр-Продюсер» в управлении нашим продуктом. Нам это было необходимо, чтобы найти баланс между стремлением создать шедевр и стремлением создать практичный и функциональный продукт. Наш продюсер принадлежал миру программной разработки и контролировал такие области, как используемая платформа, язык программирования, процесс разработки и расписание проекта; режиссёр принадлежал миру кинопроизводства и отвечал за функции анимации, рабочий процесс пользователя, внешний вид продукта и т.д. Обе этих сферы одинаково важны и зачастую пересекаются. Например, мы очень много спорили по поводу операционной системы: Mac или Linux? Принятое решение повлияет на многие технические аспекты, включая язык программирования и выбор UI-инструментария, но и творческие аспекты не остаются в стороне: скажем, пользовательский интерфейс и шаблон взаимодействия.
Наличие двух одинаково важных мнений в управлении продуктов, конечно, часто усложняет процесс, но поиск баланса между искусством и технологией – необходимый момент в создании качественного продукта. Такова была и философия Стива Джобса в построении концепции Apple: гениальные идеи находятся на стыке компьютерных технологии и искусства.
Перевод: Люся Ширшова. По материалам авторской статьи Мартина Редди. Мартин шесть лет был главным разработчиком в Pixar Animation Studio. В настоящий момент – учредитель собственного дела.

Источник

Жми «Нравится» и получай только лучшие посты в Facebook ↓

Загрузка...
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Уроки от Pixar: Зачем ПО-разработчикам быть сценаристами?