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