Почему ваше приложение проваливается еще до старта: 13 негативных факторов, которые необходимо учитывать при разработке

30 ноября 2016 |

Что является наиболее досадной причиной того, что новый и перспективный программный продукт терпит фиаско уже на стадии разработки? Ответы от профессиональных разработчиков, основанные на их личном горьком и поучительном опыте.

Не скачивается (зависло) приложение на iPhone или iPad:

 

Если это уже работает – не факт, что оно готово для рынка

Энди Каруза (Andy Karuza) из FenSens: для любой команды крайне важно быстрее прочих предоставить клиенту эффективное и простое решение его задачи. Но не надо путать МЖП (минимально жизнеспособный продукт) с тем товаром, который вы всерьез собираетесь продавать. Слишком многие торопятся нацепить ценник, реализовав лишь базовый функционал, то есть, выдавая за желаемый результат полусырой продукт. Зато раньше всех остальные. А толку?

 

Вы творите, не понимая, что именно и для чего

Эндрю Томас (Andrew Thomas) из SkyBell Doorbell: кодинг – объективно малая часть работы над приложением, не по трудозатратам, а по важности. Неудачи часто преследует тех, кто сосредотачивается на программировании, забывая об извечной пословице «семь раз отмерь, один раз отрежь». Если инвестировать, средства и время, в изучение своей ниши, в опыт и запросы пользователей, прорабатывать список критериев приложения до того, как оно начнет обретать очертания – будет толк. Пусть дизайнер, менеджер проекта и маркетолог не ленятся.

ПО ТЕМЕ: Почти весь доход в App Store получают всего 1% разработчиков.

 

Игнорирование обратной связи с пользователями

Николь Муньос (Nicole Munoz) из Start Ranking Now: бета-тестеров много не бывает – это аксиома. Привлекайте к изучению вашего приложения столько людей, сколько сможете. И цените все мнения, ведь мало просто убрать глюки из-за которых все зависает, нужно еще сделать так, чтобы пользователи не спотыкались о ваши «костыли». А потом придется освоить искусство латать дыры и выпускать апдейты максимально быстро, чтобы рынок не успевал охладевать к вашему детищу из-за обнаружившихся не к месту багов.

 

Одна задача – одно решение, а мультитулы это зло

Чарльз Моской (Charles Moscoe) SkinCare.net: молодым разработчикам свойственно возлагать на свои приложения чересчур большие задачи и ожидания. В итоге вместо простого и изящного инструмента выходит сложное нечто, которое может делать и что-то еще, но вот ту конкретную задачу, ради которой задумывалось – так себе, посредственно. Мой совет прост, сделайте мелочь, но на идеальном уровне, а затем оцените перспективы и при необходимости наращивайте масштаб функционала.

 

Лучшее – враг хорошего

Дуглас Хатчингс (Douglas Hutchings) из Picasolar: у вас есть задача и понимание, как ее решить. Разумное, элегантное решение, которое можно было бы расширить, продлить за установленные рамки. Исключительно чтобы перевыполнить план, сделать все еще лучше. А потом еще, и еще – на выходе получается нечто громоздкое, безвкусное и требующее даже не доработки, а тотального уничтожения, чтобы начать все с чистого листа.

ПО ТЕМЕ: Портрет среднестатистического Mac-разработчика.

 

Неумение обуздать фантазию

Эрик Гросет (Erik Groset) из Fantasy Sports Co: когда основная работа подходит к логическому завершению, перед разработчиком встает маленькая, но коварная дилемма. Как оформить, представить свой продукт, как бы его украсить, сделать дружелюбнее и симпатичнее для пользователя? Почему бы, например, не добавить виджет или парочку, куда можно вынести ключевые функции? Мысль, может быть, и здравая, но затем вдруг осознаешь, что за горой нагромождений исходное приложение изменилось до неузнаваемости.

 

Нереалистичные цели

Вик Патель (Vik Patel) из Future Hosting: менеджеры склонны увлекаться перспективами, строить прогнозы, чертить графики, которые слабо соотносятся с реальными возможностями и целями проекта. Нет, мечтать не вредно, но опасно распределять ресурсы студии и обозначать планы, руководствуясь мечтой, а не здравым смыслом и холодным расчетом. Спускайтесь с небес на землю заранее, по своей инициативе, чтобы не пришлось впоследствии больно падать.

 

Кроме бета-теста есть и другие важные экзамены

Айлет Нофф (Ayelet Noff), разработчик Blonde 2.0: прежде чем мы познакомили мир с нашей разработкой, мы дали «поиграть» с приложением друзьям, знакомым, родственникам и т.д. Это не профессиональное и даже не любительское тестирование, скорее, своего рода наблюдение – как разные люди воспримут его? Мы смотрели, анализировали и делали выводы, поэтому к моменту релиза уже знали, что Blonde 2.0 будет распространяться, как лесной пожар. Если люди, попробовав, не могут отказаться от вашего продукта – поздравление, это новый хит. И наоборот.

 

Неготовность менять методы, алгоритмы и отношение к проекту

Энтони Пеззотти (Anthony Pezzotti) из Knowzo.com: во время разработки у вас есть чек-поинты, разделяющие отдельные этапы, на которых вы проверяете соответствие своей разработки заранее определенным целям. Если известны критерии, то сразу прорисовываются и пути их достижения, но тут нас подстерегает опасность скатиться к косности мышления. А нужно уметь заставить себя посмотреть на задачу с иного ракурса, применить гибкий подход в реализации цели и не бояться, что подобное «самовольство» разрушит проект.

ПО ТЕМЕ: Почему программы для iOS лучше, чем для Android – позиция разработчиков.

 

Плохие API – проблема

Грегори Райс (Gregory Raiz) из Raizlabs: из хорошего материала кривым инструментом шедевра не создать, только зря мучаться. Прежде чем браться за основной пласт работы, убедитесь, что используемые сервисы действительно эффективно справляются со своей задачей. Это классическая оплошность неопытных разработчиков – полагать, что бекэнд может функционировать сам по себе и не нуждается в контроле, в отличие от фронтэнда.

 

Идея, форма, суть

Карли Финк (Carly Fink) из Provoke Insights: однажды на курсе оценки бизнес-идей студентов спросили о том, чтобы они хотели сделать в качестве дебютной работы. Почти все ответили «крутое приложение». Но ведь софт – это форма доставки, реализации, а не сама услуга или товар. Сначала нужно определиться, что именно вы собираетесь предоставить миру, а уже потом подобрать для него подходящий визуальный формат. Но большинство людей, тем не менее, все еще склонны ставить телегу впереди лошади, наивно полагая, что в ней и заключена вся суть.

ПО ТЕМЕ: Какой язык программирования лучше изучать? Советы специалиста.

 

Дизайн – дело тонкое

Кевин Ямазаки (Kevin Yamazaki) из Sidebench Studios: как руководитель проекта, не гнушайтесь общаться с разработчиками на всех этапах. Как программист, не стесняйтесь изучать общий облик продукта и высказывать свое мнение. Лишь то, что создано в постоянном совершенствовании, может рассчитывать на успех на рынке. Плюс продумать выигрышную стратегию изначально дешевле и выгоднее, чем исправлять опрометчивые решения потом.

 

Вы забыли о брендинге и эстетике

Бриана Лоулесс (Bryanne Lawless) из BLND Public Relations: если делать утилиту для лампочки в своем гараже, можно игнорировать все, кроме ее функционала. Но когда вы планируете выйти на рынок и показать потребителям свой продукт, вам нужен бренд. Не просто хорошо работающее приложение, а полноценный товар, который будет продвигаться и конкурировать. Не умеете или не желаете с этим возиться – налаживайте контакты со специалистами, без этого никуда.

Смотрите также: