Come dovrei descrivere il processo di apprendimento del codice di qualcun altro? (In una situazione di fatturazione.) [Chiuso]

Vorrei fatturare attività come "Esamina le funzionalità esistenti" e / o "Esamina il codice esistente". A seconda della complessità delle nuove funzionalità, aggiungerei un'attività "Design xxx" che includerebbe il tempo impiegato a calcolare i punti di integrazione nel codice esistente.

Penso che sia una buona idea chiarire al cliente che c'è un sovraccarico nel portare a nuova vita un nuovo consulente e che, se sono soddisfatti del risultato, continuando a lavorare con lo stesso consulente probabilmente li salverà.

Diagnosi dei problemi.

È un termine familiare, se la tua auto viene riparata o se vai da un dottore, la diagnosi è un termine comune per capire cosa c'è che non va. È anche preciso, devi andare sotto il cofano e vedere come tutto è collegato per capire cosa non funziona. È davvero come lavorare su un motore senza il manuale, e la società è andata a fare il motore senza guardare prima un altro motore (quindi è probabilmente unico).

Un elemento pubblicitario prolisso o stranamente formulato otterrà più domande che davvero non vorresti. "Problem diagnosis" è un concetto più o meno universalmente inteso.

Nulla su una fattura per un cliente dovrebbe essere una sorpresa per il cliente. Detto questo, spero che tu abbia già stabilito con il cliente che una frazione significativa del tuo tempo sarebbe inizialmente impiegata per familiarizzare con l'applicazione sia dal punto di vista dell'utente che dal punto di vista dello sviluppatore. E le tue stime per le prime funzionalità speravano di includere una quantità di tempo decente per familiarizzare con il codice.

Se hai già impostato questa aspettativa con il cliente che la maggior parte del tempo sulla fattura iniziale verrà utilizzata per familiarizzare con l'applicazione, non dovrebbe importare troppo esattamente come lo si elenca sulla fattura. Utilizza qualsiasi lingua tu abbia usato per fornire le stime e stabilire le aspettative. Se stai solo cercando di comunicarlo ora, hai un problema.

Nella mia veste di libero professionista, probabilmente definirei qualcosa come "Assimilazione della conoscenza", nel senso generale. E, questo sarebbe stato incluso in qualsiasi stima fornita inizialmente al cliente.

Potrebbe non aiutarti, ma per riferimento futuro ti suggerisco di rendere questa attività più attiva in futuro. Ad esempio, fatturare al cliente il tempo impiegato a passare e aggiungere commenti a codice non commentato, aggiungere test unitari a codice non testato, ecc. Questi sono esempi di attività che aggiungono almeno un piccolo valore mentre facilitano la comprensione del codice base .

Anche se non c'è molta differenza tra leggere e leggere durante la documentazione, il tuo cliente avrà probabilmente una piccola preferenza psicologica per questi compiti più "attivi". E, in realtà potresti imparare di più documentando il codice di qualcun altro piuttosto che semplicemente leggendolo. (Questo sarà certamente se si scrivono test contro il loro codice).

Se lo fai, puoi avere una riga di fattura che dice qualcosa come "Assimilazione della conoscenza e test / documentazione del codice legacy".

Modifica: nella tua situazione come descritta, probabilmente avrei onestamente mangiato il costo di questa attività. Non riesco a parlare con i tuoi dati finanziari, e non intendo presumere, ma quando inizierai a dare più valore alle testimonianze e ai clienti soddisfatti di alcune ore di fatturazione. Se ciò significa un tasso inferiore efficace nei primi anni, potrebbe essere un buon investimento. Mangiare un po 'di ore fatturabili a lungo termine è probabilmente un piccolo prezzo da pagare per un cliente soddisfatto che pensa di aver avuto una bella scossa.

Correzione di un bug: analisi della causa principale.

Nuova funzionalità: analisi, progettazione, integrazione e test.

Introduzione di nuovi bug: sicurezza del lavoro. :)

Con un cliente che ama capire come funzionano le cose e mi ascolta con occhi sognanti, andrei con una percentuale di Codebase Familiarization . Gli avrei già spiegato quale flusso di dolore mi stava mettendo dentro e il vantaggio di venire da me per ulteriori aggiornamenti.

Con l'altro tipo di cliente ... (stesso trattamento, ma lui non ascolta evidentemente una sola parola che sto dicendo ) vorrei andare con qualcosa sulla falsariga di:

• Planning Phase

• Intervention Planning

  (Io userei questo, in realtà, ma lo scriverei in italiano, in cui suona meglio)

• Quindi, forse ... Solution Planning

Mi piace la parte Diagnosis del Problem Diagnosis suggerimento di anon , ma Problem non mi sembra corretta. Può essere aperto a critiche miti, prevenuti, ignoranti e superficiali ... che possono lasciare dietro di sé un cattivo gusto.

Sai, tutti vogliono lanciare una freccia al consulente esterno, e lo fanno. (... come se non fosse abbastanza bravo da capire la radice del problema mentre parlava con loro, e ha dovuto fatturare la sua mancanza di clamore, o dio sa cosa)

Il mio meccanico mi invia una fattura "Cambia olio, scintilla più, controlla i filtri, rotazioni dei pneumatici.Fissaggio del motore, test su strada .....

Parti (dettagliate),

Lavoro x @ $ y / ora = z)

Non abbatte il lavoro, né tu dovresti. Bill per un totale di ore e descrivi cosa hai fatto.