„Колко време ще отнеме?“ е грешният първи въпрос
По-полезният въпрос е „Какво трябва да е ясно, за да не губим време по пътя?“. Сайт с 12 страници и подредено съдържание може да се движи по-бързо от сайт с 5 страници, ако вторият има трима decision makers и една недефинирана интеграция.
Срокът е функция на решенията и зависимостите. Кодът е само една от тях.
Пет места, на които проектът най-често спира
Ако тези точки са извадени още в discovery, календарът става много по-предвидим.
- Няма един човек, който да одобрява.
- Текстовете се пишат след дизайна, вместо паралелно.
- Scope-ът се разширява с всяка среща.
- API/ERP/плащане се оказва различно от обещаното.
- QA се оставя за последните два дни.
Най-бързият начин да ускорите проекта е да режете неизвестни, не QA
Когато deadline-ът е твърд, първата реакция често е „ще тестваме по-малко“. Това е най-лошото място за компромис. По-разумно е да намалим scope-а на първия release и да оставим secondary функции за след launch.
MVP не означава евтин или недовършен. Означава първа версия с ясен бизнес резултат и без ненужни зависимости.
Как изглежда реалистичен план
Discovery и архитектурата дават посока. UX/UI фиксира поведението на ключовите шаблони. Development може да върви паралелно с част от content production, но не трябва да гадае основните решения. После идват QA, redirects, analytics и controlled launch.
Добър график има и buffer. Ако обещанието работи само при сценарий, в който никой не задава нов въпрос и нищо не се чупи, това не е план — това е надежда.
Истинският KPI е time-to-useful, не time-to-launch
Сайтът не е готов, когато е качен на домейна. Готов е когато реален клиент може да го използва, екипът може да го управлява и conversion пътищата се измерват.
Затова предпочитаме по-малък, проверен launch пред голям release, който още първата седмица влиза в аварийна поддръжка.