Реалният график за разработка на приложение: от идея до старт

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

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

Затова нека поставим реалистични очаквания. За фокусирана първа версия на бизнес приложение — не разрастваща се платформа, а първа версия, която върши една задача добре — обикновено говорим за нещо в диапазона три до пет месеца от сериозен старт до реален launch. Къде ще попаднете в този диапазон зависи по-малко от технологията, отколкото от това колко сте наясно, колко бързо взимате решения и колко много се опитвате да натъпчете преди старта. Нека го разгледаме стъпка по стъпка.

Защо прогнозата, която са ви дали, вероятно е грешна

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

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

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

Етап 1: Проучване и обхват (1–3 седмици)

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

Направено добре, проучването е предимно разговор и трудни въпроси. Кой го използва и на какво устройство? Кое е единственото нещо, което трябва да върши блестящо? Какво може да изчака до втората версия? Добрият партньор ще ви опонира тук и вие искате точно това — всяка функция, която отрежете сега, са седмици, които си връщате. Резултатът обикновено е кратко писмено описание на обхвата и груб wireframe, нещо, което можете да хванете в ръка и да кажете да, ето това е.

Етап 2: Дизайн и прототип (2–4 седмици)

Сега приложението става нещо, което можете да видите и да докоснете, преди ред реален код да ви обвърже с каквото и да било. Дизайнерите превръщат wireframe-а в истински екрани — цветовете, потока, реалното усещане при ползване — обикновено като интерактивен прототип, който можете да докосвате на собствения си телефон.

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

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

Етап 3: Изграждане (6–12 седмици)

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

Този ритъм има значение. Искате да реагирате на реален, работещ софтуер рано, а не на отчет за статус. Когато наистина можете да ползвате процеса на резервация на четвъртата седмица, ще забележите неща, които никакво задание не би уловило — а поправянето им на четвъртата седмица е далеч по-евтино, отколкото на десетата. Добрият процес на изграждане прави приложението видимо за вас непрекъснато, а не само в края.

Какво тихомълком разтяга изграждането

Две неща разширяват изграждането повече от всичко друго. Първото са интеграциите — всяка външна система, с която приложението трябва да общува (платежният ви доставчик, съществуващият ви инструмент за резервации, счетоводният ви софтуер, услуга за доставка), добавя работа и всяка може да поднесе собствените си изненади. Второто е разрастването на обхвата: постоянното капане на малки добавки, всяка от които изглежда дребна, но заедно изместват старта с месец. И двете са управляеми, но само ако ги виждате да идват.

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

Етап 4: Тестване и поправяне (2–4 седмици)

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

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

Етап 5: Стартът и чакането на магазина за приложения (1–2 седмици, плюс преглед)

Стартът е по-малко единичен момент и повече внимателно разгръщане. Ако е уеб приложение, контролирате времето изцяло — пускате ключа, когато сте готови. Ако влиза в Apple App Store или Google Play, предавате част от графика в техните ръце: техният процес на преглед може да отнеме от ден до над седмица, а понякога ще ви го върнат с нещо за поправяне. Това си струва да се знае предварително, за да не изненада старт, който сте обещали на клиенти.

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

1. 1
   Тих старт за малка група

   Пуснете първо за шепа дружелюбни потребители или служители. Реалната употреба намира това, което тестването е пропуснало, при свалени докрай залози.
2. 2
   Подайте рано, ако отивате в магазините за приложения

   Apple и Google контролират часовника на прегледа, не вие. Подайте с буфер, така че бавен преглед или отказ да не взривят обещаната ви дата.
3. 3
   Наблюдавайте първата седмица отблизо

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

   Приложението никога не е „завършено“ при старта. Договорете предварително кой се занимава с неизбежните малки поправки и първия кръг обратна връзка.

Сглобяване на целия график

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

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

Как наистина да го ускорите (и как не)

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

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

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

Често задавани въпроси