Come condurre un progetto di sviluppo senza competenze tecniche

Sono stato uno sviluppatore pratico per tutta la mia carriera e amo lavorare con il codice. Ho sempre risentito del leader del team che ha poca o nessuna esperienza in merito a una particolare tecnologia e insiste su una certa implementazione.

Ora mi trovo dall'altra parte dello specchio. Sono lo sviluppatore principale di un client grasso da implementare in C #, tuttavia la mia esperienza è nella creazione di applicazioni Web Java. Mentre so di poter sfruttare i modelli di progettazione e i paradigmi OO in qualsiasi lingua, mi sono perso quando si tratta di standard di codifica, strumenti del ciclo di vita del progetto e procedure di rilascio / distribuzione. Non ho dubbi sul fatto che posso imparare le basi entro un mese o due, ma ci sono alcune esperienze che si possono raccogliere solo con il tempo.

Cosa devo fare e come posso evitare di diventare il capo del progetto che odiavo durante lo sviluppo?

Onestamente, non importa quanta esperienza hai con una tecnologia, il mio consiglio è lo stesso: non applicare decisioni tecnologiche su coloro che dovranno convivere con loro mentre sei impegnato nella gestione.

Sii onesto con te stesso. Scommetto che il motivo per cui odiavi quei precedenti manager non era perché non avevano la base di conoscenza da cui prendere le decisioni, era perché hanno imposto decisioni e non hanno mai affrontato le conseguenze.

Questo vale se non hai mai toccato .NET prima o sei lo sviluppatore più esperto del team. Il tuo compito ora è gestire, non prendere decisioni tecniche.

Gestire potrebbe, a seconda del livello di abilità dei tuoi sviluppatori, significare avvisarli quando lo richiedono. "Hai guardato Spring.NET?" (nota la mancanza di istruzioni lì) è una cosa perfettamente buona da dire. Inoltre, "Google in giro, guarda cosa sta facendo il resto del mondo, non siamo i primi ad affrontare questo problema".

Per alcuni aspetti, come sviluppatore Java esperto, potresti trovarti in una posizione migliore della maggior parte per questo. La maggior parte dei framework e delle tecnologie Java ha un analogo equivalente in .NET. Quindi non devi dire "Ecco la cosa migliore da usare", puoi dire "L'ho usato in Java, conosci un equivalente .NET?"

Incoraggia anche molte conversazioni all'interno della squadra. Organizza incontri settimanali di discussione tecnica. Tutto ciò di cui hai bisogno sono informazioni, alla fine; devi sapere quali decisioni hanno preso e perché. Non è necessario prendere quelle decisioni per la squadra.

Ho avuto dei manager / team leader molto bravi che sapevano molto poco della tecnologia e alcuni dei miei peggiori manager sono stati quelli che pensavano di sapere tutto.

Per essere un leader, se hai persone ragionevolmente competenti, la cosa principale è essere in grado di giudicare la loro competenza e giudizio, e dare a ciascuno la massima latitudine che può gestire, mantenendo le "anatre selvatiche" sul compito e il "a malapena concorrenti "impegnati con attività" sicure "ma produttive. Assicurati che tutti stiano marciando verso lo stesso batterista.

La tua sfida più grande è probabilmente quella di tenere a bada i dirigenti. Vorranno rapporti, pianificazioni e segni di spunta, e devi capire cosa vogliono e come farseli ragionevolmente bene. (Beh, non esattamente "falso", ma produce documentazione che li soddisfi senza perdere tempo o tempo della tua squadra.)

Non sei stato scelto per le tue abilità di codifica C # e, a meno che tu non stia scrivendo codice fin dall'inizio, non importa se conosci C # o no. Devi iniziare a pensare a un livello superiore:

• Quali abilità porta ogni persona nella tua squadra al tavolo?
• Quali componenti sono fondamentali per il successo del progetto?
• Cosa devi produrre oltre al codice attuale? (Test? Documentazione?)
• Come raccoglierai i requisiti, se non l'hai già fatto?
• In che modo tu e il tuo team affronterete il processo di progettazione?
• Sai che avere uno standard di codifica è importante, ma puoi fare affidamento sul tuo team per capire esattamente quale standard vogliono seguire.
• Come si possono rilevare i problemi in anticipo?

Alcune di queste cose possono attraversare il territorio della gestione del progetto, ma come sviluppatore principale lavorerai a stretto contatto con il project manager su questi e altri problemi.

Sicuramente impara ad essere efficace lavorando in C # il più velocemente possibile. Ricorda solo che il tuo ruolo è quello di vedere oltre la sintassi e i dettagli del framework e guardare l'immagine più grande.

Prendi un approccio pratico. Inizia prendendo un semplice primer C # e scrivi un po 'di codice. Prova alcune cose di base che potresti sapere con gli occhi bendati in un'altra lingua.

Leggi su stile di programmazione e convenzione. Dovresti trovarlo in parte nel tuo primer, ma puoi anche usare prodotti come StyleCop e Resharper per applicare regole di stile che non conosci. Questo ti insegnerà molto rapidamente a fare le cose in un modo comunemente accettato per evitare problemi nella compilazione del tuo software.

Sii solo te stesso e applica le conoscenze di progettazione che già possiedi. Le basi sono essenzialmente le stesse indipendentemente dalla lingua. Dove ci saranno differenze sarà il modo in cui le lingue differiscono in termini di struttura saranno abbastanza minime, e gran parte di esse apparirà molto rapidamente quando si mettono insieme una o due app di prova.

Se ci sono cose ovvie che non conosci, sii imminente. La tua squadra rispetterà l'onestà più che limitarsi a barattare senza indizi. Prendi decisioni ben informate e motivate e prenditi sempre un paio di minuti a parte per considerare la tua risposta. Dovrai essere assertivo senza tentare di dominare e non puoi lasciare che la tua mancanza di conoscenza in un'area appaia come una riflessione sulla tua capacità di guidare la squadra. La leadership implica il mentoring, ma il mentoring non significa che non puoi anche mostrare la volontà di imparare qualcosa di nuovo.

Se la pensi così e in realtà ti preoccupi, hai già evitato il rischio di diventare questo tipo di responsabile del progetto. È un tipo di personalità totalmente diverso che oserebbe prendere decisioni senza la giusta conoscenza. Tieni semplicemente una mente aperta su ciò che i tuoi colleghi ti dicono e crea e incoraggia una cultura del dialogo e dello scambio di informazioni nella tua squadra.

Sembra che qui ci siano alcuni problemi.

La tecnologia utilizzata nel progetto che stai conducendo e il processo che regola lo sviluppo di quel progetto.

Sei il capo squadra o uno sviluppatore principale? Uno sviluppatore principale svolge anche una parte del lavoro di progettazione e sviluppo. Quindi l'unico modo per aggirare questo è solo di tirarsi giù e imparare la nuova tecnologia .

Se stai effettivamente guidando il team, dovrai fidarti del team e lasciargli guidare la maggior parte della direzione tecnica del progetto. Naturalmente, concettualmente, sarai in grado di mantenere quel governo nella giusta direzione.

I processi che regolano lo sviluppo del progetto dovrebbero essere prevalentemente in atto . Si tratta solo di leggerli, comprenderli ed eseguirli.

In caso contrario, negozia con il tuo capo per ottenere un tutor che ti aiuti a mettere in atto un processo di sviluppo. Questo è abbastanza importante. Non funzionerà abbastanza rapidamente se il processo non è attivo ed è ad hoc.

In bocca al lupo!

L'opportunità arriva di tanto in tanto .. Afferralo .. Direi, prova ad imparare le basi di C #. Ottieni alcuni tutorial online, prova a lavorarci su. inizialmente sarebbe difficile imparare il nuovo concetto, più tardi, quando il tuo primo compito sarà completato, avrai una certa fiducia in esso.

Pensa positivo, prova a fare un duro lavoro, esegui il debug del tuo codice e sono sicuro che riuscirai a dominarlo.

Non perdere l'occasione.

Penso che se hai un buon gruppo di sviluppatori .Net ci sono molte conoscenze nel team che forse devi attingere per iniziare. Ci sono molte somiglianze tra Java e .Net che ciò che già sai potrebbe effettivamente applicare più o meno direttamente. L'importanza è sapere cosa è importante ottenere giusto per questo progetto e i rischi connessi. Comunica con il tuo team tutte le volte che è necessario. La pratica di ingegneria del software si evolve nel corso di un progetto, quindi potrebbe essere difficile avere una "migliore pratica" molto presto nel progetto.

Ho avuto il contrario della tua esperienza in cui mi è stato dato un team molto verde di laureati che non provengono dal campo relativo al software. Mentre ho tutte le ragioni per stabilire cosa deve essere fatto (ero impiegato), ho invece cercato pratica per farci muovere e un sacco di coaching e discussione per far evolvere la nostra pratica di ingegneria del software. Ho imparato un sacco dal team lungo la strada e siamo quasi lì a consegnare il nostro primo progetto interno dopo oltre un anno di lavoro!

Mi sono perso quando si tratta di standard di codifica, strumenti del ciclo di vita del progetto e procedure di rilascio / distribuzione.

Trova un prodotto open source che utilizza la stessa tecnologia che utilizzerai.

Se possibile, trovane uno che sia in qualche modo simile al dominio problematico. Questo non è importante quanto trovare un progetto con la stessa tecnologia e gli aggiornamenti attivi.

Scarica il loro codice di lavoro. Leggilo.

Scopri quali strumenti usano. Usali.

Scopri come compilare e rilasciare il progetto open source. Costruiscilo e rilascialo.

Un progetto open source (con un numero di collaboratori) illustrerà le migliori pratiche.

Non ho dubbi sul fatto che posso imparare le basi entro un mese o due, ma ci sono alcune esperienze che si possono raccogliere solo con il tempo.

Vero.

Impara dalla comunità open source.