Présentation de «20% de temps» sur un lieu de travail [fermé]

20% de temps c'est la culture d'un employeur permettant à ses employés de passer 20% de leur temps à travailler sur des projets qu'ils trouvent intéressants - il peut s'agir d'inventer une nouvelle application, ou d'améliorer un processus existant, etc. Certaines personnes peuvent le savoir comme skunk travail, mais ce terme peut ne pas signifier quelque chose (ou quelque chose de complètement différent) pour vous.

Il existe de nombreux cas documentés de produits exceptionnels nés de 20% / travail de skunk dans une entreprise. Cela ressemble à une situation gagnant / gagnant; l'entreprise peut potentiellement acquérir un excellent nouveau produit ou une nouvelle application, et le développeur a la possibilité de fléchir ses muscles créatifs et d'innover.

J'ai essayé à plusieurs reprises d'introduire une forme de 20% / Skunk travaillant chez mon ancien employeur sans succès.

Comment puis-je mieux le justifier auprès de la direction? Quelle est la "bonne" façon d'aborder ce type d'arrangement de travail?

La raison principale du temps de 20% est de maintenir l'utilisation des capacités à 80% plutôt qu'à 100%.

Vous pouvez considérer une organisation de développement logiciel comme un système qui transforme les demandes de fonctionnalités en fonctionnalités développées. Vous pouvez modéliser son comportement à l'aide de la théorie des files d'attente .

THÉORIE

Si les demandes arrivent plus rapidement que le système ne peut les traiter, elles font la queue. Lorsque les arrivées sont plus lentes, la taille de la file d'attente diminue. Étant donné que les processus d'arrivée et de service sont aléatoires, la taille de la file d'attente change de façon aléatoire avec le temps.

Les personnes mathématiquement inclinées peuvent poser des questions sur ce "caractère aléatoire": il doit y avoir une distribution de probabilité, alors quelle sera la taille de la file d'attente en moyenne? Les mathématiques (théorie des files d'attente) ont une réponse à cela: si les processus d'arrivée et de service sont tous deux Markov, alors N = rho ^ 2 / (1-rho).

(Où rho est le coefficient d'utilisation égal au rapport des taux de service et d'arrivée. Si les processus ne sont pas Markoviens, les calculs sont plus compliqués, mais ne changent pas les conclusions.)

Si vous tracez cette fonction, vous pouvez voir que la longueur moyenne de la file d'attente reste faible tandis que l'utilisation est jusqu'à 0,8 , puis augmente brusquement et va à l'infini. Vous pouvez comprendre cela intuitivement en pensant au processeur de votre ordinateur: lorsque son utilisation approche à 100%, l'ordinateur ne répond plus.

ENTRAINE TOI

L'économie du développement de logiciels est telle que les éditeurs de logiciels encourent de gros coûts lorsque leurs files d'attente sont dans des états de file d'attente élevée. Cela inclut les opportunités de marché manquées, les produits obsolètes, les projets en retard et les déchets causés par les caractéristiques du bâtiment en prévision de la demande.

Le temps de 20% est donc la réponse scientifique au problème de l'optimisation des résultats économiques: éviter les états à file d'attente élevée en évitant les ratios d'utilisation qui en sont la cause. C'est essentiellement le jeu qui maintient le système réactif.

Plusieurs conclusions pratiques suivent immédiatement:

• si vous envisagez de consacrer 20% de votre temps à la comptabilité analytique (le temps des développeurs coûte X, mais / et que l'entreprise peut / ne peut pas se le permettre), vous vous trompez.
• si vous allouez 20% à un vendredi chaque semaine, vous vous trompez
• si vous mettez en place un système de soumission / révision / approbation de proposition de projet d'une durée de 20%, vous vous trompez
• si vous remplissez des feuilles de temps, vous vous trompez
• si vous utilisez l'innovation comme facteur de motivation pendant 20% du temps, vous vous trompez. Bien que de nouveaux produits soient sortis de 20% des projets, ce n'était pas le cas. Si votre entreprise ne peut pas innover pendant ses heures d'ouverture, c'est un problème!
• 20% de temps n'est pas une question de créativité. Ne dites pas que vous libérerez votre créativité avec 20% de temps, demandez pourquoi vous n'êtes pas déjà assez créatif pendant vos heures de base.

RÉPONSES AUX QUESTIONS DES COMMENTAIRES

Dan , vous avez bien compris et décrit avec précision l'erreur commise par beaucoup. Vous ne pouvez pas choisir votre pourcentage d'utilisation, car il s'agit d'une variable de sortie. C'est un rapport des caractéristiques de deux processus, c'est donc ce que c'est parce que les processus sont tels qu'ils sont. Une organisation a une influence sur les deux processus; l'adéquation des capacités et de la demande est l'un des problèmes difficiles traités par le corpus de connaissances sur le développement logiciel allégé. L'utilisation est l'un des indicateurs de la résolution de ce problème dans une organisation. Slack émerge au fur et à mesure que votre initiative Lean progresse et que vous supprimez les déchets du flux de valeur. Mais si vous exigez 20% de temps, vous vous retrouvez dans le même piège d'utilisation avec moins de capacité disponible.

Kim , c'est encore partiellement une affaire de culture. La référence culturelle la plus proche à laquelle je peux penser est le niveau synergique du soi-disant modèle Marshall de changement organisationnel. Il émerge à la fin de transformations Lean réussies ou est présent dans les organisations construites Lean dès le départ. ( Voici un lien vers le livre blanc de Bob Marshall (PDF) .)

LES RÉFÉRENCES

La logique ci-dessus est bien prise en charge dans la littérature en génie logiciel. Mary et Tom Poppendieck en ont fait allusion dans leur livre de 2006 intitulé Implementing Lean Software Development . Donald Reinertsen dans son livre de 2009 intitulé Principles of Product Development Flow (chapitre 3) donne un traitement approfondi de ce sujet, avec des formules et des graphiques.

Quatorze mois après avoir écrit cette réponse, j'en ai trouvé une bien meilleure .

Je n'ai pas travaillé dans un endroit où de telles œuvres étaient officiellement reconnues. Mais à partir de mes conversations et de mes tentatives pour en savoir plus sur cette pratique, j'ai trouvé ceci - enfin, surtout ce que le «temps de 20%» n'est pas:

• c'est en effet une culture et non une politique
• il ne peut pas être décrété par la haute direction
• il ne peut pas être institué par un comité de développeurs
• il n'y a pas 32 heures là-dessus et 8 heures là-dessus

" Skunkworks " n'est pas la même chose que 20% de temps. 20% de temps, c'est comme vous l'avez dit - temps que le développeur choisit lui-même sur quoi travailler. Skunkworks est totalement différent. Un projet skunkworks est un projet de grande valeur et à coût élevé sur lequel travaille une équipe (souvent une équipe dissidente de gourous) qui n'est pas signalé à la haute direction, et l'équipe décide elle-même de la façon dont le projet doit se dérouler sans direction de gestion . Ces projets sont souvent motivés par un besoin tactique ou commercial de faire quelque chose, mais il n'y a pas de place dans le budget pour cela. Si quelque chose doit être fait , cela se fait - les budgets sont maudits.

J'ai dirigé une équipe de développement où j'ai mis en place 20% de temps. Ou essayé de toute façon. J'avais l'approbation de mes supérieurs, donc ce n'était pas un problème. Le problème était que l'équipe était trop petite et trop spécialisée. Chaque fois que des problèmes surgissaient nécessitant une intervention immédiate, le temps de 20% était augmenté. Cela a fini par se produire très souvent.

J'ai également constaté que certains de mes développeurs ont trouvé mon manque de direction troublant. Même si j'ai dit "travaillez sur tout ce que vous voulez, tant que c'est lié à la programmation", ils ont toujours eu du mal à accepter la partie "n'importe quoi". Ils pensaient que certains projets seraient meilleurs que d'autres, ils ont donc inévitablement travaillé sur des demandes de mise en œuvre de bas niveau dans le produit principal, des choses comme ça. Je voulais qu'ils se diversifient et se développent, mais ils ont plutôt approfondi leur expertise principale.

Je le referais, mais j'interdirais expressément de travailler sur le produit principal et je pourrais les démarrer avec quelques idées à choisir pour commencer.

Je travaille pour une start-up qui a mis en place la politique des 20%. C'est mon premier employeur à le faire, et quand il l'a soulevé lors de l'entretien d'embauche, j'ai été vraiment surpris, car la plupart des autres employeurs essayaient de ne pas "perdre" une seule heure.

J'ai rejoint la start-up lors de sa création, et pendant près d'un an j'étais le seul développeur. J'ai dépensé mes 20% avec essentiellement deux ou trois choses:

• Signaler / corriger des bugs dans des projets open source aléatoires - cela peut être aussi petit que bifurquer un projet intéressant sur Github et corriger quelques fautes de frappe dans les documents.
• Écrire des "trucs" open source - des choses comme des défis de programmation, juste pour le plaisir.
• Aller à des conférences et des sprints - tous les mois, j'irais à un sprint où je peux travailler sur des projets (dont certains pourraient être utilisés par l'application principale, d'autres non) et acquérir de l'expérience. Il y a quelques bibliothèques utilisées par notre application et par des applications développées par d'autres sociétés qui envoient des développeurs à des conférences, donc cela peut être considéré comme un avantage direct pour notre société.
• Apprendre de nouvelles technologies - c'est ainsi que j'ai appris Go , même si nous ne l'utilisons pas dans l'entreprise. Ceci est particulièrement encouragé par mon employeur. Dernièrement, j'ai suivi certains des cours gratuits en ligne de Stanford.

Les temps ne sont pas mesurés avec précision, ce n'est certainement pas 32 + 8 heures, parfois il y a des choses urgentes à faire quand il n'y a tout simplement pas assez de temps pour couper ces 20%, d'autres fois j'ai plus de temps à perdre.

Je travaille à distance, et nous utilisons le chat Campfire de 37signal pour communiquer et suivre la présence de chacun de manière lâche, et ces heures sont suivies comme des heures "de travail", je suis connecté au chat et disponible pour les collègues, bien que il est clair que je ne travaille pas sur notre projet en ce moment.

D'après ma petite expérience, beaucoup de nos projets ont réellement commencé de cette façon. Nous avions du temps libre et de la bande passante pour entreprendre de nouveaux projets, nous nous sommes réunis et avons proposé des idées intéressantes et avant-gardistes pour notre département. Dans notre temps libre, nous avons développé un prototype et une fois qu'il a été assez poli, présenté au niveau supérieur et généralement, ils voient l'avantage.

Il me semble que le niveau supérieur sait ce qu'il veut s'il le voit mais ne sait pas qu'il en a besoin / le veut jusqu'à ce qu'il le voie. Le prototypage nous a permis de créer nos propres projets, de les proposer puis, une fois approuvé, de leur consacrer plus de temps.