У студентов есть проекты на весь семестр, и недавно я проводил консультацию, что им стоит в своих проектах улучшить.
Одна студентка пришла прямо с запросом (и я считаю, что она большая молодец). Не понимаю, говорит, как делать роадмап. И я половину пары пытался это объяснить.
Конечно, это задача, которая связана с другими, так что пришлось многое ещё пояснить.
Заодно и для себя сформулировал. Еще не идеально, был кусок, где мне почему-то сложно, но я забыл, какой. Но ничего, ещё пару раз объясню, и разберусь.
Термины у всех плавают, поэтому я напишу так, как сам привык, а в комментариях уточним, если что.
В общем, записываете вы геймплей игры, как его представляете. Или геймфокус. Или вижн. Ну, хоть какое-то представление, что в игре будет.
Потом дробите его на фичи. Или задачи. Формируете фичелист, в котором есть всё.
Даже фраза "герой стреляет во врага" означает, что вам надо придумать героя, врага, механику стрельбы, урона, вид оружия и т.д. это всё задачи.
Дальше сложный для объяснения момент: надо понять, какие штуки вот это всё записанное за собой тащит. Ну например, "герой стреляет во врага" где-то. Значит, есть ещё задача "придумать локацию". Как этот этап нормально объяснить, когда у разработчика нет опыта задавания вопросов, я пока не знаю.
После этого берёте получившийся фичелист и назначаете исполнителей. Если исполнителей нет - значит, есть задача их найти.
А дальше уже с исполнителями проясняете по каждой задаче три вопроса:
- сколько времени она займёт;
- что нужно, чтобы её начать (ресурсы, условия, выполненные другие задачи);
- как будет выглядеть результат.
Последний пункт очень важен, потому что в роадмапе лучше писать задачи в виде результата: не "делать локации", а "сделать три локации". И где-то отдельно записать, что считается сделанной локацией. Иначе велик шанс получить в конце не то, что надо.
Ну и ещё наверняка куча других задач вылезет, что не на поверхности.
Эта штука сильно сложнее, чем кажется, и наверняка в процессе будет меняться. Потому вряд ли вы в начале разработки детально представляете, как игра будет выглядеть. Например, сколько локаций вам вообще надо.
Потом стоит задачи приоретизировать. По двум основаниям:
- что самое важное. Например, без разных видов оружия игра может обойтись, а без врагов нет.
- что после чего идёт. Например, механ стрельбы из дробовика не пропишешь, пока механа стрельбы в общем нет.
Собственно, сейчас у вас есть список задач с исполнителями, образом результата, длительностью и условиями. Осталось расположить их друг за другом с учётом приоритетов и всего остального.
Наилучший, как по мне, способ это сделать: диаграмма Ганта, где по вертикали исполнители, а ро горизонтали время.
Так будет сразу видно, кто недозагружен, а кого не хватает. Если у вас задач для программиста на полторы длительности проекта, то вам явно второй программист нужен.
Та-дам! Роадмап готов.
Только надо учитывать четыре сложности:
- это не единственно возможный алгоритм и вообще подход.
- за роадмапом нужно внимательно следить при разработке, иначе он вам зачем.
- он точно будет меняться по ходу.
- есть куча нюансов, которых я не перечислил. Например, надо продумать, что делать, когда сроки поплывут.
Многое приходит с опытом. Но опыт должен же с чего-то начаться.
Вот я сейчас качаю опыт объяснения сложных штук.
