{"id":97853,"date":"2020-10-22T14:42:44","date_gmt":"2020-10-22T12:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte"},"modified":"2020-11-18T00:58:50","modified_gmt":"2020-11-17T22:58:50","slug":"organizacziya-rabochego-proczessa-v-komande-na-it-proekte","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","title":{"rendered":"L'organizzazione del lavoro di squadra in un progetto IT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>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.<\/p>\n<p>La cosa pi\u00f9 importante \u00e8 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\u00e0. Come pianificare la propria giornata lavorativa e gli sprint.<\/p>\n<p>E tutto ci\u00f2 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\u00ec via.<\/p>\n<p>A suo tempo, mi sono trovato proprio in un progetto con tutte queste problematiche. <br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNessuno voleva prendersi la responsabilit\u00e0 del progetto (un grande marketplace di servizi), la rotazione del personale era elevata, e il cliente era davvero infuriato. Il CEO mi si \u00e8 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\u00e0 fantastico, allora guidalo e sviluppalo come ritieni opportuno. Alla fine sono diventato il team leader del progetto e tutto \u00e8 ricaduto sulle mie spalle.<\/p>\n<p>La prima cosa che ho fatto \u00e8 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 \u00e8 stato facile. Ma nel giro di un mese tutto si \u00e8 sistemato, i programmatori e il cliente si sono abituati, e tutto \u00e8 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\u00e0 di responsabilit\u00e0, liberando il team da compiti spiacevoli. <\/p>\n<p>Sono gi\u00e0 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 \u00e8 andato via, mentre per qualcun altro \u00e8 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\u00e0 che sono piaciute all'azienda.<\/p>\n<p>Grazie a questo approccio da parte nostra, il cliente ha deciso di ordinare un altro marketplace alla nostra azienda, il che non pu\u00f2 che farci piacere.<\/p>\n<p>Poich\u00e9 nel mio progetto questo funziona, potrebbe anche aiutare qualcun altro. Ecco quindi il processo che ci ha aiutato a salvare il progetto:<\/p>\n<p>Processo di lavoro del team nel progetto \"Il mio progetto preferito\"<\/p>\n<p>a) Processo interno al team (tra sviluppatori)<\/p>\n<ul>\n<li>Tutte le attivit\u00e0 vengono create nel sistema Jira<\/li>\n<li>Ogni attivit\u00e0 deve essere descritta il pi\u00f9 dettagliatamente possibile e deve eseguire rigorosamente un'azione<\/li>\n<li>Qualsiasi funzionalit\u00e0 sufficientemente complessa viene suddivisa in molte piccole attivit\u00e0<\/li>\n<li>Il team lavora sulle funzionalit\u00e0 come un'unica attivit\u00e0. All'inizio, facciamo tutti insieme una funzionalit\u00e0, la inviamo per il collaudo e poi prendiamo la successiva.<\/li>\n<li>Ogni attivit\u00e0 \u00e8 contrassegnata, per il backend o il frontend<\/li>\n<li>Esistono tipi di attivit\u00e0 e bug. \u00c8 necessario indicarli correttamente.<\/li>\n<li>Dopo aver completato l'attivit\u00e0, viene trasferita nello stato di revisione del codice (nel frattempo viene creato un pull request per il proprio collega)<\/li>\n<li>Chi ha eseguito l'attivit\u00e0 tiene immediatamente traccia del proprio tempo per questa attivit\u00e0<\/li>\n<li>Dopo il controllo del codice, il PR viene approvato e successivamente, colui che ha svolto questa attivit\u00e0, la unisce autonomamente nel ramo principale, dopo di che modifica il suo stato in pronto per il deployment su dev <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\">server<\/a>.<\/li>\n<li>Tutte le attivit\u00e0 pronte per il deployment sul server dev vengono deployate dal team leader (la sua zona di responsabilit\u00e0), a volte da un membro del team, se c'\u00e8 qualcosa di urgente. Dopo il deployment, tutte le attivit\u00e0 con pronte per il deployment su dev vengono trasferite nello stato \u2014 pronte per il collaudo su dev<\/li>\n<li>Tutte le attivit\u00e0 vengono testate dal cliente<\/li>\n<li>Quando il cliente ha testato l'attivit\u00e0 su dev, la trasferisce nello stato pronto per il deployment su prod<\/li>\n<li>Per il deployment su prod abbiamo un ramo separato, dove uniamo il master solo prima del deployment<\/li>\n<li>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.<\/li>\n<li>Di conseguenza, tutti i compiti seguono il percorso dalla creazione al completamento: To Do \u2192 In Development \u2192 Code Review \u2192 Ready deploy to dev \u2192 QA on dev \u2192 (Return to dev) \u2192 Ready deploy to prod \u2192 QA on prod \u2192 Done.<\/li>\n<li>Ogni sviluppatore testa autonomamente il proprio codice, inclusa l'esperienza come utente del sito. Non \u00e8 consentito unire il branch principale se non \u00e8 certo che il codice funzioni correttamente.<\/li>\n<li>Ogni compito ha delle priorit\u00e0. Le priorit\u00e0 sono stabilite dal cliente o dal team leader.<\/li>\n<li>Gli sviluppatori si concentrano prima sui compiti prioritari.<\/li>\n<li>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\u00f9 specialisti.<\/li>\n<li>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.<\/li>\n<li>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.<\/li>\n<li>Ogni giorno alla stessa ora (per noi \u00e8 alle 12.00) teniamo una riunione tra tutti i membri del team.<\/li>\n<li>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\u00e9. In questo modo, l'intero team \u00e8 aggiornato su chi sta facendo cosa e a che punto si trova il progetto. Ci\u00f2 ci consente di prevedere e correggere, se necessario, le nostre stime e le scadenze.<\/li>\n<li>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.<\/li>\n<li>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\u00e9 la vicinanza di un compito rispetto a ci\u00f2 su cui lo sviluppatore sta attualmente lavorando.<\/li>\n<li>Durante il meeting, il team leader elabora una strategia comune per l'architettura e la logica aziendale. Dopodich\u00e9, l'intero team discute e prende decisioni sulle modifiche o sull'adozione di questa strategia.<\/li>\n<li>Ogni sviluppatore scrive codice e costruisce algoritmi autonomamente all'interno di un'architettura e una logica aziendale unificate. Ognuno pu\u00f2 esprimere la propria visione della realizzazione, ma nessuno \u00e8 costretto a farlo in un modo specifico. Ogni decisione \u00e8 motivata. Se esiste una soluzione migliore, ma non c'\u00e8 tempo per implementarla, allora si crea un'attivit\u00e0 in JIRA per un futuro refactoring di una parte specifica del codice.<\/li>\n<li>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.<\/li>\n<li>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.<\/li>\n<li>Ogni giorno, lo sviluppatore deve scrivere nel chat del cliente riguardo ai compiti su cui ha lavorato ieri e su quali lavorer\u00e0 oggi.<\/li>\n<li>Il processo di lavoro segue la metodologia Scrum. Tutto \u00e8 suddiviso in sprint. Ogni sprint ha una durata di due settimane.<\/li>\n<li>Gli sprint sono creati, riempiti e chiusi dal team leader.<\/li>\n<li>Se il progetto ha scadenze stringenti, cerchiamo di stimare per lo pi\u00f9 tutte le attivit\u00e0. E le raccogliamo in uno sprint. Se il cliente cerca di aggiungere ulteriori compiti nello sprint, allora stabiliremo delle priorit\u00e0 e sposteremo alcune altre attivit\u00e0 nel prossimo sprint.<\/li>\n<\/ul>\n<p>\nb) Processo di lavoro con il cliente<\/p>\n<ul>\n<li>Ogni sviluppatore pu\u00f2 e deve comunicare con il cliente.<\/li>\n<li>Non dobbiamo permettere al cliente di imporre le proprie regole. \u00c8 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.<\/li>\n<li>\u00c8 necessario, idealmente, prima di procedere all'implementazione di qualsiasi funzionalit\u00e0, creare un diagramma di flusso dell'intero processo logico per la funzione (workflow). E inviarlo per conferma al cliente. Questo riguarda solo funzionalit\u00e0 complesse e non ovvie, come i sistemi di pagamento, i sistemi di notifiche, ecc. Questo permetter\u00e0 di capire meglio cosa serve realmente al cliente, mantenere la documentazione della funzionalit\u00e0 e proteggersi dal fatto che in futuro il cliente possa dire che non abbiamo fatto ci\u00f2 che ha richiesto.<\/li>\n<li>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.<\/li>\n<li>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\u00f2 comprendere e correggere\/modificare autonomamente.<\/li>\n<li>Se il cliente trova un bug nel progetto, chiediamo di descriverlo molto dettagliatamente in Jira. Sotto quali circostanze si \u00e8 verificato, quando, quale sequenza di azioni ha eseguito il cliente durante i test. Chiediamo di allegare screenshot.<\/li>\n<li>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\u00e0 e il progetto non rimane fermo. Inoltre, questo funge da indicazione per il cliente che il progetto \u00e8 in pieno sviluppo e che nessuno gli racconta storie.<\/li>\n<li>Spesso accade che il cliente non comprende appieno cosa desideri veramente. Poich\u00e9 sta creando un nuovo business con processi ancora non collaudati. Pertanto, \u00e8 molto comune che scartiamo intere parti di codice e rimodifichiamo la logica dell'applicazione. Da ci\u00f2 deriva che non \u00e8 necessario coprire tutto con test. Ha senso coprire solo le funzionalit\u00e0 criticamente importanti e solo con delle riserve.<\/li>\n<li>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\u00e0 e informiamo immediatamente il cliente. Come soluzione proponiamo di lanciare in tempo le funzionalit\u00e0 importanti e critiche, lasciando le altre per il post rilascio.<\/li>\n<li>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.<\/li>\n<li>Prima di iniziare qualsiasi compito, dobbiamo assicurarci che questa funzione fosse inclusa nei termini del nostro contratto. Se si tratta di una nuova funzionalit\u00e0 che esce dai nostri accordi iniziali, dobbiamo necessariamente stimare questa funzionalit\u00e0 ((tempo di esecuzione stimato + 30%) x 2) e comunicare al cliente che ci vorr\u00e0 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\u00f9 velocemente, \u00e8 fantastico, tutti ne trarranno vantaggio. Se no, ci siamo messi al riparo.<\/li>\n<\/ul>\n<p>\nc) Cosa non tolleriamo nel team:<\/p>\n<ul>\n<li>Imprevedibilit\u00e0, disorganizzazione, dimenticanza<\/li>\n<li>Ping pong. Se non puoi completare un compito, se non sai come, devi informare immediatamente il team leader, e non aspettare fino all'ultimo.<\/li>\n<li>Vanit\u00e0 e vanto da parte di una persona che non ha ancora dimostrato le proprie capacit\u00e0 e professionalit\u00e0. Se l'ha dimostrato, pu\u00f2 farlo, nei limiti della decenza \ud83d\ude42<\/li>\n<li>Inganno in ogni sua forma. Se il compito non \u00e8 stato completato, non dovresti cambiare il suo stato in completato e dire nella chat del cliente che \u00e8 pronto. Il computer si \u00e8 rotto, il sistema \u00e8 caduto, il cane ha rosicchiato il notebook \u2014 tutto questo \u00e8 inaccettabile. In caso di un reale caso di forza maggiore, il team leader deve essere informato immediatamente.<\/li>\n<li>Quando il professionista \u00e8 sempre offline e risulta difficile contattarlo durante l'orario di lavoro.<\/li>\n<li>La tossicit\u00e0 nel team non \u00e8 tollerata! Se qualcuno non \u00e8 d'accordo con qualcosa, ci si riunisce tutti insieme in una riunione e se ne discute e si decide.<\/li>\n<\/ul>\n<p>E un'altra serie di domande\/thesis che a volte pongo al mio cliente per eliminare qualsiasi malinteso:<\/p>\n<ol>\n<li>Quali sono i vostri criteri di qualit\u00e0?<\/li>\n<li>Come determinate se ci sono problemi nel progetto o meno?<\/li>\n<li>Violando tutte le nostre raccomandazioni e consigli su modifiche\/miglioramenti del sistema, tutti i rischi sono solo a vostro carico<\/li>\n<li>Qualsiasi cambiamento significativo nel progetto (ad esempio, vari flussi extra) porter\u00e0 alla possibile comparsa di bug (che naturalmente correggeremo)<\/li>\n<li>\u00c8 impossibile capire in pochi minuti quale sia il problema accaduto nel progetto, tanto meno risolverlo immediatamente.<\/li>\n<li>Lavoriamo secondo un flusso di prodotto specifico (Task in Jira - Sviluppo - Test - Deploy). Ci\u00f2 significa che non possiamo reagire all'intero flusso di richieste e reclami in chat.<\/li>\n<li>I programmatori sono programmatori e non collaudatori professionisti, e non possono garantire la qualit\u00e0 adeguata del test del progetto.<\/li>\n<li>La responsabilit\u00e0 per il test finale e l'accettazione delle attivit\u00e0 in produzione ricade completamente su di voi.<\/li>\n<li>Se abbiamo gi\u00e0 preso in carico un'attivit\u00e0, non possiamo immediatamente passare ad altre finch\u00e9 non completata l'attuale (altrimenti questo porta a ulteriori bug e a un aumento dei tempi di sviluppo).<\/li>\n<li>Il numero di persone nel team \u00e8 diminuito (a causa di ferie o malattie), ma il lavoro \u00e8 aumentato e fisicamente non riusciremo a reagire a tutto ci\u00f2 che desiderate.<\/li>\n<li>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.<\/li>\n<li>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.<\/li>\n<li>Qualsiasi task sui bug, senza una descrizione dettagliata della loro origine e schermate, non ci consente di capire cosa \u00e8 andato storto e come riprodurre quel bug.<\/li>\n<li>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.<\/li>\n<li>Poich\u00e9 abbiamo ore di lavoro straordinarie (correzioni urgenti), dobbiamo compensarle in altri giorni.<\/li>\n<\/ol>\n<p>\nDi norma, il cliente comprende subito che non \u00e8 cos\u00ec semplice sviluppare software e che un semplice desiderio non \u00e8 sufficiente.<\/p>\n<p>In generale, questo \u00e8 tutto. Dietro le quinte lascio numerose trattative e la prima messa a punto di tutti i processi, ma il risultato \u00e8 che tutto si \u00e8 sistemato. Posso dire che questo processo \u00e8 diventato per noi una sorta di \"Proiettile d'Argento\". Le nuove persone che venivano nel progetto potevano gi\u00e0 mettersi al lavoro fin dal primo giorno, poich\u00e9 tutti i processi sono descritti e la documentazione e l'architettura in forma di diagramma fornivano immediatamente un'idea di ci\u00f2 di cui ci occupiamo. <\/p>\n<p><i>P. S. Vorrei chiarire che non abbiamo un project manager dalla nostra parte. \u00c8 presente dalla parte del cliente. Non \u00e8 affatto un tecnico. Il progetto \u00e8 europeo. Tutta la comunicazione \u00e8 solo in inglese.<\/i><\/p>\n<p>Buona fortuna a tutti nei vostri progetti. Non bruciatevi e cercate di migliorare i vostri processi.<\/p>\n<p>Il sorgente \u00e8 nel mio <noindex><a rel=\"nofollow\" href=\"https:\/\/cleverman.org\/post\/organizaciya-rabochego-processa-v-komande-na-it-proekte\">blog<\/a><\/noindex>.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/524460\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443. \u041e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u0435 \u0447\u0435\u0442\u043a\u043e\u0433\u043e \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0430\u0445 \u043d\u0430 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445. \u0421\u0430\u043c\u043e\u0435 \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u2014 \u044d\u0442\u043e \u0442\u043e, \u0447\u0442\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u044b \u043d\u0435 \u043f\u043e\u043d\u0438\u043c\u0430\u044e\u0442, \u043a\u0430\u043a \u043d\u0443\u0436\u043d\u043e \u043a\u043e\u043c\u043c\u0443\u043d\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u043e\u043c \u0438 \u0434\u0440\u0443\u0433 \u0441 \u0434\u0440\u0443\u0433\u043e\u043c. \u041a\u0430\u043a \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430. \u041a\u0430\u043a \u0441\u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u0432\u043e\u0439 \u0440\u0430\u0431\u043e\u0447\u0438\u0439 \u0434\u0435\u043d\u044c \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97853","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u043d\u0430 IT-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-22T12:42:44+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-11-17T22:58:50+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Organizzazione del flusso di lavoro nel team su un progetto IT | ProHoster","description":"Ciao amici. Spesso, soprattutto nell'outsourcing, vedo sempre la stessa scena.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u043d\u0430 IT-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442 \u0434\u0440\u0443\u0437\u044c\u044f. \u0421\u043f\u043b\u043e\u0448\u044c \u0438 \u0440\u044f\u0434\u043e\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0435, \u044f \u0432\u0438\u0436\u0443 \u043e\u0434\u043d\u0443 \u0438 \u0442\u0443 \u0436\u0435 \u043a\u0430\u0440\u0442\u0438\u043d\u0443.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-22T12:42:44+00:00","article:modified_time":"2020-11-17T22:58:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97853","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:11:34","updated":"2022-10-03 07:12:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97853","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=97853"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97853\/revisions"}],"predecessor-version":[{"id":172897,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97853\/revisions\/172897"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=97853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=97853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=97853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}