Більшість людей при згадці студії Pixar відразу згадують «У пошуках Немо» або «Історію іграшок». Мало хто знає, що ця студія вже майже тридцять років виробляє програмне забезпечення для світового кінематографа, яке оживляє історії на великому екрані.
Мені пощастило працювати в якості головного інженера в команді розробників ПЗ в Pixar.
Поки я працював в студії, при розробці нової серії програмних рішень під назвою Presto ми використовували техніки і підходи, які зазвичай практикуються в кіновиробництві. І ось чому я там навчився.
Концепції кіновиробництва в ПО
У Pixar часто повторюють: «Найголовніше - хороша історія». Це і є основна причина успіху студії. Всі фільми в Pixar починаються зі сценарного відділу фундаментальних і прикладних розробок початковий сценарій, малюються розкадровки, визначається вид фільму (розкадровка виглядає як величезний дерев'яний планшет, на якому кріпляться картки 4х6 дюймів з малюнками від руки). Ця історія потім і перейде до виконавчою командою до випуску у виробництво.
Багато в чому розробка програмного продукту схожа на створення історії. Нікого не дивує, що сучасні agile-процеси збирають інформацію від користувачів, щоб зрозуміти їхні вимоги до програми. Ми трохи переробили цей підхід і в групі розробників ПЗ створили справжній сценарний відділ. Цей відділ відповідав за розробку робочих процесів, що здійснюються в новому ПЗ і за те, щоб у вигляді стандартної розкадровки донести до кінцевих користувачів функції нового ПЗ.
Розкадрування передавалася кінцевим користувачам (тобто художникам) в звичному для них вигляді і структурі, що дозволяло їм з легкістю спілкуватися з відділом розробки на їх мові. Також у нас була «сценарна кімната», на стінах якої і знаходилися раскадровочние планшети, що дозволяло в одному місці продемонструвати функції нової програми.
Звичайно, такий підхід не можна копіювати на всі інші програмні проекти, але ключовий момент тут - це розмова з користувачами і використання технік, які вони розуміють. Оскільки очевидно, що при написанні програмного забезпечення необхідно вислухати думку цих користувачів, ми вирішили піти ще далі і включили одного з користувачів в нашу групу розробки.
Ми спробували знайти тих художників, хто зараз не зайнятий в проекті, і тих, хто був зацікавлений в удосконаленні студійного ПО. Ці художники допомогли б нам визначити робочі завдання і призначений для користувача інтерфейс на основі свого досвіду роботи з існуючим ПЗ. Наприклад, одним із наших завдань була підтримка процесу артикуляції персонажів, тому на початковому етапі до нас приєднався інженер по артикуляції. Він щодня використовував наше ПО для артикуляції моделей Базз і Вуді, відвідував наші зборів для виділення основних функцій і визначення відсутніх опцій.
Такий потік вхідної інформації від користувача-експерта давав нам впевненість, що ми розробляємо продукт, який вирішить повсякденні проблеми користувачів. Ще одна перевага полягає в тому, що такі художники потім могли стати євангелістами для продукту серед своїх колег.
процес спілкування
Як тільки запускається виробництво фільму, починається робота окремих департаментів, що займаються моделюванням, артикуляцією героїв, макетами, декораціями, анімацією, симуляцією, ретушшю, спец.еффекти і рендерингом. Протягом всього процесу Произодство проходять щоденні і щотижневі рев'ю.
Ці рев'ю проходять в проекційному залі в присутності режисера. В процесі рев'ю переглядається сценарій, а ролики з поточною версією фільму демонструються всій компанії один-два рази на рік, і всі працівники студії можуть висловити свої зауваження та побажання. Це одна з фішок Pixar: будь-прибиральник або офіціант може вплинути на сценарій або на персонажів.
Усередині свого відділу ми впровадили концепцію інженерних тижневиків. Це були збори всієї групи розробників в проекційному залі, на яких кожен міг продемонструвати прогрес своєї діяльності. Презентації були досить неформальні і цинічні, оскільки призначалися тільки для розробників, не для користувачів. Такі зібрання дозволили кожному похвалитися тим, над чим він працює, і тим самим підвищити загальну залученість в створення продукту. Та й взагалі це дуже веселий спосіб тримати команду в курсі того, що відбувається.
Відносини «Режисер-Продюсер»
Коли я працював над «Суперсімейка», під час обговорення про необхідність більшого фінансування для поліпшення візуальних ефектів продюсер Джон Уолкер сказав режисерові Бреду Берду, що він просто хоче довести проект до фінішу. На що режисер відповів, що він хоче, щоб проект дійшов до фінішу чемпіоном.
У світі програмного забезпечення зазвичай тільки одна людина несе відповідальність за складання фінального продукту; часто це продакт-менеджер або власник продукту. Є інженери і дизайнери, відповідальні за зовнішній вигляд і юзабіліті продукту, але вони рідко втручаються в рішення продакт-менеджера.
Під час роботи в Pixar ми експериментували з моделлю відносин «Режисер-Продюсер» в управлінні нашим продуктом. Нам це було необхідно, щоб знайти баланс між прагненням створити шедевр і прагненням створити практичний і функціональний продукт.
Наш продюсер належав світу програмної розробки і контролював такі області, як використовувана платформа, мова програмування, процес розробки і розклад проекту; режисер належав світу кіновиробництва і відповідав за функції анімації, робочий процес користувача, зовнішній вигляд продукту і т.д. Обидві ці сфери однаково важливі і часто перетинаються. Наприклад, ми дуже багато сперечалися з приводу операційної системи: Mac або Linux? Прийняте рішення вплине на багато технічні аспекти, включаючи мову програмування і вибір UI-інструментарію, а й творчі аспекти не залишаються осторонь: скажімо, призначений для користувача інтерфейс і шаблон взаємодії.
Наявність двох однаково важливих думок в управлінні продуктів, звичайно, часто ускладнює процес, але пошук балансу між мистецтвом і технологією - необхідний момент в створенні якісного продукту. Такою була і філософія Стіва Джобса в побудові концепції Apple: геніальні ідеї знаходяться на стику комп'ютерних технології і мистецтва.
Тисни «Подобається» і отримуй тільки кращі пости в Facebook ↓