Кубики у нас, как и правила с линейками, в свободном доступе. И если они потрепаются, сомнутся, потеряются — можно скачать и распечатывать. Если такой формат не подойдет, то мы сделаем уже возможность к любому повторному заказу с допами к игре добрать лист с кубиками :) Нам не жалко.
Мы уважаем все перечисленные вами проекты, но считаем их местами излишне перегруженными и пытались некоторые моменты упростить. Да мы будем экспериментировать с механиками, да и игрокам никто не запрещает выбрать любую ему знакомую. Придумать свою и запилить мод.
Бич первого хода мы пытаемся сгладить механикой «реакции». Так в хорошо простреливаемый проход под надзором врага лучше не лезть, однако это спровоцирует тактически заходить с фланга и нападать вне поля зрения врага.
Да, мы будем расширять нашу линейку кубиков и связанных с этим механики. Но надо понимать, что наши кубики бумажные, что даёт нам кучу возможностей, но рандом будет условный.
Мы не претендуем на какую-то спортивность и топим больше за наратив и возможность реализовать интересный сюжет на столе. Отыграть своего персонажа, ведь дудла можно собрать как угодно и поменять ему закачку прямо во время игры.
Небольшой опыт есть, представление как оно все работает уж точно :) Конечно, повлияло. Еще повлияли игры из любимых 90-х Jagged Alliance и X-COM
С тестами все как обычно в настоящем стартапе: запилили MVP и пошли тестировать в рынок :) На самом деле, мы сами играли, сын мой собрал и поиграл со мной и друзьями, раздали друзьям. После запустили, но правила еще будут меняться с появлением следующих серий, сейчас уже вот-вот с инопланетянами запустим.
Лучше начинать решать проблемы не с людей, а с организации работы. Хороший и трудолюбивый специалист в посредственной организации не сможет эффективно работать.
Конечно, такой подход идеально подходит для разработки в рамках каких типовых решений и обычных (привычных) патернов поведения. Или тогда, когда абсолютно уверен и очень четко видишь конечный результат. Порой, что-то попробовать и посмотреть как оно получится, подвигать блоки, дорисовать мелочи и прочие-прочие мне намного удобнее в графическом редакторе. Идеальный вариант сделать графическую концепцию, пару-тройку страниц и уже дальше все это дело верстать.
Мы занимаемся разработкой сайтов и от макетов нам некуда не деться, так как на них с клиентом согласовывается дизайн-концепция. Чтобы как-то сократить сроки разработки мы делаем подробный прототип, по которому ведется разработка (программирование) и параллельно занимаемся разработкой дизайна и согласовываем его с клиентом. После технолог верстает страницы и «сводит» все с результатами работы программиста. Сейчас мы хотим попробовать рисовать только дизайн концепцию и элементы интерфейса, остальное все будет делать технолог по подробному прототипу, а дизайнер и иллюстратор будут дорисовывать необходимые элементы.
При последовательном подходе, согласование макетов нужно для утверждения структуры сайта и выявление всех необходимых деталей. На практике, в процессе согласования, появляется много разных нюансов, которые значительно влияют на разработку. В техническом задании всего не учтешь и, как я и писал в заметке, все его понимают по разному, а клиент часто вообще не читает. Мы стараемся сделать максимально нужный продукт клиенту и не упираемся в буквы договора, а пытаемся простроить процесс так, чтобы малой кровью добиться лучшего результата. Поэтому делаем прототип, по которому и начинается параллельная работа, другого способа на данный момент я не вижу.
Я не претендую на какое-то новшество или открытие века. На мой взгляд, в заметки я указал довольно логичный подход и по моим же наблюдениям большинство студий так не работает, а использует последовательный подход к разработке.
Цифры по времени разработки не очень верная метрика (как бы удивительно это не было), так как они во многом зависят от клиента, но вся разработка без согласований и занесением контента укладывается в цикл от 4 до 6 недель.
Интернет-магазин интернет-магазину рознь :) Мы стараемся уложить первый цикл разработки в 4-6 недель. Если клиент приходит с чем-то большим и сложным, то бьем задачу на этапы. В пример с интернет-магазином, плотную интеграцию с системой учета (бронирование заказов в самой системе) и хитрый расчет доставки можем вынести в отдельный этап.
Конечно, не всгда так получается и цикл разработки из-за долгих согласований или молчания клиента может растягиваться. Для того и разделили проекты, чтобы как-то эту ситуацию разрулить и все сильно не растягивалось.
Команда состоит из проектировщика-руководителя проекта, дизайнера, иллюстратора, программиста и технолога. Если мы сами заносим контент на сайт, то дополняется контент-менеджером.
Я, наверное, плохо описал. Дело больше не в быстром прототипировании, а скорее в начале разработке сразу после прототипа, без ожидания пока будут согласованы и сверстаны дизайн-макеты.
С таким подходом эффективно и удобно работать с одним проектом, в студии обычно их намного больше и собираться по каждому из мелких этапов всю команду разработки может оказаться убыточно.
Бывает что дизайнеру заказывают «Общую концепцию», а заказчик за остальные страницы просто не готов платить и отмахивается на «Остальное стандартно». Как правило тут и верстальщик шарашит Стандартно за 500 рублей. Заказчик съэкономил и доволен.
Думаю, толковый дизайнер сам прекрасно знает что надо отрисовать и что он может забыть. Просто не всегда готовы за это платить. Конечно, негоже забывать про качество работы, но и тут не безгранично терпение. Впроцессе работы встает вопрос перед заказчиком по дополнительным работам и тут решение за клиентом. Если он выбрал не платить, то он же не скажет Верстальщику что не стал платить за дополнительные элементы и попросит его сделать стандартно.
Если же говорить про процесс в студии, то тут уже договоренности Дизайнер-Технолог. У нас как правило Технолог говорит что ему необходимо отрисовать и сделать, а что он сам сделает. Наш Технолог молодец и он вполне многое делает сам.
Групон для предпринимателя — это реклама за Бартер, а не за деньги. За рекламу, я расплачиваюсь своими товарами или услугами. Есть момент, что предоставляя услуги дешево я снижаю их ценность. Но все должно быть в меру разумного и использовать Групон как источников клиентов — неправильно.
Ок, посчитаем время на движение глаз, а сколько времени пользователь по кнопкам тыркать и вводить данные будет? Мое мнение: время движение глаз ничтожно по сравнению со временем, которое пользователь тратит на именно введение данных и на проверку все ли правильно запомнил. В правом случае проверять данные намного удобнее.
Нельзя однозначно сказать какой вариант лучше, возможно что левый для разового заполнения лучше. А если ситуация что операционист постоянно заносит данные в однотипную форму? Он уже наизусть знает все поля, ему просто проверить надо каждое поле на правильность (правый случай удобнее, опять же движения глаз меньше ;)) и скролить меньше, так как меньше места занимает.
Мы уважаем все перечисленные вами проекты, но считаем их местами излишне перегруженными и пытались некоторые моменты упростить. Да мы будем экспериментировать с механиками, да и игрокам никто не запрещает выбрать любую ему знакомую. Придумать свою и запилить мод.
Бич первого хода мы пытаемся сгладить механикой «реакции». Так в хорошо простреливаемый проход под надзором врага лучше не лезть, однако это спровоцирует тактически заходить с фланга и нападать вне поля зрения врага.
Да, мы будем расширять нашу линейку кубиков и связанных с этим механики. Но надо понимать, что наши кубики бумажные, что даёт нам кучу возможностей, но рандом будет условный.
Мы не претендуем на какую-то спортивность и топим больше за наратив и возможность реализовать интересный сюжет на столе. Отыграть своего персонажа, ведь дудла можно собрать как угодно и поменять ему закачку прямо во время игры.
Дудл, в нашем контексте, это бумажная фигурка. С летсплеем еще снимем, пока в ближайшее время должно уже появится парочка видео обзоров от блогеров :)
С тестами все как обычно в настоящем стартапе: запилили MVP и пошли тестировать в рынок :) На самом деле, мы сами играли, сын мой собрал и поиграл со мной и друзьями, раздали друзьям. После запустили, но правила еще будут меняться с появлением следующих серий, сейчас уже вот-вот с инопланетянами запустим.
Спасибо, здесь как раз и солдатики ;)
Мы занимаемся разработкой сайтов и от макетов нам некуда не деться, так как на них с клиентом согласовывается дизайн-концепция. Чтобы как-то сократить сроки разработки мы делаем подробный прототип, по которому ведется разработка (программирование) и параллельно занимаемся разработкой дизайна и согласовываем его с клиентом. После технолог верстает страницы и «сводит» все с результатами работы программиста. Сейчас мы хотим попробовать рисовать только дизайн концепцию и элементы интерфейса, остальное все будет делать технолог по подробному прототипу, а дизайнер и иллюстратор будут дорисовывать необходимые элементы.
Правда как всегда посередине :)
Я не претендую на какое-то новшество или открытие века. На мой взгляд, в заметки я указал довольно логичный подход и по моим же наблюдениям большинство студий так не работает, а использует последовательный подход к разработке.
Цифры по времени разработки не очень верная метрика (как бы удивительно это не было), так как они во многом зависят от клиента, но вся разработка без согласований и занесением контента укладывается в цикл от 4 до 6 недель.
Конечно, не всгда так получается и цикл разработки из-за долгих согласований или молчания клиента может растягиваться. Для того и разделили проекты, чтобы как-то эту ситуацию разрулить и все сильно не растягивалось.
Команда состоит из проектировщика-руководителя проекта, дизайнера, иллюстратора, программиста и технолога. Если мы сами заносим контент на сайт, то дополняется контент-менеджером.
Думаю, толковый дизайнер сам прекрасно знает что надо отрисовать и что он может забыть. Просто не всегда готовы за это платить. Конечно, негоже забывать про качество работы, но и тут не безгранично терпение. Впроцессе работы встает вопрос перед заказчиком по дополнительным работам и тут решение за клиентом. Если он выбрал не платить, то он же не скажет Верстальщику что не стал платить за дополнительные элементы и попросит его сделать стандартно.
Если же говорить про процесс в студии, то тут уже договоренности Дизайнер-Технолог. У нас как правило Технолог говорит что ему необходимо отрисовать и сделать, а что он сам сделает. Наш Технолог молодец и он вполне многое делает сам.
Нельзя однозначно сказать какой вариант лучше, возможно что левый для разового заполнения лучше. А если ситуация что операционист постоянно заносит данные в однотипную форму? Он уже наизусть знает все поля, ему просто проверить надо каждое поле на правильность (правый случай удобнее, опять же движения глаз меньше ;)) и скролить меньше, так как меньше места занимает.