Come vendere lo sviluppo Agile ai clienti (a cascata)

Il nostro negozio di sviluppo vorrebbe davvero fare progetti più agili, ma abbiamo un problema a coinvolgere i clienti. Molti clienti desiderano un budget e una scadenza. È difficile vendere un cliente a un progetto agile quando i nostri concorrenti escono con scadenze fisse basate su cascata e prezzi fissi. Sappiamo che i loro numeri fissi sono cattivi, ma il cliente non lo sa. Quindi, finiamo per sembrare cattivi per il cliente perché non possiamo fissare il prezzo o una scadenza, ma i nostri concorrenti possono farlo.

Quindi, come puoi convincere la tua forza di vendita a vendere con successo un progetto che utilizza metodi di sviluppo agili o un prodotto sviluppato utilizzando tali metodi? Tutte le informazioni che ho trovato sembrano concentrarsi sulla gestione del progetto e sugli sviluppatori.

La chiave per farlo bene è tramite un contratto di supporto.

Fondamentalmente, quando vendi per la prima volta il cliente, lo vendi in base alla tua esperienza e lo fai a cascata. Ciò significa un contratto che stabilisce la portata e una scadenza precisa. Questo è ciò che vuole il cliente. Il cliente conosce più o meno l'ambito. Waterfall funziona molto bene, in un ambiente con portata fissa e definita, direi che funziona meglio che agile in tali ambienti. E in questo caso dà al cliente un livello di conforto quando la tendenza è quella di essere nervosi perché non ha mai lavorato con te prima. Va bene, Agile non è sempre meglio di cascata.

Quindi hai un contratto a prezzo fisso per X scope. Quindi dici al cliente “ Guarda, vorrai apportare modifiche e avrai bisogno che noi ti supportiamo nella post produzione, accantoniamo il 20% del tuo budget per queste cose da usare in base alle necessità mezzi di un contratto di sostegno . "

Se dovesse verificarsi un cambiamento durante il progetto, è sufficiente rinviarlo affinché venga gestito sotto il contatto di supporto. (Supponendo che questa modifica provocherebbe una grave interruzione del progetto)

I termini del contatto di supporto sono i seguenti: "Il lavoro da eseguire su base oraria, come richiesto dal cliente, può essere utilizzato per richieste di modifica o supporto generale e manutenzione del sistema ". BAM! Sei in Agile.

È quindi possibile continuare a estendere il contatto di supporto e utilizzare semplicemente il contatto di supporto come mezzo per eseguire nuovi progetti. Inoltre, se queste ore vengono acquistate e pagate in anticipo , di solito offriamo al cliente uno sconto del 15%. È Win-Win.

Agile non preclude scadenze e budget. Se fossi un cliente e andassi da uno sviluppatore e mi dicessero che non potevano darmi una scadenza o un costo stimato, metterei in dubbio la loro sanità mentale. E dire loro che semplicemente non capiscono che non funzionerà: devono essere in grado di pianificare e pianificare.

Non hanno bisogno di conoscere il tuo processo di sviluppo. Devono sapere quanto tempo ci vorrà per sviluppare funzionalità e quanto costerà. Dai loro un numero basato sul presupposto (spurio) che i loro requisiti siano accurati al 100% e quando cambiano i loro requisiti, quindi cambia le tue stime.

Ciò fornisce loro gli elementi pubblicitari di budget e le date di distribuzione che desiderano e, quando le cose cambiano, il processo ti consente di apparire flessibile e accomodante.

Sembra che i tuoi venditori stiano creando uno strato di cattiva comunicazione tra i team di sviluppo e i clienti. Se non vendono sul mercato IT da molto tempo, possono considerare il loro ruolo di "spostare il prodotto", ovvero ottenere una firma su un contratto "qualunque cosa serva". In breve, sono motivati ​​a chiudere, indipendentemente da ciò che promettono. In tali circostanze, seguiranno il più possibile la lingua del cliente.

Ho un record rotto citando questo, ma qui va: sei sul tavolo operatorio e mentre vai sotto il chirurgo dice "ti porteremo fuori di qui in tempo e nel rispetto del budget". Grande. Sarò vivo?

Se stai lavorando sugli organi interni di un'azienda, ti fermi in qualche punto arbitrario? In genere un'applicazione è influenzata da forze che né voi né i vostri controlli del cliente - regolamenti, clima aziendale, comportamento della concorrenza, l'emergere di alcuni nuovi paradigmi, ecc. Se dite semplicemente 'faremo' cosa x 'per' prezzo y '' allora il cliente tornerà tre mesi dopo e dirà - "beh ...". In genere significa che sanno qualcosa che non sapevano quando hai accettato un progetto a cascata.

Ciò che potrebbe funzionare in una situazione del genere è dimostrare al proprio personale di vendita com'è guidare attraverso un canyon. Ad ogni svolta ci sono sorprese. Non è possibile vedere più di circa tre mesi, quindi se un cliente chiede un progetto di 18 mesi sarà irriconoscibile al momento del completamento. Pertanto, il rappresentante di vendita deve iniziare trovando il risultato finanziario del progetto. Questo aumenterà le vendite di $ 10 milioni? In tal caso, vale la pena investire $ 2.000.000 per guadagnare altri $ 10 milioni? Se il cliente e il rappresentante di vendita stanno convergendo su un impegno di $ 500.000, allora qualcosa potrebbe essere sbagliato e nessuno può dire di cosa si tratta - semplicemente non sembra giusto. Ciò che "non sta bene" è l'impegno a fare qualcosa che rischia di essere inutile.

Gli ultimi due modelli di aereo di linea hanno avuto una storia di serpenti. Healthcare.gov non ha nemmeno bisogno di discussione. Se riesci a trovare libri o scambiare storie di stampa sugli aerei di linea, puoi far capire come sono state fatte alcune ipotesi che si sono rivelate ottimistiche e che i progetti hanno mancato ripetutamente le scadenze. Spesso ciò era dovuto alla sottovalutazione della complessità. Se non riesci davvero a capire quanto sia complesso fino a quando non inizi a codificarlo, avrai bisogno di un "giro iniziale" per avere una migliore idea dei problemi reali. Il taglio del budget dovrebbe essere una frazione degli utili aggiuntivi totali (o dei ricavi in ​​alcuni casi), e quel numero deve essere più di quanto si pensi che il progetto attuale costerà. Se riesci a mostrare come può essere superato l'ultimo traguardo senza superare il "limite di payoff",

Il principale ostacolo nel conseguire i benefici dello sviluppo software Agile-Scrum al di fuori è l'integrazione con i meccanismi di controllo esistenti. Questi meccanismi di controllo sono stipulati a causa di vari prerequisiti organizzativi e vengono normalmente attuati utilizzando l'approccio e la metodologia della cascata lineare.

Di seguito sono descritti quattro di questi prerequisiti organizzativi tipici:

• Grandi aziende globali: in queste organizzazioni a matrice gerarchica, il controllo dall'alto verso il basso del portafoglio è la regola del giorno. L'approccio agile e libero ha difficoltà a adattarsi ai controlli rigorosi. In particolare i concetti intrinseci privi di piano Agile, rendono Agile-Scrum difficile da ingoiare all'organizzazione.

• Settori altamente regolamentati: alcuni settori sono tenuti dagli organismi di conformità e di governance a disporre di un rigoroso meccanismo di controllo vincolante. Questi possono essere, ad esempio, unità di business per la ricerca di attrezzature mediche, aeromobili e prodotti farmaceutici e sviluppo di prodotti. Mentre i singoli team potrebbero operare Agile-Scrum, il processo di sviluppo deve seguire un rigido metodo di approccio a cascata lineare per la tracciabilità e la governance.

• Prodotti predefiniti complessi: alcuni prodotti integrati che includono sia hardware, software, integrato e altro sono sviluppati come un contratto con un cliente finale in base a una serie predefinita di requisiti. In questi casi il grado di flessibilità richiesta è piccolo, sebbene maggiore di quanto inizialmente previsto. In questi casi il concetto di arretrato completamente flessibile di Agile-Scrum risente notevolmente.

• Dipartimenti IT generici: gran parte delle attività quotidiane e settimanali nei dipartimenti IT orientati alla manutenzione è ad hoc. Le modifiche agli orari giornalieri sono numerose e immediate. Le interferenze costanti nel lavoro di gruppo sono la norma. Il concetto di time boxing e nessuna interferenza è difficile da mantenere in queste situazioni.

Naturalmente - molte volte le quattro categorie discrete descritte sopra, in realtà si mescolano; quindi è comune trovare un prodotto complesso in una grande azienda globale che è tenuta a rispettare le normative vigenti.

Sulla base dell'esperienza pratica, il metodo raccomandato per affrontare questi scenari e altri è quello di abilitare il PMO Agile a fungere da attivatore, pilota e traduttore tra i team emergenti di Agile-Scrum e gli elementi Linear Waterfall.

Fare riferimento alla tabella seguente per linee guida specifiche

Fonte - Interfaccia tra Linear Waterfall e Agile Approaches di Michael Nir

Abbiamo organizzato 2 o 3 sessioni di stima con il potenziale cliente e i nostri sviluppatori in cui discutiamo del lavoro a portata di mano e stabiliamo i criteri di accettazione. Gli sviluppatori stimano il lavoro nei punti della storia durante l'incontro.

Successivamente vendiamo al cliente una serie di punti storia. Questo è possibile perché ha una buona idea del valore dei punti della storia. Gli diciamo che ha la possibilità di mettere a punto il suo arretrato / ambito durante il progetto e che sarà facile grazie all'uso dei punti della storia. Gli diciamo anche che ci sarà una consegna frequente di software funzionante in modo che possa monitorare i progressi e ottenere nuove intuizioni.

Concordando una serie di punti della storia, il cliente è garantito per ottenere un valore per i suoi soldi. Se non modifica il suo arretrato, ha il suo progetto a prezzo fisso / ambito fisso, ma la mia esperienza è che farà cambiamenti. Effettuando le stime in presenza del potenziale cliente, cerchiamo di costruire una relazione basata sull'apertura e sulla fiducia.

Siamo riusciti a convincere i clienti come te descrivono, che "vogliono un budget e una scadenza", ed erano felici che volessimo davvero capire di cosa avevano bisogno, invece di lavorare da un documento. Abbiamo dimostrato che volevamo investire in questi progetti.

Durante le sessioni di stima abbiamo stimato l'intero arretrato. Questo ha dato x punti trama. Abbiamo suggerito di aggiungere il 25% per quelle funzionalità che non erano ancora chiare o conosciute al momento. Con l'arretrato stimato allegato al contratto sono stati rassicurati sul fatto che avrebbero ottenuto tutto per il budget fisso.

Inizialmente l'offerta era tempo e materiale. Dato che volevano fare un'offerta a prezzo fisso, abbiamo suggerito di lavorare per il prezzo che abbiamo loro offerto e di usare i punti storia extra del 25% per la contingenza. Se le cose andassero bene, la parte del 25% che non era utilizzata per coprire i ritardi riscontrati verrebbe utilizzata per fornire più funzionalità al cliente.

Ciò li ha stimolati in diversi modi: in primo luogo, hanno fatto tutto il possibile per consentire ai nostri sviluppatori di lavorare il più rapidamente possibile, poiché questo era chiaramente nel loro interesse. Non abbiamo mai dovuto aspettare risposte alle domande. In secondo luogo, hanno davvero capito il concetto dei punti della storia. Prima dell'inizio del progetto, avevano già rimosso alcune delle storie e ci avevano chiesto di stimarne altre. Per questo non sono state necessarie complicate negoziazioni contrattuali.

Li abbiamo tenuti informati sui progressi e abbiamo mantenuto una comunicazione molto aperta. Hanno ricevuto un rapporto sui progressi ogni 2 settimane: il x% dei punti trama realizzati in y% del tempo stimato lascia lo z% dei punti trama aggiuntivi disponibili. Abbiamo avuto un inizio un po 'difficile, ma siamo riusciti a recuperare il ritardo con le stime entro la fine del progetto, che ha lasciato il 100% dei punti extra della trama disponibili per lo sviluppo extra. Il cliente era felice perché aveva tutto ciò di cui aveva veramente bisogno (e che era un po 'diverso dalle sue funzionalità inizialmente richieste, ne ha rimosso alcune e ne ha aggiunte altre).

Il cliente è stato anche felice perché tutto è stato consegnato nei tempi previsti (dove ha anche fatto tutto il possibile per aiutarci come inseguire i biglietti, rispondere immediatamente alle domande, coinvolgere gli utenti nelle riunioni settimanali di analisi e anche coinvolgerli nei test funzionali).

La mia azienda è stata felice perché abbiamo consegnato in tempo e budget. La mia azienda è stata anche felice perché il successo di questo progetto ha aperto le porte a più progetti. Siamo stati persino menzionati nella rivista mensile del cliente che è stata inviata a persone in tutto il mondo.

Fare buone stime è stata la parte più difficile del progetto, ma avere le sessioni di stima in anticipo ci ha aiutato a capire la difficoltà e i rischi. Ci ha permesso di fornire una stima basata su fatti e ha rimosso molte incognite.

Cercare di utilizzare i metodi Agile in un ambiente di consulenza / offerta è molto difficile quando il cliente non è a bordo.

Se sono abituati allo stile Waterfall "ecco i nostri requisiti, quanto tempo e quanto tempo ci vorrà?" tipo di progetti e lo stiamo pubblicando non c'è davvero tempo per convincerli che Agile o in qualsiasi altro modo è meglio.

Agile ha il suo vantaggio (e svantaggi ovviamente), ma francamente il cliente spesso non conosce o si preoccupa dei dettagli dietro le quinte.

Vogliono 2 cose: costo e scala temporale. E una volta che lo dici loro, lo vogliono più economico e prima. E sai cosa, vogliamo tutto. Tutti i requisiti. Nessuno può aspettare o essere tagliato.

E per quanto non mi piacciano i venditori nella maggior parte dei ceti sociali, non essere troppo duro con i ragazzi delle vendite. È un lavoro duro.

Non creano software, per lo più non hanno idea di come tutto funzioni oltre le parole d'ordine.

Tuttavia, devono elaborare scale temporali e costi basati su alcuni requisiti lanosi. Forse hanno alcuni ragazzi della tecnologia con cui far loro regnare, ma devono fare una vendita per far andare avanti le cose.

Quindi, come puoi convincere la tua forza di vendita a vendere con successo un progetto che utilizza metodi di sviluppo agili o un prodotto sviluppato utilizzando tali metodi?

Avendo la tua forza di vendita portare il cliente in ufficio. L'intero punto di agilità è ottenere un feedback immediato dal cliente in modo da poter produrre ciò che vogliono (e non di più). Portali dentro, chiedi cosa vogliono. Due settimane dopo, portali e mostra loro una demo / prototipo. Vendili su quell'interazione. Mostra loro i progressi e spiega che questo tipo di iterazione è ciò che ti piacerebbe fare in modo che ottengano esattamente ciò che vogliono.

Fornisci delle stime sulla quantità di lavoro necessario (dopo tutto è quello che è un budget), ma lascia che abbiano il potere (leggi: responsabilità) di includere ciò che vogliono adattarsi al loro budget.

Penso che la risposta sia che nella maggior parte dei casi probabilmente non lo farai. Vorrei provare a vederlo inizialmente come una piccola parte della tua attività - forse il 20%, con il resto sotto un modello tradizionale. Nel tempo avrei cercato di concentrarmi maggiormente sui prodotti e sui clienti Agile e di provare a far crescere di più quella parte.

Un'altra parte dell'affronto è forse quella di provare ad usare entrambi gli approcci. Utilizzare l'approccio a cascata con gli alti dirigenti e la gente di negoziazione del contratto. Ad esempio "un sistema per consentire ai clienti di mantenere portafogli e prendere decisioni di investimento utilizzando sia dispositivi basati su browser che telefoni cellulari (Apple e Android)". o qualcosa di simile. Quindi utilizzare Agile per lo sviluppo del team di sviluppo sulle funzionalità più dettagliate, ad esempio, Crea home page, Crea pagina di accesso, Crea cronologia gestione portolio, Crea accesso mobile, ecc.

Un'altra idea è quella di rendere Agile il tuo differenziatore. So che molte, se non la maggior parte delle grandi organizzazioni, non stanno facendo Agile. Comunque la maggior parte (la stragrande maggioranza della mia esperienza) di piccole aziende lo sono. Penso che Agile stia crescendo rapidamente e questo continuerà. Il vantaggio di questo percorso è che stai lanciando ciò che più desideri fare ai clienti che lo riconoscono già. Questo approccio richiederà un certo lavoro nel tempo senza alcuna garanzia di successo.

Potresti anche trovare una certa trazione se ai tuoi clienti piacciono i test. Avere prodotti ben collaudati può essere una vendita più semplice per alcuni clienti. Un libro che trovo utile in quest'area è "Agile Testing" di Adison Wesley Press.

Puoi anche utilizzare gli eventi attuali per supportare il tuo caso. Ad esempio, l'attuale sito di assistenza sanitaria (scritto questo nell'ottobre 2012) è un ottimo esempio di come NON gestire i cambiamenti necessari 2 settimane prima di andare in diretta. Anche l'apparente ingegneria eccessiva sarebbe stata probabilmente affrontata meglio con metodi più agili.

Contatta i clienti precedenti che sono soddisfatti del tuo lavoro. Soprattutto se sono convertiti da Cascata ad Agile. Per lo meno, i convertiti che non erano i tuoi clienti.

Le loro testimonianze (come cliente) supereranno qualsiasi cosa e tutto ciò che potresti dire. Possono affrontare le preoccupazioni e le paure del tuo nuovo cliente più di quanto tu possa mai fare.

Dal punto di vista della gestione, un budget e una scadenza sono un'esigenza aziendale per il progetto. Devi assicurarti di rispondere a tali esigenze e, se cerchi testimonianze di un'azienda sul passaggio, noterai che arriva direttamente. Se guardi le testimonianze degli sviluppatori sul passaggio, noterai che spesso non lo fa.