8 скъпи грешки при разработка на приложения, които МСП повтарят

Ето неудобната истина за проектите за приложения, които тръгват накриво: докато кодът започне да изглежда сбъркан, проектът вече е бил загубен преди седмици. Скъпите грешки при разработката на приложения за малкия бизнес почти никога не се случват пред клавиатурата. Те се случват в небрежни разговори — заданието, което така и не беше записано, функцията, която някой добави „докато сме се захванали“, разработчикът, избран защото приятел го е препоръчал. Нищо от това не изглежда като решение в момента. Всичко това ви струва по-късно.

Виждал съм как много малки фирми поръчват първото си приложение и съм бил викан да спасявам доста от тях след това. Собствениците рядко са небрежни хора. Те са схватливи, внимателни, добри в управлението на бизнес. Но софтуерът си има собствен набор от капани, които не съществуват никъде другаде в работния им живот, и никой не ги е предупредил. Затова влизат право в едни и същи осем клопки, в горе-долу същия ред, всеки път.

Това е списъкът, който ми се иска всеки собственик да имаше, преди да похарчи и стотинка. Не теория — реалните, повтарящи се грешки и малките корекции на курса, които биха спасили всеки проект. Ако се каните да изградите приложение или вече сте в средата на разработката и нещо ви се струва нередно, прочетете това първо. Повечето от тях все още могат да се поправят, ако ги уловите навреме.

Грешка 1: Строите, преди да сте доказали, че някой го иска

Единствената най-скъпа грешка е и най-честата: да се ангажирате с пълна разработка, преди да има реално доказателство, че приложението решава проблем, за който хората ще плащат или ще го използват. Идеята изглежда очевидна за собственика — разбира се, че клиентите ще искат това — и точно тази увереност е опасна. Увереността усеща като валидация. Не е.

Валидацията не значи да питате десет приятели дали харесват идеята; всеки казва „да“ от учтивост. Тя означава да поставите възможно най-малката версия пред реални потребители в реална ситуация и да наблюдавате какво всъщност правят. Кликаем прототип, целева страница, която измерва регистрациите, ръчна „консиерж“ версия, в която фалшифицирате автоматизацията на ръка — всяко от тези ви казва повече от завършено приложение, изградено върху предчувствие. Редът има значение: докажете търсенето евтино, после строете скъпо. Обърнете го и можете да похарчите целия си бюджет в излъскване на нещо, което никой не отваря втори път.

Грешка 2: Разрастване на обхвата, маскирано като амбиция

Всяко приложение започва стройно и подредено. После започва „докато сме се захванали“. Докато правим екрана за резервации, може ли да обработва и подаръчни ваучери? И точки за лоялност? И система за препоръки? Всяко добавяне звучи разумно само по себе си. Заедно тихо утрояват срока и сметката — и избутват старта толкова напред, че първоначалният устрем умира.

Решението не е да казвате „не“ на добрите идеи. То е да ги паркирате. Поддържайте видим списък „версия две“, където всяка бляскава идея отива да чака реда си. Това върши нещо психологическо, освен практическо: хората спират да се борят да напъхат функции в първото издание, щом повярват, че има реално място за идеята им по-късно. Вашата първа версия трябва да прави едно нещо наистина добре, а не десет неща задоволително. Приложение, което улучва един работен процес, се използва. Приложение, което прави всичко наполовина, се изоставя.

Грешка 3: Без писмено задание — само споделена мисловна картина

Тази е невидима, докато не клъвне. Собственикът има ясно приложение в главата си. Разработчикът има ясно приложение в главата си. Всички кимат на началната среща. Никой не го записва както трябва — и двете картини, оказва се, никога не са били една и съща картина. Откривате това по средата, когато нещото, което се строи, не е нещото, което сте си представяли, и сега има спор кой какво е казал.

Не ви трябва спецификация от сто страници. Трябват ви няколко страници, които всеки новодошъл би могъл да прочете и разбере: кой използва това приложение, кои са трите или четирите неща, които трябва да правят с него, как изглежда успешен резултат. Добавете груба скица на ключовите екрани. Това е. Смисълът на заданието не е бюрокрация — то е споделен ориентир, към който и двамата можете да сочите, когато паметта и реалността започнат да се разминават, което винаги се случва.

Грешка 4: Избор на разработчика по грешен начин

Повечето собственици избират първия си разработчик по един от два неубедителни сигнала: най-ниската оферта или лична препоръка от някого в съвсем друг бранш. И двете могат да сработят по късмет. Нито едното не е надежден начин да изберете някого, на когото ще доверите значителна сума пари и няколко месеца от бъдещето на бизнеса си.

Най-ниската оферта е особено коварна в софтуера, защото разликата между офертата и крайната цена е огромна и невидима. Евтин разработчик, който се нуждае от три кръга преработки, изчезва за две седмици и ви оставя с код, който никой друг не може да поддържа, е далеч по-скъп от малко по-скъпия, който го прави както трябва. Цената е това, което виждате; общата цена е това, което плащате.

Какво всъщност да проверите

Поискайте да видите неща, които са пуснали и все още работят, и ако можете, говорете с тези клиенти без разработчика в стаята. Питайте как се справят с промени по средата на проекта, защото ще има промени. Питайте кой притежава кода и акаунтите, когато е готово — отговорът винаги трябва да е вие. И обърнете внимание дали и те задават добри въпроси в отговор. Разработчик, който само изпълнява поръчки, ще изгради точно грешното нещо много ефективно. Добрите възразяват, посочват пропуски в мисленето ви и третират заданието като начало на разговор, а не като фиксиран списък за пазаруване.

Грешка 5: Планирате бюджет за разработката, забравяте останалото

Приложението не е еднократна покупка като печатна брошура. То е живо нещо, което се нуждае от хранене. Собствениците редовно залагат бюджет за разработката и нищо друго, после биват изненадани от разходите, които пристигат след това: хостинг, такси за магазините за приложения, поддръжката за в крак с обновленията на телефонните операционни системи и неизбежния кръг от поправки и малки подобрения, щом реални хора започнат да го използват.

Разумно правило: каквото и да струва разработката, заделете значителна част от това отново за първата година на поддръжка. Точната цифра варира, но грешката е универсална — да третирате деня на старта като финална линия, когато всъщност е стартовата линия. Приложението, което се пуска и после тихо бива изоставено, защото няма бюджет за поддръжката му, е един от най-тъжните и най-чести изходи в цялата тази област, и е напълно избежим с честно планиране отнапред.

Грешка 6: Проектиране за себе си вместо за потребителя

Познавате бизнеса си отвътре и навън, което ви прави възможно най-лошия съдник дали приложението ви е лесно за използване. Неща, които са очевидни за вас — жаргонът, редът, в който вършите задачите, преките пътища, които правите без да мислите — са объркващи за потребител за първи път. Приложение, което има пълен смисъл за собственика и обърква всички останали, се е провалило, колкото и умно да е.

Лекът е евтин и леко смиряващ: гледайте как реални хора го използват, преди да го пуснете. Не екипа ви, който вече знае как се предполага да работи — реални клиенти или служители, които никога не са го виждали. Дайте им приложението, дайте им задача и не казвайте нищо. Където се колебаят, докоснат грешното нещо или въздъхнат, това е вашата обратна връзка за дизайна. Петима души стигат, за да изплуват най-лошите проблеми. Прескачането на тази стъпка е как приложения излизат с бутон „изпрати“, който никой не може да намери, и поток за регистрация, който губи половината хора, които опитват.

• Дайте на тестващия реална задача, а не обиколка — „запази час за следващия вторник“, после мълчете.
• Гледайте ръцете и лицето им, не само дали в крайна сметка успяват.
• Отбележете всяко колебание; паузата е проблем в дизайна, който не виждате отвътре.
• Устоявайте на порива да обяснявате — ако трябва да го обясните, приложението е трябвало да го направи.
• Тествайте с петима души, поправете очевидните провали, после тествайте отново.

Грешка 7: Изграждане на нативни iOS и Android, когато не ви е трябвало

Има рефлекс да се изгради „истинско“ приложение и за iPhone, и за Android от първия ден, изцяло нативно, по начина, по който го правят големите марки. За повечето малки фирми това е два до три пъти повече цена и сложност за полза, която потребителите ви никога няма да забележат. По-лошо, сега поддържате две отделни кодови бази завинаги, удвоявайки всяка бъдеща поправка.

Често правилният първи ход изобщо не е нативно приложение. Добре изградено уеб приложение, което работи в браузъра на всеки телефон, или крос-платформен подход, който произвежда и двете версии за магазините от една кодова база, ви извежда на пазара по-бързо и по-евтино — и винаги можете да минете изцяло нативно по-късно, ако реалната употреба докаже, че си струва. Въпросът, който трябва да зададете, никога не е „нативно или уеб“ абстрактно. Той е: кое е най-малкото, най-евтиното нещо, което позволява на реални потребители да свършат основната работа? Изградете това, научете от него, после харчете големите пари с доказателство вместо с предположение.

Грешка 8: Третиране на старта като края на работата

Осмата грешка е да вярвате, че проектът е готов, когато приложението влезе в експлоатация. Не е — тогава започва истинският проект. Приложение без план как да стигне до ръцете на потребителите, без начин да чуете какво мислят, и без намерение да го подобрявате въз основа на наученото, е приложение, което избледнява за месеци. Разработката беше лесната част. Възприемането е трудната част, и почти никой не я планира.

Преди да стартирате, знайте три неща: как хората ще научат, че приложението съществува, как ще измервате дали наистина го използват, и как ще събирате това, което ви казват, така че следващият кръг работа да се води от реалността вместо от догадки. Нищо от това не е скъпо. То е просто различен начин на мислене — приложението не е нещо, което завършвате и оставяте, то е връзка, която поддържате. Собствениците, които разбират това, получават приложения, които стават по-полезни с времето. Тези, които не разбират, получават пик в деня на старта и дълъг, тих спад.

Как да избегнете и осемте наведнъж

Прочетени заедно, тези грешки споделят един общ корен: да се движите бързо върху предположения вместо бавно върху доказателства. Всяка от тях е място, където е изглеждало по-евтино да прескочите внимателната стъпка. И всяка от тях е далеч по-евтина за справяне преди разработката, отколкото след нея. Ето последователността, която тихо избягва и осемте.

1. 1
   Докажете търсенето, преди да строите

   Прототип, целева страница или ръчна версия. Получете реално доказателство, че някой го иска, преди да ангажирате бюджета.
2. 2
   Напишете заданието и списъка „версия две“

   Няколко ясни страници, които всеки може да разбере, плюс паркинг за всяка идея „докато сме се захванали“, за да не дерайлира v1.
3. 3
   Изберете разработчика по постижения, не по цена

   Пуснати работи, разговори с препоръчители, ясна собственост върху кода и акаунтите, и някой, който задава добри въпроси в отговор.
4. 4
   Заложете бюджет за цялата първа година, не само за разработката

   Хостинг, поддръжка, поправки и поддръжка на потребители. Денят на старта е стартовата линия, затова финансирайте поддръжката на нещото.
5. 5
   Изберете най-малката платформа, която върши работата

   Уеб или крос-платформено първо в повечето случаи. Минете изцяло нативно по-късно, с доказателство, само ако употребата го изисква.
6. 6
   Тествайте с реални потребители, после планирайте старта

   Гледайте петима непознати да го използват, поправете очевидните провали и решете отнапред как хората ще го намерят и как ще измервате употребата.

Чести въпроси