Под катом перевод огромной статьи, написанной Майклом Чёрчем и посвящённой стартапам. Статья вызвала необыкновенное бурление… мнений, скажем так, на разных сайтах и агрегаторах, поэтому я решил её перевести на русский и посмотреть на реакцию. Текст ОЧЕНЬ длинный, но также и очень интересный. И несколько пояснений перед чтением: в статье речь идёт об инженере в стартапе, именно с этой позиции всё рассматривать; некоторые финансово-экономические термины, возможно, не очень адекватно удались и я буду рад любым конструктивным поправкам.

То, о чём я хочу рассказать, справедливо для июля 2012 г. 15 лет назад необязательно было так же, и не факт, что будет справедливо через год. Но в данный момент это абсолютно верно для большинства людей в достаточной степени, так что я считаю обязанным высказаться. Нынешний мир ИК-стартапов (ИК=инвестиционный капитал / venture capital) — я его нежно называю ИК-стан — является, мягко говоря, тотально напрасной тратой времени для большинства вовлечённых людей.

Привет.

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

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

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

Это первая статья из серии материалов, которые я планирую посвятить продвижению мобильных приложений с помощью ASO и локализации. Поэтому, в первую очередь, хотелось бы объяснить, что же такое это ASO, из каких компонентов оно состоит, с чем оно неотъемлемо связано и почему так необходимо. В дальнейшем, я, на основе своего опыта (и, соответственно, опыта компании, в которой я работаю), с удовольствием расскажу, как пользоваться этими инструментами наиболее эффективно, каких результатов ждать в долгосрочной и краткосрочной перспективе, приведу алгоритм асо действий и поделюсь полезными ресурсами, которые помогают сократить время на ASO деятельность.
Но начнем с основ. Каждый разработчик мобильных приложений хочет, чтобы его продукт был успешным. Успешность можно измерять по-разному (количество скачиваний и активных пользователей, оценки и отзывы пользователей, и т.д.), но мы же с вами понимаем, что одним из важнейших показателей успешности является окупаемость, а затем и прибыльность всего дела. Итак, что говорят нам цифры: в 2012 году мировой рынок мобильных приложений составил приблизительно 7,83 млрд долл. Российский же сегмент рынка мобильных приложений по разным оценкам в 2012 году достиг 120-160 млн долларов, и продолжил рост в первом квартале 2013 на 11%. Есть в этих замечательных цифрах как хорошая новость, так и плохая. Хорошо, что русскоязычный рынок растет. Это значит, что нам с вами есть, где развернуться, есть активная аудитория, готовая скачивать приложения и пользоваться ими. Благодаря этой аудитории мы можем совершенствовать свои продукты и делать их максимально прекрасными. А вторая новость заключается в том, что нам с вами, чтобы быть действительно успешными и много зарабатывать, нужно выходить из зоны русскоязычного комфорта и осваивать интернациональные рынки. И это совсем не плохо. Это интересно, это, как говорят наши англоязычные друзья, challenging.

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике ardin, переводит восемнадцатое занятие, редактор astropilot.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Это перевод статьи Being a Remote Worker Sucks — Long Live the Remote Worker Скотта Хенселмана за 27 февраля.

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

Работать удалённо – прекрасно, отстой.

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

Вторая цель — рассказать о том, как защитить ящик. Мы пройдемся по базовым моментам и напомним те пункты в «плане безопасности», о которых редко задумываются. Может быть, сведения из этой статьи пригодятся вам, а возможно — вашему беспечному другу, родителям или коллеге. Возможно, нам даже удастся сделать так, чтобы звонков «У меня, кажется, ящик взломали, ты же программист, сделай что-нибудь!!!11» стало чуть меньше.

Исторически в Почте Mail.Ru использовался механизм от «большого» Поиска (go.mail.ru); однако для задач поиска по почтовым ящикам такой вариант не был оптимальным ввиду большого потребления ресурсов и относительной сложности в обслуживании. Поиском по почте пользуются около 3% владельцев почтовых ящиков; однако, хотя эта цифра кажется относительно небольшой, ящики этих людей обычно достаточно объемны, и поиск им действительно необходим. Поэтому мы приняли решение написать специализированный поисковый демон, который будет заниматься именно поиском по почте. Основными требованиями к нему стали ограничения по потребляемым ресурсам (размер индекса — не более 3% от размера почтового ящика, среднее потребление оперативной памяти — не более 100 Мб, средняя утилизация CPU — не более 3%) и скорости исполнения запросов (среднее время — не более 200 мс). О том, как он был организован, я расскажу ниже.

Молодые стартаперы часто мечтают о миллионе долларов кешем. Их часто даже не особо интересует то, что они делают (не важна конкретная идея), а интересует “срубить бабла по-быстрому и отвалить” (hit and run). Быстро сделать прототип, получить финансирование, что-то доделать на угасающем интересе, продать свою долю. Если быстро не получается (а дело-то сердцу не мило) стартап загибается, и молодой стартапер, может быть и не с первого раза, но превращается в старого.

Вот и мы в Alconost часто задумываемся: “Может, ну его, эти мутные стартапы и журавлей в небе? Может быть, реальный бизнес приносит больше счастья?”

Как раз об этом и рассуждает в своей статье Melanie Io.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

Мы живем в удивительное время, то что раньше казалось очень сложным внезапно становится доступным и простым. Задачи для решения которых надо было создавать научные институты и крупные организации, сейчас решаются саморганизованными группами энтузиастов. Энтузиасты создают карты и энциклопедии снимают фильмы и разрабатывают software. Я хочу рассказать о той области, в которую этот свежий ветер перемен еще не подул в полную силу – это погода. И нашим проектом – OpenWeatherMap — мы хотим изменить эту ситуацию!

После поста Введение в разработку WinRT-приложений на HTML/JavaScript. От шаблона к приложению с данными вы уже знаете как разрабатывать RSS читалку под Windows 8 с использованием HTML и JavaScript. Пришло время попробовать сделать примерно то же самое, но с использованием XAML/C#. Это первая часть, но мы уже в ней сделаем красиво!

Переход на iOS 6, как и выпуск iPhone 5, не совершил революции (разве что с помощью приложения Будильник), а, скорее, стал логичным шагом для развития App Store. Задача усложнилась как для разработчиков приложений, так и для рекламистов. Но когда отпадают одни инструменты, стоит побыстрее искать замену для них.В этой заметке я хочу кратко пройтись по изменениям в App Store и поделиться работающими рекомендациями по продвижению мобильных приложений.



Cогласно http://www.insidemobileapps.com в октябре 2012 года для попадания бесплатого приложения в Top 100 нужны 13 000 закачки в день. Условие попадания в Топ 10 – 54 000 закачки в день. Эта цифра ниже прежней благодаря массовой чистке ботов, но она довольно высока в любом случае (и, повторюсь, боты уже не выручат). Вместо того, чтоб тратить отсутствующие деньги на дорогую промо кампанию, стоит заставить ваше приложение появляться в поиске по первому запросу ключевых слов и радовать потребителя высоким качеством продукта.

Новый App Store заточен под дизайн. Запрос поисковика выдает пользователю несколько приложений, представленных названием, иконкой, звездочками ревью и первым скриншптом. Да, именно по этим параметрам юзер и выберет то, что он захочет скачать.

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

Мы сделали подкаст с представителями компаний Mail.ru и Legendary Made, из которого вы узнаете о том, как сделать известным свой мобильный продукт. Если вы мечтаете затмить Angry Birds или Instagram, или хотя бы сделать так, чтобы ваш продукт продавался — это выпуск для вас.
В рамках дискуссии были затронуты интересные и актуальные темы:

• Как воздействовать на общественное мнение и word-of-mouth?
• Существуют ли программные методы продвижения мобильных приложений в сторах?
• Помогает ли работа с технологическими блогерами продвижению или нет?
• Как правильно определять свою аудиторию?

Эти и другие вопросы обсуждают Александр Пацай из Mail.ru, Игорь Зеленов и Виталий Смородин из Legendary Made. Если у вас появятся вопросы и комментарии к подкасту — наши уважаемые спикеры обязательно примут участие в обсуждении.

29 августа на конференции OGIC (Online Games Industry Conference) Владимир Верховский рассказал как нужно продвигать мобильные приложения.

В этом докладе не будет 20-минутного рассказа о том, что нужно делать красивую иконку и корректное описание, об этом в курсе каждый второй разработчик в App Store. Если вам интересно, что означают аббревиатуры eCPM, CPC, СPD, ARPU, RAL и как приложения попадают в ТОП, то это видео для вас.


Текстовая расшифровка и презентация

Подробнее о продвижении мобильных приложений

4 года назад я открыл для себя понятие «фриланса» и описал впечатления в статье: habrahabr.ru/post/53938

Думаю, есть смысл поделиться последними наблюдениями.

Проверка приложения, отправленного разработчиком на рассмотрение Apple Review Team в iTunesConnect в среднем занимает около недели, а если вам «повезло» и вы отправили ваше приложение около выходных или праздников, то процесс проверки и появление заветного «In Review» может затянуться на гораздо больший срок.
В данный статье я хочу описать два способа ускорения проверки iOS и Mac приложений в AppStore, работающих на сегодняшний день. Оба способа являются бесплатными.

Схема успеха

Джон, мы потеряли два листа математических выкладок! Что делать?
Как обычно, Билл… напиши: «отсюда с очевидностью следует…»



Чтобы прочитать некраткую сопроводительную записку к схеме – добро пожаловать под кат.