Я стал программистом на втором курсе колледжа, преуспев во всех своих курсах программирования и развив мышление программиста для решения проблем. Теперь, три года спустя, как продюсер видеоигр, мышление программиста, которым я так гордился, принесло мне много препятствий на моем первом этапе PoCT (Proof of Concept Technology). Стало ясно, что необходимо изменить мышление.
Вот то, что я определил как основное различие между мышлением программиста и продюсера:
- Программисты должны сосредоточиться на отдельных задачах, а производители должны быть более универсальными и доступными для своих команд.
- Программисты получают мгновенную обратную связь и четкие правильные или неправильные ответы, в то время как производители часто не получают немедленной обратной связи и сталкиваются с более неоднозначными ситуациями.
Программисты должны сосредоточиться на своих задачах
Когда программистам даются функции, которые им нужно реализовать, они продумывают архитектуру своего кода и смотрят, смогут ли они реализовать функции на основе своих существующих функций. И если они не могут, им нужно придумать новые функции (большие, вероятно, включая создание архитектур, определение логики, а также тестирование и отладку), чтобы соответствовать требованиям.
Цитирую слова одного из программистов в моей команде:
Во время работы над своим кодом я обычно надевал шумоподавляющие наушники и оставался в своем мозгу. я не слушал музыку; Мне просто нужна была тишина, чтобы сосредоточиться на своих кодах.
Однако, если продюсер надевает наушники с шумоподавлением, сидя со своей командой, это плохой продюсер.
Производители должны видеть везде и слышать везде.
Продюсеры обязаны отслеживать прогресс каждого в своей команде, следить за тем, чтобы они не превышали масштабы, и координировать свои действия с продюсерами других команд, если необходимо межкомандное сотрудничество.
Как продюсер SD, во время моего PoCT каждые десять-двадцать минут после того, как я сел на стул, мне звонил кто-то из моей команды или наш продюсер дизайна уровней, гейм-дизайнер, ведущий продюсер и т. д.
Всякий раз, когда я пытался больше сосредоточиться на конкретной задаче, кто-то звонил мне. Во время PoCT, к счастью, я удовлетворил всех, кто со мной разговаривал, нуждались ли они в разъяснениях по календарю или в помощи специалиста нашей команды и т. д.; к сожалению, я должен работать дополнительное время над своими делами после нашего обычного рабочего времени.
Это правда, что продюсеры должны следить за командой и выслушивать разные требования, но это не значит, что продюсерам не нужно ничего делать для себя. Они должны вести бэклог продукта, подсчитывать предполагаемые часы, постоянно проверять промежуточные результаты и т. д. Недопустимо, чтобы продюсер, лучший в команде с точки зрения тайм-менеджмента, не умел управлять своим временем. Должны быть внесены коррективы и приняты меры. Вот несколько предложений, которые может рассмотреть каждый производитель:
- Постарайтесь создать список обязательных дел на каждый рабочий день с расчетным количеством часов и внимательно следуйте этому списку, чтобы избежать непредвиденных ситуаций.
- Установите временной интервал для каждой беседы и строго следуйте этому временному интервалу (десять минут может быть хорошим вариантом).
Производителям требуется больше времени, чтобы получить обратную связь, и трудно сказать, правильны ли их корректировки.
Программисты привыкли к мгновенной обратной связи. Они почти сразу после нажатия «Выполнить» узнают, реализуют ли их коды функцию/соответствуют ли требования. Однако у производителей вряд ли будут быстрые ответы. Они не могут сразу сказать, решает ли их корректировка проблему. Чтобы узнать, чем закончится их корректировка, могут потребоваться дни, недели или даже до следующей вехи.
Программистам также легко сказать, правильно это или нет. Например,
· Правильно оптимизировать код, чтобы использовать меньше ресурсов памяти.
· Правильно писать чистый код с соответствующими комментариями, чтобы другие понимали его код.
· Это неправильно, когда их отладочное поведение вызывает больше ошибок.
· Это неправильно, если они реализуют плохие функции.
Однако для производителей это совсем другая история. Иногда команде нравятся корректировки продюсера, но на самом деле это плохо сказывается на производительности. Иногда команда может жаловаться на корректировку, но она повышает производительность, и команда принимает корректировку, испытав ее некоторое время.
Это чуть не свело меня с ума в первый момент, когда я понял, что мне нужно скорректировать свой способ управления, но не знал, как это сделать. Я стараюсь выделять подгруппы, такие как команда ИИ, команда физики, команда игровой логики и т. д., чтобы разделить более широкую тему на более мелкие части. Но через несколько дней кажется, что все немного отдалились друг от друга. Кроме того, у нас почти нет междисциплинарного общения в PoCT, мы, продюсеры, придумали способы приспособиться, но мы понятия не имели, что это приведет к следующему этапу.
Более того.
Согласно идее лидерства слуги. Продюсеры должны поступать правильно — «служить команде» и быть готовыми оказать поддержку, как только команда в ней нуждается. Но что именно означает лидерство служения? Каковы ожидания команды от продюсеров? Какие проблемы они не могут решить без продюсеров? Проверьте мой будущий блог именно на эту тему!
Ссылка:
[1]: Учебное мышление: как улучшить обучение чему угодно
[2]: 18 навыков, которыми должен обладать каждый программист
