Come vendere lo sviluppo Agile ai client (cascata)

La chiave per farlo bene è l'utilizzo di un contratto di supporto.

Fondamentalmente, quando vendi il cliente per la prima volta, li vendi in base alla tua esperienza e lo fai in cascata. Ciò significa un contratto che stabilisce la portata e una ferma linea di demarcazione. Questo è ciò che il cliente vuole. Il cliente conosce più o meno lo scopo. Waterfall funziona molto bene, in un fixed & ambiente con ambito definito, direi che funziona migliore di agile in tali ambienti. E in questo caso dà al cliente un livello di comfort quando la tendenza è di essere nervoso perché non ha mai lavorato con te prima. Ok, Agile non è sempre meglio di waterfall.

Quindi hai un contratto a prezzo fisso per X scope. Poi dici al cliente " Guarda, vuoi apportare delle modifiche, e avrai bisogno che noi ti supportino nella post produzione, accantoniamo il 20% del tuo budget per queste cose da usare su un bisogno di base per mezzo di un contratto di supporto . "

Se dovesse verificarsi un cambiamento durante il progetto, è sufficiente rimandarlo per essere gestito sotto il contatto di supporto. (Supponendo che questa modifica provochi gravi interruzioni del progetto)

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

È quindi possibile continuare ad estendere il contatto di supporto e utilizzare semplicemente il contatto di supporto come mezzo per eseguire nuovi progetti. Inoltre, se queste ore sono 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 sono andato da uno sviluppatore e mi hanno detto che non potevano darmi una scadenza o un costo stimato, metterei in discussione la loro sanità mentale. E dire loro che semplicemente non capiscono non funzionerà: devono essere in grado di pianificare e pianificare.

Non hanno bisogno di conoscere il tuo processo di sviluppo. Hanno bisogno di sapere quanto tempo ci vorrà per sviluppare funzionalità e quanto costa. Assegna loro un numero basato sull'ipotesi (spuria) che i loro requisiti siano accurati al 100% e quando cambiano i loro requisiti, quindi modifica le stime.

Fornisce loro gli elementi pubblicitari di budget e le date di implementazione che desiderano, e quando le cose cambiano, il tuo processo ti fa apparire flessibile e accomodante.

Sembra che i tuoi venditori stiano creando un livello di incomunicabilità tra i team di sviluppo e i clienti. Se non vendono sul mercato IT da molto tempo, possono vedere il loro ruolo di "spostare il prodotto", vale a dire 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ù fedelmente possibile la lingua del cliente.

Sono un disco rotto citando questo, ma ecco: sei sul tavolo operatorio e come stai andando sotto il chirurgo dice 'ti avremo fuori di qui in tempo e nel budget'. Grande. Sarò vivo?

Se stai lavorando agli organi interni di un'azienda, ti fermi in qualche punto arbitrario? In genere un'applicazione è influenzata dalle forze né da te né dai controlli del cliente: normative, clima aziendale, comportamento della concorrenza, l'emergere di un nuovo paradigma, ecc. Se si dice semplicemente 'faremo' cosa x 'per' prezzo y '' quindi il cliente tornerà tre mesi dopo e dirà "beh ...". Generalmente 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 personale di vendita che cosa è un viaggio attraverso un canyon. Ad ogni turno ci sono sorprese. Non è possibile vedere più di tre mesi circa, quindi se un cliente richiede un progetto di 18 mesi sarà irriconoscibile dal momento in cui si è vicini al completamento. Pertanto, il rappresentante delle vendite deve iniziare trovando il profitto finanziario del progetto. Questo aumenterà le vendite di $ 10 milioni? Se è così, vale la pena investire $ 2.000.000 per realizzare ulteriori $ 10 milioni? Se il cliente e il rappresentante 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 si sente giusto" è l'impegno a fare qualcosa che rischia di essere inutile.

I due ultimi modelli di aerei di linea hanno avuto una storia di snafus. Healthcare.gov non ha nemmeno bisogno di discussione. Se riesci a trovare libri o articoli di cronaca stampa sugli aerei di linea, puoi far notare come sono state fatte certe ipotesi che si sono dimostrate ottimistiche e che i progetti hanno perso le loro scadenze ripetutamente. Spesso questo era dovuto alla sottovalutazione della complessità. Se non riesci a capire quanto sia complesso fino a quando non inizi a codificarlo, avrai bisogno di un "giro iniziale" per avere un'idea migliore dei problemi reali. Il taglio del budget dovrebbe essere una frazione del totale dei profitti aggiuntivi (o dei ricavi in alcuni casi), e quel numero deve essere più di quanto chiunque pensi che il progetto attuale avrà un costo. Se puoi mostrare come può essere passato l'ultimo traguardo senza superare il "limite di vincita", dovrebbe essere possibile vendere il progetto come uno sforzo agile.

L'ostacolo principale nel raggiungere i benefici dello sviluppo del software esterno Agile-Scrum è l'integrazione con i meccanismi di controllo esistenti. Questi meccanismi di controllo sono stipulati a causa di vari prerequisiti organizzativi e sono normalmente attualizzati utilizzando l'approccio e la metodologia della cascata lineare.

Di seguito sono riportati quattro dei seguenti prerequisiti organizzativi:

• Grandi multinazionali: in queste organizzazioni a matrice gerarchica, il controllo del portafoglio top down è la regola del giorno. L'approccio agile e spiritoso ha difficoltà a adattarsi ai controlli rigorosi. In particolare i concetti privi di piano Agile inerente, rendono l'Agile-Scrum difficile da inghiottire per l'organizzazione.

• Industrie altamente regolamentate: alcuni organismi di compliance e governance hanno bisogno di un rigido meccanismo di controllo vincolante. Questi possono essere ad esempio unità di business di attrezzature mediche, aeromobili e prodotti farmaceutici e sviluppo di prodotti. Mentre i singoli team potrebbero operare con 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 hardware, software, incorporato e altri sono sviluppati come contratto con un cliente finale in base a una serie predefinita di requisiti. In questi casi il grado di flessibilità del fabbisogno è piccolo, sebbene maggiore rispetto a quanto inizialmente previsto. Il concetto di un backlog completamente flessibile di Agile-Scrum soffre notevolmente in questi casi.

• Reparti IT generici - gran parte delle attività giornaliere e settimanali nei reparti IT gestiti dalla manutenzione è ad hoc. Le modifiche ai programmi giornalieri sono numerose e immediate. Le interferenze costanti nel lavoro di squadra sono la norma. Il concetto di time boxing e nessuna interferenza è difficile da mantenere in queste situazioni.

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

Sulla base dell'esperienza pratica, il metodo consigliato per affrontare questi scenari e altri è quello di consentire a Agile PMO di fungere da facilitatore, driver e traduttore tra i team emergenti di Agile-Scrum e gli elementi della cascata lineare.

Fai riferimento alla tabella seguente per le linee guida specifiche

Origine- Interfaccia tra cascata lineare e approcci agili di Michael Nir

Organizziamo 2 o 3 sessioni di stima con il potenziale cliente e i nostri sviluppatori in cui discutiamo del lavoro da svolgere e stabiliamo i criteri di accettazione. Gli sviluppatori stimano il lavoro nei punti storia durante la riunione.

In seguito vendiamo al cliente un numero 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 backlog / scope durante il progetto e che sarà facile grazie all'utilizzo dei punti della storia. Gli diciamo anche che ci sarà una consegna frequente del software di lavoro in modo che possa monitorare i progressi e ottenere nuovi approfondimenti.

Accettando un certo numero di punti storia, al cliente è garantito un valore per i suoi soldi. Se non cambia il suo backlog, ha il suo progetto a prezzo fisso / ambito fisso, ma la mia esperienza è che farà dei cambiamenti. Effettuando le stime in presenza del potenziale cliente, cerchiamo di costruire una relazione basata sull'apertura e sulla fiducia.

Siamo riusciti a convincere clienti come te che descrivono, che "vogliono un budget e una scadenza", ed erano contenti di voler capire veramente 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 il loro intero arretrato. Questo ha dato x punti storia. Abbiamo suggerito di aggiungere il 25% per quelle funzionalità che non erano ancora chiare o conosciute al momento. Con il backlog stimato allegato al contratto sono stati rassicurati che avrebbero ottenuto tutto per il budget fisso.

Originariamente l'offerta era tempo e materiale. Siccome volevano avere un'offerta a prezzo fisso, abbiamo suggerito di lavorare per il prezzo che gli abbiamo dato e utilizzare il 25% di punti extra per contingency. Se le cose andassero bene, la parte del 25% che non è stata usata 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ù velocemente possibile, poiché ciò era chiaramente nel loro stesso interesse. Non abbiamo mai dovuto aspettare risposte alle domande. In secondo luogo, hanno veramente capito il concetto dei punti della storia. Prima che il progetto iniziasse, avevano già rimosso alcune delle storie e ci hanno chiesto di stimare altre storie. Per questo non sono state necessarie negoziazioni contrattuali complicate.

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

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

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

Fare delle buone stime era 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 dare una stima basata sui fatti e rimosso molte delle 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 e quanto ci vorrà?" digita i progetti e li stai mettendo in palio non c'è davvero tempo per convincerli che Agile o qualsiasi altro modo è migliore.

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

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

Per quanto non piaccia agli addetti alle vendite nella maggior parte dei settori, non essere troppo severo con i venditori. È un lavoro duro.

Non costruiscono software, per lo più non hanno idea di come tutto funzioni oltre le parole chiave.

Tuttavia devono trovare delle scale temporali e costi basati su una riunione di requisiti lanosi. Forse hanno alcuni dei tecnici con loro a regnare, ma devono fare una vendita per far funzionare le cose.

So, how can you get your sales force to successfully sell a project that uses agile development methods, or a product that is developed using such methods?

Avendo la tua forza 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, 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 quello che vogliono.

Dai una stima della quantità di lavoro necessaria (dopo tutto è un budget), ma lascia che abbiano il potere (leggi: responsabilità) di includere ciò che vogliono inserire nel 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 del tuo business, forse il 20%, con il resto sotto un modello tradizionale. Col tempo cercherò di concentrarmi maggiormente sui prodotti e sui client Agile e provare a far crescere quella parte di più.

Un'altra parte dell'affrontare questo è forse cercare di utilizzare entrambi gli approcci. Utilizzare l'approccio a cascata con la dirigenza e le persone di negoziazione del contratto. Ad esempio "un sistema che consente ai clienti di mantenere i portafogli e prendere decisioni di investimento utilizzando sia dispositivi basati su browser che dispositivi mobili (Apple e Android)." o qualcosa di simile. Quindi utilizzare Agile per lo sviluppo del team di sviluppo sulle funzionalità più dettagliate, ad esempio Crea pagina iniziale, Crea pagina di accesso, Crea cronologia gestione Portolio, Crea accesso mobile, ecc.

Un'altra idea è quella di rendere Agile il tuo elemento di differenziazione. So che molte se non la maggior parte delle organizzazioni non stanno facendo Agile. Tuttavia la maggior parte (la stragrande maggioranza nella mia esperienza) di piccole aziende sono. Penso che Agile stia crescendo rapidamente e questo continuerà. Il vantaggio di questo percorso è che stai proponendo ciò che desideri di più ai clienti che già lo riconoscono. Questo approccio richiederà un certo impegno nel tempo senza garanzie di successo.

Potresti anche trovare un po 'di trazione se ai tuoi clienti piace testare. Avere prodotti ben testati può essere una vendita più facile ad alcuni clienti. Un libro che trovo utile in quest'area è "Agile Testing" di Adison Wesley Press.

Puoi anche utilizzare gli eventi correnti per supportare il tuo caso. Ad esempio il sito di assistenza sanitaria corrente (scrivendo questo a ottobre 2012) è un ottimo esempio di come NON gestire le modifiche necessarie 2 settimane prima del go-live. Anche l'apparente sovraingegnerizzazione sarebbe stata probabilmente indirizzata a metodi più agili.

Contatta i clienti precedenti che sono contenti del tuo lavoro. Soprattutto se sono convertiti da Waterfall a Agile. Per lo meno, converte quelli che non erano i tuoi clienti.

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

Dal punto di vista della gestione, un budget e una scadenza sono esigenze aziendali per il progetto. Devi assicurarti di soddisfare queste esigenze e, se guardi le testimonianze di un business riguardo al passaggio, noterai che arriva direttamente. Se guardi le testimonianze dello sviluppatore sul passaggio, noterai che spesso non lo fa.