Я не буду писать о том, почему и для кого необходимо разрабатывать мобильные приложения. Мы все живем в 21 веке, и необходимость приложений уже никому не нужно объяснять.
Однако, есть вещи, которые потенциальным клиентам нужно объяснить. Например: из каких этапов состоит разработка приложения, и сколько времени она может занять. Сейчас в интернете достаточно информации о приблизительном тайминге изготовления мобильного приложения: от месяца до пяти (условно). Но на самом деле, эта цифра редко включает подготовительные работы и многие мелкие, но важные моменты. Поэтому я решила расписать порядок разработки мобильного приложения с приблизительным расчетом времени, которое может быть потрачено на тот или другой этап.
Базовые этапы разработки мобильного приложения:
1. Планирование
На этой стадии происходят самые важные вещи в плане стратегии: бизнес-планирование, определение и сбор основных условий, ознакомление с лучшими примерами подобных проектов, исследование конкурентов и потенциальных проблем, регулярные собеседования с клиентом. На этом этапе уже необходимо понимать свою ЦА и ее особенности.
Все это может занять до нескольких недель.
2. Определение функций и характеристик приложения
Какие основные проблемы и их решения преследует создание вашего приложения? На этом этапе нужно понимать, какие функции необходимы приложению, и как приложение будет взаимодействовать с данными. Будет ли приложение собирать данные непосредственно от пользователей, либо же подтягивать их из других ресурсов?
Другим важным решением, которое необходимо принять на этом этапе, будет мультиплатформенность. Грубо говоря, это означает выбор одной либо нескольких операционных систем одновременно. Будет ли ваше приложение нативным? Вы собираетесь создать два отдельных приложения, к примеру, на iOS и Android? Либо же вы хотите создать единственное кросплатформенное приложение? Тут также следует взвесить все за и против.
Все эти решения займут не много и не мало: от трех до пяти недель.
3. UI/UX дизайн
Этот пункт разработки предусматривает, что дизайнеры начнут создавать «персонас», формировать таск-лист и сетку для UI. Этот этап характеризуется постоянными спорами и обсуждениями мокапов с клиентом, а также исследования реакции потенциальных юзеров из фокус-группы (конечно же, в идеальном мире). Приблизительно, этап займет до двух недель.
4. Frontend-разработка
Подразумеваю, что все и так знают, что такое фронтенд, поэтому перейдем к описанию самого этапа. Здесь нужно будет создать прототип приложения для проверки взаимодействия с пользователем и получения его оценки. В результате мы получим фронтенд-код, с которым перейдем к следующему этапу.
5. Backend-разработка
Здесь нужно будет создать АРІ, бекенд-архитектуру и провести контроль качества. Оба этапа: фронтенд и бекенд займут в районе пяти недель. Но если проект сложный, то можно рассчитывать на все 18 недель: 10 для бекенда, 8 для фронтенда:
6. Тестирование
На этом этапе происходит несколько различных видов тестирования (в идеале): функциональное, пользовательское, тестирование интеграций и тестирование на устройствах, исправление ошибок. В результате, несколько раундов тестов могут занять до четырех недель.
7. Деплой
Важно! На этапе деплоя (который много времени не занимает) необходимо обеспечить бекап.
8. Поддержка
На этой стадии нужно проводить постоянные мониторинги, создавать бекапы и загружать обновления, исправлять ошибки и взаимодействовать с клиентом и пользователями приложения. Последний этап длится сколько прописано в контракте (если, конечно, поддержка в нем предусмотрена).
Теперь у вас есть представление о приблизительном времени, которое требуется на создание приложения. По-хорошему, самое простое приложение займет где-то два месяца. Сложное же может потянуть и до года разработки (например, если там изначально требуется какая-то особая экспертиза и бекенд онлайн саппорт).
Для наглядности:
- Приложение подобное Uber может быть создано приблизительно за 5,5 месяцев
- Приложение типа WhatsApp требует около 4,6 месяца для создания
- А приложения вроде Periscope или Tinder могут занять и вовсе всего от 3,8 до 4,1 месяца
Дополнительно, время на разработку может быть увеличено за счет:
— Мультиплатформенности. Разработка приложения для более чем одной платформы всегда требует больше времени. Есть данные о том, что разработка приложения на Android занимает на 20-30% больше времени, чем разработка для iOS.
— Улучшения дизайна. Есть вероятность, что после запуска клиент захочет обновить или улучшить дизайн. Связано это, чаще всего, с юзер экспириенс, которую можно оценить в полной мере только после полноценного запуска. Отсюда и возникает необходимось что-то улучшить или подправить уже после релиза.
— Социальные медиа. Если ваше приложения интегрируется с социальными сетями, вам нужно добавить в тайминг для разработки до двух недель, чтобы добавить минимальные необходимые опции вроде логина и шеринга.
В погоне за сокращением времени на разработку нужно не забывать про качество. Есть также некоторые хаки, которые помогают сэкономить время и не повлиять негативно на качество приложения:
1. Использование готовых сеток (вайрфреймы) для UI
Вместо того, чтобы рисовать их с нуля, ваш дизайнер может просто найти подходящий вариант и несколько его изменить для соответствия идее вашего приложения. Иными словами, можно обойтись без изобретения велосипеда. Как правило, чем раньше у вас появится этот фрейм, тем быстрее и лучше ваши программисты поймут идею и функционал будущего приложения. Два в одном.
2. Предварительный запуск MVP (minimal viable product) — прототипа
Прежде чем запустить готовый «вылизанный» продукт, советую лучше протестировать его в виде бета. После запуска пробной версии у вас будет достаточно данных для тестирования и улучшения продукта. В результате, готовый полноценный продукт будет качественнее, лучше и полноценнее.
3. Гибридное приложение
Если у вас нет 100% уверенности, что вам необходимо именно нативное приложение, почему бы не рассмотреть вариант с гибридным? Гибридное приложение имеет единый код для всех платформ, поэтому время на его разработку меньше. Конечно, у него есть недостатки: качество анимации, например, или требования по обеспечению большего объема памяти. В любом случае, если приложение нужно запустить быстро — выбирайте гибрид. После запуска его всегда можно заменить на нативное приложение.
4. Аутсорсинг
Нужно ли расписывать преимущества данного подхода? В двух словах: экспертиза и профессионализм. Иногда лучше нанять команду, которая разбирается в конкретной технологии, нежели тратить время на обучение своей команды, которая хороша совсем в другой области. Аутсорсинг экономит время, силы и, в итоге, деньги.
5. Автоматизированное тестирование
Есть тесты, которые занимают часы. Так зачем тратить на это время специалиста, если можно просто запустить автоматический тест, а специалиста перекинуть на другую, более интеллектуальную задачу?
Вкратце: в этой статье я привела приблизительное время на разработку мобильного приложения и описала этапы разработки. Также дополнила материал способами сокращения времени на разработку без потери качества продукта. Надеюсь, этот материал будет вам полезен!
Комментарии (33)
tmnhy
30.10.2017 19:14+1Клиенту-заказчику вы объяснили сколько потребуется времени на разработку приложения.
Но самое интересное осталось в тени, вы не показываете ресурсы со стороны исполнителя, которые брали в расчёт при прогнозе времени на все этапы.
dolphin4ik
30.10.2017 19:31Да, точно. Ресурсы — один из важнейших компонентов в разработке.
4 месяца разработки это 2 человека или 22?
Но всё равно познавательно.tmnhy
30.10.2017 19:38+1Но всё равно познавательно.
Ой, не соглашусь, без «ресурсов» исполнителя — это очередной буллшит.
IrynaKorkishko Автор
31.10.2017 12:00Рассчет приблизительный. Вы правы, от ресурсов многое зависит, как раз поэтому в статье я о них не упоминала. Иначе материал превратился бы в уравнение з тридцатью переменными.
Ведь ресурсы зависят от многих факторов, главные из которых:
- сложность проекта
- уровень проффесионализма команды (иногда вам достаточно одного или двух фуллстеков, а иногда — и двадцати, к примеру, рубистов, будет мало; а все потому, что не у всех руки растут оттуда, откуда надо)
- уровень халатности/ответственности
- сроки, которые обозначил сам клиент (иногда нужно нанимать дополнительные ресурсы, чтобы успеть, потому что релиз — через неделю, например)
И это только основные моменты. Поэтому ресурсы я в статье не рассчитывала. Это можно приблизительно сделать на примере какого-то конкретного проекта. Но для этого уже следует писать отдельный материал и все расписывать в нем.
Поэтому, на вашем месте, я бы или сама писала о ресурсах, либо попридержала комментарии вроде "буллщит" :)
Rastishka
31.10.2017 13:59Эээээ, то есть сроки не зависят от этих факторов? Это что то новое в менеджменте.
проффесионализм
фэйспалм…IrynaKorkishko Автор
31.10.2017 15:12Конечно же зависят! Вы как-то странно читаете ответы.
Опечатка про "профессионализм". Приношу извинения. Оправдываться не буду, бывает, к сожалению.
Что касается ресурсов, я лишь говорю о том, что в этой статье ресурсы не описаны, иначе материал получился бы безразмерным. Описанные сроки взяты в среднем, базируются на опыте работы. В одном проекте было столько разработчиком, в другом столько, в среднем вышло так и так.
Опять же, если у вас есть конкретный пример проекта — давайте его рассмотрим и опишем ресурсы.
tmnhy
31.10.2017 14:30Вы наугад удваиваете согласные? ) Ну уж пишите тогда «ращет, ращот», не стесняйтесь. Но это так, отвлечение, показывающее ваш уровень и уровень отношения к тому, что вы пишете.
Теперь по делу.
Рассчет приблизительный. Вы правы, от ресурсов многое зависит, как раз поэтому в статье я о них не упоминала.
«У меня посылка для вашего мальчика, но я вам её не отдам». Так получается?
Т.е. вы взяли и выдали цифры, а на чём они основываются? Поэтому и «буллшит», что итог ваших изысканий — это как объяснить неопытному заказчику (падкому на инфографику и не вникающему в детали), что мы будем делать полгода, а не 2 месяца и возьмём поэтому в 3 раза больше денег. Несоменно, это тоже полезно, уметь убеждать заказчика. Но, опытный заказчик с вас потребует подтверждения этих цифр, как минимум оценку этапов и задач в чел./час. А вы взяли и проигнорировали эту тему.IrynaKorkishko Автор
31.10.2017 15:26Опечатки у всех бывают :)
Вижу, что вы не столько заинтересованы темой, сколько возможностью потроллить автора.
Пускай материал не идеален, но, повторяю, я не преследовала цель расписать ресурсы. Я лаконично и достаточно понятно расписала процес разработки и потраченное время. Это дорожная карта для тех, кто хочет ориентироваться, сколько может занять разработка мобильного приложения.
Если бы статься называлась, скажем, "ресурсы для разработки мобильных приложений" — вы имели бы полное право требовать, чтобы я рассказала, сколько программистов, дизайнеров и менеджеров было задействовано на соответствующих этапах разработки.
Ваш же комментарий можно сравнить с недовольством человека, который получил меню, но не увидел в нем расписанного количества поваров ресторана.
Клиенту, в конечном счете, важнее всего, чтобы его приложение было разработано за определенное количество времени. Выбирая разработчика, вам важно было бы услышать тайминг и стоимость, в первую очередь.
Повторюсь, ресурсы — тема для отдельной статьи. В ней можете высказывать все свое недовольство. Конкретно эта тема, к сожалению, вам не подходит для критики :)tmnhy
31.10.2017 15:48Конкретно эта тема, к сожалению, вам не подходит для критики
«Ой, всё!..» ))
Оба этапа: фронтенд и бекенд займут в районе пяти недель. Но если проект сложный, то можно рассчитывать на все 18 недель: 10 для бекенда, 8 для фронтенда
«А если взять 9 женщин они родят ребёнка за 1 месяц?»
Простой вопрос, сколько человек и на каком проекте будут заняты 18 недель? Или признайте, что вы взяли необоснованные цифры или дайте характеристики проекта и команды на 18 недель.
Иначе получается — мы решили, чтобы быть конкурентноспособными, озвучить средние по отрасли сроки, а потом будем пытаться им соответствовать (дедлайны, оутсорс и т.п.), так?IrynaKorkishko Автор
31.10.2017 16:42Почему вы просто не напишете, что вам нужна отдельная статья с примерами? Ведь для тех же 18 недель разработки, без учета прочих этапов вроде дизайна и планирования, может потребоваться от 3 до 10 разработчиков. Почему минимум 3? Потому что для сложного проекта потребуется минимум 1 фронтенд, 1 бекенд и 1 разработчик под конкретную мобильную платформу. Или два мобильных разработчика, к примеру, под две мобильные платформы: iOS и Android. Почему до десяти? Опять же, в зависимости от количества технологий, используемых в проекте. Или, скажем, если клиенту захочется создать нативные приложения под все возможные в мире платформы… Кто знает.
Для стартапа и простого проекта часто достаточно будет даже одного фуллстека (или двух разработчиков). Ну и времени — порядка 6 недель, максимум. При условии, что проект не требует каких-то сложных интеграций и технологий.
Повторяю, что количество ресурсов зависит от сложности проекта.
Например, для такого приложения, как показано на видео: https://vimeo.com/138268307, вам нужно будет 3-4 разработчика (плюс, дизайнер) и примерно 6 месяцев на весь проект. Вот здесь и получается 18 недель на фронтенд+бекенд. Остальное время идет на дизайн, планирование, тестирование и прочее.
Проект вроде этого https://play.google.com/store/apps/details?id=com.boxatwork.app&hl=en займет 9 месяцев, 5 разработчиков (в данном случае: 3 бекенда, 1 фронтенд и 1 мобильный разработчик), плюс дизайнер.
Здесь я не учитываю менеджера проекта и архитектора, если требуется (в большинстве случаев, можно обойтись без него).
dmitry_dvm
30.10.2017 20:45>до двух недель, чтобы добавить минимальные необходимые опции вроде логина и шеринга
Я, конечно, тоже любитель раздувать время для заказчика, но не до такой же степени. Тут работы на день.
Zibx
30.10.2017 21:40Подготовить базу, бэкэнд, фронтенд, дизайн, покрыть тестами, договориться с заказчиком и с командой, распределить и спланировать задачи, провести митинги, подвигать карточки на доске? Вполне может потянуть на две недели. Суть энтерпрайза не в продолжительных сроках, а в сохранении нервов.
А если бы делалось в одно лицо — действительно — на день работы.aquamakc
31.10.2017 09:03) провести митинги и подвигать карточки на доске — это да, задачи продолжительные.
А если серьёзно — именно так и бывает. Любая вроде бы мелочь в виде нового UI функционала, если не была заложена в архитектуру заранее может вылиться в суровый геморрой.
IrynaKorkishko Автор
31.10.2017 12:09Спасибо за ваш комментарий, но если вы утверждаете, что это на день работы, то ошибаетесь. День работы в данном случае возможен:
а) если вы просто берете готовый проект и выдаете за свое детище
б) халатно подготовились и выдали "тяп-ляп" в разработку
в) проект настолько простой, что там, впринципе, можно было обойтись и без разработчиков, дизайнеров, менеджеров… да и без проекта, наверное :)
г) если работы было на день, то в итоге, наверное, исправления и доработки займут пару месяцев
Я уже не раз сталкивалась с неправильной оценкой времени. Переоценка своих возможностей, недостаточный учет деталей и недооценка сложности разработки всегда приводила к не очень хорошему результату.
IrynaKorkishko Автор
31.10.2017 12:20Спасибо за ваш комментарий, но если вы утверждаете, что это на день работы, то ошибаетесь. День работы в данном случае возможен:
а) если вы просто берете готовый проект и выдаете за свое детище
б) халатно подготовились и выдали "тяп-ляп" в разработку
в) проект настолько простой, что там, впринципе, можно было обойтись и без разработчиков, дизайнеров, менеджеров… да и без проекта, наверное :)
г) если работы было на день, то в итоге, наверное, исправления и доработки займут пару месяцев
Я уже не раз сталкивалась с неправильной оценкой времени. Переоценка своих возможностей, недостаточный учет деталей и недооценка сложности разработки всегда приводила к не очень хорошему результату.
GDXRepo
30.10.2017 20:45Ой, нет-нет, только не так. На такое планирование я уже насмотрелся, особенно в аутсорсинговых компаниях. Итог у всех одинаково плачевный.
Планирование… может занять до нескольких недель.
А может и до нескольких месяцев. Сильно зависит от задачи и степени проработки целевого приложения, а также от количества людей, вовлеченных в разработку (включая ТЗ).
Определение функций и характеристик приложения… от трех до пяти недель
Нет, и еще раз нет. В большинстве проектов, особенно долгостроев, особенно аутсорсных, определение функций и характеристик продолжается вплоть до сдачи первого этапа приложения, а чаще всего — вплоть до завершения жизненного цикла проекта. Сильно зависит от заказчика и мастерства аналитиков, проводящих опрос клиента.
UI/UX дизайн… приблизительно, этап займет до двух недель
Только если у вас очень крутой дизайнер, превосходно знакомый с особенностями дизайна под мобильную платформу, для которой он рисует, а также очень сговорчивый заказчик. А все эти факторы в сочетании встречаются в 1% из всех случаев разработки. Чаще всего дизайн будет разработан «чтобы побыстрее и заказчик особо не орал», а потом будет допиливаться и закостыливаться уже со стороны мобильной разработки. Все это будет сопровождаться постоянными драками между дизайнером, разработчиками, менеджером и заказчиком.
Backend-разработка
Посмотрел диаграмму — настолько точные сроки по-любому соблюдены не будут, плюс это все крайне сильно варьируется в зависимости от задачи. Для некоторых проектов бек + фронт можно впилить за пару месяцев, а для некоторых — один бек может разрабатываться годами. Хотя само разбиение на этапную разработку относительно верное, но все равно будет (и должно) подвергаться корректировке со стороны разработки, а не со стороны менеджмента.
Есть данные о том, что разработка приложения на Android занимает на 20-30% больше времени, чем разработка для iOS.
Неверные данные. Такую цифру можно привести только при «прочих равных», т.е. если взять двух сферических разработчиков iOS и Android в вакууме, с одинаковым уровнем подготовки и квалификации по соответствующим платформам — а так не бывает. Мультиплатформенная разработка сильно зависит от уровня (и количества) разработчиков на той и другой платформе, а также от степени подготовки дизайна под конкретную платформу, плюс от количества косяков, ранее не обнаруженных в ТЗ, которые по специфике платформы сложны или невозможны в реализации. Как правило, всплывают подобные детали уже в процессе разработки.
Есть вероятность, что после запуска клиент захочет обновить или улучшить дизайн
100%. Всегда срабатывает.
Если ваше приложения интегрируется с социальными сетями, вам нужно добавить в тайминг для разработки до двух недель, чтобы добавить минимальные необходимые опции вроде логина и шеринга
Слишком абстрактно. Если только логин и примитивный шаринг, типа отсылки мессага стандартными средствами, то 2 недели для одной соцсети — слишком много, это делается за пару дней при условии наличия должного функционала на бекенде. Если сетей больше — то оценка слишком абстрактна, каждая соцсеть обладает своими нюансами. Это не говоря про то, что зачастую интеграция может быть запрошена значительно более глубокая, чем простой шаринг.
Прежде чем запустить готовый «вылизанный» продукт, советую лучше протестировать его в виде бета. После запуска пробной версии у вас будет достаточно данных для тестирования и улучшения продукта. В результате, готовый полноценный продукт будет качественнее, лучше и полноценнее.
Это в идеальном мире. В реальном происходит так: разработчикам говорят «наваяй нам на коленке прототип, чтобы было, тупо показать заказчику». А потом показывают заказчику, и он говорит, например, следующее: «Да, вот тут подрихтовать, тут подправить, а в целом — сойдет». И менеджер возвращается к разработчику со словами «ну норм, тут подрихтуем, тут заткнем, но мы, естественно, продолжаем разработку на базе этого прототипа — заказчик не понимает, почему он должен платить за разработку полноценного приложения, если уже есть прототип». И разработчикам приходится, громко (но про себя) матерясь, на базе прототипа (собранного, напомню, на коленке за минимальные сроки), из г… на и палок пытаться отстроить шикарный дворец с башенками. Итог, думаю, понятен. Либо никаких прототипов, либо с прототипом, на на прототип время закладываться должно ровно такое же (а лучше слегка побольше), как и на обычное качественное приложение с таким же функционалом.
почему бы не рассмотреть вариант с гибридным
Без комментариев. Кстати, анимация — далеко не самый важный показатель. Решите с заказчиком, что он хочет, и направьте силы разработки на конкретную платформу (или на обе). Не используйте гибриды, или потом будете вспоминать всю родню заказчика до седьмого колена (и разработки заодно, а они — вашу, по кругу).
Аутсорсинг — нужно ли расписывать преимущества данного подхода?
Да лучше бы расписать. Потому что минусов там существенно больше. Я работал во многих (и сотрудничал со многими) аутсорсными компаниями разной степени крутизны, везде подход к учету ресурсов и принимаемым проектам заканчивался для заказчика одинаково плачевным результатом. В силу специфики работы аутсорсных компаний. Где угодно — но не в разработке программного обеспечения. Иначе потом однажды вы пожалеете о своем решении, после чего пополните лагерь ненавистников системы аутсорсинга в сфере разработки ПО. Причем неважно, кто вы, — разработчик, менеджер или заказчик. Все рано или поздно понимают это, просто разной ценой.
Так зачем тратить на это время специалиста, если можно просто запустить автоматический тест
Ну да. Не считая того, что эти тесты тоже должен писать вполне себе определенный специалист, тратить на это вполне определенное время, и вообще, TDD/BDD — это отдельная схема разработки, требующая определенной квалификации и навыков. Автотесты из ниоткуда не берутся, и отнимают они тонну времени при грамотном подходе (да, польза тоже ощутимая, но мало какой заказчик готов за эту пользу платить — привет аутсорсингу).
Это все мое личное мнение, не более.IrynaKorkishko Автор
31.10.2017 12:57Благодарю вас за комментарий!
Он достаточно полезен и интересен. Ваше мнение имеет абсолютное право быть озвученным. Однако, складывается впечатление, что вам крупно не везло ни с коллегами, ни с заказчиками, ни с клиентами. Понятное дело, что идельной ситуации не будет никогда, но вы описываете действительно какой-то ад :)
В моей практике (не исключено, что мне повезло), клиенты знали, чего хотят (поэтому этот аспект я не рассматривала), дизайнеры и разработчики біли профессиональными (ведь вы сами вибираете, с кем работать). Зачем сотрудничать с дилетатнами или попросту ненадежными специалистами?
Поэтому моя статься берет за основу работу специалистов порядочных и профессиональных. И показывает, сколько времени займет разработка в нормальных условиях. Таких, как должно быть. Копромиссам в качестве здесь не место.
Что касается гибридов — да, я дейстительно предлагаю рассмотреть этот вариант в условиях органиченного времени. Если запустить приложение нужно срочно, то это -самый быстрый вариант. Конечно, если клиент изначально не ориентируется только на одну конкретную платформу. После запуска (плюс, приложение сможет показать основные баги со стороны взаимодействия с юзером) у вас будет время на разработку нативного варианта с учетом результатов, полученных после запуска гибрида. Опять же, этот вариант не подходит, если вы сотрудничаете с тяп-ляп разработчками. Им вообще лучше ничего не доверять. Но в моей статье речь не о них.
Подойду к вашему вопросу об аутсорсе. К примеру, у вас компания с пайтон разработчиками. А технология, которую захотел клиент (либо определил архитектор / сео и так далее) — другая. И вы можете покрыть своими силами только часть работ. И, поверьте, обучать своих специалистов новой технологии, да еще и на реальном проекте, который горит, — не очень хорошая идея. Это будет дольше, дороже, и хуже. Качество работ на технологиях, с которыми ваши специалисты ранее не были знакомы — отнюдь не впечатляет. Возможно, из-за этого и складывается впечатление о недостаточном уровне и профессионализме ряда компаний, ведь они экспериментируют на заказчике.
Поэтому, почему бы не дать вашим специалистам оставаться профи в своем сегменте и не заставлять срочно менять амплуа? Здесь необходим аутсорс. Еще раз, чем это может быть полезно:
- Каждый занимается своим делом, тем, что хорошо умеет (опять же, мы не говорим о халатных специалистах)
- Мы економим время, ставя процесы разработки в паралель: вы делаете свою работу, пока аутсорс-компания делает свою. К тому же, люди, имеющие опыт в конкретной технологии, смогут работать намного быстрее и продуктивнее, нежели ваши специалисты, кторые только учат что-то
- Опять же, те, кто в курсе (кто работает давно с какой-то технологией), знают хаки, имеют опыт и могут применить последние новинки. Это позволит проекту иметь в арсенале последние технологии
- Вам не нужно распыляться, вы можете сами стать более эффективными и быстрее выдавать свою часть работы
Теперь про автотесты. Безусловно, их пишут программисты. Безусловно, они тратят время на написание этих тестов. Однако, нужно автоматизировать все, что позволено автоматизировать без потери качетсва. Зачем же садить программиста прогонять тест (который он же написал, и который можно применить еще много раз для других участков), если его достаточно просто запустить и перейти к задаче, где нужно думать и писать?
Вот, вкратце, мои ответы. Еще раз благодарна вам за ваш комментарий!
GDXRepo
31.10.2017 17:06Не за что, рад, если будет полезно. Только порадоваться за вас, если вы нашли ту самую идеальную аутсорсную компанию) Остался вопрос к вам, если не секрет: давно ли вы работаете в этой области, в частности, с аутсорсом? Если меньше пяти лет — то у вас еще все впереди))) Но желаю, конечно, чтобы вам попадались только такие же хорошие компании.
IrynaKorkishko Автор
31.10.2017 18:18Спасибо! С аутсорсом работаю уже больше пяти лет. Правда, сначала больше в диджитале и производстве интернет-рекламы, а уже позже — в IT. На самом деле, согласна с тем, что многое зависит от того, как вам повезет в подборе аутсорс компании. В любом случае, к этому вопросу всегда нужно подходить тщательно: кроме рекомендаций, ознакомиться желательно и с офисом, самой командой. Тогда сложится полное впечатление и можно будет принимать решение, стоит ли доверять этим людям.
vburmistrov
31.10.2017 11:09+1Здравствуйте!
Я решил выйти из тени и честно сказать, почему я поставил минус.
В целом материал имеет право на существование и полезен, как версия дорожной карты.
Но вот с высказыванием в пункте 4. Аутсорсинг,
я категорически не согласен.
Звучит так, что экспертиза и профессионализм у аутсорсинга всегда выше, чем у собственной команды. Это спорно.
Не обучать свою команду, вернее даже не так, не дать своей команде возможности для самообучения на данном проекте. Якобы с целью экономии времени, сил и денег. Так же спорно.
Во-первых, часто оплата одного стороннего разработчика в день в разы выше оплаты трудодня собственного разработчика.
Во вторых, вместо того что бы один раз обучить свою команду, в будущем потратите дважды на аутсорсинг, где экономия?
Ну и в третьих, Вы в своей компании кем работаете, аналитик, технолог, менеджер? А как Вам будет такой подход: экспертиза и профессионализм, иногда лучше нанять стороннего более эффективного менеджера, аналитика, который сможет лучше организовать процессы и команду?IrynaKorkishko Автор
31.10.2017 13:22Здравствуйте! Спасибо за честность и за комментарий.
В общем, материал и был запланирован изначально как дорожная карта. Поэтому отвечаю на все комментарии и объясняю спорные моменты.
Итак, аутсорс :)
Выше я уже ответила на подобный вопрос про аутсорс и привела небольшой пример. И я уверена, что обучить свою команду новой технологии в сжатые сроки вам точно не будет выгодно, еще и на реальном проекте. Возможность самообучения никто не отменял, но это не должно влиять на качество продукта. Поэтому, рекомендую браться за те проекты, в которых у вас уже есть экспертиза (и паралелно учить что-то новое, почему нет?). А то, в чем вы плохо ориентируетесь — поручить тем, кто является профессионалом в данной сфере. Это же элементарно.
Пример слишком припитивный, но наглядный: если у пациента сломана нога, то не стоит вести его к окулисту и ждать, пока тот научится хирургии на нем же, на пациенте. Пусть уж лучше окулист пройдет обучение, практику, получит диплом про переквалификацию, займется хирургией, и тогда уже будет лечить переломы. Но не на этом пациенте, которому вмешательство нужно срочно. Значит, пациента окулист должен переправить к своему коллеге — хирургу. Желательно, профессиональному. Понимаете, о чем я?
Теперь примените все это к разработке приложений. Пускай, это не так серьезно, как здоровье пациента, но провести параллель можно.
Теперь по пунктам:
- Конечно, аутсорс стоит денег. Но вы ведь не вслепую работаете? У вас есть бюджет, который на этапе планирования и опеределения технологий должен включать опцию аутсорса и затрат на него. Клиент также должен быть в курсе.
И поверьте, ваш разработчик, который будет учиться во время работы, потратит больше времени, и в результате, обойдется дороже. Пускай эти деньги останутся в компании, но клиенту увеличение времени на разработку точно не понравится, поэтому он вряд ли придет к вам во второй раз. - Вы можете учить свою команду всегда. Но не на реальном проекте, еще раз повторяю (мне хочется подчеркнуть этот момент). После достаточной практики, тренингов, курсов, мелких пробных проектов, овладев технологией на хорошем уровне, команда может взяться за проект самостоятельно, без привлечения аутсорса. Но только тогда, когда станет "уверенным, либо опытным хирургом". Зачем зарабатывать себе плохую репутацию и отпугивать клиентов?
В этом и есть економия — вы будете иметь клиентов, уверенных в качетве работы. Один раз секономить и создать что-то ужасное означает лишиться работы в будущем. Вот и вся экономия. - Про то, что нужно нанимать более профессионального человека, я с вами абсолютно согласна.
Но здесь другая ситуация. Поэтому, не стоит сравнивать дельфина с орлом :). Аутсорс-команду вы нанимаете на проект, а аналитика / менеджера / технолога в свою команию — надолго, с глубоким погружением. Поэму тут два варианта (и оба без аутсорса): учить или нанимать профи. Желательно, конечно, нанимать профи. Но и, даже если вы будете учить этого спечиалиста, риски в данном случае — несравнимы и рисками при обучении разработчиков на реальном проекте.
Надеюсь, я смогла ответить на ваши вопросы. Спасибо еще раз за комментарий!
Implozia
02.11.2017 14:08Боже мой, такое количество грамматических и пунктуационных ошибок — ставят каждое Ваше слово под сомнение. Такое чувство, что Вы написали данную статью в торопя — чисто для галочки в своем резюме.
- Конечно, аутсорс стоит денег. Но вы ведь не вслепую работаете? У вас есть бюджет, который на этапе планирования и опеределения технологий должен включать опцию аутсорса и затрат на него. Клиент также должен быть в курсе.
IrynaKorkishko Автор
02.11.2017 15:43Здравствуйте! А мне кажется, что вам просто захотелось написать комментарий для галочки. Поскольку, ваша ремарка к статье не относится. Увы.
Ну и, к слову, такие комментарии, как ваш, наверное, даже больше веселят, чем печалят. Забавно, когда люди комментируют не тему публикации, а грамматические ошибки. Зачем вы вообще пишете в данную тему, если вам в рубрику "пунктуация, грамматика, ошибки"?Implozia
03.11.2017 12:46Качество статьи, в том числе, определяется и отношением автора к ней. Если Вы не удосужились — банально проверить свою статью на грамматику и пунктуацию — это о Вас уже многое говорит, а если Вы даже и не в курсе где ошибаетесь — то это совсем плачевно, и от этого Ваши слова ставятся под сомнение еще больше. К статье это относится на прямую, это вам не двач, а все-таки довольно уважаемый информационный ресурс, так уважайте же и читателей.
IrynaKorkishko Автор
03.11.2017 13:01-1В таком случае, укажите, пожалуйста, мои ошибки. Поскольку проверка орфографии проводилась. И мне неприятно слышать о том, что я не уважаю своих читателей. Это абсурд.
Тем более, мне неприятно обсуждать в комментариях статьи не сам материал, который скрупулезно собирался и проверялся, а орфографию. Желание поделиться чем-то действительно полезным сыграло со мной злую шутку.
Слышать о том, что мои слова ставятся под сомнение, — к тому же, из-за орфографии, что совершенно необоснованно, — даже смешно. Интересно, как орфография влияет на этапы разработки мобильного приложения? Озвучьте, пожалуйста, примеры. Если они у вас есть.
П.с. Что касается "уважаемого ресурса", есть сомнения. Ни на одном другом ресурсе я не встретила столько агрессии и комментариев, которые настолько далеки от темы материала...Implozia
03.11.2017 16:23По поводу материала Вам тоже уже ответили. Совершенно нету конкретики, все на уровне каких-то абстрактных рассуждений. Не знаю, если честно, что вы скрупулезно собирали, такое чувство, что цифры взяты с потолка, в Вашем примере — «Для наглядности», к примеру хотя бы, оставляет одни вопросы — что за такой «тип приложения», что вы подразумеваете под приложением, сколько человек и в каком отделе работало, по какому принципу были организованны этапы разработки, сколько ушло на бэкэнд, на фронтэнд, тестирование bugfix'ы? И т.д и т.п. Если приводите примеры — дайте конкретные цифры, а не абстрактные «из головы», а если бы еще было обоснование почему так «быстро», или как можно было бы улучшить процесс, если медленно, в каком из отделов, к примеру.В общем, у Вас, по большому счету, даже не «вода» а какая-то «пустошь» в статье, отсюда и реакция читателей такая.
IrynaKorkishko Автор
03.11.2017 17:16Примеры я привела выше, в комментариях. Читайте. Опять же, это не та тема, которую вы так упорно хотите прокомментировать и поставить очередной минус. Если вы хотите информации о ресурсах, здесь нужна одна большая статья про то, как мы разрабатывали конкретный проект: и методы, и сроки, и технологии. Это отдельная обширная тема. Еще раз повторяю, что данный материал не имел цели рассказать о ресурсах (как и о методах разработки). Это, скорее, дорожная карта для тех, кто собирается заниматься разработкой мобильного приложения и хочет предварительно понять, сколько времени может уйти на это. Предварительно.
Тем не менее пример я привела. Будьте более внимательны.
Про то, как можно ускорить процесс разработки, я также написала.
По поводу реакции читателей — это не оценка статьи, это сплошное желание спорить (а я очень не люблю несправедливость и необоснованные обвинения), критиковать и придираться. Особенно это неприятно и непонятно, когда стараешься.
Если это не так, то почему пользователи комментируют не порядок разработки или возможные способы сокращения времени на создание приложения, а орфографию (причем, напрасно) и отсутствие примеров (ну нет их в этой статье, так зачем комментировать их?). Почему их нет, я уже неоднократно упоминала. Тем не менее примеры подала. Однако, желание травить, оказалось выше :).
lingvo
03.11.2017 18:42Статья информативна с точки зрения определения этапов разработки, но совсем неинформативна по срокам. Их лучше было бы убрать вообще, или перевести в человеко*месяцы. Тогда сразу становится понятно, что 18 человеко-месяцев = 1,5 года, если над проектом будет трудиться один человек или =6 месяцев, если будет трудиться трое. А конкретные сроки указывать только там, где они не зависят от количества ресурсов. Например "Ревью и публикация приложения в App Store" — четыре недели, если проходим с первого раза.
Это ж основы проект-менеджмента, зачем их игнорировать?
IrynaKorkishko Автор
03.11.2017 19:27"Человеко-месяцы" — это хорошее решение. Но для этого, опять же, нужно писать совершенно другую статью: в основе конкретный кейс, для него прописать все этапы разработки, специалистов и время, выраженное в человеко-часах. Моя статья носит обобщенный характер и, действительно, делает упор больше на стадии разработки.
lingvo
03.11.2017 20:27Ну вы поймите — вот вы тоже пишите — такое-то приложение займет 6 месяцев на создание, а вот это — 4,5 месяца.
И представьте себе кейс: приходит заказчик и вы ему говорите — создание вашего приложения займет 6 месяцев и будет стоить условно 100к$. А заказчик Вам говорит — давайте я вам дам 200к, но вы сделаете это приложение за 4 месяца. И что вы ему ответите? Пошлете и скажете, что он не прав?
ProgrammerMicrosoft
«Надеюсь, этот материал будет вам полезен!»
Однозначно :)
Исправьте опечатку «В этой статье, исходя их опыта компании»
IrynaKorkishko Автор
Исправляю! Благодарю! :)