Il vecchio programmatore è scomparso. Sta per assumere un altro programmatore. Come posso affrontarlo? [chiuso]

Dopo aver trascorso più di un anno a lavorare su un progetto di social network usando WordPress e BuddyPress , il mio programmatore è scomparso, anche se è stato pagato ogni singola settimana, per l'intero periodo. Sì, non è morto perché ho usato un tracker e-mail per confermare e vedere che apre le mie e-mail, ma non risponde. Sembra che abbia un altro lavoro. Mi chiedo perché non potesse dirlo. E gli ho persino pagato uno stipendio anticipato per lavoro che non ha svolto.

Il problema è che non ho mai richiesto la documentazione completa per la maggior parte delle funzioni in cui ha codificato. E c'erano MOLTE funzioni per questo periodo di oltre 1 anno, e alcune di esse hanno bug che non ha ancora risolto. Ora sembra tutto confuso.

Qual è la prima cosa che dovrei fare ora? Come procedo?

Immagino che la prima cosa da fare sarà ottenere un altro programmatore, ma voglio iniziare con il piede giusto facendo documentare tutto il codice attuale in modo che qualsiasi programmatore possa lavorare su tutte le funzioni senza problemi.

È la prima cosa che dovrei fare? Se sì, come posso procedere?

Qual è il tipo standard di documentazione richiesta per qualcosa del genere? Posso ottenere un programmatore che farà semplicemente la documentazione per tutti i codici e risolverà i bug o la documentazione non è davvero importante?

Inoltre, pensi che ottenere un altro programmatore "individuale" sia meglio o ottenere un'azienda che ha programmatori che lavorano per loro, in modo che se il programmatore assegnato al mio progetto scompare, un altro può sostituirlo, senza il mio coinvolgimento? Penso che questo sia l'approccio che avrei dovuto adottare all'inizio.

Sulla base dell'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 che questa battuta d'arresto sia ancora principalmente la tua responsabilità come responsabile delle assunzioni. Come hai detto, non hai assolutamente alcuna 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 riusciva a gestire la portata di questo progetto, ha costruito fondamenta traballanti 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. Venne pagato per le ore in cui lavorava e se ne andò quando decise di non essere più pagato. Non puoi fare niente a riguardo.

Così quello che ora? Sembra che tu abbia iniziato a seguire la strada della sostituzione delle persone con il processo. Se solo tu avessi abbastanza documentazione, le persone potrebbero andarsene e gli altri potrebbero riprendere da dove avevano interrotto. IMO che non funziona e se funziona, sarà comunque molto più costoso che avere un team affidabile di dipendenti permanenti. La direzione di varie aziende negli ultimi 30 anni ha cercato di sostituire le persone con sufficiente documentazione (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 accurati, mentre sto vivendo 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. Ciò include non solo competenze di codifica, ma anche design, architettura e gestione di base del progetto. Non tentare di definire come svolge il suo lavoro o quanti documenti deve 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 sulla sua strada, non il monitoraggio / micromanage. Non sto insinuando che lo hai fatto prima, ma so che molti manager tendono a farlo e questo è controproducente.

Parla con altri imprenditori, possibilmente quelli con più background di ingegneria del software. Leggi questi forum e presenta una serie di domande da porre al tuo eventuale noleggio. 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 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 a quando verrà spedita la tua v1.0. Come ti porterà lì. Chiedi aiuto per intervistare una persona del genere.

Solo alcuni dei miei pensieri: il tracciamento dei bug è d'obbligo (Jira costa $ 10 per un team di massimo 10 persone). Il controllo del codice sorgente è un must (git è gratuito. Per una squadra di un massimo di 5 persone, il costo delle attività è eccessivo). Il tuo codice è la tua documentazione. Non i tuoi documenti scritti. Dovrebbe rivedere il codice e mantenere ciò che è salvabile; buttare via il resto e concentrarsi sulla scrittura di codice gestibile e leggibile. Salva la documentazione per pochi documenti di progettazione di alto livello e di poche pagine. Deve conoscere la tecnologia su cui stai lavorando. Non assumere qualcuno con buone intenzioni; non puoi permetterti di farli imparare sul tuo tempo. Chiedi loro quali altri progetti hanno fatto (sfortunatamente tu o qualcuno che trovi potresti dover tenere il passo con l'aspetto tecnico delle cose). Stai cercando qualcuno con abbastanza esperienza ma allo stesso tempo non troppo quella scintilla di eccitazione si è già esaurita. Trova qualcuno che ha fame per avere un impatto. La metodologia che propone o segue dovrebbe consentirti di vedere il lavoro su base regolare (periodi di una o due settimane) e di fornire un feedback immediato. Non assumere nessuno che lo dica, sarà pronto tra 7,4 mesi esatti, ti farò sapere quando sarà finito.

In bocca al lupo

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

Ma questo non è un problema. Almeno non più; dovresti imparare dal tuo errore e cercare di non ripeterlo in futuro. E sì, sto fortemente suggerendo che il 50% è colpa tua o sua partenza.

Ora sulla risoluzione del problema attuale:

1. Prova a contattare il tuo programmatore. Legge la tua e-mail - offrigli denaro per la documentazione / correzione degli errori più cruciali. Nessun altro sarà in grado di risolvere quelli più velocemente 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 si desidera riprendere quella persona, è sufficiente la documentazione finita

2. Preparati che il tuo lavoro di un anno sarà annullato. Potrebbe essere fuggito quando gli hai chiesto i risultati e sapeva che non poteva consegnare. È possibile che il codice sia pieno di hack, implementazione sporca e qualità generale scadente. Anche se tornerà, probabilmente non avrà le capacità o il tempo per farlo bene.

3. Cerca un'altra persona. Deve conoscere le stesse tecnologie (linguaggio di programmazione, framework, ecc.). Se la qualità del codice è buona, potrebbe continuare, in caso contrario, sarà in grado di riformattarla. Sì, il refactoring richiede tempo senza l'implementazione di nuove funzionalità, ma rende il codice mantenibile ed è quello che ti serve. Inoltre, una persona in grado di refactificare un codice errato è un programmatore davvero bravo, tienilo stretto.

   NOTA: è sciocco pagare i soldi in anticipo. L'idea del salario è di pagare per il lavoro svolto. Non per una promessa fatta :)

4. Crea elenchi. È nel tuo interesse avere un piano. Una specifica tecnica che una volta letta consentirà al nuovo programmatore di comprendere il lavoro e le pietre miliari. 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.

   • Cronologia: quale parte e quando pensi di essere pronta? Cosa è già stato fatto?

   • Specifiche tecniche: questa è lunga. È il documento che un programmatore vuole leggere. Separalo in parti logiche e descrivi il maggior numero di dettagli possibile per 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ù di 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 della squadra.

Documentare il codice in seguito da un altro programmatore? È solo la mia esperienza e opinione per dirti che non dovresti prendere quella strada.

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

Tale parere ha il punto chiave di possibili modifiche (modifica o aggiunta), in quanto devono soddisfare un requisito. Ciò significa che deve essere scritta una sorta di specifica dei requisiti. Questo è un documento

Ciò porta a un punto di mantenimento dell'intero progetto. Nella tua domanda non hai detto se esistono i requisiti dei programmi attuali o anche una documentazione funzionale approssimativa, ma è qui che dovresti concentrarti ora.

Nel caso in cui non abbiate alcuna documentazione, a questo punto, spetta a voi riempire quel vuoto. Non è possibile assumere un programmatore per decodificare la propria applicazione e miracolosamente modellare la documentazione . Devi "spiegare" cosa vuoi che faccia il programma (anche se ciò significa spiegare di nuovo cosa è già stato programmato.)

Quando hai scritto quel documento (sia esso sotto forma di requisiti o specifiche funzionali), otterrai risultati migliori dall'assumere un nuovo programmatore in quanto puoi consegnare la documentazione e iniziare a lavorare da lì.

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

Quindi sì, la mia opinione è di assumere un programmatore per correggere i bug. Dopo aver corretto i bug che hai accettato, è possibile discutere l'aspetto documentale come un altro contratto. Con un po 'di fortuna hai assunto un programmatore che ha una certa esperienza e può contribuire a quali passi dovresti prendere da lì in poi.

Ecco come affrontare il problema:

• Hai la conoscenza del dominio. Sai quali funzionalità sono ora disponibili sul sito Web, quali vorresti aggiungere in futuro e probabilmente puoi elencare anche alcuni bug segnalati dagli utenti.

• C'è questo mucchio di codice seduto lì, lasciato a se stesso in un angolo. Potrebbe essere difettoso, ma offre comunque valore poiché il sito ha utenti attivi. Una riscrittura completa sarebbe quindi un errore IMO.

Il ponte tra la tua competenza di dominio e il codice è stato rotto quando il programmatore è partito. È necessario ricostruirlo in modo che la base di codice possa essere nuovamente sincronizzata con le proprie esigenze e che possano essere sviluppati futuri aggiornamenti.

Il fatto è che quel ponte non può essere interamente realizzato con documentazione. Il software è una questione umana tanto quanto tecnico. Se non spieghi nel dettaglio il nuovo programmatore cosa ti aspetti dettagliatamente, avrà difficoltà a dedurlo dal solo codice, tanto più se il programmatore precedente ha scritto codice criptico, scarsamente documentato, 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 soddisfi le tue esigenze, in altre parole per rendere il bridge più robusto, il problema è destinato a ripetersi.

• Siediti regolarmente (anche virtualmente) con il nuovo programmatore per le sessioni di elaborazione della conoscenza del dominio. Durante ciascuna di queste sessioni, scrivere insieme le specifiche per una piccola parte del prodotto. Può essere una singola pagina Web, può essere una funzione. Renderle specifiche eseguibili (a la Behavior-Driven Development ) aumenterà il tuo livello di sicurezza sul funzionamento del bridge, perché puoi eseguirle continuamente ed essere avvisato quando c'è qualcosa che non va. Renderà anche la vita dello sviluppatore più semplice.

  Dopo una sessione, lo sviluppatore è in grado di tornare al suo lavoro e scrivere test di livello inferiore che confermano che il codice corrente è conforme alle specifiche. Se non è conforme, il programmatore ha tutto ciò di cui ha bisogno per risolverlo. È anche importante rimanere disponibili per qualsiasi domanda possa avere.

• Cerca di mantenere una stretta e continua collaborazione tra te e i programmatori del 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 sopravviva, evitando problemi come quello che stai vivendo ora. Questo ovviamente richiede non solo 2+ sviluppatori che lavorano al tuo progetto, ma anche che condividano tra loro le conoscenze su tutto ciò che scrivono. Pertanto, uno può fungere da failover quando un altro si perde. Tecniche come la programmazione di coppie e la revisione del codice sono buoni modi per raggiungere questo obiettivo.

Aggiungendo semplicemente ciò che tutti hanno detto,

Se non riesci a convincere il vecchio programmatore a 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 ora per rendere produttivo il nuovo programmatore dal primo giorno.

1. Ottieni un database di bug e inizia a inserire tutti i bug che hai trovato al suo interno. Questa è la lista delle cose da fare per il programmatore. Documentalo bene e inserisci il maggior numero di dettagli possibile (file sorgente / causa principale, cosa fa e cosa dovrebbe fare). Esistono molti software gratuiti di tracciamento dei bug, come Bugzilla , Redmine e JIRA . Sentiti libero di usare quello che vuoi.
2. Crea una scheda tecnica per il tuo progetto. Questo darà al nuovo programmatore una direzione dopo che i bug sono stati eliminati. Puoi consultare la guida di Joel per le specifiche di scrittura .
3. Crea una pianificazione o una linea temporale per il tuo progetto. Dovrebbero avere scadenze e pietre miliari in cui vengono pagati per il lavoro svolto 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 disastri o far saltare il prezzo all'infinito e oltre.

Questa volta, iniziare a pianificare correttamente il fattore bus quando si assumono programmatori. Le persone vanno e vengono e non c'è niente che tu possa fare al riguardo, quindi preparati al peggio questa volta ottenendo 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 automatizzati. Inoltre, prova ad ottenere il maggior numero possibile di controlli sul test Joel con il loro aiuto, puoi farlo solo da solo.

Quindi, il tuo unico programmatore è stato investito da un autobus e ora devi sostituirlo.

Potresti provare a fare causa al 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à.

• Desideri realizzare il tuo prodotto, quindi cerca un programmatore con esperienza nella manutenzione e nello sviluppo di sistemi esistenti. Non mi concentrerei sul dire al programmatore cosa fare in quale ordine. Assicurati di assumere un professionista, che scriva documentazione e unit test quando necessario.
• Da parte tua, puoi assicurarti che il nuovo programmatore abbia tutto il necessario per il suo lavoro : specifiche dei requisiti, una potente macchina funzionante e così via. Vuoi un programmatore professionista, quindi forniscigli 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 la garanzia della qualità.