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