Connect with us

Разработка

История разработки: “Маленькие истории”

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

Diveo Media

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

/

     
     

Название нашей компании (Diveo Media) пришло во сне, зимой 2014 года. Вообще, мы просто поменяли местами буквы в слове “video”, так как хотели сначала заниматься именно видео-продукцией, но я изначально знал, что мы не будем себя ограничивать. Мы не знали только Diveo Studio или Diveo Media. Ответ пришёл во сне, когда на бумаге виднелась надпись www.diveomedia.com. К сожалению, сам сайт был уже занят, но он и не работал. В течение недели поисков мы нашли владельца, которым оказался американец из штата Юта по имени Райли. Он продал домен за 400 евро и так и начался путь.

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

altai

Я рассказал об этой идеи своему другу и он посоветовал мне сделать приложение. И тут я подумал: а почему бы и нет? Спустя полгода уже была создана первая пробная сказка – “Волшебная Ёлка”, но она вышла немного не такой, как задумывалась изначально. Ведь по плану должно было быть полноценное приложение с кучей сказок на iPad, а вышла одна сказка без дополнительных функций (просто история с картинками, там даже имя поменять нельзя было) на Android. Мы хотели сказку сделать платной, но тогда в Эстонии Google Play позволял делать приложения только бесплатными. Но зато мы получили 13 тысяч установок и много полезных отзывов, что позволило сделать нынешнее приложение “Маленькие истории” более качественным.

Спустя ещё полгода я стал искать команду энтузиастов, к этому времени уже был куплен сайт diveomedia.com.

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

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

Вера в сказку

Мы называемся Diveo Media и наша цель – стать лучшим детским разработчиком в мире. В нашей команде уже 8 человек. Все работают с душой и энтузиазмом. У всех громадный опыт за плечами. Нашей особенностью является то, что мы работаем абсолютно удалённо. Ведём сотрудничество из трёх стран: России, Эстонии и Великобритании. Сам я живу в Эстонии, в городе Усть-Нарва. 90% населения здесь русские. Через реку Нарова уже видна матушка Россия.

Когда я только начинал собирать команду, то у меня сначала было желание найти единомышленников в Эстонии, потому что думал, что так вести сотрудничество будет легче. На практике оказалось, что в маленькой стране мало хороших кадров, поэтому, когда поиски обернулись провалом, я вышел сразу на Россию. Решил, что будем работать удалённо. Но я сразу стал искать лучших, потому что хотел сделать отличное приложение и ещё у меня не было бюджета, поэтому я искал лучших энтузиастов. Удивительно, но поиски не заняли много времени. Необходимых людей удавалось найти в течении двух-трёх дней. Многие думают, что найти профессионала, который готов работать на перспективу, это всё сказки, но в нашей команде в эту сказку верят 6 из 8 человек. Думаю, секретом здесь явилось то, что мне удалось эмоционально описать свой проект, плюс были уже некоторые наработки. Например, та сказка, которая вышла в Google Play. Есть ещё один хитрый момент, который кому-то может показаться абсолютно бредовым, но я попросил вселенную помочь мне найти нужных людей. Грубо говоря, притянул их мыслями.

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

Маленькие истории: книги детям
Маленькие истории: книги детям
Разработчик: От Diveo Media
Цена: Бесплатно+

Секреты кухни

Как шла разработка, какие были проблемы и что следует учесть при удалённой работе в команде?

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

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

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

Маленькие истории

Наше приложение “Маленькие истории” представляет из себя сказки, в которых ребёнок становится главным героем, то есть иллюстрации и текст меняются в зависимости от настроек. Следовательно, для нас первой проблемой явилось склонение имён. Ведь в русском языке есть множество нюансов. Например, имена Лев и Пётр являются исключениями и по алгоритму приложения не склоняются. Пётр – у Петра – с Петром, Лев – у Льва – со Львом. Но это не сложно, сложнее было составить правильный алгоритм склонения. Наш iOS-разработчик Николай, у которого высшее математическое образование, справился с этой задачей на отлично, в чём вы можете сами убедиться. В русском языке есть ряд правил и исключений, просто их надо все собрать воедино.

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

И как стало теперь:

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

Вот пример с настройками.

Было:

5

Стало:

6

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

7

А затем превратилась вот в такой вариант:

8

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

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

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

Теперь мы подошли к самому интересному этапу – распространению информации. Сделав небольшую рекламную кампанию мы получили 300 установок и 21 положительный отзыв (20 пятёрок и 1 четвёрка). В приложении всего 4 сказки, две бесплатные и две платные. Радует то, что люди делают покупки. В России конверсия составляет 2%, то есть только 6 из 300 пользователей сделали покупки. В среднем на одного платящего пользователя приходится по 1.6 покупки. Конечно, статистика очень скудная, но какое-то представление о ситуации нам даёт. Моя ошибка это то, что я был нацелен только на iPad, а это очень сильно ограничивает. Поэтому мы работаем над iPhone версией и начали разработку под Android. Также работаем над оптимизацией самого приложения, чтобы увеличить конверсию покупок и средний чек с одного пользователя.

Какие наши планы? К концу года иметь 10,000+ установок на iOS и выйти на Android. К весне 2016 года иметь общее число установок на обоих платформах в 100,000. Ещё надо сделать перевод приложения на несколько языков (сейчас у нас только английский и русский языки). Через год должны выйти на самоокупаемость, а к концу 2018 года планируем стать лучшим детским разработчиком в России. В 2020-2021 годах наша цель стать лучшим детским разработчиком в мире. У нас есть главное преимущество перед многими конкурентами – качественный и интересный продукт. А то, что наши приложения воспитывают детей и делают их умнее и счастливее, поможет заполучить любовь родителей во всём мире.

team

Наша команда:

  • Алтай Зейналов – автор проекта и сказок;
  • Джамиля Алескерова – хужожник;
  • Анна Горлач – художник;
  • Елена Буркова – художник-дизайнер;
  • Артём Акмулин – композитор;
  • Константин Жуков – переводчик, корректор, автор;
  • Николай Джулай – iOS-программист;
  • Артемий Терехов – Android-программист;
  • Рафаэль Зейналов – маленький тестировщик приложений :).
Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
3 комментария

3 Comments

  1. Stepan S.

    22.09.2015 at 19:52

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

    • Altai Zeinalov

      24.09.2015 at 17:08

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

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

Hyperion

Hyperion – встраиваемый в iOS-приложения плагин, помогающий контролировать верстку.

Леонид Боголюбов

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

/

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

  

 

 

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

Новости

Интересные материалы: 07.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

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

/

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

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

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

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

/

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

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

Пустые объекты не являются подходящим инструментом для работы. Если случилось что-то исключительное, то вы должны выбросить исключение.

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

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

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

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

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

Правка 3: Использование Optionals вместо null

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

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

Вы должны избегать методов, которые выглядят следующим образом:

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

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

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

 

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

Новости

Интересные материалы: 06.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

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

/

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

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

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

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

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

Популярное

X

Спасибо!

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