Vraag:
Hoe kan een bedrijf een "20% tijd" -programma zoals dat van Google implementeren?
Reinstate Monica - Goodbye SE
2012-04-13 02:03:46 UTC
view on stackexchange narkive permalink

Ik heb gelezen dat de 20% -regel van Google gaat over het aanmoedigen van plezier en innovatie.

Hoe kan mijn bedrijf een programma als dit implementeren en beheren?

Een goed antwoord op deze vraag moet ook betrekking hebben op deze subvragen:

  • Wat zijn de grenzen voor die 20% van de tijd?
  • Wat gebeurt er als ik 40 uur moet werken om mijn project op tijd af te ronden?
    Zou ik dan verwachten dat ik 10 uur extra "leuk" werk zou doen?
    Kan ik de volgende week gewoon 16 normale uren besteden? Als ik een week mis, verlies ik dan gewoon de 20% uur?
Zeer verwant: [Today is Goof off at work day] (http://www.codinghorror.com/blog/2012/08/today-is-goof-off-at-work-day.html), een blogartikel over 20% tijd door Jeff Atwood.
Eigenlijk gaat Google weg van de 20%. Als je hun officiële pitches leest, praten ze er niet meer over, en het is niet zo aangemoedigd als het was.
Misschien is dat de reden waarom ze niet zo innovatief lijken als ze ooit waren?
Zeven antwoorden:
#1
+38
Hrafn
2012-04-21 03:28:37 UTC
view on stackexchange narkive permalink

Ik kan hier wat informatie over geven op basis van hoe mijn bedrijf het heeft geïmplementeerd en hoe we worstelen.

Bij mijn bedrijf hebben we het geïmplementeerd als een rekruteringsinstrument en als een manier om ingenieursvaardigheden te behouden scherp. Er zijn ook enkele potentieel interessante redenen om te voorkomen dat het gebruik te hoog wordt om het wisselen van context te vergemakkelijken. Dat antwoord bevat ook verschillende goede richtlijnen rond 20% tijd en enkele aanvullende referenties die zijn punt verder ondersteunen.

We baseren ons niet op de punten die daar worden genoemd, maar ik denk dat het de moeite waard is om erover na te denken of u probeert uw eigen 20% tijd in een bedrijf te besteden.

We hebben een paar basisrichtlijnen over waar de 20% tijd van mensen voor kan worden gebruikt. Het moet iets zijn dat in het algemeen bijdraagt ​​aan het bedrijf (inclusief aan de cultuur die we proberen op te bouwen) of aan uw eigen professionele ontwikkeling. Dus tijd besteden aan het leren van een nieuwe programmeertaal is geweldig, de tijd gebruiken om gitaar te leren is dat niet.

We houden ook regelmatig presentaties, en als u de tijd neemt, moet u ook een presentatie geven over waar u aan werkte. Dit houdt de tijd van 20% productief. Sommige dingen waar we 20% tijd voor hebben gevonden, zijn vooral goed voor:

  • Prototypen van ideeën of spelen met technologieën die we nog niet in productie kunnen nemen.
  • Vaardigheden scherp houden.
  • Geweldige mensen rekruteren.
  • Geef engineering de kans om effectieve proofs of concept te bouwen die ondersteuning op productniveau kunnen krijgen.

Wat de toewijzing betreft, hebben we verschillende dingen geprobeerd.

Tijd per week

Het idee hier is dat 1 dag per week wordt besteed aan zijprojecten. In wezen de "als je elke week 20% aan een vrijdag toewijst" -benadering van het probleem. We hebben deze implementatie eerst geprobeerd en kwamen verschillende onmiddellijke problemen tegen:

  • Veel interessante uitdagingen zijn niet bevorderlijk om één dag aan te werken. Het duurt zo lang om vertrouwd te raken met wat u doet.
  • Als u zelfs maar een beetje achterliep bij een bepaalde taak, nam u die niet aan ... wat vaak betekende dat u nooit 20% tijd nam . Omrollen was problematisch, want eerlijk gezegd, als je het op dat niveau volgt met een urenstaat, is er iets misgegaan.
  • Niet erg voorspelbaar vanuit het oogpunt van planning, want hoewel vrijdagen gebruikelijk waren, waren ze niet universeel, en je wist niet wie het zou nemen of dat ze het daadwerkelijk zouden nemen.
  • Het hielp meer bij het plannen, omdat het hielp te voorkomen dat mensen hun persoonlijke snelheid te hoog legden als ze een automatische buffer van 20% installeerden.
  • Het werd grotendeels nooit gebruikt.

Eén iteratie op vijf

We werkten lange tijd met iteraties van twee weken. Dus de volgende implementatie van het idee was dat je één op de vijf iteraties zou besteden aan welke zijprojecten dan ook. Dit werkte redelijk goed - aanzienlijk beter dan de vorige versie. Enkele overwegingen:

  • Dit maakte de zaken zeer voorspelbaar vanuit een productstandpunt. Je wist precies welke weken je zou verliezen en kon dienovereenkomstig plannen.
  • Aan de andere kant kwamen planningsconflicten vaak voor omdat een team de week erna een release zou krijgen en schijnimplementaties of last-minute testen gedaan. Ze merkten dus vaak dat hun planning veranderde, en ze konden gemakkelijk de 20% tijd van iemand anders verstoren vanwege de behoefte aan hun expertise op het gebied van de implementatie of de code.
  • Het hielp niet echt bij het gebruik probleem.
  • Teams die geen perfect gesynchroniseerde iteraties hadden (geen van ons deed het) konden niet echt effectief samenwerken aan grotere of interessantere projecten.

Eén Week op vijf

Toen begonnen we over te stappen op een kanban-systeem en begonnen we in weken te denken in plaats van iteraties, dus schakelden we over van 1 iteratie op 5 naar 1 op 5 week.

  • Conflicten met implementaties kwamen vaker voor (frequentie), maar hadden over het algemeen een lagere impact omdat het gemakkelijker was om een ​​week te blokkeren dan om twee weken te blokkeren.
  • Omdat iedereen week na week werkte, was het gemakkelijker om met andere teams te synchroniseren.

Behalve dat leek het erg op één iteratie op vijf.

Tijdsblokken per kwartaal

Dit is het huidige systeem dat we proberen. Het idee hier is dat je taken voor jezelf instelt op de kanbanborden met de hoeveelheid tijd die eraan wordt toegewezen die je voor het kwartaal krijgt. De tijd rolt niet tussen de kwartalen, maar je kunt het allemaal van voren of helemaal aan het einde nemen, of in kleinere stukjes zoals je wilt. Hierdoor kunnen individuen en teams uitzoeken wat het beste voor hen zou werken op basis van hun releaseschema, en ook om tijd te nemen in stappen van meer of minder dan een week, afhankelijk van hun schema, wat ze proberen te doen, enz.

Dit lost veel van de problemen op die we eerder tegenkwamen, maar het heeft als nadeel dat de tijd beter beheerd moet worden en moeilijker precies te voorspellen is. Aan de andere kant kan het optreden op een lager niveau van verstoring.

#2
+21
jcmeloni
2012-04-21 20:28:06 UTC
view on stackexchange narkive permalink

Ik heb ervaring met werken in organisaties die zoiets als "20% tijd" hebben geïmplementeerd (ook al was het maar "10% tijd") en het is iets dat ik ga implementeren in het bedrijf waar ik zojuist lid van ben geworden.

Het antwoord op de vraag hoe is "zorgvuldig". Dat is niet bedoeld als een sneaky reactie, maar eerder als een echte op een brede vraag waarvan we de details van uw bedrijf niet kennen. Met "zorgvuldig" bedoel ik:

  • met steun van superieuren, of op zijn minst een stilzwijgend begrip van wat er gaande is
  • met consistentie (implementeer het programma niet en neem het onmiddellijk weg)
  • door steun te geven aan degenen die het proberen (kleineer het werkproduct niet en vier de output)
  • met het besef dat u in het begin minder direct voordeel (of output) voor de projecten waaraan mensen officieel zijn toegewezen

Dit leidt tot de vraag die je niet echt stelde, wat waarom doe je dit in de eerste plaats ? Als u het "waarom" hierachter begrijpt, worden de volgende antwoorden op uw subvragen logischer.

Wat zijn de grenzen voor die 20% van de tijd?

Wat je ook wilt, dat verbetert op de een of andere manier de producten van het bedrijf of zijn middelen (bv. jij).

Wat gebeurt er als ik 40 uur moet werken om mijn project op tijd af te ronden? (etc)

Als je geen tijd hebt om aan iets extra's te besteden, doe dat dan niet.

Als je naar de eerste regel van de NY Times-artikel waarnaar u linkt, staat er "Ingenieurs worden aangemoedigd om 20 procent van hun tijd te besteden aan iets bedrijfsgerelateerds dat hen persoonlijk interesseert." Nadruk van mij.

Aangemoedigd. Niet gedwongen. "20% tijd" gaat niet over "verplicht plezier" of "extra werk buiten je eigenlijke opdracht". Het is vrijwillig en het gaat over het ontdekken en aanmoedigen van motivatie op de werkplek.

Het is vermeldenswaard dat het niet iets is dat Google heeft uitgevonden. De notitie ontstond begin jaren zeventig omdat een medewerker van 3M zijn ‘15% tijd’ gebruikte om het te verzinnen.

Daniel Pink, auteur van Drive: The Surprising Truth About What Motivates Us concentreert de discussie over de motivatie van werknemers op drie factoren: de behoefte aan autonomie (de wens om onze eigen levens), meesterschap (de wens om beter te worden in iets dat ertoe doet), en vele voorbeelden van '20% tijd' of Atlassian's FedEx Days, dit zijn evenementen van 1,5 dag die bedoeld zijn om creativiteit te stimuleren en jeuk te krabben , grip krijgen op radicale ideeën en (uiteindelijk) plezier hebben, in de kern de wens hebben om gelukkiger, meer gemotiveerde en betrokken werknemers te maken met het besef dat de investering zich zal terugbetalen in beter werk tijdens de andere 80% van de tijd, als dat de dingen zijn die voor u werken .

Terug naar de oorspronkelijke vraag "hoe doet een bedrijf dit"? Ik kom terug op mijn antwoord "voorzichtig", maar zou ook "met enthousiasme!"

toevoegen
Dit is een geweldig antwoord!
#3
+8
Jim In Texas
2012-04-16 21:09:05 UTC
view on stackexchange narkive permalink

Ik werk in een bedrijf dat zichzelf beschouwt als een 'resultaatgerichte werkplek', ook wel ' resultaatgerichte omgeving' genoemd.

Een ROW-team verwerpt het fabrieksmodel van werkgelegenheid in welke managers en voormannen worden betaald om kudde te rijden op een fabrieksvloer van schapen als kinderen die niet te vertrouwen zijn.

[Terzijde: in de VS worden defensie-aannemers zo goed als tot Taylorisme gedwongen door contractvereisten van de overheid. Dit kan de oorzaak zijn van de veelvoorkomende enorme kostenoverschrijdingen en vaak gemiste leverdata.]

De werkomgeving van het fabrieksmodel wordt soms 'Taylorisme' genoemd, naar Fredrick W Taylor.

Een softwareteam dat in een Taylor-achtige structuur werkt, zou het 20% -concept van Google niet kunnen implementeren, alleen de tijdregistratie zou erg duur en afleidend zijn. Aangezien veel, waarschijnlijk de meeste, van de 20% -projecten nooit resulteren in winst op korte termijn, zou een bedrijf in Taylor-stijl het experiment niet lang voortzetten.

Ik heb nog nooit bij Google gewerkt, maar ik vermoed dat ze een ROW type organisatie. Ik vermoed dat Google-ontwikkelaars samenwerken met hun teamleiders om een ​​schema van verwachte resultaten op te stellen, waarin rekening wordt gehouden met 20% van de projecten van de ontwikkelaars. Ik vermoed dat zolang een ontwikkelaar resultaten levert min of meer volgens het afgesproken (niet opgelegde) plan, er geen zorgen zijn over hoe lang iemand heeft geluncht of dat ze vorige week 9 uur hebben besteed aan hun 20% -project .

Tsjaad - Ik heb de oorspronkelijke vraag bewerkt om speculatie mogelijk te maken, omdat anders alleen het management van Google deze zou kunnen beantwoorden. Ik hoop dat het een geïnformeerde speculatie lijkt, aangezien mijn organisatie, hoewel het geen formeel 20% -beleid heeft, werknemers veel persoonlijke vrijheid geeft om te experimenteren en te leren op werktijd.
Dat is prima in Tsjaad, maar zoals geschreven, kan de vraag door niemand anders dan een Google-manager worden beantwoord. De vraag moet zo worden geformuleerd dat niet-Google-medewerkers op de een of andere manier antwoord kunnen geven. Dat betekent dat de antwoorden 'speculatie' inhouden, of we dat woord nu leuk vinden of niet.
"Hoe kan dit effectief worden geïmplementeerd", wanneer een dergelijk plan * duidelijk is geweest *, mag niet worden beantwoord met "Nee, dat kan je niet doen".
Ik ben blij dat je het Taylorisme hebt genoemd. Er staat een geweldige documentaire over op YouTube, ik zal die vanavond proberen te vinden.
#4
+3
HLGEM
2012-04-16 23:54:40 UTC
view on stackexchange narkive permalink

Ik ga proberen het volgende te beantwoorden:

Of hoe kan een softwareontwikkelingsorganisatie een soortgelijk '20% project'-concept implementeren dat acceptabel zou zijn voor management, klanten en werknemers.

Zoals ik het zie, zou het implementeren van zoiets op een werkplek verschillende wegversperringen moeten overwinnen. U moet zich realiseren dat dit een zakelijke beslissing is en dus zakelijk gezien iets moet zijn dat aan het senior management kan worden verkocht.

Ten eerste, hoe wordt het salaris van de ontwikkelaar momenteel betaald? Als, zoals in de plaats waar ik werk, het grootste deel van de tijd van de ontwikkelaar wordt aangerekend aan klantspecifieke projecten, zal 20% van de tijd die wordt besteed aan niet-factureerbaar werk een moeilijke verkoop zijn. Het geld om die salarissen te betalen, moet ergens vandaan komen en bij elk voorstel om dit te doen, moet worden gespecificeerd van waar. Ik zie drie basiskeuzes: het bedrijf haalt het uit de huidige winst, het bedrijf verhoogt het uurtarief dat aan de klanten in rekening wordt gebracht om ervoor te kunnen betalen of het bedrijf schrijft de veranderde uren aan de klant met 20% (wat al dan niet legaal zijn). Als u geen klantfactureerbaar werk doet, is de eerste keuze uw enige keuze. Als u dat doet, kan het tweede levensvatbaar zijn als (en het is een grote als) het onwaarschijnlijk is dat u klanten zult verliezen als u uw tarieven verhoogt. De derde optie lijkt mij niet echt levensvatbaar en ik zou het niet aanraden tenzij ik wist dat het legaal was.

Om het voorstel te verkopen, moet u echter laten zien wat ze voor het geld krijgen. Het is vergelijkbaar met R&D in een farmaceutisch bedrijf. Het is een groot risico en hoge kosten met een potentieel enorme uitbetaling. Maar hoe te bepalen of het een uitbetaling heeft opgeleverd? Nou, dat is waar je de persoonlijke projecten moet volgen. Dus als u zoiets voorstelt, zorg er dan voor dat u een systeem bedenkt voor persoonlijke projecten die worden geïmplementeerd om bij te houden en kostenbesparingen of nieuwe winsten ervan bij te houden.

U zult de potentiële voordelen in zakelijke termen moeten kwantificeren. Praten over het vermogen om het beste talent aan te trekken, lagere kosten door een hoger personeelsbehoud en natuurlijk de hierboven besproken potentiële winsten.

Vervolgens moet je laten zien hoe de uren zullen worden besteed en hoe de projectplanning moet worden aangepast aan de tijd. Dit betekent dat deadlines vervallen, wat opnieuw geen gemakkelijke verkoop is. Ik zou willen voorstellen dat tot 20% van de uren die in een maand per week in rekening worden gebracht het meest logisch zou zijn. En ja, als je het die maand niet deed, zou je het verliezen, behalve onder buitengewone omstandigheden die een voor een door het management zouden worden beslist. U kunt ook overwegen om een ​​deel of de hele tijd in te lassen als rustperiode tussen grote projecten. Het is een beetje gemakkelijker om externe klanten te vertellen dat niemand tot 1 juni beschikbaar zal zijn om te werken en dat het project 40 werkdagen zal duren dan om hen te vertellen dat het op 15 mei begint en 48 werkdagen zal duren. Een deel hiervan zou moeten overwegen hoe u momenteel zaken doet. Teams die zich meestal in de onderhoudsmodus bevinden, zouden niet zo'n gemakkelijk te definiëren uitvaltijd hebben, maar bij kortere projecten is het waarschijnlijk gemakkelijker om de uren op wekelijkse basis te vinden.

U moet ook aan: Hebben wij meer mensen kopen of deadlines verplaatsen om rekening te houden met de extra 20%.

#5
+2
mhoran_psprep
2012-04-16 17:11:41 UTC
view on stackexchange narkive permalink

De vraag kan het beste worden beantwoord door een bedrijf dat dit beleid heeft, maar ik heb samengewerkt met een aantal organisaties die het hebben geprobeerd, maar het niet hebben gebruikt.

  • In 40 uur werkweek zullen 8 uur worden gebruikt om niet af te vallen, maar om productief te verslaan. In één organisatie betekende de hoeveelheid documentatie die voor deze 20% nodig was, dat er 4 uur aan papierwerk verloren ging.

  • Een groep verwachtte dat werknemers 60 uur per week zouden besteden, daarom wist niemand of het 48 uur werk en 12 uur experimenteren moest zijn; of 60 uur werk en daarna experimenteren aan het einde van de week.

Het idee dat het bedrijf of de werknemer de uren moet bijhouden, zodat het kan worden gebruikt om de werklast te verdelen, klinkt als een administratieve nachtmerrie. Het betekent ook dat de medewerker weet dat het management de tijd bijhoudt en dat het management beslist met welke projecten het waard is om mee te spelen.

Als het niet leuk klonk, of in ieder geval minder stressvol vergeleken met de andere projecten, zou ik er niet in geïnteresseerd zijn.

Ik betwijfel op de een of andere manier dat Google de helft van 20% tijd met papierwerk doodt. Welk bedrijf had een dergelijk documentatieniveau nodig en waarom zou dit vereist zijn?
Het was vereist door een groep die een artikel las over het Google-beleid, maar eigenlijk microbeheerders waren.
Micromanage! = Google. Ik zou dat niet opvatten als een afwijzing van de 20% -regel, alleen het incompetente bedrijf.
Als het doel van een bedrijf is om de kwartaalwinst te maximaliseren door de arbeidskosten te minimaliseren, dan zou een 'goof off' van 20% natuurlijk onbegrijpelijk zijn voor management of werknemers. 's werelds beste werknemers om de wereldheerschappij van hun branche op de lange termijn te implementeren, dan lijkt 20%' goof off 'een kleine prijs te betalen.
@JimInTexas Ik zou zeggen dat het complexer is dan dat, 100% werktijd betekent niet 100% productiviteitstijd. Google's "Goof off" -projecten veranderen soms ook in echte producten (het huidige ontwerp van Google Play is "Goof Off" -tijd). Ik denk dat veel mensen hier het beleid van Google niet begrijpen en niet begrijpen wat er werkelijk gebeurt.
-1 omdat u uitlegt hoe een incompetent bedrijf dit zou doen, niet hoe het correct moet worden geïmplementeerd.
Ik moet dit -1 om dezelfde redenen doen als Rarity.
#6
+1
Thaddeus Howze
2012-04-20 03:29:53 UTC
view on stackexchange narkive permalink

Alle voorgaande ideeën maken het reserveren van tijd veel gecompliceerder dan nodig is. 20% is een dag van een week. Op deze manier wordt er vier dagen gewerkt aan "normale" projecten. Vier weken lang wordt een dag per week besteed aan "ander", meer inspirerend werk. Probeer dit proces voor de grootte.

  1. Het klinkt alsof het idee is verkocht aan de hoger opgeleiden. Als dat het geval is, is daar geen werk te doen.
  2. Als u het project wilt implementeren, doe dit dan op basis van 20% van één dag per week.
  3. Op de vijfde dag van de periode (4 vrijdagen op rij, op de 5e vrijdag) Presenteer het werk.
  4. Zesde vrijdag, selecteer het meest geweldige project. Voeg het toe aan een verfijningswachtrij.
  5. De volgende vier vrijdagen werken rond de ontwikkeling van het project, beslissen of het project echte verdienste heeft.
  6. Zo ja, voeg het dan toe aan het primaire werkschema als een project en werk toe naar een alfaversie.
  7. Demonstreer de alfaversie en beslis of je verder wilt gaan. Houd een lijst bij van andere, minder waardevolle projecten die u kunt overwegen. Waarschijnlijk krijgt de nummer twee van het gekozen project dezelfde aandacht.
  8. Als het project wordt gekozen voor verdere ontwikkeling, voeg het dan toe aan de ontwikkelingswachtrij. Wacht een maand totdat het project is gestabiliseerd, gespoeld en herhaal.
  9. Je zou dit minstens vier keer per jaar moeten kunnen doen.
  10. "Mislukkingen" betekent projecten afgezien van de eerste 8 gekozen projecten kan altijd worden herzien en later opnieuw worden herzien.
#7
+1
Scott Stevens
2013-01-11 05:47:31 UTC
view on stackexchange narkive permalink

Ik ben het eens met de andere opmerkingen dat men dit zeer zorgvuldig moet doen. Ik denk dat je misschien naar het volgende moet streven:

1) evenwichtige doelen . U wilt dat uw werknemers aan projecten werken die mogelijk uw bedrijf ten goede kunnen komen, maar u wilt niet per se teveel controle hebben over wat ze besluiten met deze tijd te doen. Als je ze vertelt waaraan ze kunnen werken, zullen ze het zien als niet anders dan het toevoegen van een ander project op hun bord.

2) Normale uren . Als uw 20% -regels correct zijn geïmplementeerd, is de kans groot dat uw werknemers er buiten kantooruren aan werken. Ik zou het echter niet nodig hebben. Dit valt enigszins samen met het hebben van "evenwichtige doelen". Als je je werknemers vertelt waaraan je wilt dat ze in hun 20% tijd naast hun huidige tijd werken, zullen ze het dure jargon voorbij zien komen en het zien als gedwongen overuren . Het zou gemaakt moeten worden. het is echter duidelijk dat hun normale werkverantwoordelijkheden voorrang hebben. Je zult hard moeten werken om ervoor te zorgen dat hun normale werk wordt beperkt, zodat het hun 20% tijd niet zo vaak binnendringt als realistisch is. Ik zou er verder aan willen toevoegen, als je er moeite mee hebt dat werknemers alleen hun vakbond 40 inzetten terwijl er nog veel werk aan de winkel is, is de kans groot dat je een moreel probleem hebt. Gelukkige medewerkers zullen de tijd nemen om het werk gedaan te krijgen.

3) erkenning . U moet het werk van uw medewerkers herkennen. Zorg ervoor dat u succes, hard werken en innovatie herkent. Niet elk idee dat ze hebben, zal een homerun zijn. Maar je moet deelname aanmoedigen. Ze moeten inzien dat u hun ideeën en bijdragen op prijs stelt.

4) Leuk . U wilt dat uw medewerkers hier plezier aan beleven. Dit is een manier voor hen om intellectuele stoom af te blazen, met andere afdelingen en groepen te praten waar ze normaal niet mee te maken hebben, en problemen of ideeën te ontdekken waarvan ze niet wisten dat ze bestonden. Dit is niet alleen een oefening voor software-ingenieurs, het is ook een oefening voor zakenmensen. Vaak is er een gebrek aan communicatie tussen de softwarekant en de zakelijke kant. Softwaremensen bouwen oplossingen die het bedrijf niet nodig heeft en de zakelijke behoeften hebben geen idee dat er softwareoplossingen zijn voor de problemen waarmee ze dagelijks worden geconfronteerd. Geef beide partijen de kans om met elkaar te communiceren en de tandwielen in hun kop beginnen te slijpen.

5) feedback . Over het algemeen kan uw kilometerstand variëren. Ik denk dat de belangrijkste bron voor u uiteindelijk uw medewerkers zelf zijn. Vraag niet alleen online om feedback vanuit de stapel. Vraag uw medewerkers om hun mening. Ze zullen het waarderen dat je ze vraagt ​​en waarderen de kans om een ​​manier te vinden om dingen te doen die bij hen passen. Uiteindelijk is de 20% -regel naar mijn mening een machine om het moreel te verbeteren, ideeën te genereren en uw organisatie af te vlakken. Ik denk dat het helpt om de bureaucratie te elimineren waar veel bedrijfsculturen mee worstelen. Als er uitdagingen zijn waarmee uw bedrijf wordt geconfronteerd, is de kans groot dat er iemand is die een manier heeft om deze op te lossen. Ze zijn misschien niet de persoon die u verwacht. Luister naar uw medewerkers en ontdek wat voor u werkt.



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...