{"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\/nl\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","title":{"rendered":"Organisatie van het werkproces in een team voor IT-projecten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo vrienden. Het gebeurt vaak, vooral in outsourcing, dat ik steeds dezelfde situatie zie. Gebrek aan een duidelijke werkstructuur binnen teams op verschillende projecten.<\/p>\n<p>Het belangrijkste is dat programmeurs niet begrijpen hoe ze moeten communiceren met de klant en met elkaar. Hoe ze een continu proces van kwaliteitsontwikkeling moeten opbouwen. Hoe ze hun werkdag en sprints moeten plannen.<\/p>\n<p>En dit resulteert uiteindelijk in gemiste deadlines, overuren, constante ruzies over wie schuldig is, en ontevreden klanten \u2013 waar alles naartoe gaat en hoe. Dit leidt vaak tot het vervangen van programmeurs of zelfs hele teams. Klantverlies, reputatieschade, enzovoort.<\/p>\n<p>Tijd geleden kwam ik op zo'n project terecht, waar al deze problemen zich voordeden. <br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNiemand wilde verantwoordelijkheid nemen voor het project (een groot servicemarktplaats), de personeelsverloop was enorm, de klant was voortdurend woedend. De CEO kwam op een gegeven moment naar me toe en zei dat ik de nodige ervaring had, dus hier heb je de kans. Neem het project over. Als je faalt, sluiten we het project en ontslaan we iedereen. Als het lukt, is het geweldig, dan leid je het en ontwikkel je het zoals jij denkt dat nodig is. Uiteindelijk werd ik teamleider van het project en viel alles op mijn schouders.<\/p>\n<p>Het eerste dat ik deed, was een werkproces vanuit het niets ontwikkelen, dat op dat moment aan mijn visie voldeed, en ik schreef een functieomschrijving voor het team. Het implementeren was niet gemakkelijk. Maar na ongeveer een maand was alles geregeld, de ontwikkelaars en de klant waren eraan gewend en alles verliep rustig en comfortabel. Om het team te laten zien dat dit niet gewoon \"een storm in een glas water\" is, maar een echte oplossing voor de situatie, nam ik zoveel mogelijk verantwoordelijkheden op me, zodat het onaangename routinewerk van het team werd weggenomen. <\/p>\n<p>Nu is het anderhalf jaar later en het project ontwikkelt zich zonder overuren, zonder \"rat races\" en allerlei stress. Iemand in het oude team wilde niet zo werken en is vertrokken, anderen waren juist erg blij met de transparante regels. Maar uiteindelijk zijn alle leden van het team zeer gemotiveerd en kennen het enorme project volledig, zowel de frontend als de backend. Inclusief de codebase en de volledige bedrijfslogica. Het is zelfs zover gekomen dat we niet alleen \"peddelaars\" zijn, maar zelf veel zakelijke processen en nieuwe functies bedenken die de onderneming leuk vindt.<\/p>\n<p>Dankzij deze benadering van onze kant, besloot de klant om weer een marktplaats bij ons bedrijf te bestellen, wat ons uiteraard verheugt.<\/p>\n<p>Aangezien dit op mijn project werkt, kan het ook anderen helpen. Dus hier is het proces dat ons heeft geholpen het project te redden:<\/p>\n<p>Het werkproces van het team op het project 'Mijn favoriete project'<\/p>\n<p>a) Binnen het teamproces (tussen ontwikkelaars)<\/p>\n<ul>\n<li>Alle taken worden aangemaakt in het systeem Jira.<\/li>\n<li>Elke taak moet zo goed mogelijk worden beschreven en moet strikt \u00e9\u00e9n actie uitvoeren.<\/li>\n<li>Elke functie die voldoende complex is, wordt opgesplitst in veel kleine taken.<\/li>\n<li>Het team werkt aan functies als \u00e9\u00e9n enkele taak. Eerst doen we samen \u00e9\u00e9n functie, geven deze vervolgens ter test, en daarna pakken we de volgende op.<\/li>\n<li>Elke taak wordt gemarkeerd, voor backend of frontend.<\/li>\n<li>Er zijn typen taken en bugs. Deze moeten correct worden aangegeven.<\/li>\n<li>Na voltooiing van de taak wordt deze overgezet naar de status code review (waarbij een pull request naar een collega wordt aangemaakt).<\/li>\n<li>Degene die de taak heeft uitgevoerd, houdt direct zijn tijd voor deze taak bij.<\/li>\n<li>Na de codecontrole wordt de PR goedgekeurd en daarna voegt degene die deze taak heeft uitgevoerd deze zelfstandig samen in de masterbranch, waarna hij de status wijzigt naar klaar voor deployment op dev. <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\">server<\/a>.<\/li>\n<li>Alle taken die klaar zijn voor deployment op de dev-server worden gedeployed door de teamleider (zijn verantwoordelijkheid), soms door een lid van het team als er iets dringends is. Na de deployment worden alle taken met de status klaar voor deployment op dev veranderd naar de status - klaar voor testen op dev.<\/li>\n<li>Alle taken worden getest door de klant.<\/li>\n<li>Wanneer de klant de taak op dev heeft getest, verandert hij de status naar klaar voor deployment op prod.<\/li>\n<li>Voor de deployment op prod hebben we een aparte branch, waar we de master alleen net voor de deployment samenvoegen.<\/li>\n<li>Als de klant tijdens het testen bugs vindt, stuurt hij de taak terug voor herziening en stelt de status in op teruggestuurd voor herziening. Op deze manier scheiden we nieuwe taken van diegene die niet zijn goedgekeurd.<\/li>\n<li>Uiteindelijk doorlopen alle taken het proces van creatie tot voltooiing: To Do \u2192 In Development \u2192 Code Review \u2192 Ready deploy to dev \u2192 QA op dev \u2192 (Terug naar dev) \u2192 Ready deploy to prod \u2192 QA op prod \u2192 Done.<\/li>\n<li>Elke ontwikkelaar test zijn code zelf, ook als gebruiker van de site. Het is niet toegestaan om de branch met de hoofdtak samen te voegen, tenzij zeker is dat de code werkt.<\/li>\n<li>Elke taak heeft prioriteiten. De prioriteiten worden bepaald door de opdrachtgever of de teamleider.<\/li>\n<li>Ontwikkelaars werken in de eerste plaats aan prioritaire taken.<\/li>\n<li>Ontwikkelaars kunnen taken aan elkaar toewijzen als er verschillende bugs in het systeem zijn gevonden of als een taak uit het werk van meerdere specialisten bestaat.<\/li>\n<li>Alle taken die door de opdrachtgever zijn aangemaakt, komen bij de teamleider, die ze beoordeelt, en vraagt of de opdrachtgever ze moet aanpassen of wijst ze toe aan een van de teamleden.<\/li>\n<li>Alle taken die klaar zijn voor deployment naar dev of prod, komen ook bij de teamleider, die zelfstandig bepaalt wanneer en hoe de deployment plaatsvindt. Na elke deployment moet de teamleider (of een lid van het team) de opdrachtgever hierover informeren. Ook moet hij de statussen van de taken wijzigen naar klaar voor testen op dev\/prod.<\/li>\n<li>Elke dag op hetzelfde tijdstip (bij ons is dat om 12.00 uur) houden we een vergadering met alle teamleden.<\/li>\n<li>Iedereen rapporteert tijdens de vergadering, inclusief de teamleider, wat hij gisteren heeft gedaan, wat hij vandaag van plan is te doen. Wat niet lukt en waarom. Op deze manier is heel het team op de hoogte van wat iedereen doet en in welke fase het project zich bevindt. Dit geeft ons de mogelijkheid om indien nodig onze schattingen en deadlines te voorspellen en bij te stellen.<\/li>\n<li>Tijdens de vergadering informeert de teamleider ook over alle veranderingen in het project en over het niveau van de huidige bugs die niet door de opdrachtgever zijn gevonden. Alle bugs worden besproken en toegewezen aan elk teamlid voor oplossing.<\/li>\n<li>Tijdens de vergadering wijst de teamleider taken toe aan iedereen, rekening houdend met de huidige werklast van de ontwikkelaars, hun niveau van professionele voorbereiding, en de nabijheid van de verschillende taken tot de werkzaamheden van de ontwikkelaar op dat moment.<\/li>\n<li>Tijdens de vergadering ontwikkelt de teamleider een algemene strategie voor de architectuur en bedrijfslogica. Daarna bespreekt het hele team dit en neemt een beslissing over het aanbrengen van correcties of het aannemen van deze strategie.<\/li>\n<li>Elke ontwikkelaar schrijft code en bouwt algoritmes op zelfstandige basis binnen een gezamenlijke architectuur en businesslogica. Iedereen kan zijn visie op de implementatie uitdr\u00fccken, maar niemand wordt gedwongen om het op een bepaalde manier te doen. Elke beslissing wordt onderbouwd. Als er een betere oplossing is, maar er op dat moment geen tijd voor is, wordt er een taak in JIRA aangemaakt voor toekomstige refactoring van een bepaald deel van de code.<\/li>\n<li>Wanneer een ontwikkelaar een taak oppakt, verandert hij de status naar ontwikkeling. Alle communicatie over de verduidelijking van de taak bij de klant ligt op de schouders van de ontwikkelaar. Technische vragen kunnen aan de teamleider of collega's worden gesteld.<\/li>\n<li>Als de ontwikkelaar de essentie van de taak niet begrijpt en de klant deze niet duidelijk kan uitleggen, begint hij aan de volgende taak. De huidige taak wordt door de teamleider opgepakt en zelf met de klant besproken.<\/li>\n<li>Elke dag moet de ontwikkelaar in de klantenchat laten weten aan welke taken hij gisteren heeft gewerkt en aan welke taken hij vandaag zal werken.<\/li>\n<li>Het werkproces verloopt volgens Scrum. Alles is verdeeld in sprints. Elke sprint duurt twee weken.<\/li>\n<li>De teamleider cre\u00ebert, vult en sluit de sprints.<\/li>\n<li>Als het project strenge deadlines heeft, proberen we alle taken te schatten. Vervolgens stellen we een sprint samen. Als de klant probeert extra taken aan de sprint toe te voegen, stellen we prioriteiten en schuiven we andere taken naar de volgende sprint.<\/li>\n<\/ul>\n<p>\nb) Het proces van werken met de klant<\/p>\n<ul>\n<li>Elke ontwikkelaar kan en moet communiceren met de klant.<\/li>\n<li>We mogen de klant niet toestaan om zijn spelregels op te dringen. We moeten op een beleefde en vriendelijke manier duidelijk maken aan de klant dat wij specialisten zijn in ons vakgebied en dat alleen wij de werkprocessen moeten opzetten en de klant daarin moeten betrekken.<\/li>\n<li>Idealiter is het, voordat je begint met de implementatie van een functionaliteit, noodzakelijk om een stroomschema van het volledige logische proces voor de feature (workflow) op te stellen. Dit moet naar de klant worden gestuurd ter goedkeuring. Dit betreft alleen complexe en niet-voor-de-hand-liggende functionaliteiten, zoals een betalingssysteem of een meldingssysteem, enz. Dit zal helpen om beter te begrijpen wat de klant precies nodig heeft, de documentatie van de feature te behouden en jezelf te verzekeren tegen het feit dat de klant in de toekomst zou kunnen zeggen dat we niet hebben gedaan wat hij vroeg.<\/li>\n<li>Alle diagrammen\/stroomschema's\/logica enz. bewaren we in Confluence\/Jira, waar we de klant vragen om in de opmerkingen de juistheid van de toekomstige implementatie te bevestigen.<\/li>\n<li>We proberen de klant niet te belasten met technische details. Als we inzicht nodig hebben in wat de klant wil, maken we primitieve algoritmes in de vorm van stroomschema's, die de klant kan begrijpen en zelf kan corrigeren\/aanpassen.<\/li>\n<li>Als de klant een bug in het project vindt, vragen we hem deze zeer gedetailleerd te beschrijven in Jira. Onder welke omstandigheden deed het zich voor, wanneer, welke reeks acties ondernam de klant tijdens het testen. We vragen om screenshots toe te voegen.<\/li>\n<li>We proberen elke dag, maximaal om de dag, een deployment naar de ontwikkelserver te doen. De klant begint dan met testen van de functionaliteit en het project staat niet stil. Dit is ook een indicator voor de klant dat het project volop in ontwikkeling is en niemand vertelt hem sprookjes.<\/li>\n<li>Het komt vaak voor dat de klant niet volledig begrijpt wat hij eigenlijk nodig heeft. Aangezien hij een nieuw bedrijf begint met nog niet geoptimaliseerde processen. Daarom komt het vaak voor dat we hele stukken code in de prullenbak gooien en de logica van de applicatie herschrijven. Hieruit volgt dat je niet alles moet dekken met tests. Het heeft zin om alleen de kritieke functionaliteit te testen en dat met voorbehouden.<\/li>\n<li>Er zijn situaties waarin het team zich realiseert dat we niet binnen de deadlines kunnen blijven. Dan voeren we een snelle audit van de taken uit en informeren we de klant direct. Als oplossing stellen we voor om belangrijke en kritieke functionaliteit op tijd te lanceren en de rest voor na de release te laten.<\/li>\n<li>Als de klant begint met het verzinnen van verschillende taken uit het niets, begint te fantaseren en alles met de hand uitlegt, vragen we hem om ons een pagina-ontwerp en flow met logica te geven die het gedrag van het hele ontwerp en zijn elementen volledig moet beschrijven.<\/li>\n<li>Voordat we met een taak aan de slag gaan, moeten we ervoor zorgen dat deze functie onder de voorwaarden van ons contract valt. Als het een nieuwe functie is die buiten onze oorspronkelijke afspraken valt, moeten we deze functie beoordelen ((geschatte uitvoeringstijd + 30%) x 2) en de klant laten weten dat we zoveel tijd nodig hebben, plus dat de deadline wordt verschoven met de geschatte tijd vermenigvuldigd met twee. Als we de taak sneller kunnen voltooien \u2014 geweldig, dan profiteert iedereen daarvan. Zo niet, dan hebben we onszelf beschermd.<\/li>\n<\/ul>\n<p>\nv) Wat we niet accepteren in het team:<\/p>\n<ul>\n<li>Onbetrouwbaarheid, chaos, vergeetachtigheid.<\/li>\n<li>Het \"voederen met ontbijten\". Als je een taak niet kunt uitvoeren of niet weet hoe, moet je dit onmiddellijk aan de teamleider melden, en niet tot het laatste moment wachten.<\/li>\n<li>Stoer doen en opscheppen door iemand die zijn vaardigheden en professionaliteit nog niet bewezen heeft. Als ze bewezen zijn, is het acceptabel, in redelijkheid \ud83d\ude42.<\/li>\n<li>Bedrog in al zijn vormen. Als een taak niet is uitgevoerd, moet je de status niet wijzigen naar voltooid en in de chat van de klant schrijven dat deze klaar is. De computer is kapot, het systeem is gecrasht, de hond heeft de laptop geknaagd \u2014 dit is allemaal onacceptabel. Als er zich een echte overmacht voordoet, moet de teamleider onmiddellijk op de hoogte worden gesteld.<\/li>\n<li>Wanneer een specialist voortdurend offline is en moeilijk bereikbaar is tijdens werktijden.<\/li>\n<li>Toxiciteit in het team is niet toegestaan! Als iemand het ergens niet mee eens is, komt iedereen samen in een vergadering om dit te bespreken en op te lossen.<\/li>\n<\/ul>\n<p>En een aantal andere vragen\/stellingen die ik soms aan mijn klant stel om misverstanden te voorkomen:<\/p>\n<ol>\n<li>Wat zijn uw kwaliteitscriteria?<\/li>\n<li>Hoe bepaalt u of er problemen in het project zijn of niet?<\/li>\n<li>Door al onze aanbevelingen en adviezen voor wijzigingen\/verbeteringen te negeren, dragen alleen jij de risico's.<\/li>\n<li>Elke belangrijke wijziging in het project (bijvoorbeeld alle extra flows) kan leiden tot mogelijke bugs (die we natuurlijk zullen oplossen).<\/li>\n<li>Het is onmogelijk om binnen enkele minuten te begrijpen wat voor probleem er zich in het project heeft voorgedaan, laat staan het onmiddellijk op te lossen.<\/li>\n<li>We werken volgens een specifieke productflow (Taken in Jira \u2014 Ontwikkeling \u2014 Testen \u2014 Deploy). Dit betekent dat we niet op alle verzoeken en klachten in de chat kunnen reageren.<\/li>\n<li>Programmers zijn echt programmeurs en geen professionele testers, en kunnen de kwaliteit van het testen van het project niet waarborgen.<\/li>\n<li>De verantwoordelijkheid voor de eindtest en de acceptatie van taken in productie ligt volledig bij u.<\/li>\n<li>Als we al een taak in behandeling hebben genomen, kunnen we niet onmiddellijk overschakelen naar andere, totdat we de huidige hebben afgerond (anders leidt dit tot nog grotere bugs en een verlenging van de ontwikkelingstijd).<\/li>\n<li>Het aantal mensen in het team is afgenomen (omdat mensen op vakantie zijn of ziek zijn), terwijl het werk is toegenomen en we fysiek niet in staat zijn om op alles te reageren wat u wilt.<\/li>\n<li>Uw verzoek om een deployment naar productie te doen zonder de geteste taken op development is alleen uw risco, en niet dat van de ontwikkelaars.<\/li>\n<li>Wanneer u vage taken stelt, zonder een correcte flow, zonder ontwerpen, dan vereist dit van ons veel meer inspanning en tijd voor uitvoering, omdat wij in plaats van u extra werk moeten doen.<\/li>\n<li>Elke taak over bugs, zonder gedetailleerde beschrijving van hun ontstaan en screenshots, geeft ons geen mogelijkheid om te begrijpen wat er mis is gegaan en hoe we deze bug kunnen reproduceren.<\/li>\n<li>Het project vereist voortdurende aanpassingen en verbeteringen om de prestaties en veiligheid te verhogen. Daarom besteedt het team een deel van zijn tijd aan deze verbeteringen.<\/li>\n<li>Vanwege het feit dat we soms overuren maken (spoedfixes), moeten we deze compenseren op andere dagen.<\/li>\n<\/ol>\n<p>\nOver het algemeen snapt de klant meestal meteen dat softwareontwikkeling niet zo eenvoudig is, en dat alleen de wil niet genoeg is.<\/p>\n<p>Dat is alles. Achter de schermen laat ik veel vergaderingen en de initi\u00eble afstemming van alle processen achter, maar uiteindelijk is alles op orde gekomen. Ik kan zeggen dat dit proces voor ons een soort 'zilveren kogel' is geworden. Nieuwe mensen die bij het project kwamen, konden vanaf de eerste dag direct aan de slag, omdat alle processen zijn gedocumenteerd en de documentatie en architectuur in de vorm van diagrammen meteen inzicht geven in waar we hier allemaal mee bezig zijn. <\/p>\n<p><i>P.S. Ik wil verduidelijken dat er aan onze kant geen projectmanager is. Deze is aan de klantzijde en is helemaal geen techneut. Het project is Europees. Alle communicatie is alleen in het Engels.<\/i><\/p>\n<p>Ik wens iedereen veel succes met de projecten. Burnout is niet de bedoeling; probeer uw processen te verbeteren.<\/p>\n<p>De bron ligt bij mij. <noindex><a rel=\"nofollow\" href=\"https:\/\/cleverman.org\/post\/organizaciya-rabochego-processa-v-komande-na-it-proekte\">blog<\/a><\/noindex>.<br \/>\n<br \/>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47Organisatie van de werkprocessen in een team voor IT-projecten | ProHoster","description":"Hallo vrienden. Vaak en overal, vooral in de outsourcing, zie ik hetzelfde patroon.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/organizacziya-rabochego-proczessa-v-komande-na-it-proekte","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/97853","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=97853"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/97853\/revisions"}],"predecessor-version":[{"id":172897,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/97853\/revisions\/172897"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=97853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=97853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=97853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}