Тупые способы сэкономить на мобильной разработке
Здесь я собрала грабли, на которые можно наступить при разработке приложения. С этих граблей мы снимали несколько проекты, но подозреваю есть еще. Если знаете — дополняйте.
Маркетологи, продавшие душу дьяволу за ежемесячное выполнение KPI и миндальный капучино, могут убеждать вас сколь угодно долго, что создание мобильного приложения — это быстро, дешево, легко и непринужденно. Но мы будем честны и признаемся сразу — создание полноценного приложения с учетом особенностей бизнеса не будет простым и легким, не может быть дешевым и быстрым, а если верить в чудеса и вообще всему, что пишут в интернете, то может оказаться еще и грустным и болезненным.
Большая красивая модная аппликуха, магнитом притягивающая новых клиентов и не отпускающая старых, аддиктивная как героин и быстрая как феррари, полезная, клевая и работоспособная как азиатские школьники — это всегда много-много работы. Работа, она только в школе равняется силе, помноженной на пройденный путь. В бизнесе — это всегда деньги, помноженные на время.
С одной стороны все это как бы понимают. С другой — ну бюджеты же тоже не резиновые, ну. Поэтому на лице любого руководителя любого звена при виде сметы всегда читается «где бы тут сэкономить, а?» И часто результатом этих размышлений являются максимально фиговые решения, которые в итоге приводят весь проект к тупику, вовлеченных в него людей — к депрессии и злоупотреблениям по пятницам, бюджет — к раздуванию за счет экстренного латания дыр, а менеджмент — к цитированию русской классики про «не гонялся бы ты поп за дешевизной».
Давайте мы в паре слов обрисуем, как это происходит.
1. А давайте отдадим проект в ООО «Рога и Копыта»!
Выбор подрядчика, основываясь только на ценовой политике — это порочная практика вне зависимости от того, чем вы занимаетесь: ищите IT-специалистов или мандарины на рынке.
Дешевые мандарины могут оказаться подгнившими, а дешевые программисты, наоборот, слишком недозрелыми. На рынке сейчас достаточно много компаний, укомплектовывающих свой штат студентами, фрилансерами с минимальным опытом работы и вообще, недоквалифицированными ребятами всех сортов.
Конечно, во время обсуждения деталей проекта, подписания контракта и внесения правок именно с программистами вы общаться не будете, да и мало у кого есть возможность оценить уровень скиллованности нанимаемых технических специалистов. Но давайте запомним — хороший программист не может стоить дешево. Поэтому если вам предлагают что-то критично ниже рынка — скорее всего, те мандарины с гнильцой.
Есть свои хитрости и в выборе свежих фруктов и в поиске квалифицированных команд. Про то, как выбрать хорошего подрядчика и не облажаться, расскажем в одном из следующих текстов. Про фрукты — уточняйте на рынке.
От себя можем лишь заметить, что неквалифицированный менеджер способен угробить работу и нервную систему самой крутой команды разработки, поэтому, как правило, клевые программисты с плохими менеджерами не уживаются. Так что обращайте внимание на профессионализм всех, с кем работаете.
2. Да ну их нафиг, этих программистов, давайте купим готовое приложение, там все есть!
Мы уже писали подробно о том, в чем коварство «коробочных» приложений, написанных неизвестно кем, непонятно когда, для неопределенного количества пользователей.
Если вкратце — за качество там никто не отвечает. За то, что решение подойдет именно вашему бизнесу — никто не отвечает. За то, что если нужно будет прикрутить новый функционал и расширить приложение, это будет возможно — никто не отвечает. За то, что поддержка коробочки будет существовать какое-то продолжительное время — никто не отвечает.
В этом прекрасном безответном мире так или иначе большинство компаний приходят к тому, что к черту эту коробочку с набором напильничков, давайте напишем все с нуля и под себя.
3. А пусть сервер будет на нашей стороне, это ж в два раза меньше проблем и денег!
Ох, заиньки. Ох, милые. Нет. Это никогда не будет «меньше проблем». Ни вашим, ни нашим.
Как это обычно бывает. У вас есть айти отдел. Ну или у вас есть Макс-Программист. И в том и в другом случае у них есть какие-то свои задачи, с которыми они как-то справляются. Они получают за это деньги, компания получает работающий без сбоев Exchange, корпоративный портал или бухгалтеров, которые знают, куда звонить, если принтер не печатает.
Тут приходите вы и говорите: «Теперь, Макс-Программист, ты не просто Макс-Программист, ты нам еще серверную часть мобильного приложения пишешь!».
В лучшем случае, Макс честно признается, что он вообще не в курсе что это и с чем это пьют и откажется. В худшем — согласится и начнет гуглить.
В случае с полноценным айти отделом, шансов у ребят слиться еще меньше. И они берутся за поставленную задачу. А дальше начинается подлинное великолепие. Конечно, человек, или группа людей до этого не влезавшие в предметную область, будут, мягко говоря, менее эффективными, чем люди, для которых эта область является основной, профессиональной. По-простому если — они будут тупить и лажать, лажать и тупить. У проекта тем временем будут срываться и срываться сроки.
Сторона подрядчика, которого вы наняли писать все остальное, будет закидывать письмами, правками, а иногда мольбами и угрозами ваших спецов, на что они будут тупить и лажать еще быстрее и супер-эффективней. Подрядчик не сможет адекватно работать и внедрять то, что должно быть внедрено, и оперативно убирать то, что должно быть убрано. Теряется быстрота реакций, возможность маневра, широта эксперимента, а главное — совершенно нет возможности взять трубку и наорать на бекэндчиков, ибо бэкенд в данном случае — на стороне клиента.
Невозможно уволить к чертовой матери разгильдяя или дурака, если разгильдяй или дурак на вас не работает.
Но даже если вдруг так получилось, что ваш айти отдел — лучший на свете, а Макс-Программист — врожденный создатель бэкенда, то, во-первых, люди иногда ходят в отпуска, болеют и увольняются. Если это случается на вашей стороне — то это наша проблема, которую мы не можем решить. И мы снова простаиваем, теряя время, деньги и нервы. А, во-вторых, вы же не зря столько лет держали всех этих прекрасных людей в штате? Они же у вас что-то делали там? Кто будет выполнять эту работу, пока они вдохновленно ваяют серверную часть? Ах, они же? А кто будет работать с подрядчиком в команде, пока Макс чинит принтер, а все остальные поднимают упавший скуль? Ах, все одновременно… А какое будет качество работы и сколько все это займет времени? Вот то то же.
4. А давайте использовать кроссплатформенные движки?
Бога ради, не делайте этого.
Если только у вас цель создать что-то такое, что будет одинаково хреново работать, вылетать и глючить и на андроиде и на айос — тогда пожалуйста. В остальных случаях — НЕТ.
Ну, окей. Есть еще один кейс, когда кроссплатформа — наш бро. Если у вас есть идея и вам СРОЧНО нужно ее проверить, и вы готовы в случае, если «взлетит» потом переписать все нативно. Окей.Кроссплатформы не способны масштабироваться, вы не получите полноценный продукт, который можно развивать. Так, посмотреть-поиграться на пару месяцев — да. Но серьезно работать можно только с нативом.
Ну, окей, в каждом правиле есть исключения и в природе встречаются качественные кроссплатформы, написанные маститыми сеньорами. Вот как в Яндексе. И они работают. (Стоят правда тоже не так, чтобы очень демократично, но все же). Но вы готовы полагаться на случай и надеяться попасть в 5% успешных кейсов?
5. А давайте забьем на тестирование?
А потом всем отделом директоров возьмем вилки и засунем их в розетки!
Да, мы понимаем, что те рекомендации тестирования, которые описаны в гайдлайнах часто невыполнимы. Да, мы понимаем, что если делать все по уму, то тестирование сожрет даже не половину, а большую часть бюджета. Да, мы понимаем, что покрыть весь проект автотестами, функциональным и нагрузочным тестированием часто бывает невозможным.
НО. То, что почти все забивают на технику безопасности не значит, что она не написана кровью.
Вы можете вложить немыслимый бюджет в разработку, нанять лучших на свете дизайнеров, провести такой аудит рынка, что чуваки с Уолл Стрит будут тусить у вас в приемной и спрашивать совета, куда акции девать. Все будет зашибись. Но, если вы не отловили критический баг и при запуске приложения оказалось, что оно вылетает у половины пользователей — вы мало того, что слили кучу денег в унитаз, вы еще и получили репутационный ущерб такого масштаба, что вам от него не отмыться никогда.
Ребят, тестировать надо. Хотя бы минимально, хотя бы не очень глубоко. Если у вас совсем кончаются бюджеты — оставьте достаточное количество времени на фазу тестирования. Поверьте, отсутствие нормального системного тестирования потом выльется в такие деньги, что вы проклянете тот день, когда вас надоумило махнуть рукой в стиле «и так сойдет».
Простите, если сейчас получилось больно, но в следующей статье, обещаю, будет обезболивающее в виде четырех вариантов разумной экономии. И разумной, и безболезненной.
