Архивы Перевод

Перевод

Мы не смогли пройти мимо крутейшей статьи по Agile от главы проектов Toptal. А чтобы было легче ей поделиться, мы ее перевели. Просим любить и жаловать!

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

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

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

Написание качественного ПО – это хлеб с маслом для разработчиков; создание же классного программного продукта – намного более сложное предприятие для всех, кто в него вовлечен.

Разработка крутого ПО требует идеального баланса

Однако, когда мы говорим о ПО, понимание сроков и стоимости является ключевым для принятия стратегических бизнес-решений. Это верно и для стартапов, и для сложившихся бизнес-проектов, и для оптимизации бизнес-процессов. Затраты времени, возврат инвестиций и полученные преимущества могут помочь бизнесу или разрушить его. Логичны вопросы: что мы получим за наши деньги? Можем ли мы предсказать издержки? Сколько будет стоить создание продукта, который мы хотим? Когда мы его запустим? Получим ли мы качественный продукт в результате? Поможет ли он развитию бизнеса? Принесет ли он нам дополнительную ценность?

Итак, как же быть с оценкой масштабов, сроков и стоимости проекта? Давайте исследуем возможности Agile, и то, что делаем мы в Toptal.

Традиционный подход к цене договора и оценке

Традиционно, если вы не используете Agile и создаете ПО с определенным функционалом, для определенной сферы, то допускаете вариабельность сроков и затрат. Это приводит к проблемам:

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

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

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

Все следствия вариативных сроков и стоимости отрицательные и нежелательны.

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

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

Подход к проектам разработки в Agile

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

Что лучше звучит и вызывает больше доверия у заказчика – фиксированная или переменная стоимость? При этом важно, чтобы продукт исполнял свое предназначение и удовлетворял нуждам заказчика. Нет никакого смысла в том, чтобы потратить точное количество времени и денег и получить инструмент, который невозможно эффективно использовать.

Поэтому контракты, созданные по методологии Agile, предполагают следующие опции:

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

– Ранняя остановка разработки. Это позволяет заказчику остановить работу над проектом на любой стадии, если результат уже получен и дальнейшая разработка не ускорит возврат инвестиций, а только увеличит затраты на работу команды. Преимущество для покупателя в этой ситуации заключается в скорейшем завершении работы над проектом, если он имеет весь необходимый функционал и вполне жизнеспособен. Чаще всего, разработчик получает при этом компенсацию рисков, например, в размере 20% от оставшейся стоимости договора.

– Гибкие изменения. Изменения заложены в ДНК разработки по методологии Agile. Мы ожидаем, что в самом начале не знаем всего необходимого для успеха проекта. Поэтому мы поощряем изменения, основанные на релевантных данных и обратной связи. Они помогают убедиться в том, что мы работаем в правильном направлении. В конце каждой итерации мы можем отказаться от функционала, который больше не нужен или не является приоритетным, или заменить его. И если новый имеет ту же стоимость, то это не повлияет на цену договора. Если же стоимость будет ниже, то мы сможем добавить что-то, от чего ранее решили отказаться. Это возможно в любое время, если команда проекта и заказчик поддерживают тесные и доверительные рабочие взаимоотношения.

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

– Гибкие сметы. В рамках работы по Agile можно создать два варианта гибкой сметы проекта: с гибкими сроками или с гибким функционалом. Первый позволяет сказать, к примеру, что работа над проектом или его частью с указанным списком опций займет от 12 до 16 недель. Однако, увеличение сроков приводит к росту затрат на работу команды, которая не может в это время приступить к работе над новыми проектами. Поэтому мы в Toptal предпочитаем использовать гибкий список опций. Мы гарантируем, что продукт будет иметь определенный минимум функционала, достаточный для достижения целей заказчика, и будет разработан строго в указанные сроки.

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

Наш подход к стоимости ПО и ценообразованию

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

Чтобы произвести оценку и зафиксировать стоимость проекта, мы предпринимаем следующие шаги:

1. Начальная общая оценка

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

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

Б. Набор эпиков(epic). Не углубляясь в детали, определите функционал, который необходим для продукта. Это будет структурированный «список покупок», который станет скелетом вашего продукта.

В. Анализ MoSCoW. Это техника, которая позволяет определить, что именно делает продут жизнеспособным, а что необязательно, но просто хочется в нем реализовать. Функции, которые вы определяете как Must – то, что будет привлекать и удерживать пользователей продукта. То, что вы обозначите как Should, будет радовать и удивлять покупателей, однако это можно будет добавить и позже. Функции Could не добавляют значительной бизнес-ценности и не ускоряют возврат инвестиций, поэтому будут в наименьшем приоритете. Наконец, Won’t могут стать важными в один прекрасный день, но на этой стадии развития проекта они не нужны. Таким образом, вы можете заодно определить и потенциал продукта.

2. Предложение

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

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

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

Предложение – это первый инструмент определения продолжительности и стоимости работы. Как только оно принято, мы можем двигаться дальше к фиксированной цене.

3. Планирование релизов

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

А. План продукта (product backlog). Это список пользовательских историй, основанный на уже существующем списке эпиков. На этом этапе работу ведет уже выделенная команда проекта, проектный менеджер и заказчик, и в результате они получают более значимый документ. Каждая история в новом списке представляет некоторую часть бизнес-ценности, которая заключается в продукте. На этом этапе мы по-прежнему не слишком углубляемся в детали, нам не нужны какие-либо качественные критерии, мы не хотим знать, будет ли кнопка синей или зеленой. Нам просто нужно знать: будет кнопка, которая запускает выполнение определенной задачи.

Б. Оценка. Когда у нас есть список пользовательских историй, команда проводит его оценку, используя технику «Покер-планирование» (Planning Poker). Это очень полезная техника, гарантированно дающая быстрый и надежный результат, основанный на экспертном мнении и оценке аналогов. Каждой истории в списке присваивается определенное число очков в зависимости от масштабов и сложности реализации. Доступны и другие техники оценки Agile, например «Идеальные дни» (Ideal Days).

В результате этой процедуры мы получим точную оценку масштабов проекта и установим зависимости между опциями. Масштаб – это сумма очков всех пунктов, например, 120.

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

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

Г. Планирование релиза. К этому моменту мы определили, каким должен стать наш продукт и каких он масштабов.

Теперь нам нужно понять, сколько времени займет создание проекта, готового к релизу. Заказчик и команда, включая дизайнеров, инженеров, тестеров, скрам-мастера и проектного менеджера, вместе определяют, чего можно достичь и как быстро может выполняться работа – в результате мы получаем план релиза.

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

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

Для начала, мы берем общее количество очков проекта, определенное на стадии журнала продукта, и делим его на скорость работы команды. Обычно скорость определяют как диапазон, но мы для простоты используем одно число. В работе мы используем двухнедельные итерации, поэтому наша скорость определяется как количество работы, которую мы можем выполнить существующей командой за две недели. Если наш проект имеет 120 очков, а мы ожидаем, что за две недели выполним 20 очков, то общее время разработки будет равняться 12 неделям, или шести итерациям. К этому мы добавляем нулевой спринт в две недели и еще один спринт на подготовку релиза. Итого, наш проект будет длиться 16 недель. Есть техники, которые позволяют создать достаточный буфер для рисков при планировании, и их мы обсудим ниже. Но если коротко, то буфер мы используем, чтобы управлять рисками неопределенности и прийти к соглашению о том, какое количество очков проекта мы обязаны предоставить. Итог может варьироваться от 90 до 150 очков, при этом 90 – это тот минимум, который необходим для жизнеспособности продукта.

Когда проект должен быть завершен к конкретной дате, например, за 10 недель, команда должна определить, какой объем журнала продукта можно реализовать за это время. Если мы ожидаем разработку 20 очков за этап, плюс нулевой спринт и релиз, то будем стремиться к реализации 60 очков к концу работы над проектом. И вновь мы должны учесть возможные риски, создав для них разумный буфер, что в итоге выльется в диапазон от 45 до 75 очков выполненной работы к моменту релиза. В 45 очков мы должны уложить минимальный функционал, необходимый для ценного и жизнеспособного продукта. Возможно, при таком сценарии вы сочтете разумным расширить команду, чтобы увеличить скорость разработки.

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

4. Фиксированная цена договора

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

Цена договора предоставляется вместе с графиком работ и согласованным графиком платежей.

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

Техники оценки

Для планирования и оценки по Agile есть множество техник, которые команда разработки может использовать для уверенности в объемах, сложности, продолжительности и стоимости проекта. Вот некоторые из них, которые используем мы для наших разработок программных продуктов.

Оцениваем масштаб

Масштаб проекта указывает на его область применения, сложность, габариты, риски и значимость. Если проводить аналогии, то нам нужно понять, что мы строим – Эйфелеву башню или Великую китайскую стену. Эйфелева башня – это высокая, тяжелая и сложная структура, созданная в тесной городской среде. А Великая китайская стена – сравнительно простая, но длинная и устойчивая структура, которая тянется на многие мили по холмистой местности. И хотя оба проекта можно назвать большими, их назначение, сложность, габариты и значимость различны.

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

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

Очки

Очки – это единицы измерения, демонстрирующие общий объем пользовательских историй. Этот размер при оценке включает все аспекты дизайна, разработки, тестирования, ревью кода, интеграции, и так далее.

Размер каждой истории соотносится с размером всех других. Например, опция А «стоит» 1 очко, опция Б – два, а опция В – три. Таким образом, опция В в три раза масштабнее, чем А, и в полтора раза, чем Б.

Из суммы очков всех историй в журнале продукта мы получаем общее число очков проекта.

Идеальные дни

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

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

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

Способы оценки

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

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

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

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

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

Скорость

Скорость – это оценка способности команды выполнять некоторый объем работы в течение заданной итерации (спринта).

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

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

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

Прогноз скорости включает оценку отдельных спринтов с помощью очков историй и разбивку их на отдельные задачи, необходимые для реализации истории. Мы оценим количество часов, которые нужны для завершения каждой задачи, включая дизайн, разработку, тестирование, и так далее, и предположим, какую работоспособность будет иметь команда на протяжение отдельного спринта. Работоспособность в 70% в случае свободной от других задач команды подойдет для начальных расчетов. Поэтому, в простых ситуациях, мы рассчитаем количество часов для команды следующим образом:

4 участника команды * 2 недели * 40 часов в неделю = 320 часов
Умножаем на 70% = 224 часа
Добавляем все задачи, нужные для реализации, пока не дойдем до 224 часов
Суммируем очки историй для выбранных задач и получаем скорость, например, 36
Применяем коэффициент в 20% в обе стороны и получаем оценочный диапазон скорости в 29-43 очка

Скорость обычно варьируется в течение первых 2-4 итераций, а затем стабилизируется в рамках небольшого диапазона очков. И если наш начальный диапазон был 29-43 очка, то к четвертой итерации он выйдет на плато, например, 34-38. Это позволит нам с большей точностью предсказать дату завершения проекта.

Планируем буферы для рисков и неопределенности

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

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

Обычно буфер бывает двух видов: функциональный и временной. И так как мы чаще всего обозначаем фиксированную стоимость и срок релиза, то предпочитаем использовать функциональный буфер.

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

Функциональные буферы

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

Таким образом, заказчик решает, какие приоритетные опции из журнала продукта наиболее важны – например, на общую сумму до 100 очков историй. Затем он может добавить дополнительный функционал еще на 30 очков. Таким образом, команда будет планировать разработку «весом» в 130 очков, с обязательным минимумом в 100, к установленной дате релиза и по фиксированной цене договора.

Некоторые мысли в завершение

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

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

Мы знаем, что объем работы меняются, возникают новые ранее неизвестные факторы или то, чего изначально хотел заказчик, изменилось, порой радикально. Адаптивный подход к ценообразованию, планированию и оценке позволяет клиентам получить именно такой продукт, который требует их рынок. А разработчику он позволяет быть гибким, креативным и одновременно эффективным. Ключ ко всему – максимальное взаимодействие между заказчиком и разработчиком при переговорах.

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

Заключение

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

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

Автор материала – Paul Barnes, глава проектов Toptal

Оригинал был опубликован в блоге Agile-Nightmare.

Разработка программного обеспечения на основе рисков

Posted on 04.04.201424.03.2021 by enterra

Перевод материалов Mike Griffiths

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

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

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

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

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

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

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

Гибкие методы и их механизмы проталкивания и частые изменения приоритетов могут заранее предпринимать действия по управлению рисками. Эти действия предпринимаются настолько заранее, насколько это возможно в жизненном цикле, минимизируя эффект домино. Так как тестирование проводится в каждой итерации, то к окончанию проекта шансы того, что какие-то элементы риска остались не протестированными, существенно снижаются. По существу, гибкие методы могут быть названы «управляемые рисками» (risk-driven), так как варианты с рисками проталкиваются вперед в списке задач.

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

Вообще говоря, мы стремимся преодолеть большинство так называемых «правильных, но не достаточных» аспектов управления рисками, которые слишком часто встречаются в проектах:

Плохо вовлеченный – сухой, скучный, академический, не приносящий достаточных изменений
Сделано единожды – обычно происходит в самом начале, когда мало что известно о проекте
Недостаточно пересмотрено – обычно «заброшено» в одну сторону и больше не пересматривалось
Не интегрировано в цикл проекта – скудные инструменты для интеграции задачи
Без вовлеченности, слабая видимость – немногие участники регулярно проверяют проект на риски

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

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

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

Итак, зачем вообще нужно заниматься организацией команды? Почему нельзя просто дать возможность делать то, что они делают – разрабатывают проект? В общем, есть ряд повторно возникающих проблем в том, как управление рисками покушается на проекты. Большинство софтверных проектов больше походят на задачи по решению проблем, чем на план по выполнению задач. Очень тяжело отделить экспериментирование и миграцию риска от чистого выполнения. Участники команды активно вовлечены в ежедневное управление рисками. Можно получить пользу от их вклада в процесс управления рисками и если они осознают риски проекта (будучи вовлеченными в их определение), то, то, какой подход к работе они используют, может лучше осведомлять о рисках и быть в итоге более успешным.

Преимущества такого сотрудничества нашли широкое признание. В исследовании, проведенным Стивеном Яффи (Steven Yaffee) из университета Мичигана, выделяются следующие преимущества:

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

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

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

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

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

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

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

Планирование управления рисками
Идентификация рисков
Выполнение качественного анализа рисков
Выполнение количественного анализа рисков
Планирование системы реагирования на риски
Контроль рисков

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

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

Кооперативные игры, которые охватывают эти шаги:

1) Планируйте поход (Планируйте управление рисками)
а. 4C – учитывайте стоимость, следствия, содержание и селекцию (Costs, Consequences, Context and Choices)
б. Покупаем ли мы кофе, диван, машину или квартиру? Насколько все должно быть строго и какой подход самый лучший?
в. Депозиты и банковские сборы – понимание функционала и рисков

2) Найдите друзей и врагов (идентификация рисков и возможностей)
а. Часы судного дня
б. День кармы
в. Другие формы идентификации рисков (профили рисков, листы рисков проекта, ретроспективы, анализ историй пользователей, вальсирование с медведями – топ 5-10 для софта)

3) Размести свою рекламу – (качественный анализ риска)
а. Разыскиваются инвесторы и помощь – классификация и визуализация возможностей и рисков.
б. Перетягивание каната – категоризация проекта

4) Сегодняшний прогноз – (количественный анализ риска)
а. Логова дракона – следующий лучшим способом потраченный доллар
б. Битвы роботов – симуляции

5) Инъекции в записи (backlog) – (планирование реагирования на риски)
а. Функция распределения – выберите путь реагирования на риски
б. Баланс доллара – сравнение риска/возможности метода освоенного объема к окупаемости инвестиций (Risk / Opportunity EVM to ROI)
в. Карточка отчета – соприкосновение покупатель/владелец продукта
г. Инокулятор – проведите инъекцию избегание риска/смягчение и истории возможностей в записи списка задач

5) Радар рисков – (мониторинг и контроль рисков)
а. Диаграмма сгорания рисков – отслеживание и мониторинг
б. Ретроспектива рисков – оценка эффективности плана по управлению рисками
в. Промывание и повторение – обновление артефактов по управлению рисками, процесс пересмотра

40 секретов заработка с внутриигровых покупок

Posted on 25.02.201424.03.2021 by enterra

Перевод статьи 40 Secrets to Making Money with In-app Purchases

Заработок с внутриигровых покупок(IAP) сводится к одному простому вопросу – почему мы покупаем? Я дам вам подсказку – главным образом для удовлетворения своих эмоциональных и психологических потребностей. Если вы поймете, как думают люди в вашем приложении, вы сможете заработать, и эта статья как раз об этом. В этой статье я расскажу 40 секретов, которые вы можете использовать в ваших приложениях прямо сейчас, чтобы зарабатывать больше с внутриигровых покупок. Вот некоторые из методов, о которых вы узнаете:

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

Готовы ли вы приступить к монетизации вашего приложения, как настоящий профи? Тогда давайте начнем!

1. Постепенно увеличивайте сложность игры
Давайте начнем с основ – это очень важно для облегчения пользователю работы с вашим приложением. Подумайте, будете ли вы тратить деньги в игре, с которой вы не знакомы? Скорее всего нет! Эта стратегия работает, если ваше приложение отвечает следующему требованию – пользователь должен в полной мере или с небольшими ограничениями оценить все возможности игры. Благодаря этому вы сможете достичь сразу двух вещей:

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

Люди, которые не хотят тратить деньги, будут тратить огромное количество времени, чтобы попробовать пройти её на одном лишь мастерстве. Поскольку эти пользователи проводят время в вашей игре, вы можете получить дополнительный доход с рекламы, интегрировав ваше приложение с такими сервисами, как Tapjoy, SponsorPay и др. Вы можете увидеть данную стратегию в игре Contract Killer Zombies 2 ниже:

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

2. Предлагайте бонусы

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

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

3. Покажите примеры вашего IAP контента

Вы бы стали тратить деньги на вещь, не зная на сколько полезна она вам окажется ? Дайте вашим пользователям попробовать некоторые из платных возможностей или даже все из вашего списка платного контента, но с расходуемым, ограниченным количеством. Например, если пользователи привыкнут к использованию расходуемых бонусов в самом начале игры, то вероятнее всего в будущем игроки будут склонны покупать больше, после того как они закончатся. Fruit Ninja использует эту стратегию ниже:

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

4. Заставьте игрока зарабатывать ваш IAP контент

Эта стратегия используется в феноменально успешной игре Candy Crush Saga. Данный метод зарабатывания на IAP основан на концепции того, что пользователь должен разблокировать последовательно все содержимое IAP, чтобы продолжать проходить игру:

Эта стратегия обеспечит сразу несколько преимуществ:

повышение внимания на платном контенте в вашем приложении;
увеличение ценности вашего содержимого в IAP;
уменьшение недовольства пользователей, которые не заинтересованы в вашем платном контенте.

5. Завлекайте игроков

Это совет от моего друга: Magnus Söderberg, CEO of Triolith Entertainment Triple Town является прекрасным примером той игры, которая завлекает пользователя своим увлекательным геймплеем и предлагает пользователям платную версию, чтобы улучшить их геймплэй.

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

6. Предложите платную функцию «Save me»

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

Бесконечные игры являются наиболее подходящим видом приложения для этого метода. Некоторые из известных приложений, в которых можно увидеть данную стратегию: Subway Surfers и Temple Run.

7. Любопытство – хороший рычаг

Этот совет исходит от Trey Smith, маркетингового гения. Вы можете посмотреть и проверить некоторые из его идей в Trey Smith – Live at App Empire 2012. Вы должны использовать любопытство вашего игрока и заставить его хотеть купить ваш платный контент. Extreme Road Trip 2 является отличным примером игры, в которой это реализовано, как нельзя лучше. Вы можете затереть или скрыть содержимое до тех пор, пока он не будет разблокирован – это повысит желание игрока увидеть, что скрыто за занавесом.

8. Используйте отвлекающий эффект

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

Какой бы вы выбрали и почему? Если вы выбрали большой пакет вы стали жертвой отвлекающего эффекта. 74% людей будут выбирать большой пакет. Обычно никто не выбирает средних, так что можем предположить, что 26% людей выберут небольшой размер. Бьюсь об заклад, вы выбрали большой размер, потому что он выглядит гораздо привлекательнее, чем средний и он только на 50 центов дороже. Отличная сделка! Теперь представьте, что вы столкнулись со следующим меню:

Какой размер пакета вы бы выбрали теперь? В этом случае 87% людей выбрали бы небольшой размер. Поскольку это огромная разница! В среднем в кинотеатре 100 человек, вот как продажи попкорна будут отличаться в двух сценариях: Сценарий А: Отвлекающий эффект – $7.00 * 74 человек + $3.00 * 26 человек = $596.00 Сценарий В: Без отвлекающего эффекта – $7.00 * 13 человек + $3.00 * 87 человек = $352.00 Просто добавив отвлекающий пакет среднего размера кинотеатр заработал дополнительные $244. Отлично! Отвлекающий эффект, как правило, работает только в том случае если пунктов всего три. Пункты должны выглядеть привлекательно и казаться пользователю потрясающей покупкой.

9. Погружайте пользователя в атмосферу приложения

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

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

10. Предоставьте возможность «Удалить рекламу»

Хотя кажется, что каждый использует данную стратегию, не стоит недооценивать её. Это очень просто, поскольку многие пользователи хотят в полной мере насладиться вашим приложением и не хотят отвлекаться на рекламу. В качестве эксперимента зайдите в App Store и просмотрите отзывы ТОП приложений, которые не предлагают эту функцию. Вы не представляете сколько людей попросит эту возможность!

11. Если вы сомневаетесь использовать ли в игре легко расходуемые материалы

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

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

12. Дайте вашим игрокам больше статистики – они это любят

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

13. Цените время игроков

Большинство людей ценят время, как драгоценный дар, и геймеры не являются исключением. Люди, как правило, нетерпеливы и хотят удовлетворить свои потребности, как можно скорее. Большая часть людей тратит время на мобильные игры в ситуациях, когда ожидает чего-либо, например, находится в очередях и поэтому в любой момент может прекратить игру. Геймеры хотят выжать максимум игрового времени из каждой сессии. Вы можете заработать на этом, продавая им время. Если вы просматриваете App Store вы увидите множество игр, которые реализуют эту стратегию достаточно эффективным способом. Clash of Clans является достаточно успешной игрой, которая в основном реализует данную стратегию:

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

14. Группируйте содержимое IAP

Если у вас есть набор игровых элементов, которые могут быть связаны и проданы вместе, как группа, сделайте это! Люди любят покупать вещи в большом количестве. Draw Something это довольно неплохое приложение, которое предлагает цвета и группы цветов для их приложения:

15. Формируйте положительные чувства к вашей игре

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

16. Предлагайте реликвии

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

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

17. Добавьте в игру юмор

Кто не хотел бы купить летающий холодильник?

Этот пример из очень успешной игры Mega Jump. То, что начиналось, в шутку в студии превратилось в играбельной красный холодильник, тысячи игроков потратили свои с трудом заработанные деньги на него.

18. Используйте ограниченные временем предложения

Предлагайте вашим пользователям товары в вашем магазине с ограничением времени сделки. Предлагайте товар со скидкой 50% тем самым вы будите повышать интерес пользователя приобретать у вас контент. Следующий скриншот из игры Contract Killer Zombies отлично это демонстрирует:

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

19. Предлагайте правильный инструмент в нужное время

Специальные предложения, сделанные для нужных игроков в нужное время – это мощный метод продаж.

Например, специальное предложение в игре Contract Killer Zombies 2 нанять наемника, когда вы столкнулись с полной комнатой зомби. В этот момент игроки не знают своих шансов на победу и могут прибегнуть к помощи наемника.

20. Создавайте красочные магазины

Noble Nutlings имеет один из лучших магазинов:

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

21. Используйте психологию цвета

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

Вы можете использовать эти данные в качестве отправной точки. Отличной идеей является техника, известная как A/B тестирование, позволяющая понять какой цвет или сочетание цветов приведет к повышению коэффициента конверсии. Вы не должны перестраивать весь интерфейс, иногда небольшие изменения цвета кнопки «Купить» достаточно чтобы был получен отличный результат. clutch.io это отличный онлайн инструмент, который позволяет использовать A/B тестирование в вашем приложении. Этот инструмент недавно был приобретен компанией Twitter, которая в свою очередь предоставляет все необходимые инструменты для того, чтобы настроить все на своем сервере для поддержки A/B тестов в вашем приложении. Вот простой пример того, как цвет обычно влияет на поведение покупателей:

Желтый – часто используется, чтобы привлечь внимание покупателей.
Красный показывает актуальность, попробуйте применить его к ограниченному по времени предложению.
Синий создает ощущение доверия и безопасности.
Зеленый является самым простым цветом для наших глаз и обычно используется, чтобы помочь людям расслабиться.
Оранжевый создает призыв к действию.
Черный используется для рынка роскоши. Если вы используете реликвии в вашем IAP сделайте его черного и золотых цветов, чтобы придать ощущение, что этот товар является бесценным.

22. Ваш магазин должно быть легко найти

Сделайте несколько способов попасть в ваш магазин. Чем легче найти магазин, тем больше вероятность, что люди приобретут там что-то. Посмотрите на скриншот игры Draw Something, где видно, что в игре используется сразу несколько способов попасть в магазин:

23. Предлагайте игрокам разовые сделки

Eternity Warriors 2 показывает отличный вариант реализации разовой сделки:

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

24. Привлекайте внимание игроков

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

25. Предложите мульти-покупки

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

26. Создайте свою собственную экономику

Постройте экономику из доступной и премиум валюты. Доступная валюта – это та валюта, которую можно заработать в процессе игры. Премиум валюта доступна только тем игрокам, которые используют реальные деньги. Вам нужно заставить игроков, которые зарабатывают доступную валюту, играя в игру, играть как можно больше, зарабатывая тем самым вам на рекламе или приобрести премиум валюту и обменять её на доступную валюту. На этом скриншоте вы можете увидеть пример премиум валюты на продажу:

Хорошим подходом к управлению виртуальной экономикой считается возможность удаленного редактирования параметров. Это упрощает обслуживание вашего IAP.

27. Используйте Applicasa для управления стратегией вашего IAP

Applicasa.com является мобильной платформой, которая поможет вам настроить и оптимизировать IAP. Их платформа все еще находится в бета-версии, но уже сейчас кажется многообещающей и качественной. Есть несколько способов, которыми Applicasa помогает вам управлять вашими предложениями в IAP:

Помогает понять насколько высоки или низкие цены.
Следить за валютой доступной в вашей виртуальной экономике и сколько из этого используется каждый день.
Получайте подтверждение каждой сделки в IAP.
Настройте динамический виртуальный магазин, где вы можете уточнять цены, детали и загружать новые элементы.
Отслеживайте, какой элемент наиболее привлекательный и сколько раз он был приобретен.
Выполнять A/B тестирование для любого вашего содержимого.
Автоматическое разделение пользователей по их поведению на группы. Это позволит рекламировать содержимое на различные категории людей.

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

Applicasa также позволяет создавать акции и специальные предложения или объявления на основе поведения пользователей. Два следующих графика показывают, как возраст и пол влияет на покупательские привычки пользователей:

28. Предложите платный контент в качестве награды

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

Когда вы отдаете виртуальную валюту в качестве подарка вы тем самым повышаете шанс того что игрок вернется в ваше приложение повторно. Одним из хороших примеров такой награды является игра The Simpsons™: Tapped Out:

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

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

29. Управляйте сложностью игры

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

30. Адаптируйте игру для различных аудиторий и предпочтений

Дайте пользователям возможность изменить их внешний вид в игре, покупать одежду или выбирать аватар. Это позволит игрокам быть индивидуальными. В игре Temple Run это сделано превосходно:

31. Предлагайте помощь в сложных моментах

Предлагайте игрокам, зашедшим в ваше приложение впервые, пройти обучение. Contract Killer Zombies 2 используют эту технику. Если у вас закончились патроны или вам необходимо более сильное оружие это игра предложит вам это.

32. Сделайте список рекомендуемых покупок

Большинство игроков проходя тот или иной уровень думают «Как бы было круто, если бы я купил ту пушку». Чтобы подобного не происходило, предоставьте игрокам список рекомендуемых товаров для покупки перед прохождением того или иного уровня. Игра Eternity Warriors 2 предлагает игрокам рекомендуемые покупки перед каждым уровнем:

33. Продавайте реальные товары

Такие известные приложения, как Fruit Ninja и Angry Birds могут продавать собственные товары через приложение. Большинство разработчиков не достигают такого уровня, но если вы набрали огромную базу лояльных игроков, то вполне можете предложить им реальные товары в виде футболок и кружек с символикой вашего приложения.

Temple Run предлагает купить обои в своем приложении, кто сказал что и вы не можете сделать подобное:

34. Следите за самыми кассовыми приложениями

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

35. Предлагайте платный контент в обмен на услуги

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

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

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

36. Создавайте много платного контента

В среднем менее 2% пользователей будут приобретать ваш платный контент. По исследованиям W3i контент по цене от $0,99 до $1,99 генерирует только 6% от общего дохода вашей игры. Тем не менее содержимое по цене от $9,99 до $19,99 генерирует 47% от общего дохода. Вы можете попытаться изменить свой контент, чтобы привлечь случайных пользователей, чтобы попытаться увеличить количество покупок в приложении. Статистика говорит о том, что готовые на трату денег пользователи пойдут и на крупные покупки. В долгосрочной перспективе вы будете делать большую часть денег на дорогостоящих товарах, даже если продавать вы их будите меньше.

37. Просьбу о выполнении действий пишите вежливо

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

38. Анализируйте и оптимизируйте вашу стратегию монетизации

Даже если ваш бизнес успешен, всегда есть место для усовершенствований. Задайте себе три вопроса и попытайтесь найти на них ответы:

Как я могу повысить эффективность моей стратегии IAP?
Как я могу сделать мой контент более привлекательным?
Как я могу упростить процедуру покупки моего контента?

Чтобы помочь ответить на эти вопросы, сравним две игры из той же франшизы: Contract Killer Zombies и Contract Killer Zombies 2:

Если у вас будет недостаточно золота, то вы будете перенаправлены на покупку золота, что значительно снижало процент конверсий. А теперь давайте взглянем, как в Contract Killer Zombies 2 это было исправлено, там сделали небольшой твик для процесса покупки:

Вы заметили изменение? Теперь приобрести оружие можно в один шаг.

39. Используйте маркетинговые слова

Язык является невероятно мощным средством, когда дело доходит до продажи. Вот некоторые из слов, которые удивительно влияют на поведение потребителей: Sale – 52% потребителей войдут в магазин у которого на вывеске будет слово «Sale» Guaranteed – 60% зайдут в магазин где будет написано «Guaranteed». «Free» – не все ли любят бесплатное? Чтобы проиллюстрировать возможности слова «Free» давайте рассмотрим следующий сценарий. Клиенты имеют возможность выбора между двумя видами конфет. Одним из них является известный бренд шоколада с ценою 0,19 $ – около 50% от обычной цены. Другой шоколад – идентичный по качеству и вкусу, хотя и не известный бренд – по цене $ 0,01.

В этом случае около 75% выберут шоколад по цене $0.19, который известен, в то время, как только около 25% выберут шоколад по цене $ 0.01. Теперь снижаем цену каждого вида конфет на один цент, в результате образуется следующая схема ценообразования:

Внезапно ситуация обратная: люди забудут о шоколаде, который продается по $0.18 и 71% выберут бесплатный шоколад. Только 29% людей выберут шоколад за деньги. Мораль этой истории? Бесплатный контент может быть мощным инструментом для изменения поведения покупателей.

40. Не раздражайте пользователя

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

Introduction to In-App Purchases in iOS 6 Tutorial – великолепный учебник, где вы найдете информацию о том как реализовать ваш IAP

In-App Purchases in iOS 6 Tutorial: Consumables and Receipt Validation – отличный учебник о безопасных покупках в приложении

http://blog.flurry.com/?Tag=In-App-Purchase – выборка статей из блога Flurry и других ресурсов по статистике IAP

Часть 1 и Часть 2 статья из PlayHaven об 11 приемах, которые позволяют максимизировать ценность ваших пользователей.