Aspettative del CFO e Sviluppo della Scrum

Dopo aver avuto un'interessante conversazione su Twitter con Berry Hawkins ( link ) penso di avere la mia risposta.

Il problema è che stavo ancora pensando che dovevo avere il mio account per gli sviluppatori per il tempo dedicato alla progettazione del software come spesa.

La soluzione consiste nel verificare se l'attività è prima o dopo che il prodotto o la funzionalità sono considerati fattibili. Qualsiasi attività, indipendentemente dal fatto che si tratti di progettazione, sviluppo o test, può essere capitalizzata fintanto che ha superato la fase di ricerca.

Ho scritto alcune nuove linee guida e le ho inviate al mio CFO per la revisione (dita incrociate). Il vero test saranno gli auditor, ma penso che ottenere il CFO a bordo sia il primo passo. Grazie per tutti i tuoi commenti.

Questo non dovrebbe essere il tuo problema .

La capitalizzazione dei costi è il tuo CFO aziendale e / o il problema del contabile. Le regole variano in diverse giurisdizioni. I contabili sono gli esperti e dovrebbero capitalizzare i costi secondo le regole contabili pertinenti.

Al massimo, potrebbe essere necessario chiederti alcune informazioni di supporto (ad es. delle 5.000 ore di sviluppo lavorate nel trimestre, puoi stimare quale percentuale era sul nuovo sviluppo del software o sulla valorizzazione delle risorse software esistenti?). Ma sta a loro chiederti la domanda giusta.

Se stai principalmente sviluppando un nuovo software in un prodotto che la tua azienda vende o intende vendere (vale a dire che il prodotto conta come un bene immateriale che restituisce benefici economici futuri), allora è perfettamente possibile capitalizzare il 100% dei costi di sviluppo. Inoltre, alcuni paesi hanno incentivi speciali per gli investimenti in R & D, che è possibile che il lavoro di sviluppo del software possa essere idoneo.

La metodologia di sviluppo del software che usi è irrilevante, l'unica cosa che probabilmente conta è avere un modo di categorizzare quali costi sono stati spesi su progetti o beni capitalizzabili. Ma lo stesso problema si applica allo sviluppo a cascata!

Ma, per carità, lascia che i ragionieri risolvano tutto. Non ti aspetti che il CFO scriva codice, vero?

Ho letto il link che hai postato. È semplice e crivellato di presupposti! Se devi difenderlo davvero, sfortuna!

Tuttavia, direi, convincere il CFO non dovrebbe essere difficile (una volta che sai cosa conta).

Il punto è che nessun CFO è veramente preoccupato per il denaro speso (se c'è una giusta giustificazione) tanto quanto è preoccupato che i soldi vengano sprecati perché alla fine il progetto fallisce. (L'articolo che hai pubblicato ignora semplicemente alcune semplici situazioni di vita reale); Se vuoi veramente promuovere Agile, non promuovilo mai per dire che ridurrà i costi. Il punto principale è che

1. riduce i rischi: ti assicurerà che non dovrai cancellare tutta la roba! Se non lo farai, ti assicurerai che con Agile / Scrum ti saresti reso conto molto prima di altri metodi.

2. riduce il rischio di aspettare di arrivare al mercato (e di iniziare le entrate) molto prima dell'attesa dell'intero registro.

3. riduce il rischio di costruire un progetto sbagliato!

Questo è vero con qualsiasi metodo iterativo e non solo Agile / Scrum. Quello che devi davvero mostrare non è che Agile sia fatto meglio; ma quanto sono orribili le cose quando i progetti falliscono. (Immagino che sia qui che spiegare il CFO è persino meglio di quanto non facciano i responsabili IT perché iniziano subito a difendere cose!).

In generale, se l'organizzazione (e in particolare i leader) è in sintonia con tali filosofie (come cascata), è probabilmente una cattiva idea vendere-promessa . È meglio dimostrarlo facendo . Inizia in piccolo dove hai un controllo constrongvole. E probabilmente la prima pugnalata che farei è mettere in discussione - perché iniziare con così tante funzioni? Dividiamoli in 10 versioni! Quindi, chi ti impedisce di incontrare i clienti? Passo dopo passo, inizia ad aderire ad alcune parti dell'Agile senza fare rituali esplicitamente annunciati. Una volta, hai successo, la gente vedrà il punto su ciò che Agile porterà a bordo.

Quando formuli raccomandazioni specifiche (piuttosto che filosofia) le persone tendono ad ascoltare molto meglio.

Stai tralasciando molte informazioni e, di conseguenza, intendo che non sei una società di consulenza; poiché in quel caso, a mio parere, tutte le ore che tutti i fatturabili sono in grado di essere capitalizzati.

Ok, onestamente, quello che il CFO vuole sentire è un buon argomento per il motivo per cui un'enorme percentuale delle ore sono ore non R & D - e per quanto sono in grado di dire ruling number 86 da parte della FASB è l'unica regola che conta; sebbene raccomando vivamente di leggere il documento reale e non il riassunto .

A mia conoscenza, le uniche ore che sarebbero sempre state classificate come R & D in Scrum sono durante i picchi, tutte le altre ore potrebbero essere considerate ore non R & D secondo me; Significa che Scrum sta solo facendo ciò che è fattibile.

Inoltre, se leggi le linee guida sulla contabilità, non sono definibili fattibili per fattibilità del mercato, ma la convinzione che lo sforzo sia fattibile dopo che è stata eseguita una completa iterazione del lavoro. Si potrebbe facilmente affermare che una singola iterazione è uno sprint , che include "Ai fini di questa Dichiarazione, la fattibilità tecnologica di un prodotto software per computer viene stabilita quando l'impresa ha completato tutta la pianificazione, progettazione, codifica, e testare le attività necessarie per stabilire che il prodotto può essere prodotto per soddisfare le sue specifiche di progettazione incluse funzioni, caratteristiche e requisiti tecnici di prestazione. " Dopodiché tutto è in grado di essere in maiuscolo, a meno che tu non creda che una parte del progetto "non possa essere prodotta".

(Infine, non sono un CPA, e probabilmente nessun altro qui è - e anche se lo fossero, prendere in considerazione Internet per le pratiche contabili è quello che è. Se non sei soddisfatto di nessuno dei le risposte, quindi onestamente suggerirei alla compagnia di assumere una terza parte, renderle responsabili per la loro opinione e farla finita.)