Я стал программистом на втором курсе колледжа, преуспев во всех своих курсах программирования и развив мышление программиста для решения проблем. Теперь, три года спустя, как продюсер видеоигр, мышление программиста, которым я так гордился, принесло мне много препятствий на моем первом этапе PoCT (Proof of Concept Technology). Стало ясно, что необходим сдвиг в мышлении.

Вот то, что я определил как основное различие между мышлением программиста и продюсера:

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

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

Цитируя слова одного из программистов в моей команде:
Работая над своим кодом, я обычно надевал шумоподавляющие наушники и оставался в своем мозгу. Я не слушал музыку; Мне просто нужна была тишина, чтобы сосредоточиться на своих кодах.

Однако, если продюсер надевает наушники с шумоподавлением, сидя со своей командой, это плохой продюсер.

Производители должны видеть везде и слышать везде.

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

Как продюсер SD, во время моего PoCT каждые десять-двадцать минут после того, как я сел на стул, мне звонил кто-то из моей команды или наш продюсер дизайна уровней, гейм-дизайнер, ведущий продюсер и т. д.

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

Это правда, что продюсеры должны следить за командой и выслушивать разные требования, но это не значит, что продюсерам не нужно ничего делать для себя. Они должны вести бэклог продукта, подсчитывать предполагаемые часы, постоянно проверять промежуточные результаты и т. д. Недопустимо, чтобы продюсер, лучший в команде с точки зрения тайм-менеджмента, не умел управлять своим временем. Должны быть внесены коррективы и приняты меры. Вот несколько предложений, которые может рассмотреть каждый производитель:

• Постарайтесь составить список обязательных дел на каждый рабочий день с расчетным количеством часов и тщательно следуйте этому списку, чтобы избежать сбоев.
• Установите временной интервал для каждого разговора и строго следуйте этому временному интервалу (десять минут может быть хорошим вариантом).

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

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

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

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

Более того.

Согласно идее лидерства слуги. Продюсеры должны поступать правильно — «служить команде» и быть готовыми оказать поддержку, как только команда в ней нуждается. Но что именно означает лидерство служения? Каковы ожидания команды от продюсеров? Какие проблемы они не могут решить без продюсеров? Проверьте мой будущий блог именно на эту тему!

Ссылка:

[1]: Учебное мышление: как улучшить обучение чему-либо

[2]: 18 навыков, которыми должны обладать все программисты

[3]: Важность своевременной и эффективной обратной связи