Dar sună a fast-tracking. Se practică. Uneori chiar trebuie făcut. Implică asumarea de costuri suplimentare şi rework pentru câştigarea de timp. Există şi metode de reducere a riskului (dar nu de evitare).

În primul rând, specificarea corectă; în al 2lea rând comunicarea intensivă între echipele diferite care lucrează în paralel la WP-uri care în mod normal se fac secvenţial.

Dacă a existat o specificaţie iniţială bine făcută, diferenţele ar trebui să fie minore între manual şi aplicaţie. Rezultă efort suplimentar de sincronizare – dar acceptabil, comparabil poate cu efortul de actualizare a unui manual de la o versiune de sistem la alta.

Concluzia mea este că specificaţia iniţială era vagă şi sistemul definit insuficient (notă: deşi mai sus scrie că specs erau clare…) (notă 2: se întâmplă şi aşa – dar în acest caz într-adevăr nu te apuci să faci fast-tracking).

Concluzia mea 2 este că autorul manualului nu a vorbit niciodată cu echipa de dezvoltare. Ca o mini-extrapolare, mă întreb dacă vreunul din cei doi au vorbit vreodată şi cu analistul de business

PS: doar de plăcerea root-cause analysis şi ca să fiu eu avocatul diavolului în sensul bun – poate manualul era corect şi aplicaţia era greşită. E un murphism incredibil de adevărat că orice program face ceva bun, dar nu întotdeauna (aş zice că de fapt foarte rar) ceea ce trebuia să facă. See validare vs. verificare.
Mă rog, nu am date suficiente, acesta este doar un joc ideatic.