zal2

Ответы на 22 вопроса об организации работы @DevNight Dnepr

  • Facebook
  • Twitter
  • VKontakte
  • LinkedIn
  • Email
  • RSS

В субботу, на конференции DevNight посвященной техническому дизайну, после доклада я в течении 30 минут ответил на 22 вопроса, которые носили по большей части организационный характер. Участники конференции озвучивали актуальные проблемы, советовались по способам решения. Так как тема актальна — публикую ответы на эти вопросы здесь.

 

Должен ли постановщик согласовывать задачу с продюсером?

Продюсер в любом случае несёт ответственность за результат. Именно он определяет, что нужно делать в ближайший спринт, поэтому без его визы задача в работу не должна идти.

Нужно ли отдельно описывать задачу для программиста или ему должно быть достаточно общего описания?

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

Как приучить продюсера в письменном виде ставить задачи?

То, что сказано устно и ни где не задокументировано, можно трактовать по разному. И это ненадежно, так как результат зависит исключительно от понимания исполнителем слов постановщика, что чаще ведет к переделкам. Нужно напомнить продюсеру, что эффективнее ставить задачи в письменном формате — это экономит время на реализацию задачи, дает возможность перечитать отдельные моменты, найти ответы на возникшие вопросы.

Может ли дизайнер участвовать в совещаниях на этапе создания концепта игры?

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

Такой подход поможет избежать неловких моментов, когда придуманное не стоит воплощать в жизнь.

Как организовать процесс работы постановки задачи для аутсорс команды, чтобы не тратить деньги на переделки и пересогласования?

В идеале необходимо организовать работу по тем же правилам: договоренность по стандартам описания задачи, обратная связь, и только потом работа и оплата. Если же и после этого фрилансер выполняет задание не по ТЗ, и работу надо переделать — имеет смысл задуматься о другом исполнителе.

Кто и как оценивает задачи? Как предотвратить срывы сроков по таким оценкам?

У каждого члена команды есть своя производительность, исходя из своего опыта члены команды оценивают задачи. Новая же задача, с которой сталкивается исполнитель — всегда оценивается «пальцем в небо», наугад, интуитивно. Эта оценка может не соответствовать действительности. В таких случаях хороший Project Manager, по предыдущему опыту работы с каждым конкретным исполнителем, закладывает некий коэффициент погрешности.

Если же сроки постоянно срываются, тогда задавать вопросы нужно исполнителю, переоценивающему свои силы. А проджект менеджеру увеличить коэффициенты, дабы предотвратить неэффективное планирование.

Как организовать процесс, чтобы не было необходимости готовить графику «на вчера»?

Нужно стремится к тому, чтобы графика была принята продюсером к моменту запуска спринта тех.команды. Лучше всего готовить графику за месяц или хотя бы за несколько недель до того момента, пока она не будет востребована в сборку.

Тем не менее такие ситуации случаются, что делать, чтобы исправить такой подход?

Нужно больше общаться и доносить, что такой подход к организации работы не эффективен. Что переделывая работу, компания переплачивает за рабочие часы, за аутсорс, и в итоге проект стоит дороже своей реальной стоимости. Это в первую очередь должен понимать человек, который несёт ответственность за финансовые показатели продукта — продюсер. Если он не понимает этого, его пора менять.

Как ограничить вмешательство других членов команды в работу над задачей? Кого стоит слушать?

Первый способ — объяснять другим членам команды, что если они хотят что-то изменить в задаче, то стоит обратится к постановщику, чтобы тот внёс правки в ТЗ, если посчитает пожелание стоящим.

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

Какую стилистку выбирать? Что сейчас в тренде?

Сейчас очень много продуктов с плоскими, прозрачными элементами интерфейса. Однако для игры это не всегда хорошо. Выбирая стилистку стоит задуматься, соответствует ли она запросам целевой аудитории. Если у вас возникают разногласия по поводу стилистики — соберите оба варианта в прототипе, покажите коллегам, знакомым, потенциальной ЦА и спросите, на сколько он им понятен.

В конечном итоге финальное решение принимает продюсер, как человек отвечающий за результат.

Как мнение UX дизайнера может влиять на работу UI дизайнера?

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

Если работа над проектом уже начата без должной организации, каким образом стоит вводить артефакты из презентации, чтобы повысить эффективность?

Нужно понимать, что советы из доклада — это лишь малая часть процессов, которые присутствуют в разработке. Если команда готова к изменениям, можно пробывать вводить эти принципы работы. Если же ввести всё одним махом не представляется возможным, то имеет смысл вводить по-этапно, начиная с наиболее проблемной зоны.

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

Сколько итераций прототипирования и переделок  может быть при разработке продукта с нуля?

Ответу на этот вопрос посвящена целая глава в книге «Искусство Гейм Дизайна» (The Art of Game Design»). Если коротко, то при разработке проекта вы определяется для себя несколько точек «невозврата». Например первая точка — это стилистика и сеттинг. К этой точке вы должны испробовать все варианты и определиться. После прохождения этой точки к этому вопросу вы больше не возвращаетесь. В процессе определения делайте столько прототипов, сколько вам нужно для принятия решения.

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

Каждая точка невозврата отвечает за отдельный компонент игры: сеттинг, базовые механики, дополнительные обвесы…

Как организовать работу отделов между собой, отчетность, чтобы избежать простоев? Какой софт в этом поможет?

За способ организации взаимодействия отделов и ведения процессов отвечает Project Manager. Именно он определяет удобный способ планирования, ведения работы и отчетности. Это его зоны ответственности.

Диаграмма Ганта, проверенный способ для упорядочивания процессов. По ней хорошо делать ремонт в квартире, строить дом, так же по ней можно делать и игры. Но есть более удобные и современные решения, например Jira. В этом продукте вы можете выставить зависимости и организовать работу так, чтобы она была разбита по разным компонентам (скетч, отрисовка, анимация, сборка), которые определены в разные спринты. Таким образом задача может готовится несколько недель, но продюсер может быть уверен, что функционал будет готов к сроку в наилучших кондициях.

Кто при таком подходе отвечает за сроки?

Project Manager. Именно он оценивает реальные сроки. Если продюсер и Project Manager выступают в одном лице, тогда есть вопросы при планировании. Может ли продюсер организовать реализацию своих пожеланий без ущерба для продуктивности работы команды на долгой дистанции.

Используете ли вы Чек-Листы для того, чтобы упростить адаптацию новичка в работе над проектом?

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

Как наилучшим образом донести до продюсера пожелания по организации, что бы не задеть эго?

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

Что делать в случае кранчей, если не налажены коммуникации? Какую экстренную схему ты используешь?

В таких случаях мы собираемся, обозначаем срок и цель и кранчуем! Речь уже не идет об оценках задач — все работают на результат. Если команда не готова тратить сверх ресурсы, есть вопросы к подбору такой команды и мотивации. Если менеджер не организовал коммуникации, сам не ходит на работу, а задачи ставит в скайпе в стиле «сделай как там» — он практически не имеет возможности реализовать задачу за короткий срок. Команда должны быть готова к кранчам морально.

Сколько переделок одной задачи приемлемо?

Работая в команде, менеджеры знают, как часто у исполнителя не принимается та или иная задача. При определении конечных сроков закладывается буфер на доработки. Суть ТЗ снизить количество переделок до минимума. Могут быть корректировки, заложенные в рамках спринта, которые не должны превышать 1 дня максимум.

Презентация задачи, коммуникации после презентации задачи, правильное техническое задание —  должны исключить ситуации, когда приходится переделывать работу или её часть! Если переделка задачи занимает еще один спринт — то вопросы к постановщику задачи: Как ты доносил до команды этот компонент игры?

Как избежать коллегиального обсуждения доработок, занимающих много времени?

Если коммуникации налажены в команде, то такие быстрые обсуждения доработок не влияют на сроки. В любом случае правильно все пожелания и корректировки высказывать на собрании и вносить в ТЗ. Если же члены команды продолжают влиять на работу друг друга, то Project Manager должен пресечь подобные затеи и вынести все обсуждения на ретроспективу.