Live Mobile! European Mobile Congress – ключевое событие российской мобильной индустрии. Мероприятие пройдет в Москве 12-13 ноября в центре Digital October. Организатор и ключевой эксперт — компания Game Insight. Live Mobile предлагает уникальный состав спикеров и мега-актуальную программу. В этом году конференцию посетят Google, Facebook, Microsoft, Warner Bros. Entertainment, Яндекс, Flurry, App Annie, Alawar, Social Quantum, Nevosoft, Chartboost, Afisha, J’son & Partners  и многие другие. Присоединяйтесь и вы узнаете о перспективах дальнейшего развития рынка мобильных приложений и игр, особенностях мобильного маркетинга, новейших инструментах аналитики, возрастающей роли мобильных сервисов, инвестициях в мобильной индустрии. В 2012 году более 400 участников приняли участие в Live Mobile и смогли не только погрузиться в нюансы мобильного бизнеса, но и установить полезные деловые контакты среди разработчиков, инвесторов и представителей мобильного рынка.

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

Итак, поехали!

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

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

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

Что надо делать с рисками

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

Как их выявлять

Собраться всей командой на планирование по рискам. Это может быть даже мозговой штурм; задача — понять все узкие места проекта. Можно поделить проект на части: жанр, код, арт, сообщество, функционал, юзабилити, сюжет, геймплей (если это игра) и прочее. Можно каждую эту часть поделить на подчасти, например код на сервер, клиент, верстку. Арт на стиль, сеттинг (если это игра), моделинг, текстурирование (если это 3D), восприятие целевой аудиторией. Например, задача — сделать многопользовательскую космическую игру с видом верху, стрельбой в реальном времени и реалистичной физикой. Следует задать например такие вопросы: какие тут есть узкие места? Сколько будет одновременно игроков в одной локации, десять или тысяча (кстати, этот вопрос сразу же и ответ на то, зачем документировать архитектуру и дизайн до начала разработки — чтобы на этапе оценки рисков точно знать, что нужно получить в итоге)? Если будет 1000 человек в нужной локации, то как они поместятся на экране? Сколько будет передаваться информации и справятся ли современные интернет-каналы с нагрузкой? Справится ли сервер с нагрузкой? Справится ли физика на сервере, если все будут одновременно стрелять? Вопросов будет много, но нужно отличать те, которые серьезные и могут отразиться на успешности/провальности разработки от минорных. Все важные, ключевые вопросы должны составить небольшой список (большим он не будет, потому что серьезных рисков, которые могут завалить весь проект, на самом деле не так много).

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

Грудью на амбразуру

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

Прототип — начинающий убийца

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

Микропрототипирование

Давайте вернемся к списку рисков. Каждый риск — это вопрос, на который прототип должен дать ответ. Для того, чтобы получить нужные ответы, не надо тратить по полгода на что-то сложное; достаточно сделать прототип, решающий только какую-то одну задачу, дающий только один ответ. Например, на вопрос «что будет, если в локации будет 1000 игроков?» можно сделать локацию, наводненную тысячей кубиков, равных по размеру кораблям и просто летают по каким-то примитивным траекториям. Сразу же станет видно, будут ли они толкаться, помещаются ли они в сцену и если нет, то сколько влезает; как можно максимально отодвигать камеру, насколько можно ее приближать и так далее. Если вы видите, что когда в кадре пятьдесят кораблей, и они начинают толкаться, между ними не пролететь, то можно вовремя скорректировать геймплей. После этого прототип можно выбросить, или же частично использовать его для проверки, например, возможностей движка, заменив кубики на рандомные модельки, количество полигонов и текстуры которых примерно равны будущим кораблям.

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

Итеративное прототипирование

Возвращаясь к спирали Барри Бима, аджайлу и итерациям, а также к тому, зачем и почему они нужны. Каждая итерация — это прототип; каждое ее завершение — это ретроспектива, на которой анализируются результаты, полученные при помощи прототипа. Можно ли помещать 1к игроков в одну локацию, если они все будут стрелять? Если нет, то почему и что делать? Может быть, сделать зоны видимости определенного радиуса, и тогда нагрузка на трафик снизится в Х раз? Или может быть замедлить стрельбу, сделать ее более редкой но более сильной? Может быть сделать 90% пуль — лучами, которые в Y раз менее нагрузочны, чем летящие по физике пули? Тут может быть очень много решений но для того, чтобы их принять, нужно знать проблему. И лучше знать ее заранее. Ведь если вы будете писать игру год, и только по прошествии которого вдруг узнаете, что физика и трафик не справляются, вам придется переделывать фундаментальный геймплей. А на нем, вполне возможно, построено вообще все остальное: модели и текстуры, квесты, локации и все это, вероятно, тоже придется переделывать просто потому, что изначально не было сделано нужное исследование.

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

Прототип на выброс

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

Это не значит, что надо выбрасывать все, что вы сделали. Что-то из прототипов наверняка будет полезно в работе над альфой: небольшие кусочки чистого кода, алгоритмы, функционал (геймплеи). Реже и почти никогда — графика, модели, арт, звуки.

Кстати есть одно замечание, сделанное, по-моему, Фредом Бруксом: «Чем менее опытна команда, тем сложнее ей выбросить прототип потому, что им кажется, что они провалили разработку» .

Документирование

Как справедливо было замечено к предыдущей статье, очень важно фиксировать в документации изменения в разработке и архитектуре. Я ни в коем случае не соглашусь, что до начала прототипирования не нужна документация и она возникнет по ходу создания прототипов. Документация нужна, потому что она формирует цели и ставит границы, в пределах которых вы будете двигаться. Это — рельсы для поезда разработки, наличие которых нужно изначально. И это не значит, что на этих рельсах не может возникнуть ответвлений, стрелок и прочих изменений маршрута: они должны возникнуть. Но отправная точка в виде базовой архитектуры должна быть, и именно ее будут проверять (и корректировать) микропрототипы.

Задача прототипирования — выявление проблем и нахождение методов их решение. Как исправлять технические и функциональные проблемы, думаю, понятно. Но есть еще одна проблема, о которой не пишут в книгах и особо не говорят. Между тем, проблема очень частая и простая: квалификация. «Кадры решают все» (с), и это действительно так. Вполне вероятно, что прототипирование выявит еще одну проблему — что ваша команда, или ее часть, не справляется с поставленными задачами. Может не получаться прототип, может получаться не то, прототип может не давать ответов; на раннем этапе может выявиться, что кто-то не может работать в команде, не выдерживает рабочий график команды, проваливает сроки или вообще занимается чем-то своим в рабочее время. В таком случае заменить такого человека (или людей), на раннем этапе, пока не прошло полгода-год, самое время. Если протянуть, не решаться на расставание, то потом можно вообще не найти человека, который сможет поддерживать проект или захочет разбираться в говнокоде.

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

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

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

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

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

Вот и все, удачного прототипирования!

Источник: http://www.gamedis.ru/

В данной статье Михаил Токовинин, CEO amoCRM, делится своим опытом выхода на рынок, рассказывает о поиске инвестора и сделанных выводах.

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

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

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

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

Когда мы начинали, всем казалось, что Saas нужно продавать как обычный софт. Мы достаточно плотно общались с Runa Capital. Они нам «продавали» идею, что нужно начать сотрудничать и тогда они нам помогут организовать продажи через своих партнеров-хостеров. Инвестиции мы так и не получили, а позже выяснилось, что продавать наш сервис можно только напрямую. Если бы мы тогда послушались их советов, то получили бы очень плохие результаты. Безусловно, в Runa работают опытные люди, предприниматели, но в нашей теме они не разбираются. Никаких «умных» денег не существует, каждый проект должен набить шишки сам.

Что обидно, все инвесторы обожают рассуждать о ценности команды, об опыте основателей, но на деле они любят людей им понятных. Которые умеют красиво упаковывать свой проект, представить его. В итоге не самые профессиональные люди получают кучу денег. Однако лишние деньги позволяют совершать лишние ошибки. Мы развивались на свои, так что не могли позволить себе убытки. В итоге сейчас бизнес стабильно растет: у нас уже более 1,5 тыс. платных подписчиков, два офиса — в России и США.

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

Источник: http://www.kommersant.ru/

«Этот год стал первым, когда я понял, что моя продуктивность снизилась из-за потребления медиа, — признавался Дэвид Карр, медиаобозреватель The New York Times. — Я смотрю в будущее и думаю: от чего мне отказаться? Перестать следить за NFL? Ходить на концерты? Или надо просто вернуться назад и отказаться от привычек цифрового мира, которые съедают мою жизнь?».

Вопросы, заданные Карром в 2011 году, актуальны и сами собой не растворятся, если только мир не настигнет апокалипсис. Единственный шанс — научиться справляться с ураганными инфопотоками. Если сейчас пользователь смотрит на телефон в среднем 150 раз в день (исследование Kleiner Perkins Caufield & Byers), то что будет потом (учитывая, что новости, подобно сериалам, врываются в сознание, чтобы держать внимание до развязки событий)?

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

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

У меня есть личный to do-список на собственном закрытом вики-сайте, для которого использую движок PBworks. Вообще, иметь собственный вики-сайт —очень удобно. В отличие от Google-документов там меньше полей, больше текста помещается на первый экран и можно быстрее и удобнее ставить ссылки между документами.

Использую почту на Gmail, я читаю все письма. Отвечаю сразу или ставлю звёздочку. Звёздочек обычно от 3 до 10. Примерно раз в неделю отвечаю на сложные письма, доводя число «со звёздочками» до 0.

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

Любимый новостной сайт — новости YCombinator. Это лучший новостной поток для технологических предпринимателей. Смотрю образовательное видео на charlierose.com, ecorner.stanford.edu и видео из серии pandomonthly.

До 60% всего времени, которое можно назвать рабочим (то есть всё время, пока не сплю), уходит на обработку разного вида информации. Продюсирование — это, по сути, управление проектами, поэтому информация — большая часть того, чем необходимо оперировать. Запросы заказчиков, отчёты исполнителей и подчинённых, графики эфиров, таблица с дедлайнами и пр.

В плане создания to do-списков я так и не смог привыкнуть к какому-либо софту или веб-приложениям, поэтому дела выписываю в список в открытом листе notepad и по мере выполнения просто удаляю строки.

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

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

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

Так что можно сказать, весь мой день — систематизирование знакомых (управление текущими проектами) и перекапывание огромной горы новых данных.

Для новой информации есть проверенное временем и опытом соотношение: 98-99% данных — бесполезный мусор.

Хоть я и подписан на ряд рассылок профресурсов про кино, раньше их было больше. Постепенно начал от них отказываться, так как слишком много «воды», а поступление в почтовый ящик отвлекает. Вернулся в режим ручного управления: чтение всякого — от Variety до обзорных статей на разных ресурсах без подписки на них.

В браузере встроен Adblock Plus, который помогает убирать визуальный мусор с сайтов. Никаких других блокировок, на мой взгляд, не нужно.

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

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

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

Инструментов много: RSS, выделенные каналы для тематических групп и страниц в Facebook, сервисы для курирования контента. Честно говоря, мне это мало помогает — как будто стоишь с ведёрком под водопадом. Поэтому иногда приходится исполнять что-то вроде цифровой медитации — глубоко вздохнуть и возрадоваться тому, что есть, остановив поиск и метания мысли.

Блокировщики — это слишком сложно. Находить их, устанавливать, не забывать специально включить. Если нужно прицельно поработать не отвлекаясь, достаточно выключить Wi-Fi. Это тоже требует определённой привычки, но она вырабатывается довольно быстро. Если дедлайн через неделю — ничего не заставит решить задачу раньше, а если дел становится бесконечно много, то и концентрация появляется сама собой. Не можете себя заставить не отвлекаться — просто возьмите больше работы.

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

Как я себя ограничиваю? Обычно это выглядит так: у меня открыто 87 вкладок в одном браузере, открываю другой для быстрых дел и коротких запросов, но очень быстро, и там вкладок становится предельное количество. Некоторое время браузер мучается, тормозит, а потом вылетает. Вкладки оказываются потеряны, что примерно равносильно потере музыки во времена MP3 и Winamp. Несколько дней я пытаюсь восстановить что-то из истории и оплакиваю то, что потерялось безвозвратно. Потом забываю, но история повторяется.

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

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

Во-первых, ограничивая свободу передвижения в интернете, нельзя добиться роста собственной сознательности при потреблении информации. Забанив в своём браузере Facebook, ты всё равно будешь ходить на «Ленту.ру» почитать про очередные часы патриарха — и возможно, даже чаще, чем ты это делал раньше.

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

Из инструментов контроля за личным медиапотреблением пользуюсь:

Инструменты отслеживания новостей не только использую, но и делаю своими руками. «Метабар» cоздаёт браузерные приложения — в основном такие, которые позволяют узнавать о новостях любимого издания сразу, как только появилась новость. Это наш способ отвлечь обычного пользователя от постоянного чтения Facebook.

В почте стараюсь отвечать только на важные письма. В этом очень помогает фича интерфейса Gmail Priority Inbox, где можно отделить «Важные непрочитанные» от просто «Непрочитанных».

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

Едва ли не треть всего рабочего дня, то есть от 4 до 5 часов в день, я нахожусь в информационном потоке. Нужно, правда, сделать оговорку, что я фанат информации: мне нравится и выгодно быть в контексте фидов, которые так или иначе относятся к работе. В моём списке около 700 ежедневных информационных источников, в том числе Twitter, Facebook и, конечно же, Linkedin.

Количество писем в почте считаю отдельно, но получается от 100 до 150 ответов в день. Для внутренней работы в компании используем Basecamp и метод Getting Real (мы правда в это верим, и у нас получается).

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

Как при всём вышеперечисленном не запутаться? Стараюсь не превышать 30% порога и уделять остальные 30% и 40% времени работе с людьми и развитию продукта.

Из инструментов использую разве что списки в Twitter и приложения ключевых СМИ на iPhone, рекомендательные сервисы пока не прижились.

В моем Gmail простая система ярлыков: «нужно ответить», «курс в ГУ-ВШЭ» и по всем клиентам. Раз в неделю довожу число непрочитанных писем, тех, что с ярлыком «нужно ответить», до нуля. Как успеваю, науке неизвестно. Новая фильтрация заметных преимуществ не принесла, разве что хорошо убирает коммерческие рассылки.

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

Источник: http://www.hopesandfears.com/
Иллюстрации: Наталья Осипова

Наверно, все стартаперы хотят, чтобы рассказ об их продукте опубликовало как можно больше (желательно, авторитетных) СМИ. Это даст и дополнительных пользователей, и авторитет среди инвесторов, и массу других бонусов. Вот только достучаться до журналистов могут далеко не все. Почему?

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

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

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

2. Массовые рассылки. Если кто-то рассылает одно и то же письмо одновременно сотням изданий, вряд ли на него обратят внимание. Никто, даже блогеры, не любят, когда пиарщик пишет, что ему очень нравится сайт или блог, а получатель видит, что он один из сотен. И даже когда кто-то пользуется опцией «скрытая копия», отличить рассылку от индивидуального письма все равно очень просто. Лесть не работает, особенно в случае рассылки.

3. Проблемы с языком. Позаботьтесь о том, чтобы вас поняли. В русскоязычных изданиях, в отличие от англоязычных, почти не сталкиваются с проблемой релизов и предложений на вьетнамском (или любом другом), — зато сталкиваются, и еще как, с недостаточным знанием родного. Журналисты, конечно, не всегда граммар-наци, но они терпеть не могут письма, составленные на несуществующем языке. Пользуйтесь словарями или хотя бы автопроверкой в Microsoft Word. Ну, на крайний случай хотя бы перед тем, как нажать на кнопку «отправить», попросите старшего товарища перечитать письмо. Он наверняка хорошо учился в школе.

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

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

И если стартапер пишет что-то в духе: «Три месяца назад про нас рассказывал TechCrunch», это вряд ли поможет делу. Дайте новому изданию что-то новое.

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

Источник: http://www.siliconrus.com/

Опрос, проведённый сотрудниками ITG Investment Research среди взрослых жителей США, показал, что в течение ближайшего года операционные системы iOS и Windows Phone имеют все шансы укрепить позиции на американском рынке смартфонов.

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

Сообщается, что 35% участников опроса выбрали iPhone. При этом в настоящее время iOS занимает второе место по распространённости на рынке смартфонов США с долей в 27%.

Аппарат на базе Android готовы приобрести 32% респондентов. В настоящее время эта операционная система лидирует на американском рынке с 34%.

Ещё 6% участников исследования отдали бы предпочтение смартфону под управлением Windows Phone. Сейчас на долю данной мобильной платформы приходится только 4% американского рынка.

Аппараты на базе BlackBerry считают привлекательными только 1% респондентов. Сейчас эта ОС занимает 2% рынка.

Среди нынешних пользователей Windows Phone и BlackBerry перейти на другую платформу намерены соответственно 59 и 80% опрошенных. В лагерях iOS и Android этот показатель гораздо ниже — 14 и 23%.

Источник: http://www.3dnews.ru/

Компания «Яндекс» создала бесплатный аналитический сервис для разработчиков мобильных приложений. Новая служба работает с программами на платформе iOS, Android и Windows Phone и доступна на русском и английском языках.

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

Например, разработчики смогут узнать, сколько пользователей и с каких именно устройств работали с определенным приложением в Нижнем Новгороде на прошлой неделе, уточнили в «Яндексе».

Источник: http://www.gazeta.ru/

Конференция для специалистов по тестированию приложений на мобильных устройствах Mobile ConfeT&QA будет проходить 9-10-11 декабря 2013 года с 17 до 19 часов по московскому времени (UTC+4).

Одним из самых распространенных современных трендов в разработке программного обеспечения является рынок программ для портативных устройств. Каждый день появляются тысячи новых мобильных приложений, сотни тысяч загружаются и покупаются ежедневно на Apple Market и Google Play. Всему этому способствует ошеломляющая статистика продаж смартфонов и планшетов, одних только Android-устройств активируется более 500 000 ежедневно!

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

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

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

Поэтому приходите на Mobile Confet&QA, задавайте вопросы и получайте ответы!

Открыта регистрация участников по ранним ценам!