Il vecchio programmatore è scomparso. In procinto di assumere un altro programmatore. Come approccio a questo? [chiuso]

In base all'interazione che abbiamo avuto nei commenti, partirò dal presupposto che non hai allontanato il tuo unico sviluppatore a causa di cose personali. Tuttavia, basandomi su quella conversazione, farò un'altra ipotesi sul fatto che questa battuta d'arresto è ancora in gran parte la tua responsabilità come gestore assumente. Come hai detto, non hai TUTTA l'esperienza con gli sviluppatori, ma come prendi una decisione su come assumerne uno?

Sembra che tu abbia fatto del tuo meglio, ma hai assunto qualcuno che semplicemente non poteva gestire le dimensioni di questo progetto, ha costruito fondamenta instabili che si sono sbriciolate sotto di lui e poi se ne è semplicemente andato. Sfortunatamente, la differenza tra sviluppatori e imprenditori è che i primi vengono pagati ogni ora / stipendio ma possono scegliere di andare e venire a loro piacimento. È stato pagato per le ore in cui ha lavorato e se n'è andato quando ha scelto di non essere più pagato. Niente di ciò che puoi fare per questo.

E adesso? Sembra che tu abbia iniziato a seguire la strada della sostituzione delle persone con il processo. Se solo avessi abbastanza documentazione, la gente potrebbe andarsene e altri potrebbero riprendere da dove avevano lasciato. IMO che non funziona e se funziona, sarà comunque molto più costoso di avere un team affidabile di dipendenti permanenti. Il management di varie aziende negli ultimi 30 anni ha cercato di sostituire le persone con una documentazione sufficiente (incluso il mio ultimo lavoro) e hanno fallito ogni volta. Ecco perché ho deciso di cambiare lavoro e ora sono bloccati con i loro documenti obsoleti e mai precisi, mentre sto avendo il tempo della mia vita in una nuova startup.

Quello che farei se fossi in te sarebbe cercare di trovare la persona giusta con abbastanza capacità ed esperienza per raccogliere questo progetto e portarlo a termine. Questo include non solo capacità di codifica, ma anche design, architettura e gestione di base del progetto. Non cercare di definire come fa il suo lavoro, o quanti documenti ha bisogno di produrre. Concentrati solo sulla ricerca della persona giusta e preparati a pagare di conseguenza. Quando lo trovi, assicurati che il tuo ruolo sia quello di supportarlo e rimuovere gli ostacoli dalla sua strada, non dal monitor / micromanage. Non sto insinuando che tu l'abbia fatto prima, ma so che molti manager tendono a farlo e questo è controproducente.

Parla con altri imprenditori, possibilmente quelli con più esperienza di ingegneria del software. Leggi questi forum e trova una serie di domande per chiedere il tuo possibile affitto. Presenta il problema e chiedi quale sarebbe l'approccio. Se è il ragazzo giusto (e supponendo che non abbia visto questa pagina), dovrebbe essere in grado di suggerire molte delle cose che altre persone hanno già suggerito in termini di cosa dovrebbe essere fatto nella tua azienda quando inizi a recuperare. Chiedigli di definire un piano dal momento in cui viene assunto al momento della spedizione della v1.0. Come ti porterà lì. Chiedi aiuto per intervistare una persona del genere.

Solo alcuni dei miei pensieri: il tracciamento dei bug è un must (Jira costa $ 10 per una squadra di massimo 10 persone). Il controllo del codice sorgente è un must (il git è gratuito, perché le spese per un team di un massimo di 5 persone sono inferiori). Il tuo codice è la tua documentazione. Non i tuoi documenti di parole scritte. Dovrebbe rivedere il codice e conservare ciò che è recuperabile; buttare via il resto e concentrarsi sulla scrittura di codice manutenibile e leggibile. Salva la documentazione per pochi documenti di progettazione di pochi pagine di alto livello. Deve conoscere la tecnologia su cui stai lavorando. Non assumere qualcuno con solo buone intenzioni; non puoi permetterti di farli imparare sul tuo tempo. Chiedete loro quali altri progetti hanno fatto (sfortunatamente voi o qualcuno che trovate dovreste tenere il passo con l'aspetto tecnico delle cose). Stai cercando qualcuno con abbastanza esperienza ma allo stesso tempo non troppo che quella scintilla di eccitazione è già bruciata. Trova qualcuno che ha fame per avere un impatto. La metodologia che propone o segue dovrebbe consentire di vedere il lavoro su base regolare (di una o due settimane) e di fornire un feedback immediato. Non assumere CHIUNQUE che dice, sarà pronto in esattamente 7.4 mesi, ti farò sapere quando è fatto.

Buona fortuna

Questa è una situazione strana, e sono abbastanza sicuro che non stai raccontando tutta la storia. Ho lavorato con molte persone, alcune delle quali sono partite per vari motivi (io sono il loro collega), ma non provate a dirci che tutto è andato benissimo e un giorno solo nessun contatto.

Ma non è un problema. Almeno non più; dovresti imparare dal tuo errore e cercare di non ripeterlo in futuro. E sì, sto suggerendo strongmente che il 50% è colpa tua se se ne va.

Ora a proposito di risolvere il problema attuale:

1. Prova a contattare il tuo programmatore. Legge la tua e-mail - offrigli denaro per la documentazione / risolvendo i bug più importanti. Nessun altro sarà in grado di aggiustare quelli più veloci di lui. Non funziona? Prova a trovare dove lavora, contatta quell'azienda e racconta la tua storia. Una buona compagnia non assumerà una persona che potrebbe fare lo stesso per loro. Almeno gli diranno di finire la documentazione per te.

   NOTA: non vuoi che quella persona torni, hai solo bisogno della documentazione finita

2. Siate pronti a rendere nullo il vostro valore di un anno di lavoro. Potrebbe essere fuggito quando hai chiesto risultati e sapeva che non poteva consegnare. È possibile che il codice sia pieno di hack, implementazione sporca e scarsa qualità complessiva. Anche se tornasse, probabilmente non avrà le competenze o il tempo per farlo bene.

3. Cerca un'altra persona. Ha bisogno di conoscere le stesse tecnologie (linguaggio di programmazione, strutture, ecc.). Se la qualità del codice è buona, potrebbe continuare, in caso contrario, sarà in grado di effettuare il refactoring. Sì, il refactoring richiede tempo senza l'implementazione di nuove funzionalità, ma rende il codice gestibile ed è ciò di cui hai bisogno. Inoltre, una persona che può refactoring codice errato è un programmatore davvero buono, tenetelo stretto.

   NOTA: è sciocco pagare in anticipo. L'intera idea di stipendio è di pagare per il lavoro svolto. Non per una promessa fatta:)

4. Crea elenchi. È nel tuo miglior interesse avere un piano. Una specifica tecnica che una volta letta permetterà al nuovo programmatore di comprendere il lavoro e le tappe fondamentali. Avere almeno tre documenti importanti:

   • Descrizione generale del progetto: un documento che permetterà anche a un non programmatore di sapere di cosa tratta il progetto.

   • Timeline - quale parte e quando ti aspetti di essere pronto? Cosa è già stato fatto?

   • Specifiche tecniche: è lunga. È IL documento che un programmatore vuole leggere. Separalo in parti logiche e descrivi nel modo più dettagliato possibile le funzionalità e il flusso di lavoro di quella parte specifica.

Lavorare con le aziende non è poi così bello; le tue possibilità non miglioreranno. E pagherai più del dovuto 10 volte se assumi un solo programmatore. Se hai una piccola squadra, diciamo 3-5 persone, basta assumere un programmatore disposto a diventare un capo squadra. Farà un lavoro molto migliore nella gestione del team.

Documentare il codice successivamente da un altro programmatore? È solo la mia esperienza e opinione a dirti che non dovresti intraprendere questa strada.

Senza una conoscenza più approfondita della qualità di quella base di codice, la mia opinione è che il tuo approccio migliore è assumere un nuovo programmatore per correggere i bug, mantenere e possibilmente apportare le modifiche necessarie.

Quell'opinione ha il punto chiave di eventuali modifiche (modifica o aggiunta), in quanto richiedono l'adempimento di un requisito. Ciò significa che una sorta di specifica dei requisiti deve essere scritta. Questo è un documento.

Che porta al punto di mantenere l'intero progetto. Non hai detto nella tua domanda se i requisiti dei programmi correnti o persino la documentazione funzionale approssimativa esiste, ma è lì che devi concentrarti ora.

Nel caso in cui non possiedi alcuna documentazione, a questo punto, spetta a te riempire quel vuoto. Non puoi assumere un programmatore per decodificare la tua applicazione e creare miracolosamente la documentazione da quella . Devi "spiegare" cosa vuoi che faccia il programma (anche se significa ripensare a ciò che è già stato programmato).

Quando hai scritto quel documento (che si tratti di specifiche di requisiti o funzionali), otterrai risultati migliori dall'assunzione di un nuovo programmatore dato che puoi consegnare la documentazione e iniziare a lavorare da lì.

Ci sono anche molti programmi che producono documenti dal codice sorgente, che è un buon modo per produrre uno scheletro di spiegare il vero codice sorgente (questo è nell'area delle specifiche tecniche) che puoi solo lavorare nel contesto della spiegazione del aspetti tecnici della funzionalità specificata nelle specifiche funzionali, che specifica la funzionalità dei requisiti specificati nella specifica dei requisiti.

Quindi sì, la mia opinione è di assumere un programmatore per risolvere i bug. Dopo aver corretto i bug che dovevi concordare, potresti discutere l'aspetto della documentazione come un altro contratto. Con la fortuna hai ingaggiato un programmatore che ha una certa esperienza e può contribuire a quali passi dovresti fare da lì.

Ecco come affronterei il problema:

• Hai la conoscenza del dominio. Sapete quali funzioni sono disponibili sul sito web ora, quali vorreste aggiungere in futuro e probabilmente potete elencare alcuni bug che sono stati segnalati dagli utenti.

• C'è questa pila di codici seduti lì, abbandonati a se stessi in un angolo. Potrebbe essere bacato, ma offre comunque valore dal momento che il sito ha utenti attivi. Una completa riscrittura sarebbe quindi un errore IMO.

Il ponte tra l'esperienza del dominio e il codice è stato interrotto quando il programmatore è uscito. È necessario ricostruirlo in modo che il codice base possa essere nuovamente sincronizzato con i requisiti e che possano essere sviluppati futuri aggiornamenti.

Il fatto è che quel ponte non può essere interamente fatto di documentazione. Il software è tanto umano quanto tecnico. Se non si spiega al nuovo programmatore ciò che si aspetta con grande dettaglio, sarà difficile dedurlo dal solo codice, tanto più se il programmatore precedente ha scritto codice criptico, scarsamente documentato e scarsamente testato. E se non lavori in stretta collaborazione con il nuovo programmatore per trovare un modo automatico e continuo per verificare che il codice corrisponda ai tuoi requisiti, in altre parole per rendere il bridge più robusto, il problema è destinato a ripetersi.

• Sedetevi regolarmente (anche virtualmente) con il nuovo programmatore per le sessioni di elaborazione della conoscenza del dominio. Durante ciascuna di queste sessioni, scrivi insieme le specifiche per una piccola parte del tuo prodotto. Può essere una singola pagina web, può essere una caratteristica. Rendili specifiche eseguibili (a la Sviluppo guidato dal comportamento ) aumenterà il tuo livello di fiducia nel funzionamento del bridge, perché puoi eseguirli continuamente ed essere avvisati quando c'è qualcosa di sbagliato. Renderà anche la vita dello sviluppatore più facile.

  Dopo una sessione, lo sviluppatore è in grado di tornare al suo lavoro e scrivi test di livello inferiore che convalidano che il codice corrente è conforme a spec. Se non è conforme, allora il programmatore ha tutto lui ha bisogno di aggiustarlo È anche importante rimanere a disposizione per qualsiasi domanda che potrebbe avere.

• Cerca di mantenere una collaborazione stretta e continua tra te e i programmatori sul tuo progetto e assicurati che ciò sia vero anche tra di loro. Ciò è necessario se vuoi che la cultura funzionale e tecnica attorno al tuo progetto continui a vivere, evitando problemi come quello che stai vivendo ora. Questo ovviamente richiede non solo 2+ sviluppatori che lavorano al tuo progetto, ma anche che condividono tra loro la conoscenza di tutto ciò che scrivono. Quindi si può agire come un failover quando un altro viene a mancare. Tecniche come programmazione coppie e le recensioni del codice sono buoni modi per farlo.

Semplicemente aggiungendo ciò che tutti hanno detto,

Se non riesci a far sì che il vecchio programmatore possa documentare il suo codice anche a un prezzo, non aspettarti che qualcun altro sia in grado di documentarlo meglio. Quindi ecco alcune opzioni su cosa puoi fare per rendere produttivo il nuovo programmatore il primo giorno.

1. Ottieni un database di bug e inizia a inserire tutti i bug che hai trovato. Questa è la lista delle cose da fare prioritaria del programmatore. Documentalo bene e inserisci quanti più dettagli possibili (file sorgente / causa principale, cosa fa e cosa dovrebbe fare). Esistono molti software di tracciamento dei bug gratuiti, come Bugzilla , Redmine e JIRA . Sentiti libero di usare quello che preferisci.
2. Crea una scheda delle specifiche per il tuo progetto. Ciò darà al nuovo programmatore una certa direzione dopo che i bug saranno stati cancellati. Puoi consultare la guida di Joel sulle specifiche di scrittura .
3. Crea una pianificazione o una linea del tempo per il tuo progetto. Dovrebbero avere scadenze e pietre miliari in cui vengono pagati per il lavoro che hanno reso, piuttosto che pagarli in anticipo.

Ora che è fuori mano, puoi iniziare a cercare un programmatore. E come ha detto Creative Magic, esternalizzare il lavoro alle aziende può portare a un disastro o far saltare il prezzo all'infinito e oltre.

Questa volta, inizia a pianificare correttamente il fattore di bus quando assumi i programmatori. Le persone vanno e vengono e non c'è nulla che tu possa fare al riguardo, quindi preparati per il peggio questa volta con due programmatori, o come ha detto Uooo, prendi un programmatore e un tester.

Ora, una volta che i programmatori sono nel negozio con te, puoi iniziare a chiedere loro di documentare il loro codice andando avanti piuttosto che chiedere loro di documentare il vecchio codice, davvero, dimenticalo.

Altre cose da considerare quando si ottiene un nuovo programmatore, assicurarsi che conoscano il controllo del codice sorgente e i test automatici. Inoltre, prova ad ottenere il maggior numero possibile di controlli sul Joel Test il più possibile con il loro aiuto, puoi solo fare così tanto da solo.

Quindi, il tuo unico programmatore era hit da un autobus e ora è necessario sostituirlo.

Potresti provare a citare in giudizio il tuo ex programmatore, in base al tuo contratto, o scoprire cosa c'è che non va in lui. Supponendo che non tornerà, questo non ti aiuterà.

• Vuoi fare il tuo prodotto, quindi cerca un programmatore che lo abbia esperienza nel mantenimento e nello sviluppo di sistemi esistenti. Vorrei non concentrarsi sul dire al tuo programmatore cosa fare in quale ordine. Rendere certo di assumere qualcuno professionista, che scrive documentazione e unità prova quando necessario.
• Da parte tua, puoi assicurarti che il nuovo programmatore abbia tutto il necessario per il suo lavoro : requisiti, un potente macchina funzionante, e così via. Vuoi un programmatore professionista, quindi offrigli un ambiente di lavoro professionale.

Inoltre, pensa di assumere un secondo sviluppatore per rendere più facile questo tipo di situazioni difficili in futuro. Un tester sarebbe utile anche per l'assicurazione della qualità.