Out of Scope

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

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

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

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

Но к чему я это веду, это же состояние Out of Scope постоянно случается во время разработки и избавится от него довольно тяжело, если его запустить, но даже в запущенном состоянии это реально.

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

Основные причины, которые приводят к выходу за рамки scope:

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

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

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

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

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

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

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

Документация устаревает в момент ее написания

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

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

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

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

Даже фичи, которые мы писали в начале, к концу проекта в 90 процентах случаев будут изменены, некоторые выкинуты за ненадобностью и так далее.

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

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

• пишется one page document или же pitch, который отвечает на основные вопросы и на основе которого принимается решение о том, будет ли делаться проект;
• на основе питча пишется расширенная концепция, которая покрывает вопросы об основных механиках, которые мы будем использовать;
• после этого весь проект разбивается на промежуточные этапы для реализации этих механик;
• на основе этого создается дальнейшая документация, которая покрывает конкретно и детально те фичи, которые мы будем реализовывать на ближайшем промежутке.

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

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

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

Что мы имеем в сухом остатке:

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

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

Во всем виноваты бюджеты

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

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

Но перед тем как продолжить читать дальше, послушайте отличный доклад от Petri Purho "Why Being Poor and Having No Budget is Good For Making Game". Его я привожу часто в пример, когда начинаются разговоры за бюджеты. Он банальный, в нем нет ничего нового, но он дает понять, что игры можно делать и без бюджетов.

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