Ciao a tutti. Spesso, soprattutto nel contesto dell'outsourcing, vedo sempre la stessa situazione. La mancanza di un chiaro processo lavorativo all'interno dei team sui vari progetti.
La cosa più importante è che i programmatori non capiscono come comunicare con il cliente e tra di loro. Come costruire un processo continuo di sviluppo di un prodotto di qualità. Come pianificare la propria giornata lavorativa e gli sprint.
E tutto ciò si traduce infine in scadenze mancate, straordinari, continue discussioni su chi sia il colpevole e insoddisfazione dei clienti riguardo a dove e come si sta muovendo il progetto. Molto spesso tutto questo porta al cambio di programmatori, o addirittura di team interi. Alla perdita di clienti, al deterioramento della reputazione, e così via.
A suo tempo, mi sono trovato proprio in un progetto con tutte queste problematiche.
Nessuno voleva prendersi la responsabilità del progetto (un grande marketplace di servizi), la rotazione del personale era elevata, e il cliente era davvero infuriato. Il CEO mi si è avvicinato e mi ha detto che avevo l'esperienza necessaria, quindi il progetto era nelle mie mani. Se fallisci, chiudiamo il progetto e licenziamo tutti. Se funziona, sarà fantastico, allora guidalo e sviluppalo come ritieni opportuno. Alla fine sono diventato il team leader del progetto e tutto è ricaduto sulle mie spalle.
La prima cosa che ho fatto è stata sviluppare un processo lavorativo da zero, che si allineasse alla mia visione di quel momento, e ho redatto una descrizione dei compiti per il team. Implementarlo non è stato facile. Ma nel giro di un mese tutto si è sistemato, i programmatori e il cliente si sono abituati, e tutto è iniziato a procedere in modo tranquillo e confortevole. Per dimostrare al team che non si trattava solo di 'una tempesta in un bicchiere d'acqua', ma di una vera soluzione alla situazione, ho assunto su di me la massima quantità di responsabilità, liberando il team da compiti spiacevoli.
Sono già passati un anno e mezzo, e il progetto sta procedendo senza straordinari, senza "corsa dei topi" e varie forme di stress. Qualcuno nel vecchio team non ha voluto lavorare in questo modo ed è andato via, mentre per qualcun altro è stato molto positivo vedere la nascita di regole trasparenti. Ma alla fine, tutti coloro che sono nel team sono molto motivati e conoscono il progetto in dettaglio, sia il frontend che il backend. Compresa la base di codice e tutta la logica di business. Siamo arrivati addirittura al punto di non essere solo "coppie di rematori", ma di inventare molti processi aziendali e nuove funzionalità che sono piaciute all'azienda.
Grazie a questo approccio da parte nostra, il cliente ha deciso di ordinare un altro marketplace alla nostra azienda, il che non può che farci piacere.
Poiché nel mio progetto questo funziona, potrebbe anche aiutare qualcun altro. Ecco quindi il processo che ci ha aiutato a salvare il progetto:
Processo di lavoro del team nel progetto "Il mio progetto preferito"
a) Processo interno al team (tra sviluppatori)
- Tutte le attività vengono create nel sistema Jira
- Ogni attività deve essere descritta il più dettagliatamente possibile e deve eseguire rigorosamente un'azione
- Qualsiasi funzionalità sufficientemente complessa viene suddivisa in molte piccole attività
- Il team lavora sulle funzionalità come un'unica attività. All'inizio, facciamo tutti insieme una funzionalità, la inviamo per il collaudo e poi prendiamo la successiva.
- Ogni attività è contrassegnata, per il backend o il frontend
- Esistono tipi di attività e bug. È necessario indicarli correttamente.
- Dopo aver completato l'attività, viene trasferita nello stato di revisione del codice (nel frattempo viene creato un pull request per il proprio collega)
- Chi ha eseguito l'attività tiene immediatamente traccia del proprio tempo per questa attività
- Dopo il controllo del codice, il PR viene approvato e successivamente, colui che ha svolto questa attività, la unisce autonomamente nel ramo principale, dopo di che modifica il suo stato in pronto per il deployment su dev server.
- Tutte le attività pronte per il deployment sul server dev vengono deployate dal team leader (la sua zona di responsabilità), a volte da un membro del team, se c'è qualcosa di urgente. Dopo il deployment, tutte le attività con pronte per il deployment su dev vengono trasferite nello stato — pronte per il collaudo su dev
- Tutte le attività vengono testate dal cliente
- Quando il cliente ha testato l'attività su dev, la trasferisce nello stato pronto per il deployment su prod
- Per il deployment su prod abbiamo un ramo separato, dove uniamo il master solo prima del deployment
- Se durante il testing il cliente trova dei bug, restituisce il compito per le modifiche, assegnandole lo stato restituito per revisione. In questo modo, separiamo i nuovi compiti da quelli che non hanno superato il testing.
- Di conseguenza, tutti i compiti seguono il percorso dalla creazione al completamento: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done.
- Ogni sviluppatore testa autonomamente il proprio codice, inclusa l'esperienza come utente del sito. Non è consentito unire il branch principale se non è certo che il codice funzioni correttamente.
- Ogni compito ha delle priorità. Le priorità sono stabilite dal cliente o dal team leader.
- Gli sviluppatori si concentrano prima sui compiti prioritari.
- Gli sviluppatori possono assegnare compiti l'uno all'altro, se vengono trovati diversi bug nel sistema o se un compito richiede il lavoro di più specialisti.
- Tutti i compiti creati dal cliente arrivano al team leader, che li valuta e chiede al cliente di effettuare modifiche oppure li assegna a uno dei membri del team.
- Tutti i compiti pronti per il deployment su dev o prod arrivano anche al team leader, che determina autonomamente quando e come effettuare il deployment. Dopo ogni deployment, il team leader (o un membro del team) deve informare il cliente e cambiare lo stato dei compiti in pronto per il testing su dev/prod.
- Ogni giorno alla stessa ora (per noi è alle 12.00) teniamo una riunione tra tutti i membri del team.
- Ognuno durante la riunione riporta, incluso il team leader, cosa ha fatto ieri, cosa prevede di fare oggi. Cosa non riesce a fare e perché. In questo modo, l'intero team è aggiornato su chi sta facendo cosa e a che punto si trova il progetto. Ciò ci consente di prevedere e correggere, se necessario, le nostre stime e le scadenze.
- Durante la riunione, il team leader comunica anche tutte le modifiche al progetto e il livello attuale dei bug trovati non dal cliente. Tutti i bug vengono analizzati e distribuiti a ciascun membro del team per la risoluzione.
- Durante la riunione, il team leader assegna compiti a ciascuno, considerando l'attuale carico di lavoro degli sviluppatori, il loro livello di preparazione professionale, nonché la vicinanza di un compito rispetto a ciò su cui lo sviluppatore sta attualmente lavorando.
- Durante il meeting, il team leader elabora una strategia comune per l'architettura e la logica aziendale. Dopodiché, l'intero team discute e prende decisioni sulle modifiche o sull'adozione di questa strategia.
- Ogni sviluppatore scrive codice e costruisce algoritmi autonomamente all'interno di un'architettura e una logica aziendale unificate. Ognuno può esprimere la propria visione della realizzazione, ma nessuno è costretto a farlo in un modo specifico. Ogni decisione è motivata. Se esiste una soluzione migliore, ma non c'è tempo per implementarla, allora si crea un'attività in JIRA per un futuro refactoring di una parte specifica del codice.
- Quando uno sviluppatore inizia a lavorare su un compito, lo sposta nello stato di sviluppo. Tutta la comunicazione per chiarire il compito con il cliente ricade sulle spalle dello sviluppatore. Le domande di natura tecnica possono essere rivolte al team leader o ai colleghi.
- Se lo sviluppatore non comprende il compito e il cliente non riesce a spiegarlo chiaramente, allora passa al prossimo compito. L'attuale viene preso in carico dal team leader che lo discute personalmente con il cliente.
- Ogni giorno, lo sviluppatore deve scrivere nel chat del cliente riguardo ai compiti su cui ha lavorato ieri e su quali lavorerà oggi.
- Il processo di lavoro segue la metodologia Scrum. Tutto è suddiviso in sprint. Ogni sprint ha una durata di due settimane.
- Gli sprint sono creati, riempiti e chiusi dal team leader.
- Se il progetto ha scadenze stringenti, cerchiamo di stimare per lo più tutte le attività. E le raccogliamo in uno sprint. Se il cliente cerca di aggiungere ulteriori compiti nello sprint, allora stabiliremo delle priorità e sposteremo alcune altre attività nel prossimo sprint.
b) Processo di lavoro con il cliente
- Ogni sviluppatore può e deve comunicare con il cliente.
- Non dobbiamo permettere al cliente di imporre le proprie regole. È necessario far capire in modo educato e amichevole al cliente che siamo esperti nel nostro campo e solo noi dobbiamo organizzare i processi di lavoro e coinvolgerlo in essi.
- È necessario, idealmente, prima di procedere all'implementazione di qualsiasi funzionalità, creare un diagramma di flusso dell'intero processo logico per la funzione (workflow). E inviarlo per conferma al cliente. Questo riguarda solo funzionalità complesse e non ovvie, come i sistemi di pagamento, i sistemi di notifiche, ecc. Questo permetterà di capire meglio cosa serve realmente al cliente, mantenere la documentazione della funzionalità e proteggersi dal fatto che in futuro il cliente possa dire che non abbiamo fatto ciò che ha richiesto.
- Tutti i diagrammi/diagrammi di flusso/logiche, ecc. vengono salvati in Confluence/Jira, dove chiediamo al cliente di confermare nei commenti la correttezza della futura implementazione.
- Cerchiamo di non sovraccaricare il cliente con dettagli tecnici. Se abbiamo bisogno di capire come il cliente desidera procedere, disegniamo algoritmi primitivi sotto forma di diagrammi di flusso, che il cliente può comprendere e correggere/modificare autonomamente.
- Se il cliente trova un bug nel progetto, chiediamo di descriverlo molto dettagliatamente in Jira. Sotto quali circostanze si è verificato, quando, quale sequenza di azioni ha eseguito il cliente durante i test. Chiediamo di allegare screenshot.
- Cerchiamo di effettuare il deploy sul server di sviluppo ogni giorno, al massimo ogni due giorni. In questo modo il cliente inizia a testare la funzionalità e il progetto non rimane fermo. Inoltre, questo funge da indicazione per il cliente che il progetto è in pieno sviluppo e che nessuno gli racconta storie.
- Spesso accade che il cliente non comprende appieno cosa desideri veramente. Poiché sta creando un nuovo business con processi ancora non collaudati. Pertanto, è molto comune che scartiamo intere parti di codice e rimodifichiamo la logica dell'applicazione. Da ciò deriva che non è necessario coprire tutto con test. Ha senso coprire solo le funzionalità criticamente importanti e solo con delle riserve.
- Ci sono situazioni in cui il team si rende conto che non siamo in linea con le scadenze. In tal caso, facciamo un rapido audit delle attività e informiamo immediatamente il cliente. Come soluzione proponiamo di lanciare in tempo le funzionalità importanti e critiche, lasciando le altre per il post rilascio.
- Se il cliente inizia a inventare compiti vari, a fantasticare e a spiegare gestualmente, chiediamo di fornirci un modello di pagina e un flusso con la logica che deve descrivere completamente il comportamento dell'intero modello e dei suoi elementi.
- Prima di iniziare qualsiasi compito, dobbiamo assicurarci che questa funzione fosse inclusa nei termini del nostro contratto. Se si tratta di una nuova funzionalità che esce dai nostri accordi iniziali, dobbiamo necessariamente stimare questa funzionalità ((tempo di esecuzione stimato + 30%) x 2) e comunicare al cliente che ci vorrà un certo tempo per essa, oltre al fatto che la scadenza si sposta per il tempo di stima moltiplicato per due. Se riusciamo a completare il compito più velocemente, è fantastico, tutti ne trarranno vantaggio. Se no, ci siamo messi al riparo.
c) Cosa non tolleriamo nel team:
- Imprevedibilità, disorganizzazione, dimenticanza
- Ping pong. Se non puoi completare un compito, se non sai come, devi informare immediatamente il team leader, e non aspettare fino all'ultimo.
- Vanità e vanto da parte di una persona che non ha ancora dimostrato le proprie capacità e professionalità. Se l'ha dimostrato, può farlo, nei limiti della decenza 🙂
- Inganno in ogni sua forma. Se il compito non è stato completato, non dovresti cambiare il suo stato in completato e dire nella chat del cliente che è pronto. Il computer si è rotto, il sistema è caduto, il cane ha rosicchiato il notebook — tutto questo è inaccettabile. In caso di un reale caso di forza maggiore, il team leader deve essere informato immediatamente.
- Quando il professionista è sempre offline e risulta difficile contattarlo durante l'orario di lavoro.
- La tossicità nel team non è tollerata! Se qualcuno non è d'accordo con qualcosa, ci si riunisce tutti insieme in una riunione e se ne discute e si decide.
E un'altra serie di domande/thesis che a volte pongo al mio cliente per eliminare qualsiasi malinteso:
- Quali sono i vostri criteri di qualità?
- Come determinate se ci sono problemi nel progetto o meno?
- Violando tutte le nostre raccomandazioni e consigli su modifiche/miglioramenti del sistema, tutti i rischi sono solo a vostro carico
- Qualsiasi cambiamento significativo nel progetto (ad esempio, vari flussi extra) porterà alla possibile comparsa di bug (che naturalmente correggeremo)
- È impossibile capire in pochi minuti quale sia il problema accaduto nel progetto, tanto meno risolverlo immediatamente.
- Lavoriamo secondo un flusso di prodotto specifico (Task in Jira - Sviluppo - Test - Deploy). Ciò significa che non possiamo reagire all'intero flusso di richieste e reclami in chat.
- I programmatori sono programmatori e non collaudatori professionisti, e non possono garantire la qualità adeguata del test del progetto.
- La responsabilità per il test finale e l'accettazione delle attività in produzione ricade completamente su di voi.
- Se abbiamo già preso in carico un'attività, non possiamo immediatamente passare ad altre finché non completata l'attuale (altrimenti questo porta a ulteriori bug e a un aumento dei tempi di sviluppo).
- Il numero di persone nel team è diminuito (a causa di ferie o malattie), ma il lavoro è aumentato e fisicamente non riusciremo a reagire a tutto ciò che desiderate.
- La richiesta da parte vostra di effettuare il deploy in produzione senza compiti testati in sviluppo rappresenta solo i vostri rischi, non quelli degli sviluppatori.
- Quando poste compiti poco chiari, senza flusso corretto, senza mockup di design, questo richiede da parte nostra uno sforzo e tempi di realizzazione molto maggiori, dal momento che ci tocca fare un lavoro aggiuntivo al posto vostro.
- Qualsiasi task sui bug, senza una descrizione dettagliata della loro origine e schermate, non ci consente di capire cosa è andato storto e come riprodurre quel bug.
- Il progetto richiede costanti miglioramenti e ottimizzazioni per aumentare le prestazioni e la sicurezza. Pertanto, il team dedica parte del proprio tempo a queste migliorie.
- Poiché abbiamo ore di lavoro straordinarie (correzioni urgenti), dobbiamo compensarle in altri giorni.
Di norma, il cliente comprende subito che non è così semplice sviluppare software e che un semplice desiderio non è sufficiente.
In generale, questo è tutto. Dietro le quinte lascio numerose trattative e la prima messa a punto di tutti i processi, ma il risultato è che tutto si è sistemato. Posso dire che questo processo è diventato per noi una sorta di "Proiettile d'Argento". Le nuove persone che venivano nel progetto potevano già mettersi al lavoro fin dal primo giorno, poiché tutti i processi sono descritti e la documentazione e l'architettura in forma di diagramma fornivano immediatamente un'idea di ciò di cui ci occupiamo.
P. S. Vorrei chiarire che non abbiamo un project manager dalla nostra parte. È presente dalla parte del cliente. Non è affatto un tecnico. Il progetto è europeo. Tutta la comunicazione è solo in inglese.
Buona fortuna a tutti nei vostri progetti. Non bruciatevi e cercate di migliorare i vostri processi.
Il sorgente è nel mio .
Fonte: habr.com
