Come condurre un progetto di sviluppo senza esperienza tecnica

Onestamente, non importa quanta esperienza hai con una tecnologia, il mio consiglio è lo stesso: Non imporre le decisioni sulla tecnologia a coloro che dovranno vivere con loro mentre sei occupato a gestire.

Sii onesto con te stesso. Scommetto che la ragione per cui odiavi quei precedenti manager non era perché non avevano la base di conoscenze da cui prendere le decisioni, era perché hanno forzato le 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 il potere, a seconda del livello di abilità dei tuoi sviluppatori, significa consigliarli quando lo chiedono. "Hai consultato Spring.NET?" (notare 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, in qualità di sviluppatore Java esperto, potresti trovarti in una posizione migliore rispetto alla maggior parte per questo. La maggior parte dei framework e delle tecnologie Java hanno un equivalente analogo in .NET. Quindi non devi dire "Ecco la cosa migliore da usare", puoi dire "Ho usato questo in Java, conosci un equivalente .NET?"

Incoraggia anche molte conversazioni all'interno del team. Organizzare incontri di discussione tecnica settimanali. Tutto ciò che ti serve è l'informazione, alla fine; hai bisogno di sapere quali decisioni hanno preso e perché. Non è necessario prendere queste decisioni per il team.

Ho avuto alcuni ottimi manager / team leader 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 il loro giudizio, e dare a ciascuno la stessa libertà che può gestire, mantenendo le "anatre selvatiche" sul compito e i "a malapena concorrenti" impegnati con attività "sicure" ma produttive. Assicurati che tutti marcino verso lo stesso batterista.

La tua sfida più grande è probabilmente quella di tenere a bada la gestione superiore. Vogliono report, pianificazioni e segni di spunta, e tu devi capire che cosa vogliono e come fingerli ragionevolmente bene. (Beh, non esattamente "falso", ma produrre una documentazione che li soddisfi senza intaccare il tuo tempo o il tempo della tua squadra.)

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

• Quali abilità porta ciascuna persona del tuo team al tavolo?
• Quali componenti sono fondamentali per il successo del progetto?
• Che cosa devi produrre oltre al codice effettivo? (Test? Documentazione?)
• Come raccoglierai i requisiti, se non lo hai già fatto?
• In che modo lei e il suo team si avvicinano al 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 puoi rilevare i problemi in anticipo?

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

Con tutti i mezzi, impara a lavorare efficacemente in C # il più velocemente possibile. Ricorda solo che il tuo ruolo è quello di vedere oltre la sintassi e i dettagli della struttura e guardare l'immagine più grande.

Avvicinati. Inizia afferrandoti un semplice primer C # e scrivi del codice. Prova alcune cose basilari che sapresti come fare con gli occhi bendati in un'altra lingua.

Leggi su programmazione stile e convenzione. In ogni caso dovresti trovare questo in parte nel tuo primer, ma puoi anche usare prodotti come StyleCop e Resharper per applicare regole di stile che non conosci. In questo modo ti addestrerai molto rapidamente a fare le cose in un modo comunemente accettato al fine di evitare problemi nella compilazione del software.

Sii te stesso e applica le conoscenze progettuali che già possiedi. Le basi sono essenzialmente le stesse indipendentemente dalla lingua. Dove ci saranno differenze sarà in come le lingue differiscono in termini di struttura sarà abbastanza minima, e gran parte di esso apparirà molto rapidamente come si getta insieme una app di prova o due.

Se ci sono cose ovvie che non conosci, sii pronto. La tua squadra rispetterà l'onestà più che semplicemente se la spunterai senza un indizio. Prendi decisioni ben informate e ragionate e prenditi sempre un paio di minuti per considerare la tua risposta. Dovrai essere assertivo senza tentare di dominare e non puoi lasciare che la tua mancanza di conoscenza in una determinata area sembri una riflessione sulla tua capacità di guidare la squadra. La leadership implica il mentoring, ma il mentoring non significa che non puoi mostrare anche 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 lead di progetto. È un tipo di personalità totalmente diverso che oserebbe prendere decisioni senza una conoscenza adeguata. Mantieni una mente aperta a ciò che i tuoi colleghi ti dicono e crea e incoraggia una cultura di dialogo e scambio di informazioni nella tua squadra.

Sembra che ci siano alcuni problemi in gioco qui.

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

Sei il capo squadra o uno sviluppatore principale? Uno sviluppatore principale svolge anche un bel po 'di lavoro di progettazione e sviluppo. Quindi, l'unico modo per aggirare questo è solo quello di ridimensionare e imparare la nuova tecnologia .

Se stai guidando il team, devi fidarti del team e lasciare che guidino la maggior parte della direzione tecnica del progetto. Ovviamente, concettualmente, sarai in grado di mantenere lo sterzo nella giusta direzione.

I processi che governano lo sviluppo del progetto dovrebbero essere principalmente in atto . È solo una questione di leggere su di loro, capirli ed eseguirli.

In caso contrario, negozia con il tuo capo per ottenere un mentore che ti aiuti a mettere in atto alcuni processi di sviluppo. Questo è abbastanza importante. Fallirà abbastanza rapidamente se il processo non è a posto ed è ad hoc.

Buona fortuna!

L'opportunità arriva una volta ogni tanto. Prendilo ... direi, prova a imparare le basi di C #. Ottieni alcuni tutorial da online, prova a lavorarci sopra. inizialmente sarebbe difficile imparare il nuovo concetto, più tardi, quando il tuo primo compito sarà fatto, avrai una certa fiducia in esso.

Pensa in modo positivo, prova a svolgere un compito difficile, esegui il debug del tuo codice e sei sicuro che ci riuscirai.

Non perdere la tua opportunità.

Penso che se hai un buon numero di sviluppatori .Net c'è molta conoscenza nel team che forse hai bisogno di attingere per iniziare. Ci sono molte somiglianze tra Java e .Net che ciò che già sapete potrebbe effettivamente applicarsi più direttamente. L'importanza è sapere che cosa è importante per avere ragione per questo progetto e per i rischi coinvolti. Comunica con la tua squadra tutte le volte che è necessario. La pratica dell'ingegneria del software si evolve nel corso di un progetto, quindi potrebbe essere difficile avere una "buona pratica" molto presto nel progetto.

Ho avuto il contrario della tua esperienza in cui mi viene assegnata una squadra molto verde di laureati che non provengono dal campo del software. Mentre ho tutte le ragioni per stipulare ciò che deve essere fatto (sono stato assunto) ho invece cercato la pratica per farci muovere e un sacco di coaching e discussione per far evolvere la nostra pratica di ingegneria del software. Ho appreso moltissimo dal team e siamo quasi arrivati a consegnare il nostro primo progetto in casa dopo più di un anno di lavoro!

I am lost when it comes to coding standards, project life cycle tools and release/distribution procedures.

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

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

Scarica il loro codice di lavoro. Leggilo.

Scopri quali strumenti usano. Usali.

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

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

I have no doubt that I can pick up the basics within a month or two, but there are certain experiences one can only gather with time.

True.

Impara dalla community open source.