Lavorare da solo su un progetto

Assicurati di ricevere informazioni dal membro più anziano in merito alla sicurezza. Le informazioni sui dipendenti non sono pubbliche.

Ecco alcuni risparmiatori di tempo:

Management Brains - Sono a conoscenza che questo è iniziato come il lavoro di 3 persone e ora è ridotto a uno? Qualcuno deve fare i conti e aggiustare.

Applicazioni esistenti . Esistono molti modi per creare un'app, ma alcuni dei tuoi colleghi torneranno a questo progetto (in modo formale o informale) e rivedranno il tuo lavoro. Prova ad utilizzare alcune delle migliori pratiche che hanno già incluso. Il ragionamento è parte: non reinventare la ruota, potrebbero aver affrontato le esigenze richieste dalla tua infrastruttura e / o dalle regole aziendali, non lasciare che il loro pregiudizio personale nei confronti di determinate tecniche / framework offuschi il loro giudizio sul tuo lavoro.

Adeguamento dei requisiti : l'app che stai sviluppando potrebbe probabilmente essere acquistata dallo scaffale, quindi assicurati di capire di cosa ha bisogno la tua azienda che gli altri prodotti non offrono. Rendi queste tue priorità e regola gli altri requisiti lungo la strada. Non devi includere tutte le campane e i fischi che volevano in anticipo.

Overhead del team - Avrai alcuni vantaggi di non lavorare con un team. Non devi sederti alle riunioni e discutere delle tue decisioni. Questo farà risparmiare tempo, ma perderai l'input da ciò che potrebbe essere un buon sviluppo / due teste sono meglio di una. Potrebbero non essere sul progetto, ma fare ciò che puoi per ottenere una revisione del codice anche se devi trattarli a pranzo.

Gestione del tempo, dell'energia e delle risorse : scopri quando esegui il meglio e pianifica le difficili attività di programmazione per quei tempi. Ti sentirai un po 'svuotato, quindi usa quelle volte per fare alcuni dei banali compiti amministrativi. Non dimenticare le sottigliezze sociali e considera i tuoi tester di corridoio come l'oro. Ascoltarli parlare del loro gatto NON è una perdita di tempo. Sii la persona che prenderanno il loro tempo per aiutare anche se hanno una casella di posta piena.

La pianificazione è buona, ma devi creare qualcosa. Fai il lavoro e pianifica, ma non perdere troppo tempo tra la codifica. Buona fortuna con la tua prima app.

Se intendi che i diversi tipi di compiti sono stati suddivisi prima tra tre, ti suggerisco di richiedere una sessione settimanale (diverse ore) con l'ingegnere senior per discutere di progressi, problemi, idee. Sarebbe molto imprudente dal punto di vista aziendale lasciarti fare tutto da solo, indipendentemente dal tuo livello di competenza.

Potrebbe essere difficile.

Penso che la pianificazione sia la tua chiave. Hai un piano di progetto a cui stai lavorando?

Se no, ti suggerirei di inventarne uno prima che i tuoi colleghi salti la nave. Per lo meno questo sarà un elenco di tutti i compiti che devi fare sul progetto. Più dettagli ci sono, meglio è (fino a un certo punto), ma solo "sviluppare uno schermo di questo tipo" probabilmente non è abbastanza dettagliato). Includere anche cose come documentazione e piani.

Questa è la priorità assoluta.

Dovresti esaminare tutte le attività della lista e accertarti che il tempo concesso per il compito si adatti a tu . Non è buono per nessuno dei tuoi colleghi stimare un giorno per un particolare compito, se è qualcosa di cui non sai nulla e probabilmente ti prenderà una settimana. Inoltre, tieni presente che gli sviluppatori tendono ad essere ottimisti sui tempi: dal momento che dici di avere poca esperienza in quest'area, probabilmente cadrai in questa trappola. Sfortunatamente la cosa principale che ti aiuterà è l'esperienza, ma alcune "regole" che ti vengono in mente potrebbero essere:

• nulla richiede meno di mezza giornata. Anche se è stato modificato un codice a una riga. Perché perderai il tempo altrove
• per quanto tempo pensi che ci vorrà, raddoppialo (non è uno che uso perché non può reggere il controllo accurato, ma potrebbe aiutarti a iniziare)
• se una singola attività richiede più di una settimana, non è stata definita abbastanza bene. La ragione di questo è semplicemente che se hai un compito di 20 giorni è quasi impossibile dire con certezza che sei completo al 75%.

A seconda di quanto sia importante adattarsi agli standard esistenti, è necessario aggiungere attività (ad altre persone) per rivedere aspetti come documentazione, piani di test e ovviamente codice. E dovresti aggiungere compiti (per te) al refactoring della tua documentazione / piani / codice seguendo queste recensioni.

Se ci sono alcuni aspetti del progetto che semplicemente non puoi fare, o non puoi fare entro un ragionevole lasso di tempo, o hai bisogno di un addestramento per farlo, dillo.

Non budget per lavorare la sera o nei fine settimana. Se lo fai, e scivoli, allora non hai speranza di recuperare il tempo perduto. Può darsi che tu senta il bisogno di inserire queste ore extra, ma dovresti usarle per giocare a catchup. Tienili nella manica, per così dire.

Assicurati che il tuo capo sia a conoscenza di questo nuovo piano ed è consapevole che la consegna richiederà più di x settimane / mesi. Se lo vogliono più velocemente, sta a loro ordinare più risorse o decifrare parti del progetto. Questo è importante perché se non comunichi queste cose al tuo capo, si aspetteranno che tu trasporti le cose quando non sei affatto vicino pronto.

Infine, mantieni aggiornato il tuo piano. Se stai iniziando a scivolare, assicurati di essere il primo a saperlo. Ora, che tu dica qualcosa a qualcuno o tienilo per te, dovrà essere una sentenza. Se sei sicuro di poter recuperare il tempo, allora probabilmente non ha senso dire nulla.

La linea di fondo è questa: non farti ricucire. Se ti ritrovi a mancare le scadenze, la tua unica difesa sarà se puoi dire "Guarda, ho evidenziato questo come un rischio x mesi fa".