Трябва ли клиентът да заплаща допълнително за отстраняване на бъгове?
Какво ни провокира да напишем тази статия? В скорошна доработка, която направихме в софтуерната система на наш клиент, беше открита грешка, което доведе до дискусия относно това защо грешката не е била уловена по време на тестване и защо ги таксуваме, за нейното отстраняване.
Като се има предвид нашият бизнес модел, това е дискусия, която се случва от време на време, и затова решихме да опишем нашата гледна точка в тази статия, която да дава повече яснота на нашите клиенти (и не само) относно подобни ситуации. Считаме, че в отношенията между клиент и агенция има много ситуации, които произлизат от факта, че има разлика във вижданията на двете страни относно процесът на планиране и изграждане на една софтуерна система или уебсайт.
Но нека първо да направим следното уточнение, тъй като то е много важно за останалата част от статията. Има две ситуации, които трябва да се разглеждат поотделно:
- Отстраняване на бъгове при уеб приложение (или уебсайт) след неговото пускане онлайн.
- Отстраняване на бъгове при техническа поддръжка на уеб приложение (или уебсайт), което не е разработвано от агенцията, която е поела техническата поддръжка.
Какво трябва да се разбира под бъг?
Преди всичко е много важно да направим правилна дефиниция на термина “бъг” или “неизправност” в едно уеб приложение или уебсайт. Бъг е всяка една грешка (неправилно поведение или фатална грешка) в някоя функционалност, чиято логика е била ясно описана в техническото задание на проекта между клиента и фирмата разработчик.
Ситуации, в които това, което се определя като бъг или незавършена работа всъщност е нещо, което не е било правилно комуникирано в началната фаза на планиране и уточняване на техническото задание реално не може да се счита за бъг.
Именно поради тази причина изграждането на подробно и ясно техническо задание независимо дали става въпрос за изграждане на уебсайт, уеб базироно приложение или просто добавяне на нова функционалност към вече съществуваща система е много важна стъпка, която винаги когато се пренебрегне води до конфликтни ситуации между клиента и фирмата разработчик.
Чия е отговорността при появили се бъгове?
Всяка една софтуерна система ще има бъгове от време на време и е нездравословно да се приема убеждението, че всички бъгове могат да бъдат предвидени и избегнати при първоначалното пускане в реална среда.
Не винаги е правилно да се мисли, че бъг е равно на грешка, допусната от фирмата разработчик. Това определено може да е вярно на моменти, но има ситуации, в които не винаги е абсолютно ясна причината за даден бъг. Тук ще посочим няколко примера спрямо двете ситуации, които описахме по-горе:
Бъгове при уеб приложение (или уебсайт) след неговото пускане онлайн
- Вариант 1: бъг, който се дължи на лоша комуникация между клиента и фирмата разработчик във фазата на договаряне при което клиента остава с неправилна представа относно крайния резултат.
- Вариант 2: бъг, който се дължи на грешка допусната от фирмата при изпълнението на проекта.
- Вариант 3: бъг, който се дължи на грешка, която произлиза от липсата техническа поддръжка.
Бъгове при техническа поддръжка на уеб приложение (или уебсайт), което не е разработвано от агенцията, която е поела техническата поддръжка.
Тук вариантите 1 и 2 са също възможни и често срещани, но при тази ситуация има и други причини, които ще се опитаме да опишем:
- Вариант 4: бъг, който се дължи на конфликт между новата функционалност и стара функционалност, която не е разработвана от фирмата, която е направила новата.
- Вариант 5: бъг, който се дължи на промяна (или ъпдейт) на доставчик от трета страна например - библиотека, тема, външен модул, CMS платформа и др.
- Вариант 6: бъг, който се дължи на проблем създаден от потребител на системата, защото не е разбрал как да използва конкретна функция.
Както можете да видите има много различни ситуации, които могат да доведат до произлизането на бъгове и причината за тяхната поява не винаги е праволинейна за определяне и подлежи на тълкуване.
В тази връзка е важно е и двете страни (клиентът и фирмата разработчик) да са отворени за комуникация и да има високо ниво на доверие помежду им при определяне на причината за даден бъг.
Тестването е сложен, времеотнемащ и трудоемък процес
Не отнема много време, докато една софтуерната система (уебсайт, онлайн магазин и др.) стане достатъчно сложна, така че тестването на всички възможни функционалности да стане доста скъпо и отнемащо време. Това води до ситуация, в която трябва да приемем, че работата по нея независимо дали става дума за някакъв ъпдейт или добавяне на нова функционалност може да доведе до бъгове.
За нашия клиент, който споменахме в началото на статията ние поддържаме сложна софтуерна система, която представлява онлайн магазин, който има интеграция с ERP платформа и още доста други къстъм функционалности.
Ако трябва да се запише всяко едно функционално поведение, поддържано от системата, списъкът лесно може да нарасне до няколко стотици редове. И ако се вземат предвид функционалните зависимости – поведения, които са свързани с други поведения – списъкът може да нарасне многократно.
Тези оценки са приблизителни, но това, което искаме да кажем е следното нещо: за системи с подобно ниво на сложност — за да се тества всяка една функционалност на системата — „тестване“ (независимо дали става дума за програмиране на автоматизирани тестове или изпълнението на ръчно провеждани тестове) трябва да се вложат много часове.
Всеки път, когато се разработва нова функция или се модифицира съществуваща, трябва да се вземе решение относно обхвата и количеството на провежданите тестове, с идеята, да се постигне разумен баланс между вложеното време за тестване и последствията от пропускането на бъг.
Кога таксуваме или не за отстраняване на бъгове
С оглед на всичко написано до тук в статията се надяваме да сме внесли ясното относно принципа на таксуване за отстраняването на бъгове и логиката зад него.
Ситуациите при които ние таксуваме нашите клиенти са следните:
- Всички ситуации при които грешката не е при самото разработване.
- Когато е изтекъл срокът за безвъзмездно отстраняване на проблеми след пускането на даден проект в реална среда.
Във всички останали ситуации ние таксуваме отстраняването на бъгове, като съответно винаги има изключения, които в повечето случаи са свързани със ситуациите, когато нещо не е правилно комуникирано при изготвянето на заданието.
Заключение
Както споменахме вече доверието между клиент и фирмата разработчик е от голямо значение и ако същото липсва то неимоверно в такъв тип взаимоотношения ще се стигне до проблемни ситуации.
Ние в Webtitan целим да работим дългосрочно с нашите клиенти, затова имаме политика на максимална прозрачност.