Connect with us

Разработка

История о поиске своего места под солнцем на рынке мобильных приложений

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

AppTractor

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

/

     
     

В самом начале 2014 года мне было 28, 13 лет стартапов и собственного бизнеса за плечами. Был локальный трудно масштабируемый “оффлайн” бизнес и цель на следующий год: построить онлайн бизнес, заниматься которым я смогу где захочу, когда захочу, сколько захочу. Доход позволит мне жить в любом месте мира вместе с семьей и при этом иметь возможность регулярно путешествовать.

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

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

Январь, 2014

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

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

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

Проект №1. Карточные игры

С февраля по март я нашел гейм-дизайнера энтузиаста (думал, что все крутые игры делают только энтузиасты) и начинающую дизайнера (студентка, подешевле, видимо).

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

До макетов и дизайнов, к счастью, дело не дошло.

Всего 2 месяца хватило, чтобы понять, что нельзя вот так просто соединить несколько людей, которые что-то умеют делать, и чтобы они сами взяли и что-то сделали. “Разработка” велась примерно так: раз в неделю примерно собирались в кофейне, обсуждали какие-то игры, а потом все расходились и до следующей встречи.

Очевидно, проект провальный.

Главные ошибки мои – непонимание продукта, наивная надежда, что найденные мной люди сами что-то сделают, а я буду просто тут “руководить”. Убытки на данном этапе это время, кофейни и 2 месяца зарплаты программисту, который, к счастью, не бездельничал и освоил Android-студио и еще что-то там для разработки.

4

Затраты

  • Зарплата программист (оклад) – 40000, посиделки в кофейнях (примерно) – 5000р.

Итого: Минус 45000 рублей чистых потерь без учета моего времени.

Выводы:

  • Для создания продукта нужно самому понимать что именно ты хочешь сделать. Такое вот банальное озарение вывело меня из тумана непонятных “клиповых” действий.
  • Конечный результат и сотрудники-энтузиасты чрезвычайно трудно совместимые категории.

Проект №2. “Бомбочка”.

Это хоть и провал, но тут уже прогресс налицо: за те же 2 месяца проект дожил до публикации в Google Play.

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

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

  • Делать игры с дизайнером без опыта – это провал или авантюра. Много потрачено времени на поиски разных людей, много потрачено денег и очень много нарисовано ужасов.
  • Энтузиасты заканчивают что-то делать сразу после “собрания”, и даже на эти собрания их выловить – нужно еще потрудиться. Такого рода сотрудники не годятся для построения бизнеса.
  • Поиск исполнителей на фриланс-сайтах та еще затея. Чтобы получить один ужасный экран подешевке (30у.е.), я потратил пару недель на создание проекта, переписки, составления ТЗ и прочие бюрократии. Когда я получил работу, я уже понимал, что такой подход невероятно длительный и тут нужно немало потратить времени, чтобы научиться быстро работать. Или просто нужно найти правильных людей. Не знаю.

Затраты:

  • Зарплата программист (оклад) – 60000.
  • Посиделки в кофейнях (примерно) – 3000р.
  • Дизайны все вместе (много попыток разных) – 13000р.
  • Аккаунт Google – 850р.
  • Домены – 1000р.
  • Офис, техника и прочие канцелярии и связи в расчет не беру.

Итого: игра запущена . Про монетизацию там и речи не велось, а про продвижение я узнал уже после запуска. 10-30 скачиваний в день. Забываем про это. Около 80.000 рублей стоил этот опыт.

Выводы:

Выводов и мыслей было так много, что, можно сказать, моя жизнь немного изменилась. Пришло осознание, что Я МОГУ СОЗДАТЬ МОБИЛЬНОЕ приложение. Это окрыляло и давало ощущение близкого входа в новый огромный мир.

По разработке выводы такие:

  • Дизайнер без опыта – авантюра.
  • Держаться от энтузиастов подальше или брать их в расчет только, если не о чем поболтать и нужно обсудить какие-то идеи.
  • Работать с фрилансерами наверное можно, но их поиск и вся бюрократия вокруг этого может занять чертовски много времени.
  • Из предыдущего следует, что браться за какой-либо проект без команды – это блеф.
  • Разработка приложения – это лишь один этап. Его продажа (в широком смысле) – огромная и сложная работа. Этот момент абсолютно не очевиден на старте и никак не принимается во внимание. Пока сам не увидишь, что само твое приложение не торопится покорять топ.

Проект №3. Аптечка в кармане

Начало лета. Розовые мечты о внезапном обогащении, по примеру создателя Flappy Bird, начали рушиться. Вот тут-то, кажется, я стал уже более-менее осмысленно читать чужие опыты, смотреть всякие семинары, узнал кто такой Анар Бабаев и из его лекций вынес вот что: нужно делать приложения для жизни или бизнеса. Они должны быть полезными, понятными и нишу нужно выбрать не очень популярную, чтобы легче (и дешевле продвигать).

1

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

Затраты:

  • Зарплата программист (оклад) – 21000, посиделки в кофейнях (примерно) – 2000р.

Итого: минус 23000 рублей чистых потерь без учета моего времени.

Выводы:

  • Выдуманная полезность и “кажется нужно” – верный путь в тупик. Продукт должен быть РЕАЛЬНО нужным и ОЧЕНЬ полезным, пусть даже очень узкой нише.
  • Планирование и оценка до начала разработки – верный путь сэкономить время и деньги.

Проект №4. Чужой проект

В поисках интересных, полезных и прибыльных проектов меня занесло на какой-то сайт о стартапах и поиске команды/инвестиций/партнеров.

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

Парень собрал команду разработчиков (8-10 человек) и уже почти год работал над своей идеей для ресторанного бизнеса. Суть (примерно) это конструктор сайтов и приложений с неплохим функционалом для ресторанного бизнеса. т.е. у вас мелкий частный бизнес, вы не можете себе позволить сайт с бронированием, меню, онлайн-оплатой, мобильное приложение и еще кучу сервисов в придачу, но тут есть такой чудесный сервис, который даст вам все это за сколько-то долларов в месяц. Проект был ориентирован на США.

По итогу переговоров, решено было подключиться к ним и создать некое шаблонное Android-приложение, которое будет зависеть от их сервера и станет “макетом”, на базе которого их система будет генерировать клоны для своих клиентов.

Если очень коротко, то:

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

Лето пролетело. Убытки в рублях не так велики, как “стратегические”. Вместо повышения своего опыта и практики создания бизнеса, я по сути сдал в аренду своего программиста, а сам отвлекся на один оффлайн-проект, сулящий баснословные прибыли.

5

К концу лета настал момент апатии и казалось, что ничего не выйдет.

Оффлайн-проект, кстати, тоже принес убытки, порядка -300.000р.

Затраты:

  • Зарплата программист (оклад) – 40000, посиделки в кофейнях (примерно) – 5000р.

Итого: минус 45000 рублей чистых потерь без учета моего времени.

Выводы:

  • Сотрудничество/партнерство/инвестиции и прочие “отношения” это всегда риск и тут я не могу сказать, что ошибся. Рискнул. Ошибся в том, что не уделил должного внимания оценки проекта партнеров.
  • Отношения “на словах” – плохой путь.
  • Я допустил отклонение от намеченной цели, отошел в сторону от пути “независимого” разработчика. Считаю это стратегической ошибкой.

Проект №5. Первые шаги в аппстор

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

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

Ребята хотели очень дешево и понимали, что опыта у меня немного. Обговорили сумму, сроки, получили ТЗ. Собрали технику необходимую, iPhone для тестов. Это вдохновляло, было ощущение какого-то подъема. Круто звучало: “делаем приложение для iPhone”.

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

2

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

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

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

Выводы:

  • Достойный продукт можно создать только набравшись опыта и набив шишек, сходу шедевры – это, скорее, сказки.
  • Делать что-то “на заказ” лично для меня это абсолютная авантюра. Ящик пандоры – все эти переговоры, согласования и столкновение субъективных миров, непонимания, неведения и невежества.
  • Браться за работу без детального ТЗ с объемами, сроками, ценами – это похоже на добровольную продажу в рабство за так.

Проект №6. Вовсе и не проект

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

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

Выводы:

  • Есть классная идея – СМЕЛО стучись во все двери.
  • На стадии “попытки” продать идею не нужно тратиться на графику, презентации “от профессионалов” и вообще тратиться. Мне показалось, что действительно классную идею видно и в плохой упаковке.

Проект №7. Агония

Доллар растет. Первое, что пришло в голову – искать заказчиков на работу в валюте.

Пара недель убиты на изучение иностранных бирж. Начал с Еланс. Отличная биржа. Обилие предложений и предполагаемые гонорары воодушевляли и я начал писать всем подряд. День за днем я не получал ни одного ответа и лишь после 20 попытки мне ответили, предложили перейти в скайп и тут же обсудить. Что я и сделал. Наивно было полагать, что я настолько знаю английский, чтобы налету сходу обсудить проект с Австралийцем. ПРОВАЛ.

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

Для фрилансеров, может, и не плохое решение. Но даже в долларах это все равно не бизнес и к цели меня не приближает.

Выводы:

  • Международные биржи типа одеск и еланс – это хорошее место для построение карьеры на удаленном месте и там действительно можно работать.
  • Только вот выход на стабильные и достойные доходы предположительно может начаться месяцев через 5-6, если усердно работать над своим портфолио, профилем и рейтингом.
  • Хороший английский язык в мире мобильной разработки и международного фриланса – это НЕОБХОДИМОСТЬ.

Проект №8. Казуалки

Начинаем все с начала. Снова игры.

Только на этот раз я сам управляю разработкой и никаких энтузиастов.

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

Решено было засучить рукава и начать делать по такому же принципу. А там видно будет.

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

3

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

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

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

Этот этап я бы назвал началом осмысленного пути. Тут я понял, что нужно все-таки делать свое и не сбиваться с пути на всякие быстрые деньги. Это осознание погрузило меня в мир разработки и я начал слушать подкасты о разработке игр, приложений, рунетологию, апптрактор и читать множество всего, что НЕОБХОДИМО для самостоятельной работы над своим проектом.

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

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

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

Итог на конец января 2015 года. По последним играм убыток порядка 150.000 (покупка программы, 2 месяца разработки, более дорогой дизайнер (наконец-то нашел!)) и ожидание запуска последней игры.

Выводы:

  • Банально, но ПЛАНИРОВАНИЕ, КОНТРОЛЬ, СРОКИ, АНАЛИЗ, РАБОТА НАД ОШИБКАМИ – планирование…
  • “Полное погружение” в тему – это верный путь к осознанию и повышению опыта. Без этого какой бы то ни было сносный результат – скорее случайность.
  • Снова дизайнер. Хотите что-то сделать? – найдите себе нормального дизайнера С ОПЫТОМ.

На сегодня

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

В конкурсе прошли во второй тур и задумались – нужен ли он нам, это “УКРАИНСКИЙ Международный конкурс”?

Послесловие

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

Может быть стоит отметить то, что параллельно с разработкой, были еще 3 проекта оффлайн бизнеса. Все они рухнули также феерично, как рубль по осени.

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

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

15 Comments

  1. Игорь

    05.03.2015 at 13:36

    А можно ссылку на твиттер разработчика из Германии? Думаю не мне одному стало интересно

  2. Stepan S.

    05.03.2015 at 13:42

    Да пожалуйста. https://plus.google.com/+DavidZobristGames/posts Если найдете как он делает и с помощью чего – с меня приз;) Если не найдете – подскажу и поделюсь опытом.

    • Игорь

      05.03.2015 at 13:57

      GameSalad Даже не знал про такой движок)

      • Stepan S.

        05.03.2015 at 14:03

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

        • Игорь

          05.03.2015 at 14:16

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

          • AppTractor

            05.03.2015 at 14:19

            Unity для 2D игр по-моему слишком велик. Может Corona SDK? Она недавно бесплатной стала.

          • Игорь

            05.03.2015 at 14:28

            Согласен, Unity может показаться излишне большим для 2d игр, но С#, огромное комьюнити, множество плагинов стоит 10 лишних Мб на выходе. Тем более если посравнить технические характеристики и что доступно “из коробки” в каждом из них, сомневаюсь что Корона сможет конкурировать.
            У каждого движка конечно есть плюсы и минусы, просто Unity мне удобней всего

          • Stepan S.

            05.03.2015 at 14:21

            Это чистая правда. Теперь я сам убедился)

          • Stepan S.

            06.03.2015 at 13:54

            Статья готова, запостил на Хабре сегодня в песочнице.

  3. гость

    05.03.2015 at 14:11

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

    • Stepan S.

      05.03.2015 at 14:21

      5217 не планировщик и не туду лист. Это просто таймер по методике помодоро. Она популярная довольно и я надеюсь на эффект новизны и нового взгляда на временные интервалы. Плюс часы от эппл.

  4. Анна

    05.03.2015 at 14:26

    а увидеть приложения можно?

  5. pilot34

    06.03.2015 at 21:48

    где же таких программистов берут по 20-30 тысяч в месяц :)

You must be logged in to post a comment Login

Leave a Reply

Новости

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

У нас код полета на Луну, голосовые интерфейсы и эпические фейлы.

AppTractor

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

/

Автор:

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

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

Разработка

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

Ждет нас покупка авто или ремонт холодильника, мы всегда спрашиваем о стоимости. И хотим услышать конкретную цифру. Наши клиенты тоже ожидают конкретики: «Разработка стоит 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, который активно осваивает и развивает облачные технологии, мобильные вычисления, большие данные и другие актуальные инновации.

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

Новости

Microsoft и National Geographic выделяют гранты на разработку экологического ИИ

Microsoft и National Geographic запускают программу грантов объемом в $1 млн для разработки искусственного интеллекта в сфере экологии.

AppTractor

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

/

Автор:

Как пишет “Хайтек”, в рамках проекта от 5 до 15 разработчиков получат финансирование, доступ к облачным инструментам Microsoft и инструментам для машинного обучения, а также консультации экспертов National Geographic Labs и National Geographic Explorer.

Мы считаем, что люди и компьютеры, работающие вместе при помощи искусственного интеллекта, могут изменить отношение к экосистеме Земли, а также контролировать и моделировать ситуацию в экологии, — рассказал главный экологический эксперт Microsoft Лукас Джоппа.

Компании смогут получить гранты до 8 октября 2018 года. Для работы с Microsoft и National Geographic разработчики должны работать в сфере изменения климата, сельском хозяйстве, загрязнении водоемов или вымирании различных видов животных. Любые нейросети, разработанные на деньги с грантов, должны быть с открытым исходным кодом, чтобы любой исследователь мог использовать эти инструменты.

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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