Rifiutare un progetto software può essere una decisione responsabile quando obiettivo, vincoli e capacità disponibile non permettono di assumere un impegno credibile. Il valore della risposta sta nel rendere chiaro il problema e, quando possibile, proporre un percorso praticabile.
Per Romiltec, lavorare in partnership significa anche discutere le condizioni della consegna. Accettare una richiesta non dovrebbe richiedere di nascondere ciò che ancora non sappiamo o di promettere una disponibilità che il team non ha.
Distinguere difficoltà e impossibilità di impegnarsi
Un sistema legacy può richiedere più indagine, ma non è automaticamente un progetto da evitare. Il punto è capire se possiamo accedere alle informazioni e costruire le condizioni necessarie a intervenire.
Se mancano repository, backup o ambiente di prova, valuterei una fase iniziale circoscritta. Se manca la disponibilità a ricostruire queste basi e la scadenza resta rigida, il problema riguarda l’impegno che possiamo assumere, non un giudizio sulla persona che chiede il lavoro.
Rendere visibili i vincoli che cambiano la stima
Un’integrazione con un sistema esterno dipende da accessi, documentazione e ambiente di test. Una migrazione dipende anche dalla qualità dei dati e da ciò che deve continuare a funzionare durante il passaggio.
Descriverei queste dipendenze con effetti concreti. “Manca l’ambiente di prova del fornitore, quindi non possiamo verificare il flusso di autenticazione” permette una scelta più utile di “il progetto è rischioso”.
La valutazione deve includere anche il nostro team: competenze disponibili, impegni già assunti e copertura durante il rilascio. Non tutto ciò che sapremmo costruire è un lavoro che possiamo prendere in quel momento.
Proporre una fase che riduca l’incertezza
Un’alternativa può essere un’indagine tecnica con un risultato definito: mappa del sistema, prova dell’integrazione e opzioni con limiti. Non deve diventare un preventivo aperto senza criteri di completamento.
Un’altra possibilità è ridurre il primo rilascio a un percorso utile, rinviando parti che richiedono ulteriori decisioni. La riduzione deve preservare lo scopo, non soltanto eliminare test o attività di recupero per far tornare la data.
Spiegare il rifiuto senza usarlo come pressione
Comunicherei cosa impedisce di accettare e quali condizioni consentirebbero una nuova valutazione. Il cliente può scegliere un’altra strada: la nostra responsabilità è rappresentare correttamente capacità e limiti.
Se esiste già un accordo, il problema va gestito nel suo contesto con le parti coinvolte. Non tratterei un ripensamento tecnico come il permesso automatico di cancellare unilateralmente un impegno.
Dire no non garantisce che il cliente torni, né che il ricavo perso venga recuperato. Può comunque essere la decisione coerente con il lavoro che siamo in grado di sostenere. Preferisco che questa coerenza sia visibile nelle ragioni e nelle alternative, senza trasformare il rifiuto in una dimostrazione di superiorità.