Корпоративни уебсайтове и сигурни онлайн магазини

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

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

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

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

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

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

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

Ако промяната засяга обхвата на проекта, предварително се оценява отражението ѝ върху необходимата работа, зависимостите, тестовете, бюджета и срока за изпълнение. Малки корекции често могат да бъдат включени в текущия етап, докато по-големи допълнения е по-разумно да се планират отделно или за следваща версия.

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

Цената се изчислява според реалния обем и сложност на работата, а не по фиксирана тарифа за страница или продукт.

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

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

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

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

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

Да. Не е необходимо всички дейности по проекта да бъдат изпълнявани от един екип.

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

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

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

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

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