5 неща, които да запомним за бъг и функционалност

5 неща, които да запомним за бъг и функционалност

Много често, голяма част от клиентите и потребителите не правят разлика между две понятия – бъг и функционалност. В практиката ни с клиентите разбираме, че те често се сблъскват с този фундаментален въпрос: как да различим бъг от функционалност?

Да, в 10% от случаите наистина сайтът или част от него не функционира правилно заради бъг. Това обаче са проблеми, които се открояват лесно и ясно, още в процеса на работа, и се отстраняват максимално бързо. Почти винаги клиентът или потребителят не разбират за съществуването им.

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

От клиентска и наша, обаче, нещата не са толкова прости, колкото изглеждат на пръв поглед.

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

1. Не одобрявайте техническо задание, преди да сте напълно сигурни.

Целта на ТЗ е нещо като преговори. Клиентът посочва какво желае да има на сайта си. Програмистите го оценяват според сложността, поставят цена и срок. След това клиентът изпраща примерни сайтове или дизайн, които харесва. Дизайнерите преценяват кое ще пасва по-добре на идентичността на компанията и предлагат на свой ред промени и подобрения.

От клиента зависи да предостави максимално подробно и ясно техническо задание.  Когато всичко това е направено – техническото задание се въвежда в експлоатация и започва същинската работа. По-добре предоговорете условията и изискванията си няколко пъти преди да одобрите ТЗ и да стартирате. По този начин ще намалите и улесните работата на програмисти и дизайнери, а с това ще намалите своите разходи и ще сте много по-доволни от крайния продукт.

В този пример сме посочили ТЗ, което изисква брояч, обвързан с фирма за уеб дизайн.

Техническо задание за броя

2. Бъговете са неволни грешки или пропуски. Не се сърдете.

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

В този пример сме посочили ТЗ, същото като горното, но с бъг.

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

3. Всеки иска промяна.

Така стигаме до следващия пример, където клиентът е предал ТЗ, отстранени са бъговете, но той желае промяна.

В този пример сме посочили ТЗ, което клиентът желае да промени.

Промяна в ТЗ

Този тип промени се делят на няколко вида, но няма да описваме всички.

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

4. Допълнителна функционалност се заплаща.

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

В този пример сме посочили функционалност, която не е описана в ТЗ.

Добавяне на функционалност в ТЗ

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

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

5. Гаранцията покрива бъговете, а поддръжката покрива функционалности и промени.

Рядко срещано явление е фирма за изработка на уеб сайт да предлага гаранция към продукта си (уеб сайт). Ние, от своя страна, предлагаме гаранция към всеки един сайт, който направим. Напълно сме убедени, че той ще функционира изрядно, когато го завършим. Ако все пак възникне някакъв проблем, сме готови да го отстраним бързо и безплатно. В поддръжката ни се включват няколко технически часа на месец – в тях се включват множество безплатни дребни промени, които клиентите искат, след като сме уточнили дизайна и функциите, както и добавяне на допълнителни функционалности.

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