Wereldwijde teams managen heeft een solide structuur nodig en de juiste (software) tools. Er wordt mij vaak gevraagd welke tool wij gebruiken in ons bedrijf. Ik ben altijd verrast als ik iemand onze management tool laat zien en wat zij ervan denken. Voor mij is het logisch zo’n tool te hebben, maar voor mensen zonder ervaring met offshoring is het helemaal niet zo logisch.
Het doel van zo’n tool gebruiken is structuur maximaliseren. Softwareontwikkeling is complex. Menselijk gedrag is complex. De tools moeten softwareontwikkeling gestructureerd maken. En ze moeten de betrokkenen helpen een bepaald gedrag te vertonen dat tot de gewenste resultaten leidt. Dit tweede element is de grootste uitdaging. Softwareontwikkeling is een creatief proces, geen fabriekswerk. Dus we willen creativiteit van de mensen en tegelijk ook dat ze zich op een bepaalde manier gedragen.
Dus welke tools/ingrediënten zijn er nodig om wereldwijde samenwerking tussen teams te creëren?
1. Een gedocumenteerd proces dat antwoord geeft op de vraag 'hoe werken wij'.
Ik denk dat dit het uitgangspunt is van elke wereldwijde samenwerking. Voor de trein vertrekt moet iedereen weten 'hoe wij werken'. Dit proces moet zowel gedocumenteerd als door iedereen ondersteund worden. Het proces moet ook constant bekeken en verbeterd worden. Het zou makkelijk zijn hier een online proces building tool voor te hebben, maar deze heb ik nog niet gevonden. Word documenten zijn ook goed genoeg.
2. Project management tool
Een online tool die ervoor zorgt dat het team alles binnen het project kan managen. Zo´n tool moet verschillende functies hebben:
a. Vereistendocumenten opslaan
b. Taken managen
c. Een bug tracker
d. Een planningsmodule om vooruitgang te plannen en volgen
Populaire project management tools zijn: Redmine en Jira. Simpele bugtrackers zijn Bugzilla en Mantis.
3. Skype of een ander video conferencing tool
Dit lijkt logisch maar veel mensen die geen ervaring hebben met offshoring zijn niet gewend aan skype. Het is erg belangrijk om onderlinge interactie te stimuleren dus de (groep) video functie van skype is hier van groot belang. Het team moet elkaar regelmatig zien zodat ze elkaar leren kennen en over projecten kunnen discussiëren.
4. Tijdsregistratie + reporting
Als mensen ver weg zitten is het moeilijk te begrijpen wat ze precies doen. Tijdsregistratie kan ons daarbij helpen. Programmeurs kunnen de tijd die ze aan bepaalde taken/bugs/projecten spenderen registreren in een online tool, die eens per week door de onshore projectleider wordt bekeken. Het is ook handig om een wekelijkse analyse te hebben van de gespendeerde tijd, zodat mensen begrijpen hoe en waarom tijd gebruikt wordt aan beide kanten.
5. Een version control system
De meest gebruikte tools hier zijn subversion of CVS. Vaak is dit op een webserver geïnstalleerd en vullen mensen aan het einde van hun werkdag hun code in. Een ander systeem dat samenwerkt met onder andere Redmine, is a GIT.
6. Een codeerstandaard
Hoewel dit misschien logisch lijkt hebben maar weinig bedrijven een codeerstandaard. Met verschillende mensen op verschillende locaties die aan één project of systeem werken is het van groot belang dat iedereen weet ‘dit is hoe wij willen dat de softwarecode ontwikkeld wordt’. Een codeerstandaard moet duidelijk zijn voor iedereen en het is handig om de code regelmatig te checken zodat men zich aan de standaard houdt.
7. Een overzicht van verantwoordelijkheden
Wie doet wat? Wie is waar verantwoordelijk voor? Zelfs als mensen voor verschillende bedrijven werken is het handig om een functieprofiel te creëren, waar een overzicht in staat van wat er van ieder persoon verwacht wordt.
8. Een systeem waarin prestaties meetbaar zijn
Als u een samenwerking op lange termijn met een offshore team samenstelt, is het belangrijk hen feedback te geven op hun prestaties. Het is het beste ze te behandelen alsof ze uw eigen werknemers zijn. Voorbeelden zijn ‘stelt vragen als vereisten niet duidelijk zijn’, ‘stelt ideeën voor voor betere oplossingen’, ‘is proactief’, ‘haalt deadlines’. U kunt hier een cijfer aan geven van 1 tot 10. Het is ook handig om het offshore team te vragen feedback te geven op bepaalde factoren (bijvoorbeeld duidelijke takenspecificaties, duidelijke verwachtingen, helpt bij technische problemen). Het helpt ook om een online survey tool (bijv. surveymonkey) te gebruiken of een ander systeem dat hier specifiek voor bedoelt is.
Met zulke tools en systemen gaat het werk makkelijker. Gedrag wordt gestructureerd, er wordt feedback gegeven en het team heeft het gevoel controle te hebben. En nog is er veel ruimte voor gedrag om af te wijken van het verwachte gedrag. Misschien heeft u een aantal tools of methoden die u aan de lijst kunt toevoegen?
Het lijkt een open deur, maar ik heb zelden gezien dat projecten het bovenstaande lijstje in zijn geheel hebben ingevuld. Ik bedoel dan interne projecten en externe projecten. Het is vaak zo dat men maar begint en na verloop van tijd worden de tools voor besturing e.d. toegevoegd.
in die zin is het een goed en bruikbaar artikel.
Dus een mooi lijstje met bijbehorende bekende tools. Op cloudtools.nl staan nog een aantal mooie tools en je ziet ook dat de tools van 37signals.com worden gebruikt, ze hebben hier een set van “almost free tools” die veel van de bovengenoemde items ondersteunen. Vooral basecamp is handig.
Github.com en cloudfoundry.com bieden gecombineerde omgevingen aan voor social coming, dit is dan wel de open source wereld, maar die kan je afsplitsen en commercieel maken. Ook springsource.com biedt geïntegreerde omgevingen aan die dan weer met github en cloudfoundry samenwerken.
Leuk verhaaltje, maar veel oude wijn in nieuwe zakken.
Grote multinationals die internationaal werken hebben deze tools al jaren in place (m.u.v. videoconferencing wat nog niet zo lang in betaalbare vorm beschikbaar is)
Met name voor code-co-development over meerdere fysieke plaatsen hadden bedrijven als telelogic en IBM/Rational >10 jaar geleden al oplossingen.
Door ook je documenten in een dezelfde repositories op te slaan waren ook deze vanuit alle vestigingen toegankelijk.
Dit alles gedreven vanuit een CMM level 3 organisatie vult al een groot deel van de punten in die genoemd worden.
Het grootste verschil is dat er destijds veel gevlogen werd voor de vergaderingen, waar we vandaag de andere oplossingen kennen.
Door de webinterfaces is het allemaal wat toegankelijker geworden, maar de technieken hierachter zijn niets nieuws.
Kijk ik nu op de markt, dan zie ik steeds meer geïntegreerde suites die de hele lifecycle van softwareontwikkeling ondersteunen. Nummer 1 t/m 5 zijn geïntegreerd in één omgeving. Denk hierbij aan tools als Collabnet, Rational Team Concert of Team Foundation Server.
Even een reflectie:
1) Documenteren?
Ik krijg al jeuk van het woord. Documenteren is dood of zou dood moeten. Ieder project wat ik oplever heeft als requirement documentatie. In *ieder* document zet ik een paar regels als “Als je dit leest heb je gebak verdiend, stuur een email naar henri@henrikoppen.nl, ik vind het fantastisch dat je mijn documentatie leest!”
Mijn eerste gebakje moet ik nog sturen en dit doe ik al ruim 10 jaar!
Het kan zijn dat het zo gebruiksvriendelijk is wat ik doe, maar dat denk ik niet. Natuurlijk is het belangrijk om houvast te hebben, maar pak het natuurlijker aan. Gebruik interne social media zoals een Yammer, SharePoint of Google Docs en leg daar eventueel een wiki bij aan zodat je een beginner wat wegwijs maakt met startpunten. Zorg dat dit goed zoekbaar is op een manier zoals Google werkt. Punt is dat tekst organisch moet groeien en niet apart kunstmatig gefabriceerd moet worden want dat is weggegooid geld. Ik snap compliance, maar las je doet zoals ik beschrijf gaat het prima.
Punt 5 en 2:
Kijk eens op https://tfspreview.com/ . Dit is source control met scrum templates en bugtracker uit de cloud van Microsoft. Op dit moment nog gratis, maar wat een heerlijk product!
Ik werk niet veel met enterprises, maar doe wel veel in internationale teams.
@Henri
Ik herken voor een deel wat je zegt, maar in een aantal sectoren zul je niet onder documentatie uitkomen.
Kijk eens onder op je toetsenbord bijvoorbeeld. Daar staan allerlei kreten en logo’s als CE en Tüv. Wil je die certificeringen binnen halen zul je toch echt e.e.a. aan documenten op moeten hoesten, en dan worden je “gebaks-grapjes” niet gewaardeerd.
Wat hierbij belangrijk is, is dat je weet welke documenten je waarom op moet leveren, en dat je gaat voorkomen dat je gaat documenteren om het documenteren.
Veel documenten worden geschreven omdat iemand x jaar geleden bedacht heeft dat het nodig was vanwege een bepaalde regelgeving. Belangrijk is dat je eens in de zoveel tijd alles eens tegen het licht houdt, en kijkt of dat soort uitspraken nog steeds valide zijn, en/of de regelgevingen nog steeds gelijk zijn.
Voor projecten waarin er samengewerkt moet worden gebruiken wij GroupCamp Project (http://www.groupcamp.nl). Heel compleet om samen te werken met synchronisatie van de agenda’s en veel meer. Mooie interface en super simpel te gebruiken.