Мой опыт в IT компании
Дисклеймер
Я делюсь личным опытом, он может как вам пригодится, так быть вообще не релевантным. Многое зависит от разных факторов (компания, команда, культура, личность, финансы и т.п.).
Здесь написано про шаги в моей компании без погружения в процессы и инструментов.
У меня достаточно негативного и неуспешного опыта, так и положительного в разных компаниях.
Решил написать эту статью, потому что добился успешного опыта без негатива (опираясь на сухие цифры, которые под NDA и не могу сказать что за проект).
Пожалуйста, поделитесь своим опытом, он может мне пригодится в будущем.
Одна из лучших команд в компании
Это может быть субъективное определение. И мой параметр может не соответствовать вашему. Для меня лучшая команда, это когда качественно и в срок выполняет свою работу. Это 2 самых сложных параметра. И у многих команд с этим проблемы. С другими параметрами обычно лучше в командах, по этому я их тут не выделяю.
Самостоятельная — это когда я могу уйти в отпуск и не заниматься микроменеджментом.
Сейчас по порядку пройдусь по шагам что я делал в компании, чтобы сформировать такую команду и улучшать постоянно ее эффективность.
Адаптация
Устроился в компанию, как Project Manager.
Изучил основные документы компании по адаптации и предложил свое видение по разработке нового продукта.
Продукт разбил на компоненты и расписал пайплайн процессов.
Затем я начал знакомиться с лидами и директорами разных отделов. Т.е. программирование, арт, тестирование и т.д.
Формирование команды
Т.к. сегмент, который моя команда должна была разработать, являлся самым основным и важным — мне руководство дало самых сильных ребят. В основном это сеньоры и мидлы. Это не значит что джуны не нужны. У меня в команде они тоже были, но позже.
Знакомство с командой
Я познакомился с командой и рассказал о процессах, которые хочу запустить.
Т.к. я в прошлых компаниях был в роли Scrum Master, а не просто PM. Я решил взять часть артефактов из Скрама, которые легко внедряются.
Презентовал команде что хочу внедрить часть Scrum. В первую очередь, это были спринты, включающие в себя планирование, стендапы, обзор спринта и ретроспективу.
Для меня было важно, чтобы команда доверилась мне и согласилась на такие нововведения.
Я за то чтобы у каждого своя была зона ответственности. Каждый качественно выполняет свою работу и за каждым последнее решающее слово как нужно делать в их области. Это мои убеждения.
Состав команды
Состав команды я определяю так: Producer, Project Manager и Game Designer (это в геймдеве, вне геймдева это Product Owner и Scrum Master), те кто задают вектор разработки, инициаторы. Лиды отделов, кто ответственны за качество, сроки и экспертизу своих отделов (это арт, программирование, тех.дизайн, анимация, тестирования, озвучка, нарратив и т.д.). И линейные специалисты данных направлений. Всё мы — составляем единую команду. Важный момент, что есть лиды направлений. Это сыграло хорошую роль в процессах, когда команда стала 30, а потом и 40 человек.
Запуск процессов
В итоге я запустил все процессы, которые презентовал. Настроил структуру в таск-трекере.
Создал дорожную карту. Я ее разбил на компонентные основы. Когда какой компонент будет готов и какие зависимости существует. И спрогнозировал всё это сначала по типичным срокам аналогичных проектов, которые уже существовали в компании. Затем я их обновил исходя из возможности, скорости своей команды.
Единственное что я не вводил — это Story Points из Scrum. Т.к. не знал, как это сработает. До этого у меня был опыт Скрам Мастера только с программистами. Весь арт или дизайн был в других отделах и считался по умолчанию готовый, который не нужно учитывать в эстимации.
А в этой компании у меня были все сферы. От идеи до релиза. Т.е. от геймдизайнера с продюсером до QA. Где между ними код, арт, верстка, анимация, эффекты, озвучка.
Планирование
У меня было четкое планирование спринта, которое я умудрялся проводить за 60 минут, а с опытом это всё дошло до 30 минут. Чем я горжусь, т.к. я помню как только с программистами могло планирование обходиться в 1,5–2 часа в других компаниях. Удалось сократить за счет груминга (анализ перед планированием). Каждый спринт длился 2 недели.
У меня были цели от продюсера, что он ожидает к определенному релизу, дэдайну. Напоминаю, что это мы создавали продукт, который не был в релизе.
Я цели продюсера декомпозировал на большие сущности с геймдизайнером. Например, сделать определенное окно с работающим функционалом. Эти сущности как раз и были в дорожной карте.
В спринт мы могли брать несколько сущностей, все зависело от их объема или наоборот, делить одну сущность на несколько спринтов.
Я декомпозировал все эти компоненты на задачи для каждого отдела и проставлял зависимости.
На самом планировании команда могла уточнить интересующие моменты или подсветить со своей стороны риски, блокеры, которые могу возникнуть. Происходила синхронизация. Геймдизайнер выставлял приоритеты основным задачам, а я ориентировочные сроки, когда ожидаю результат.
В четких сроках смысла нет — это утопия. Если задачи сложные и каждый раз новые. Нет типичных сроков и даже на опыт специалистов и их оценки сложно ориентироваться (мне нравятся методы Э. Голдратта и его теории ограничения систем). В ходе разработки часто появляются новые вводные.
По этому я ставил глобальные сроки большим сущностям, но не декомпозированным задачам.
Спринт
В ходе спринта мы проводили короткие стендапы, они же дэйлики, не более 15 минут, где был полный состав команды (команда была ~12 человек).
Когда команда выросла до ~22 человек, то стендапы я адаптировал. Обязательные для лидов направлений, где я спрашивал статусы по интересующим меня задачам. А для всех остальных линейных специалистов пожеланию — таким образом мы сохранили тайминг, потому что говорит небольшое количество людей. И любой потом может задать вопрос из присутствующих. Те кому важна прозрачность и синк, те ходили на стенда. Те, кто считал что их отвлекает стендап от задач и нужно опять вникать в задачу, те не ходили. И это никак не сказалось плохо на процессах (можете со мной спорить, пишу только о фактах из личного опыта).
Обзор спринта
В обзоре спринта я обсуждал с командой, что сделано, а что нет, но совсем короткий период времени, т.к. для меня это выглядело, будто я ищу виноватых в том, почему что-то не сделали и публичная «казнь». Вместо этого, я на обзоре спринта показывал функционал, которая команда сделала, чтобы все были в контексте, замотивировались.
Ретроспектива — главное событие из всех в цикле спринта. Мы обсуждали как положительные моменты, так и негативные. Сама команда писала о моментах, которые хочет обсудить. Если это проблема, то мы также обсуждали варианты ее решения и назначали ответственного, чтобы это действительно было исправлено. Таким образом, мы постоянно улучшались от спринта к спринту.
Когда я видел, что хочется какого-то разнообразия и на ретро мало событий, особенно проблем, которые мы обсуждаем. Я проводил тимбилдинги. Что очень влияло на положительное настроение команды. Смеялись до слез и напряжение пресса)
Культура команды
Культура команды сформировалась естественным образом за счет нас, как личностей, так и единой сущности, как команда. Я выделил важные особенности нашей команды и каждому новому участнику их транслировал при знакомстве. Т.к. важно поддерживать эту культуру.
Почти в каждой компании транслируют схожие понятия их культуры. У нас это: ответственность, вовлеченность, насмотренность (широкий кругозор), самостоятельность, коммуникабельность, саморазвитие.
Почему это не просто слова, а ценность в моей команде. Т.к. я не занимался микро менеджментом, у меня на это не было желания и считаю бессмысленным и рутинным занятием. Мое время стоит дороже, чем заниматься такой ерундой. По этому несамостоятельные сотрудники у нас в команде долго не задерживались. Я не люблю контролировать людей — я хочу, чтобы просто дать задание и через период времени получить результат. Даже не спрашивать их, где результат, а просто он есть в нужный для меня срок.
По этому каждому новому сотруднику я говорил, что он заинтересован в выполнении своей задачи. Если его что-то блокирует ее выполнить, например, есть зависимость от другой задачи или не понимает как сделать. То обращаться к тем, кто может помочь или пушить те задачи, от которых он зависит. И не просто один раз спросить. А на системном уровне раз в день общаться с другими ребятами, которые его блочат. И так по цепочке.
Для этого нужна коммуникабельность, не бояться общаться с командой, с кем ты зависим над задачами. Не только обращаться ко мне как к Project Manager’у или своему лиду, но и линейным сотрудникам своего направления, чтобы обмениваться опытом или с другого отдела, чтобы понимать текущую ситуацию той или иной задачи.
Т.к. мы работаем над продуктом, то важно знать конкурентов, иметь высокую насмотренность, чтобы понимать ключевые особенности, наши или конкурента преимущества. Делать продукт высокого качества и говорить на одном языке, иметь одно понимание над чем работаем. И эту насмотренность сложно привить. Да, можно поставить задачу, чтобы изучал другие проекты, но это не то. Поэтому важна вовлеченность, чтобы сам хотел все это изучать, смотреть, гореть этим.
И также важно как развитие, так и саморазвитие. Под развитием имею ввиду, когда тебе лид рассказывает как сделать ту задачу, которую ты не знаешь как делать и первый раз с ней сталкиваешься, то запоминать подход и в дальнейшем делать самостоятельно.
Также самому изучать новые подходы, технологии.
Почему я говорю больше про линейных сотрудников об этих качествах, а не лидах? Потому что лиды всеми этими качествами по умолчанию обладали. Я смотрел на них и сформировал эти понятия в нашу команду. А остальным ребятам некоторым не хватали данные качества и нужно в них было развиваться.
Личность
По итогу мы сделали продукт, у него очень хорошие показатели! Это не только заслуга нашей команды, но и всей компании. Наша команда внесла существенный вклад в это.
И хочу отметить, что моя личность, лидерские качества в том числе сыграли большую роль. И сейчас расскажу почему.
По мимо того что у меня уже был хороший опыт как Project Managera и Scrum Master«a. Мне полностью доверилась компания. Все свои инициативы и решения я делал не спрашивая руководства. Потому что я считал что так нужно делать и правильно. А со стороны моих руководителей было полное доверие и поддержка. Они только со стороны наблюдали для синхронизации и понимания вектора развития нашего продукта и процесса.
Также как я выше говорил, команда мне тоже полностью доверилась и была лояльна к моим нововведениям. Где-то им было страшно, но они верили в то, что я делаю и каждый раз я только подтверждал верность своих решений результатами нашей команды.
Я общался с любыми людьми, когда это требовалось, с разными продюсерами, директорами, начальниками. Как нашей компанией, так и с другими компаниями, которыми сотрудничал. Потому что у меня были потребности в решение вопросов и я просто шел и их решал, обсуждал, договаривался.
Где-то я директивно менял процессы или встречи со стейкхолдерами, т.к. считал что это будет более эффективно. И видя мои результаты, другие команды это подхватывали или сами стейкхолдеры рекомендовали другим делать также.
По этому решительность, опыт и знания играют также важную роль в построении эффективных процессов и лучшей команды в компании.
Завершение
Возможно, такие статьи сюда нельзя писать и они плохо принимаются аудиторией. Если так, то об этом обязательно мне напишут в комментарии.
Но если статья была полезной, могу предложить:
Данную статью посмотреть в формате видео
Также в телеграм я рассказал (какая у меня зарплата, какие игры разработал, сколько зарабатываю на ютубе, как помогаю инди разработчикам и другое)
P.s. Ознакомлюсь с вашей точкой зрения и экспертизой. Всегда полезно узнать чужой опыт и альтернативное мнение. Спасибо вам)
Разработчик игр с 2005 года
С 2007 начал работать в IT компаниях как программист (as3, js, lua)
С 2012 ушел в разработку инди игр
С 2017 ушел в Blockchain (solidity) и FinTech
С 2018 ушел в менеджмент и процессы. Team Lead разработчиков, Scrum Master, Project Manager (разные роли в разных компаниях)
С 2021 вернулся в GameDev как менеджер
