Connect with us

Статьи

Почему авторы Trello не смогли создать бизнес на 1 миллиард долларов

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

Анна Гуляева

Опубликовано

/

     
     

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

В 2011 Джоэл Спольски на TechCrunch Disrupt запустил новый продукт компании Fog Creek под названием Trello. Он был похож на белую доску со стикерами, перенесенную в веб-браузер и в приложение для iPhone. Вместо того, чтобы перемещать физические заметки на доске, вы могли перетаскивать карточки на доске в браузере.

За считанные дни Trello удалось привлечь внимание 131 тысячи человек. 22% из этих людей зарегистрировались. Trello хотели создать простой и полезный продукт, который сможет использовать кто угодно. Он распространялся, как лесной пожар.

Поэтому Trello в итоге пришлось продать Atlassian за $425 миллионов, хотя он и мог стать следующим SaaS-приложением на миллиард долларов.

Спустя пару месяцев после запуска Спольски написал пост, в котором предвидел самую большую сложность:

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

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

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

Давайте поговорим о возможности, которую упустил Trello, и что следовало сделать вместо этого.

Почему Trello нужно было заниматься продажами

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

На практике это выглядело так:

Когда Trello только появился, технически было действительно сложно создать браузерную доску, в которой вы сможете совместно перемещать карточки в разные списки. Многие SaaS-инструменты того времени были большими базами данных с визуальным интерфейсом, натянутым поверх (например, Salesforce). Создавалсь архитектура, в которой вы структурируете данные по лидам, клиентам или задачам.

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

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

Архитектура Trello

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

Все это было новым в то время и привлекло к Trello много внимания. Но в 2016 подобное красивое и отзывчивое  приложение стало не так сложно создать, и канбан-доски начали появляться везде:

GitHub представили канбан-доски в сентябре 2016:

Asana анонсировали канбан-доски в ноябре 2016:

Airtable запустили канбан-доски в ноябре 2016:

Джастин Розенштейн, сооснователь одного из крупнейших конкурентов Trello, Asana, сказал: “Мы определенно отдаем должное Trello. Этот продукт первым создал подобное видение”. Но Джастин непреклонен в вопросе копирования функции досок Trello: “Мы рассматриваем Trello как функцию, а не как продукт”.

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

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

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

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

1. Trello недостаточно быстро монетизировался

При помощи freemium модели возможно построить нацеленную на пользователей миллиардную компанию. В 2013, спустя шесть лет после запуска, Dropbox был оценен в 8 миллиардов долларов, их доход – 200 миллионов долларов, а количество пользователей – 200 миллионов человек. Это было даже до того, как Dropbox запустил тариф для бизнеса – доход компания преимущественно получала от продажи пользователям месячной подписки за 10 долларов.

Спустя три года после запуска рост количества пользователей Trello обещал превысить уровень Dropbox: в 2015 году у Trello было 10 миллионов пользователей (через три года после запуска у Dropbox было четыре миллиона клиентов). Но Trello было гораздо сложнее переводить неплатящих пользователей на свой план “Trello Gold”.

Запуск Trello Gold в 2013 был освещен этим постом в блоге, которые выделил три причины, по которые пользователю следует платить 5 долларов в месяц за Trello:

  • Настраиваемый фон доски
  • Ограничение в 250 МБ для файлов, прикрепленных к карточке (против 10 МБ в бесплатном плане)
  • Стикеры и кастомные эмодзи

Хотя все любят эмодзи, это не очень хорошая причина тратить деньги на приложение. Бесплатный тариф Dropbox предоставляет 2 ГБ пространства. Платный тариф предоставляет 1 ТБ, что в 50 раз больше бесплатной версии.

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

Решение: Изучить кейсы freemium-модели

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

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

  • Существует ли у вас конкурент, который может делать то же самое или уже делает это сейчас?
  • Каков потенциальный доход этого варианта?

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

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

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

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

2. Trello не стал незаменимым для SMB

Даже без доходного B2C-бизнеса Trello могли стать SaaS-инструментом для работы компаний, закрепившись на SMB-рынке. Проблема заключалась в том, что Trello не доказал свою незаменимость в качестве инструмента для управления рабочими процессами, чтобы оправдать свою стоимость перед компаниями.

В 2013 Trello запустил первый план Business Class для малого и среднего бизнеса. Сначала они установили цену в 200 долларов в год для организации, прежде чем перейти к более традиционной модели ценообразования SaaS за рабочее место.

Trello Business Class стоил 10 долларов за пользователя (плата взималась раз в год), и за эти деньги вы получали:

  • Безграничную интеграцию досок
  • Дополнительные функции совместной работы
  • Режим “только для чтения” и настройки приватности

Когда Дэвид Кэнсел, со-основатель Drift, упомянул годовую стоимость Trello в своей презентации, вся команда была шокирована – цена составила 1700 долларов. Как говорит Дэвид: “Только несколько людей используют Trello ежедневно. Однако мы платим за количество подключенных людей. Очевидно, существует разрыв между ценой, которую мы платим, и пользой, которую мы получаем”. Дэвид затем перевел свою команду обратно на бесплатный план.

В статье на Forbes CEO Trello Майкл Прайор сказал: “Я не хочу, чтобы люди проводили по десять часов в Trello ежедневно, мы не продаем рекламу и не хотим получать больше вашего времени, как это делают социальные платформы”.

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

Что следовало сделать Trello?

Решение: Создать лучшую интеграцию для SMB

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

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

Вместо этого главные функции Trello были скопированы. Представителю GitHub задали вопрос о создании досок для визуального управления вопросами, на что он сказал: “Все ожидали этой функции и спрашивали, почему у нас её не было”. Поэтому GitHub создали доски.

Если вы создаете подобное горизонтальное SaaS-приложение, разделите своих пользователей по интеграциям:

  • Какие API используют люди?
  • Сколько данных входит в продукт и выходит из него?

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

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

3. Trello не подходил для предприятий

Смена фокуса на рынок предприятий – доказанная модель для SaaS. Slack сделал это, запустив Enterprise Grid. Trello могли бы построить прибыльный бизнес таким же образом, быстро переключившись на рынок предприятий.

Менее чем через год после запуска стратегии корпоративных продаж, ежегодные платежи (ARR) достигли отметки в 10 миллионов долларов. В своем интервью вице-президент Trello по продажам Кристен Хабахт сказала, что Trello следует достаточно простой стратегии корпоративных продаж:

«Наша команда по работе с предприятиями рассматривает [клиентов], у которых действительно много пользователей Trello. Большая часть нашей стратегии исходящих продаж – это просто связаться с этими компаниями и сказать: У вас более 2 000 человек пользуются Trello, с кем мы можем поговорить об этом?»

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

Решение: Стать системой хранения данных для предприятия

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

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

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

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

Поздравляю, Trello

Смотреть в прошлое, конечно, проще. Хотя большая часть статьи посвящена упущенной возможности Trello, мы не должны забывать, что создание SaaS-бизнеса, оцененного в 425 миллионов долларов, это большое достижение.

Команда Fog Creek заплатила за создание Trello из своего кармана. Приложение стало успешным с момента запуска на TechCrunch Disrupt. За два года Trello приобрел 500 тысяч пользователей, а за четыре года – 4,75 миллиона, и это до привлечения средств инвесторов. Команда создала удивительный продукт, который опередил свое время. Он был простым, изящным и легким в использовании.

В прошлом году я написал такой твит:

Вот такое влияние Trello оказал на SaaS, и вы видите его следы везде: от GitHub до Jira.

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

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

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

Сколько стоит разработка мобильного приложения?

Ждет нас покупка авто или ремонт холодильника, мы всегда спрашиваем о стоимости. И хотим услышать конкретную цифру. Наши клиенты тоже ожидают конкретики: «Разработка стоит X рублей». Но возможно ли такое?

Magora Systems

Опубликовано

/

Автор:

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

Не можем говорить за всех, поэтому пишем о своем опыте и процессах оценки.

Уточнение

Чем точнее требования, тем меньше шанс, что вас поймут неправильно. И тем точнее получится оценка стоимости разработки. Поэтому мы планируем звонок, чтобы обсудить:

  • Бизнес. Спрашиваем: для кого делаем приложение, каковы потребности аудитории. Уточняем ключевые функции, желаемые сроки и бюджет. Выясняем, какую проблему решит приложение, и как поможет вам зарабатывать или экономить. Даем первичную оценку – можно ли вообще реализовать проект за выделенную сумму? Например, сделать сервис такси с нуля за 200 тысяч рублей просто невозможно.
  • Техническую сторону. Это про охват (влияет на архитектуру), объемы данных, платформы (iOS, Android, Web?), устройства (смартфоны, планшеты, гаджеты?), интеграцию с другими сервисами (Google Maps и др.) и т.д. А еще узнаем о предпочтениях в дизайне.

Анализ

Назначаем опытного специалиста. Он изучает все, что предоставите: техническое задание, описания, прототипы, сценарии использования и т.д.

Бывает, есть только идеи или общие описания. Бывает, есть какое-то ТЗ, но почти всегда данных недостаточно для оценки. Поэтому сначала мы и уточняем детали.

Если возможно, после разговора выделяем список функций, оцениваем каждую и подбиваем итог. Эту работу мы делаем бесплатно и отправляем КП через 1-3 рабочих дня. Предупреждаем, что стоимость может измениться. Фиксирована только та цена, которая указана в контракте.

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

Оценка стоимости разработки

Изучив входные данные, мы разделим объем работ на блоки и оценим. Если функций много и проект масштабный, предложим выделить и начать с MVP (базовой версии). Так вы быстрее выпустите продукт, чтобы проверить «в бою» и собрать отзывы пользователей.

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

Чтобы ускорить оценку, у нас есть список стандартных функций с установленными трудозатратами. Это не цифры «с потолка», а результат опыта и реальных проектов.

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

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

Что-то пошло не так…

Исследование Standish Group agency показало, что только 3% крупных проектов и около половины малых проходят по плану. Как же так?!

Разработчики не умеют оценивать?

Не совсем. Зачастую оценивают идеальный сценарий.

На деле получается, что сервер упал, документация устарела, разработчик заболел и надо подключить нового к проекту. Оценка растет с X часов до X+Y, а вместе с ней и стоимость. Кому это понравится?

А потом вы решаете добавить 2 функции. Но их не оценивали, надо пересчитывать. И да, цена вырастет.

Конечно, причины бывают разные, суть в том, что непредвиденные ситуации возникают в 97% проектов.

Зачем вообще оценивать?

Несмотря на все сказанное, вы:

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

Как получить максимум от оценки

  • Узнать ставку часа. Если ставкая высокая, а общая сумма – нет, что-то могли упустить при оценке.
  • Посмотреть, есть ли в команде тестировщики, аналитики, менеджеры. Чтобы сделать продукт, мало просто написать код.
  • Подробно описать проект. Дать ТЗ, макеты, схемы… Чем четче требования, тем точнее оценка.
  • Перепроверить, что оценили все функции, которые хотите получить в приложении.
Комментарии
Продолжить чтение

Разработка

DevOps на службе разработки ПО и Open Source

Всего за несколько лет разработка ПО превратилась в стратегический сектор ИТ-индустрии и экономики в целом, особенно во Франции, если верить недавно представленным планам широкомасштабной цифровизации. Карин Браун-Энно, управляющий директор Red Hat France, рассказала нам о роли DevOps в росте индустрии.

AppTractor

Опубликовано

/

Автор:

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

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

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

Почему структура команды разработки может вас замедлять

Почему DevOps?

Одна из главных причин возникновения концепции DevOps – это стремление к непрерывности, причем, непрерывности не только самих ИТ-сервисов, но и их совершенствования и доработки силами разработчиков и заказчиков в лице представителей бизнеса. Очевидно, что, сводя к минимуму перебои в работе ИТ-сервисов, можно автоматически максимизировать результаты работы компании. Однако, постоянно улучшая взаимодействие с пользователем (исправляя ошибки и запуская новые функции, которые тестируются в «боевых» условиях и при необходимости очень быстро дорабатываются), ИТ-подразделение также оказывает весомую поддержку своему предприятию, предоставляя ему средства для реализации и моделирования бизнес-стратегий, ориентируясь на поведение рынка, которое отслеживается в режиме близком к реальному времени.

Компания Puppet Labs отмечает, что 63% организаций, внедряющих DevOps, делают это для повышения качества развертывания, примерно такой же процент опрошенных хотят повысить частоту доставки, а 61% респондентов прежде всего фокусируются на улучшении качества процессов.

И это еще не все. Экспоненциальный рост обмена данными в результате пришествия интернета вещей вынуждает практически полностью пересмотреть модели обработки данных и связанные с этим приложения. Умные бытовые приборы и носимая электроника, финансовые услуги, автономные автомобили, системы управления воздушным движением, промышленность нового поколения (т.н. «Индустрия 4.0»), цифровое управление цепочками поставок – уже становятся обыденностью, охватывая значительную аудиторию за счет оптимизации фундаментальных процессов. Основываясь на новых методах обработки огромных объемов данных (структурированных и неструктурированных) и включая в себя расширенное и автоматизированное управление корпоративными процессами с охватом партнеров и клиентов, и эти модели интероперабельности, гибкости, сотрудничества, совместного использования и, прежде всего, инноваций лежат в основе модели Open Source, формирующей информационные системы следующего поколения.

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

Сегодня у нас есть все, чтобы вывести эволюционировавшие процессы сотрудничества в фазу зрелости. Решения IaaS («инфраструктура как услуга») и PaaS («платформа как услуга»), лежащие в основе модели DevOps, предлагают разработчикам гораздо больше гибкости и свободы, позволяют создавать новые приложения быстрее и с меньшими усилиями, облегчают развертывание приложений, устраняя барьеры и повышая управляемость. Переходя на язык конкретики, IaaS на основе OpenStack и PaaS с открытым кодом дают возможность быстро и итеративно разрабатывать облачно-ориентированные приложения, построенные на основе микросервисов (базовых компонентов приложений), объединенных в рамках супер-обновляемой модели, предоставляя все необходимые ресурсы и полностью отвечая целям DevOps.

Android Dev Подкаст. Выпуск 54. DevOps

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

Комментарии
Продолжить чтение

Разработка

Дневники разработчиков: Snek Fite — «змейка» с непрямым управлением

Привет, меня зовут Михаил, я разработчик и вообще не занимаюсь приложениями-играми. Snek Fite — это первый опыт (ну, вернее, первый удачный: проект находится в играбельном состоянии и количество игроков понемногу растет).

AppTractor

Опубликовано

/

Автор:

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

Геймплей выглядит так:

С другой стороны, это симуляция программирования. Такая, где не нужно непосредственно писать код, но обучать свою змею придется — в игре нет прямого управления змейкой с клавиатуры, мышки или любого другого контроллера. Вместо этого — экран настроек, который вызывает умиление у любого человека, который пробовал делать свою игру в конструкторе со сценарным программированием (типа Scirra Construct 2, RPG Maker, да хоть Aurora Toolset).

Так выглядит экран настройки змеи. Девять полей, объекты, которые можно расставить по полю, логические операторы (must, must not и optional). Программирование для тех, кто не умеет писать код.

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

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

В общем, это далеко не развлекуха с мобилочки на вечер. По крайней мере, для большинства. Snek Fite — игра по-своему хардкорная, и затягивает избранных. Зато если затянула — то можно стать таким, как наш игрок с никнеймами Zerro/Undefined (у него две змеи). Он сделал иллюстрированное руководство, где разобрал поведение змей, выигрышные тактики, частые вопросы и сделал много другой полезной работы. Руководство на английском.

Сейчас его змеи на первом и втором месте общего топа:

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

Игра всегда заканчивается по истечении 1000 ходов. То есть примерно за минуту.

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

Игра — идейный наследник классической Snake Battle, которую российская компания Gamos выпустила в 1992. Геймплей был схожим, только онлайн-баталий не было — всё-таки это была эра MS-DOS и флоппи-дисководов.

Геймплей старой игры:

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

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

В общем, если заинтересовал опыт — то пишите в комментариях, о чем хотелось бы почитать (матчмейкинг, разработка на VUE, организация базы данных для игры, выигрышные тактики, опыт продвижения или что-то еще). Сама игра живет по адресу snek.app.

Комментарии
Продолжить чтение

Разработка

Интересные материалы для разработчика мобильных приложений #221 (9-15 июля)

На этой неделе случилась бомбическая история с приложением Burger King и аналитикой Appsee, App Store исполнилось 10 лет, мы узнали про чат-боты, банковские приложения, архитектуру приложений и нейронных сетей.

AppTractor

Опубликовано

/

Автор:

11 июля появился на Pikabu, а 12 июля был продублирован на Хабре пост, в котором пользователь fennikami изучает данные трафика мобильного приложения Burger King и делает вывод, что за ним следят: записывают видео с экрана, когда он вводит данные своей банковской карты, а потом передают эту информацию третьим лицам.

Burger King и тайная запись экрана вашего телефона
Запись видео с вашего экрана не такая уж тайная. Версии Бургер Кинга и Appsee
А что такое этот ваш AppSee?
Разбираемся, что записывает, а что не записывает приложение Burger King
Басня о Burger King и данных пользователей. Комментарии разработчика
Приложение Burger King: насмешка над защитой персональных данных. Исправляем?

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 AI, Устройства, IoT

 Вакансии

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.