Распределять, документировать и свалить

Вопрос:

Грамотное распределение ответственных за части системы. Особенно когда изначальный автор фичи собирается уйти из компании или перевестись в соседний отдел.

Начнем со второй части вопроса: "Когда автор собрался свалить".

Предисловие к ответу:

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

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

Самое важное в техническом отделе - это Документация.

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

Мы всегда документируем сложные системы. А не сложные можно разобрать в течение дня и без документации. Как-нибудь обязательно расскажу вам про технику разбора систем, которую я для себя открыл. Обещаю, вам понравится =)

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

А как там это работает?

Знаете, что я отвечаю? =) Правильно:

Идите и читайте документацию, потому что у нас она есть =)

И это не потому, что я ничего не помню, ненене =)

Третий путь - самый рискованный. Это надежда на то, что другие программисты сами разберутся с чужим кодом. Нет, не разберутся =) Им легче будет переписать, чем разбираться в чужом коде.

Кстати, от этой проблемы у нас в команде есть небольшое лекарство в виде Формальной Инспекции. Однажды я напишу и о ней свой большой пост =)

Что еще можно сделать, чтобы избежать подобных ситуаций?

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

Узконаправленная специальность.

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

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

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

Ну или можно просто верить и надеяться, что аниматор не уйдет. Если вы в этом варианте, то мои поздравления, у вас высокая связность объектов =)

Грамотное распределение ответственных за части системы.

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

Поэтому если у вас лид команды с 2-летним стажем работы в этой среде - вашей команде конец прописан еще до начала работы =)

А если ваш лид это номинальная должность, а сам он постоянно пишет код, то давайте уже признаем - он не руководитель, а исполнитель. Он явно даже близко не представляет то, чем он обязан заниматься.

Об этом будет, кстать, следующий пост - ответ на вопрос Маргариты о уровнях опыта программистов.