Рубрика «планирование проекта»

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

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

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

Рецепт гладкого релиза: PMy на заметку - 1
Читать полностью »

image

Создавать игры сложно

И самая сложная часть создания игр — это препродакшен. Это заявление может показаться обескураживающим. Все мы слышали о очень тяжёлых периодах продакшена игр и часто видели лёгкие, простые и интересные периоды препродакшена. Почему же я утверждаю, что препродакшен сложнее? Потому что один из аспектов, способных отравить продакшен — это выполняемый во время него препродакшен. Как бы ни был сложен препродакшен, гораздо сложнее (и намного дороже) выполнять его на этапе продакшена. Позвольте объяснить: в идеальном мире никто не брался бы за производство коммерческой игры, которую ждёт провал. Если вы намереваетесь создать игру с целью извлечения прибыли, и вы знаете, что игра прибыль не принесёт, то к продакшену вы не перейдёте.

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

В момент соединения всех частей (то есть создания первой играбельной версии) вы понимаете, действительно ли ваша команда шла к исходной цели. Это совершенно неподходящий момент, если вы проработали над игрой несколько лет.
Читать полностью »

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

image
Читать полностью »

Теоретики управления проектами говорят, что до 78% проектов не выполняются в срок, либо выходят за рамки бюджета. Любой, кто сталкивался с задержками проекта и срывом дедлайна сразу назовет вероятные причины. Это плохо сформулированные цели проекта, нереалистичные сроки, нехватка ресурсов и неэффективная коммуникация в команде.

Как создавать реалистичные планы: рекомендации Института управления проектами - 1
Читать полностью »

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

Веб-студии вне хаоса - 1

Читать полностью »

Зачем нужен план - 1Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.

Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:

  1. у нас слишком большая неопределённость, будет гадание на кофейной гуще;
  2. и так всё предельно ясно, план — лишняя трата сил.

Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.

Но сначала…
Читать полностью »

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

Читать полностью »

Данный пост является ненаучными комментариями к статическому анализу неких графиков (которые всё равно нельзя публиковать, потому что они ДСП). Все факты вымышлены, все имена изменены.

Представьте, идёт строительство дома…
Читать полностью »

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

Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
Читать полностью »