Лучшая команда в Gamedev компании. Как я ее создал?

Я в IT с 2005 года. 13 лет - программист. 5 лет - scrum master (project manager).

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

Пожалуйста, поделитесь своим опытом, он может мне пригодится в будущем.

Это может быть субъективное определение. И мой параметр может не соответствовать вашему. Для меня лучшая команда, это когда качественно и в срок выполняет свою работу. Это 2 самых сложных параметра. И у многих команд с этим проблемы. С другими параметрами обычно лучше в командах, по этому я их тут не выделяю.

Самостоятельная - это когда я могу уйти в отпуск и не заниматься микроменджментом.

Сейчас по порядку пройдусь по шагам что я делал в компании, чтобы сформировать такую команду и улучшать постоянно ее эффективность.

Устроился в компанию.

Изучил основные документы компании по адаптации и предложил свое видение по разработке нового продукта.

Продукт разбил на компоненты и расписал пайплайн процессов.

Затем я начал знакомиться с лидами и директорами разных отделов. Т.е. программирование, арт, тестирование и т.д.

Т.к. сегмент, который моя команда должна была разработать, являлся самым основным и важным - мне руководство дало самых сильных ребят. В основном это сеньоры и мидлы. Это не значит что джуны не нужны. У меня в команде они тоже были, но позже.

Я познакомился с командой и рассказал о процессах, которые хочу запустить.

Т.к. я Scrum Master, а не просто PM. Я решил взять часть артефактов из Скрама, которые легко внедряются.

Презентовал команде что хочу внедрить часть Scrum. В первую очередь, это были спринты, включающие в себя планирование, стендапы, обзор спринта и ретроспективу.

Для меня было важно, чтобы команда доверилась мне и согласилась на такие нововведения.

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

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

Состав команды я определяю так: Producer (Product Owner), Project Manager (Scrum Master) и Game Designer, те кто задают вектор разработки, инициаторы. Лиды отделов, кто ответственны за качество, сроки и экспертизу своих отделов (это арт, программирование, тех.дизайн, анимация, тестирования, озвучка, нарратив и т.д.). И линейные специалисты данных направлений. Всё мы - составляем единую команду. Важный момент, что есть лиды направлений. Это сыграло хорошую роль в процессах, когда команда стала 30, а потом и 40 человек.

В итоге я запустил все процессы, которые презентовал. Настроил стуктуру в таск-трекере.

Создал дорожную картку. Я ее разбил на компонентные основы. Когда какой компонент будет готов и какие зависимости существует. И спрогнозировал всё это сначала по типичным срокам аналогичных проектов, которые уже существовали в компании. Затем я их обновил исходя из возможности, скорости своей команды.

Единственное что я не вводил - это Story Points из Scrum. Т.к. не знал, как это сработает. До этого у меня был опыт Скрам Мастера только с программистами. Весь арт или дизайн был в других отделах и считался по умолчанию готовый, который не нужно учитывать в эстимации.

А в этой компании у меня были все сферы. От идеи до релиза. Т.е. от геймдизайнера с продюсером до QA. Где менжду ними код, арт, верстка, анимация, эффекты, озвучка.

У меня было четкое планирование спринта, которое я умудрялся проводить за 60 минут, а с опытом это всё дошло до 30 минут. Каждый спринт длился 2 недели.

У меня были цели от продюсера, что он ожидает к определенному релизу, дэдайну. Напоминаю, что это мы создавали продукт, который не был в релизе.

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

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

Я декомпозиорвал все эти компонеты на задачи для каждого отдела и проставлял зависимости.

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

В четких сроках смысла нет - это утопия. Если задачи сложные и каждый раз новые. Нет типичных сроков и даже на опыт специалистов и их оценки сложно ориентироваться (мне нравятся методы Э. Голдратта и его теории ограничения систем). В ходе разработки часто появляются новые вводные.

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

В ходе спринта мы проводили короткие стендапы, они же дэйлики, не более 15 минут, где был полный состав команды (команда была ~12 человек).

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

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

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

Когда я видел, что хочется какого-то разнообразия и на ретро мало событий, особенно проблем, которые мы обсуждаем. Я проводил тимбилдинги. Что очень влияло на положительное настроение команды. Смеялись до слез и напряжение пресса)

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

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

Почему это не просто слова, а ценность в моей команде. Т.к. я не занимался микроменеджментом, у меня на это не было желания и считаю бессмысленным и рутинным занятием. Мое время стоит дороже, чем заниматься такой ерундой. По этому несамостоятельные сотрудники у нас в команде долго не задерживались. Я не люблю контролировать людей - я хочу, чтобы просто дать задание и через период времени получить результат. Даже не спрашивать их, где результат, а просто он есть в нужный для меня срок.

По этому каждому новому сотруднику я говорил, что он заинтересован в выполнении своей задачи. Если его что-то блокирует ее выполнить, например, есть зависимость от другой задачи или не понимает как сделать. То обращаться к тем, кто может помочь или пушить те задачи, от которых он зависит. И не просто один раз спросить. А на системном уровне раз в день общаться с другими ребятами, которые его блочат. И так по цепочке.

Для этого нужна коммуникабельность, не бояться общаться с командой, с кем ты зависим над задачами. Не только обращаться ко мне как к Project Manager'у или своему лиду, но и линейным сотрудникам своего направления, чтобы обмениваться опытом или с другого отдела, чтобы понимать текущую ситуацию той или иной задачи.

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

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

Также самому изучать новые подходы, технологии.

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

По итогу мы сделали продукт, у него очень хорошие показатели! Это не только заслуга нашей команды, но и всей компании. Наша команда внесла существенный вклад в это.

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

По мимо того что у меня уже был хороший опыт как Project Managera и Scrum Master’a. Мне полностью доверилась компания. Все свои инициативы и решения я делал не спрашивая руководства. Потому что я считал что так нужно делать и правильно. А со стороны моих руководителей было полное доверие и поддержка. Они только со стороны наблюдали для синхронизации и понимания вектора развития нашего продукта и процесса.

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

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

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

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

if (вы не захейтили меня дочитав до сюда) {

Могу предложить:

} else {

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

}