[Разработка мобильных приложений] Тупые способы сэкономить на мобильной разработке
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Здесь я собрала грабли, на которые можно наступить при разработке приложения. С этих граблей мы снимали несколько проекты, но подозреваю есть еще. Если знаете – дополняйте. Маркетологи, продавшие душу дьяволу за ежемесячное выполнение KPI и миндальный капучино, могут убеждать вас сколь угодно долго, что создание мобильного приложения – это быстро, дешево, легко и непринужденно. Но мы будем честны и признаемся сразу – создание полноценного приложения с учетом особенностей бизнеса не будет простым и легким, не может быть дешевым и быстрым, а если верить в чудеса и вообще всему, что пишут в интернете, то может оказаться еще и грустным и болезненным.Большая красивая модная аппликуха, магнитом притягивающая новых клиентов и не отпускающая старых, аддиктивная как героин и быстрая как феррари, полезная, клевая и работоспособная как азиатские школьники – это всегда много-много работы. Работа, она только в школе равняется силе, помноженной на пройденный путь. В бизнесе – это всегда деньги, помноженные на время.С одной стороны все это как бы понимают. С другой – ну бюджеты же тоже не резиновые, ну. Поэтому на лице любого руководителя любого звена при виде сметы всегда читается «где бы тут сэкономить, а?» И часто результатом этих размышлений являются максимально фиговые решения, которые в итоге приводят весь проект к тупику, вовлеченных в него людей – к депрессии и злоупотреблениям по пятницам, бюджет – к раздуванию за счет экстренного латания дыр, а менеджмент – к цитированию русской классики про «не гонялся бы ты поп за дешевизной».
Давайте мы в паре слов обрисуем, как это происходит. 1. А давайте отдадим проект в ООО «Рога и Копыта»! Выбор подрядчика, основываясь только на ценовой политике – это порочная практика вне зависимости от того, чем вы занимаетесь: ищите IT-специалистов или мандарины на рынке.Дешевые мандарины могут оказаться подгнившими, а дешевые программисты, наоборот, слишком недозрелыми. На рынке сейчас достаточно много компаний, укомплектовывающих свой штат студентами, фрилансерами с минимальным опытом работы и вообще, недоквалифицированными ребятами всех сортов.Конечно, во время обсуждения деталей проекта, подписания контракта и внесения правок именно с программистами вы общаться не будете, да и мало у кого есть возможность оценить уровень скиллованности нанимаемых технических специалистов. Но давайте запомним – хороший программист не может стоить дешево. Поэтому если вам предлагают что-то критично ниже рынка – скорее всего, те мандарины с гнильцой.
Есть свои хитрости и в выборе свежих фруктов и в поиске квалифицированных команд. Про то, как выбрать хорошего подрядчика и не облажаться, расскажем в одном из следующих текстов. Про фрукты – уточняйте на рынке.От себя можем лишь заметить, что неквалифицированный менеджер способен угробить работу и нервную систему самой крутой команды разработки, поэтому, как правило, клевые программисты с плохими менеджерами не уживаются. Так что обращайте внимание на профессионализм всех, с кем работаете.2. Да ну их нафиг, этих программистов, давайте купим готовое приложение, там все есть!Мы уже писали подробно о том, в чем коварство «коробочных» приложений, написанных неизвестно кем, непонятно когда, для неопределенного количества пользователей.Если вкратце – за качество там никто не отвечает. За то, что решение подойдет именно вашему бизнесу – никто не отвечает. За то, что если нужно будет прикрутить новый функционал и расширить приложение, это будет возможно – никто не отвечает. За то, что поддержка коробочки будет существовать какое-то продолжительное время – никто не отвечает.В этом прекрасном безответном мире так или иначе большинство компаний приходят к тому, что к черту эту коробочку с набором напильничков, давайте напишем все с нуля и под себя.3. А пусть сервер будет на нашей стороне, это ж в два раза меньше проблем и денег!Ох, заиньки. Ох, милые. Нет. Это никогда не будет «меньше проблем». Ни вашим, ни нашим.Как это обычно бывает. У вас есть айти отдел. Ну или у вас есть Макс-Программист. И в том и в другом случае у них есть какие-то свои задачи, с которыми они как-то справляются. Они получают за это деньги, компания получает работающий без сбоев Exchange, корпоративный портал или бухгалтеров, которые знают, куда звонить, если принтер не печатает.Тут приходите вы и говорите: «Теперь, Макс-Программист, ты не просто Макс-Программист, ты нам еще серверную часть мобильного приложения пишешь!».
В лучшем случае, Макс честно признается, что он вообще не в курсе что это и с чем это пьют и откажется. В худшем – согласится и начнет гуглить.В случае с полноценным айти отделом, шансов у ребят слиться еще меньше. И они берутся за поставленную задачу. А дальше начинается подлинное великолепие. Конечно, человек, или группа людей до этого не влезавшие в предметную область, будут, мягко говоря, менее эффективными, чем люди, для которых эта область является основной, профессиональной. По-простому если – они будут тупить и лажать, лажать и тупить. У проекта тем временем будут срываться и срываться сроки.Сторона подрядчика, которого вы наняли писать все остальное, будет закидывать письмами, правками, а иногда мольбами и угрозами ваших спецов, на что они будут тупить и лажать еще быстрее и супер-эффективней. Подрядчик не сможет адекватно работать и внедрять то, что должно быть внедрено, и оперативно убирать то, что должно быть убрано. Теряется быстрота реакций, возможность маневра, широта эксперимента, а главное – совершенно нет возможности взять трубку и наорать на бекэндчиков, ибо бэкенд в данном случае – на стороне клиента.
Невозможно уволить к чертовой матери разгильдяя или дурака, если разгильдяй или дурак на вас не работает.
Но даже если вдруг так получилось, что ваш айти отдел – лучший на свете, а Макс-Программист – врожденный создатель бэкенда, то, во-первых, люди иногда ходят в отпуска, болеют и увольняются. Если это случается на вашей стороне – то это наша проблема, которую мы не можем решить. И мы снова простаиваем, теряя время, деньги и нервы. А, во-вторых, вы же не зря столько лет держали всех этих прекрасных людей в штате? Они же у вас что-то делали там? Кто будет выполнять эту работу, пока они вдохновленно ваяют серверную часть? Ах, они же? А кто будет работать с подрядчиком в команде, пока Макс чинит принтер, а все остальные поднимают упавший скуль? Ах, все одновременно... А какое будет качество работы и сколько все это займет времени? Вот то то же.4. А давайте использовать кроссплатформенные движки?Бога ради, не делайте этого.Если только у вас цель создать что-то такое, что будет одинаково хреново работать, вылетать и глючить и на андроиде и на айос – тогда пожалуйста. В остальных случаях – НЕТ.Ну, окей. Есть еще один кейс, когда кроссплатформа – наш бро. Если у вас есть идея и вам СРОЧНО нужно ее проверить, и вы готовы в случае, если «взлетит» потом переписать все нативно. Окей.Кроссплатформы не способны масштабироваться, вы не получите полноценный продукт, который можно развивать. Так, посмотреть-поиграться на пару месяцев – да. Но серьезно работать можно только с нативом.Ну, окей, в каждом правиле есть исключения и в природе встречаются качественные кроссплатформы, написанные маститыми сеньорами. Вот как в Яндексе. И они работают. (Стоят правда тоже не так, чтобы очень демократично, но все же). Но вы готовы полагаться на случай и надеяться попасть в 5% успешных кейсов? 5. А давайте забьем на тестирование? А потом всем отделом директоров возьмем вилки и засунем их в розетки!Да, мы понимаем, что те рекомендации тестирования, которые описаны в гайдлайнах часто невыполнимы. Да, мы понимаем, что если делать все по уму, то тестирование сожрет даже не половину, а большую часть бюджета. Да, мы понимаем, что покрыть весь проект автотестами, функциональным и нагрузочным тестированием часто бывает невозможным.
НО. То, что почти все забивают на технику безопасности не значит, что она не написана кровью.
Вы можете вложить немыслимый бюджет в разработку, нанять лучших на свете дизайнеров, провести такой аудит рынка, что чуваки с Уолл Стрит будут тусить у вас в приемной и спрашивать совета, куда акции девать. Все будет зашибись. Но, если вы не отловили критический баг и при запуске приложения оказалось, что оно вылетает у половины пользователей – вы мало того, что слили кучу денег в унитаз, вы еще и получили репутационный ущерб такого масштаба, что вам от него не отмыться никогда.
Ребят, тестировать надо. Хотя бы минимально, хотя бы не очень глубоко. Если у вас совсем кончаются бюджеты – оставьте достаточное количество времени на фазу тестирования. Поверьте, отсутствие нормального системного тестирования потом выльется в такие деньги, что вы проклянете тот день, когда вас надоумило махнуть рукой в стиле «и так сойдет».Простите, если сейчас получилось больно, но в следующей статье, обещаю, будет обезболивающее в виде четырех вариантов разумной экономии. И разумной, и безболезненной.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Разработка под iOS, Разработка мобильных приложений, Swift] Как мы ускоряли работу отладчика Swift
- [Java, Разработка мобильных приложений, Разработка под Android, Kotlin] Android — ViewPager2 — заменяем фрагменты на лету (программно)
- [Высокая производительность, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android] Как мы ускорили запуск приложения Dropbox для Android на 30 % (перевод)
- [Клиентская оптимизация, Разработка мобильных приложений, Микросервисы] Платформа по работе с обращениями клиентов в «Пятёрочке»
- [Программирование, Разработка мобильных приложений, Разработка под Android, Kotlin] Влияние data-классов на вес приложения
- [Разработка мобильных приложений, Управление продуктом, IT-компании] Ничего не будет: ни приложений, ни мобильных сайтов — одни супераппы
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android] Кроссплатформенная мобильная разработка: история вопроса
- [Разработка мобильных приложений, Алгоритмы] Навигатор для пешеходов
- [Разработка мобильных приложений, Разработка игр, Дизайн игр, Игры и игровые приставки] Как мы «вырастили» и победили читеров в своем онлайн-шутере
- [Программирование, Разработка мобильных приложений, Rust] Запускаем Rust-приложение на мобильной ОС Аврора
Теги для поиска: #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_mobilnaja_razrabotka (мобильная разработка), #_razrabotka_mobilnyh_prilozhenija (разработка мобильных приложения), #_ekonomija (экономия), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:56
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Здесь я собрала грабли, на которые можно наступить при разработке приложения. С этих граблей мы снимали несколько проекты, но подозреваю есть еще. Если знаете – дополняйте. Маркетологи, продавшие душу дьяволу за ежемесячное выполнение KPI и миндальный капучино, могут убеждать вас сколь угодно долго, что создание мобильного приложения – это быстро, дешево, легко и непринужденно. Но мы будем честны и признаемся сразу – создание полноценного приложения с учетом особенностей бизнеса не будет простым и легким, не может быть дешевым и быстрым, а если верить в чудеса и вообще всему, что пишут в интернете, то может оказаться еще и грустным и болезненным.Большая красивая модная аппликуха, магнитом притягивающая новых клиентов и не отпускающая старых, аддиктивная как героин и быстрая как феррари, полезная, клевая и работоспособная как азиатские школьники – это всегда много-много работы. Работа, она только в школе равняется силе, помноженной на пройденный путь. В бизнесе – это всегда деньги, помноженные на время.С одной стороны все это как бы понимают. С другой – ну бюджеты же тоже не резиновые, ну. Поэтому на лице любого руководителя любого звена при виде сметы всегда читается «где бы тут сэкономить, а?» И часто результатом этих размышлений являются максимально фиговые решения, которые в итоге приводят весь проект к тупику, вовлеченных в него людей – к депрессии и злоупотреблениям по пятницам, бюджет – к раздуванию за счет экстренного латания дыр, а менеджмент – к цитированию русской классики про «не гонялся бы ты поп за дешевизной». Давайте мы в паре слов обрисуем, как это происходит. 1. А давайте отдадим проект в ООО «Рога и Копыта»! Выбор подрядчика, основываясь только на ценовой политике – это порочная практика вне зависимости от того, чем вы занимаетесь: ищите IT-специалистов или мандарины на рынке.Дешевые мандарины могут оказаться подгнившими, а дешевые программисты, наоборот, слишком недозрелыми. На рынке сейчас достаточно много компаний, укомплектовывающих свой штат студентами, фрилансерами с минимальным опытом работы и вообще, недоквалифицированными ребятами всех сортов.Конечно, во время обсуждения деталей проекта, подписания контракта и внесения правок именно с программистами вы общаться не будете, да и мало у кого есть возможность оценить уровень скиллованности нанимаемых технических специалистов. Но давайте запомним – хороший программист не может стоить дешево. Поэтому если вам предлагают что-то критично ниже рынка – скорее всего, те мандарины с гнильцой. Есть свои хитрости и в выборе свежих фруктов и в поиске квалифицированных команд. Про то, как выбрать хорошего подрядчика и не облажаться, расскажем в одном из следующих текстов. Про фрукты – уточняйте на рынке.От себя можем лишь заметить, что неквалифицированный менеджер способен угробить работу и нервную систему самой крутой команды разработки, поэтому, как правило, клевые программисты с плохими менеджерами не уживаются. Так что обращайте внимание на профессионализм всех, с кем работаете.2. Да ну их нафиг, этих программистов, давайте купим готовое приложение, там все есть!Мы уже писали подробно о том, в чем коварство «коробочных» приложений, написанных неизвестно кем, непонятно когда, для неопределенного количества пользователей.Если вкратце – за качество там никто не отвечает. За то, что решение подойдет именно вашему бизнесу – никто не отвечает. За то, что если нужно будет прикрутить новый функционал и расширить приложение, это будет возможно – никто не отвечает. За то, что поддержка коробочки будет существовать какое-то продолжительное время – никто не отвечает.В этом прекрасном безответном мире так или иначе большинство компаний приходят к тому, что к черту эту коробочку с набором напильничков, давайте напишем все с нуля и под себя.3. А пусть сервер будет на нашей стороне, это ж в два раза меньше проблем и денег!Ох, заиньки. Ох, милые. Нет. Это никогда не будет «меньше проблем». Ни вашим, ни нашим.Как это обычно бывает. У вас есть айти отдел. Ну или у вас есть Макс-Программист. И в том и в другом случае у них есть какие-то свои задачи, с которыми они как-то справляются. Они получают за это деньги, компания получает работающий без сбоев Exchange, корпоративный портал или бухгалтеров, которые знают, куда звонить, если принтер не печатает.Тут приходите вы и говорите: «Теперь, Макс-Программист, ты не просто Макс-Программист, ты нам еще серверную часть мобильного приложения пишешь!». В лучшем случае, Макс честно признается, что он вообще не в курсе что это и с чем это пьют и откажется. В худшем – согласится и начнет гуглить.В случае с полноценным айти отделом, шансов у ребят слиться еще меньше. И они берутся за поставленную задачу. А дальше начинается подлинное великолепие. Конечно, человек, или группа людей до этого не влезавшие в предметную область, будут, мягко говоря, менее эффективными, чем люди, для которых эта область является основной, профессиональной. По-простому если – они будут тупить и лажать, лажать и тупить. У проекта тем временем будут срываться и срываться сроки.Сторона подрядчика, которого вы наняли писать все остальное, будет закидывать письмами, правками, а иногда мольбами и угрозами ваших спецов, на что они будут тупить и лажать еще быстрее и супер-эффективней. Подрядчик не сможет адекватно работать и внедрять то, что должно быть внедрено, и оперативно убирать то, что должно быть убрано. Теряется быстрота реакций, возможность маневра, широта эксперимента, а главное – совершенно нет возможности взять трубку и наорать на бекэндчиков, ибо бэкенд в данном случае – на стороне клиента. Невозможно уволить к чертовой матери разгильдяя или дурака, если разгильдяй или дурак на вас не работает.
НО. То, что почти все забивают на технику безопасности не значит, что она не написана кровью.
Ребят, тестировать надо. Хотя бы минимально, хотя бы не очень глубоко. Если у вас совсем кончаются бюджеты – оставьте достаточное количество времени на фазу тестирования. Поверьте, отсутствие нормального системного тестирования потом выльется в такие деньги, что вы проклянете тот день, когда вас надоумило махнуть рукой в стиле «и так сойдет».Простите, если сейчас получилось больно, но в следующей статье, обещаю, будет обезболивающее в виде четырех вариантов разумной экономии. И разумной, и безболезненной. =========== Источник: habr.com =========== Похожие новости:
Разработка мобильных приложений ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:56
Часовой пояс: UTC + 5