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

Modifica: Justin Cave ha sottolineato che questo tipo di comunicazione dovrebbe essere in primo piano nelle mie citazioni / stime. In questo caso, sono ancora interessato a sapere che tipo di linguaggio le persone usano per descrivere le attività di "apprendimento del codice esistente". Soprattutto per un'azienda che non ha mai avuto a che fare con appaltatori di software. Termina modifica

Ho un contratto per l'aggiornamento di alcuni software interni per una grande azienda. La società ha richiesto più aggiunte di funzionalità e alcune correzioni di bug. Questo è il mio primo lavoro come freelance.

Innanzitutto, avevo bisogno di familiarizzare con il funzionamento dell'applicazione: l'ho imparato come se fossi un utente.

Successivamente, ho dovuto imparare come funzionava il software. Ho iniziato con concetti generali e poi ho ridotto i dettagli necessari prima di lavorare su ogni correzione di bug e funzionalità.

Almeno all'inizio del progetto, mi ci è voluto molto più tempo per imparare il codice esistente che per scrivere le funzionalità aggiuntive.

Come posso descrivere il processo di apprendimento del codice esistente sulla fattura? (Questa parte dell'azienda di solito fa le cose internamente, quindi non ha molta esperienza con gli appaltatori di software come me, e temo che non capiscano il sovraccarico dell'apprendimento del codice di qualcun altro). Non voglio limitarmi a fissare il tempo di apprendimento sull'effettivo aggiornamento delle funzionalità, perché in alcuni casi questo renderebbe un 'semplice compito' come se mi ci fosse voluto troppo tempo. Voglio suddividere la fattura in passaggi pertinenti e comunicare che sto caricando il grande costo di apprendimento del codice di qualcun altro prima di poter aggiungere il mio.

Esiste un modo standard per descrivere questo tipo di attività durante la fatturazione di un lavoro?

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

Penso che sia una buona idea chiarire al cliente che c'è un certo sovraccarico nel velocizzare un nuovo consulente e che, se sono soddisfatti del risultato, continuare a lavorare con lo stesso consulente probabilmente li salverà i soldi.

Diagnosi del problema

È un termine familiare, se hai mai riparato la tua auto o vai da un medico, 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 simile a lavorare su un motore senza il manuale, e la società è andata a fabbricare il motore senza guardare un altro motore prima (quindi probabilmente è unico).

Un elemento pubblicitario prolisso o con parole strane riceverà più domande che davvero non vuoi. "Diagnosi dei problemi" è un concetto più o meno universalmente compreso.

Nulla in una fattura per un cliente dovrebbe essere una sorpresa per il cliente. Detto questo, spero che tu abbia già impostato l'aspettativa con il cliente che una frazione significativa del tuo tempo inizialmente sarebbe stata spesa familiarizzando con l'applicazione sia dal punto di vista dell'utente che dal punto di vista dello sviluppatore. E si spera che le tue stime per le prime funzionalità abbiano incluso un discreto periodo di tempo per familiarizzare con il codice.

Se hai già impostato quell'aspettativa con il cliente che la maggior parte del tempo sulla fattura iniziale verrà spesa familiarizzando con l'applicazione, non dovrebbe importare troppo esattamente come lo elenchi nella fattura. Usa la lingua che hai usato per fornire le stime e impostare le aspettative. Se stai solo provando a comunicarlo ora, hai un problema.

Nella mia veste di libero professionista, probabilmente definirei qualcosa di simile a "Assimilazione della conoscenza", in senso generale. E questo sarebbe stato incluso in qualsiasi preventivo fornito inizialmente al cliente.

Potrebbe non aiutarti qui, ma per riferimento futuro, ti suggerisco di renderlo più un compito attivo in futuro. Ad esempio, fatturare al cliente il tempo impiegato per 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 facilitando la comprensione della base di codice .

Anche se non c'è molta differenza tra leggere e leggere durante la documentazione, il 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 che semplicemente leggendolo. (Questo sarà certamente il caso se scrivi test contro il loro codice).

Se lo fai, puoi avere un elemento pubblicitario con fattura che dice qualcosa come "Assimilazione della conoscenza e Test / documentazione del codice legacy".

Modifica: Nella tua situazione come descritto, onestamente probabilmente mangerei il costo di questa attività. Non posso parlare con i tuoi dati finanziari, e non intendo presumere, ma quando inizi, darei un valore molto più alto alla raccolta di testimonianze e ai clienti soddisfatti rispetto ad alcune ore di fatturazione. Se ciò significa un tasso inferiore efficace all'inizio, potrebbe essere un buon investimento. Mangiare alcune ore fatturabili a lungo termine è probabilmente un piccolo prezzo da pagare per un cliente soddisfatto che pensa di aver ricevuto una bella scossa.

Correzione di un bug: analisi della causa principale.

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

Presentazione di nuovi bug: sicurezza del lavoro. :)

Con un cliente a cui piace capire come funzionano le cose e che mi ascolta con occhi sognanti, andrei con una scala Codebase Familiarization. Gli avrei già spiegato in quale flusso di dolore mi sta facendo soffrire e il vantaggio di venire da me per ulteriori aggiornamenti.

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

• Planning Phase

• Intervention Planning

  (Userei questo, in realtà, ma lo scriverei in italiano, in cui suona molto meglio)

• Quindi, forse ... Solution Planning

Mi piace la Diagnosisparte del Problem Diagnosissuggerimento di anon, ma il Problemsuono non suona bene per me. Può essere aperto a critiche lievi, di parte, ignoranti e superficiali ... che possono lasciarsi alle spalle un cattivo gusto.

Sai, tutti vogliono lanciare un dardo al consulente esterno, e lo fanno. (... come se non fosse abbastanza bravo da capire la radice del problema mentre parlava con loro, e doveva fatturare la sua incapacità, o dio sa cosa)

Il mio meccanico mi invia un conto "Cambio olio, spark plus, controllo filtri, rotazione pneumatici. Correggi sonaglio motore, prova su strada .....

Parti (dettagliate),

Lavoro x @ $ y / ora = z)

Non interrompe il lavoro, e nemmeno tu. Fattura per ore totali e descrivi ciò che hai fatto.