Разработчик после непростого релиза собирается участвовать в техдне
Разработчик после непростого релиза собирается участвовать в техдне

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

Пожалуй, наиболее узнаваемый пример допуска такой свободы выражения — это правило 20%, выработанное в Google. В соответствии с ним, каждый сотрудник компании имеет право 20% рабочего времени — считай, один день в неделю — посвящать сторонним проектам, не связанным с основной деятельностью. Благодаря правилу 20% в свое время появились на свет такие проекты, как Gmail и AdSense, а также сотни мелких фичей, многие из которых ушли в open source. Вокруг этой методики раньше ходило много споров, но в самой Google она действует до сих пор, да и перенимали ее даже такие гиганты, как Atlassian и Apple — в последнем программа называется Blue Sky и позволяет сотрудникам на две недели отойти от своих обычных обязанностей в пользу чего-то нового. В LinkedIn это выродилось в программу InCubator, в рамках которой сотрудники могут пропитчить свой проект и в случае, если он получит «зеленый свет», заниматься им последующие три месяца.

У нас в Pixonic тоже есть похожая инициатива. Мы называем это техдни.


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

“Первое, что сделал наш новый сотрудник, — это пофиксил баг, который вечно его нервировал как пользователя еще до того, как он устроился к нам на работу. Затем он выдохнул с облегчением и подал заявление об увольнении. В смысле?”

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

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

У нас это устоявшаяся практика, которую мы планируем продолжать, потому как в целом от нее видим много плюсов:

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

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

  • Это и возможность сделать прототипы, которые затем вырастают в полноценные фичи: игровые режимы, обновление артов и т. д.

Более того, мы стараемся не просто регулярно проводить техдни, но и собирать фидбэк команды и вносить улучшения, чтобы это было полезнее для всех:

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

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

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

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

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

  • Например, у нас давно были мысли насчет нового игрового режима, но мы не были до конца уверены, что стоит начинать над ним работу. И вот на техдне небольшая команда собрала «на коленке» прототип, посмотрев на который стало понятно: крутяк, мы хотим видеть это на проде! Так оно и получилось. 

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

Было
Было
Стало
Стало
  • Было такое, что в результате техдня решались судьбы фичей. Так, в бэклоге давно висела доработка из разряда “quality of life” — просмотр профиля игроков с другой платформы (когда-то это отфичекатили при создании кроссплатформенного матчмейкинга). Вроде бы и сделать хочется, и игроки будут рады, но впереди всегда будет целый список куда более приоритетных вещей. В случае этой доработки дело осложнялось тем, что задача казалась довольно трудоемкой, и даже ее оценка требовала немало времени на RnD. И вот в рамках техдня один из разработчиков исследовал таки этот вопрос, и оказалось, что если немного упростить реализацию, можно все сделать довольно бюджетно. Это и стало аргументом, чтобы задача наконец-таки попала в скоуп очередного релиза.

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

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

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

Комментарии (4)


  1. dididididi
    01.08.2022 14:20
    -6

    Можно ещё кроме написания документации, по фану помассажировать начальнику ступни, отказаться от части зарплаты или наконец почистить грязный унитаз.

    Надо уметь развлекаться)


    1. Alexandroppolus
      01.08.2022 15:05

      Если не начальник, а симпатичная начальница, то затея со ступнями кажется совсем недурственной..


  1. ov7a
    02.08.2022 15:25

    Можно "сделать что-то по фану", но:

    1. "делаешь что-то связанное с проектом"

    2. "у кого-то может быть реально много задач"

    3. "можно просто выбрать из списка"

    4. "на время техдней объединяться в мини-команды"

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

    6. "специальная встреча с продюсером и лидами команд, где рассматриваются все результаты"

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

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


  1. Mike-M
    02.08.2022 16:20

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