From 6ab0a09a9eba397bc38d01de947b35f1c94f90d8 Mon Sep 17 00:00:00 2001 From: hlassiege Date: Sat, 26 Aug 2023 21:13:40 +0200 Subject: [PATCH] Travailler avec des contraintes --- .../2022/09/travailler-avec-contraintes.md | 90 ++++++++---- .../en/2022/09/working-with-constraints.md | 130 ++++++++++++++++++ data/books.ts | 3 + 3 files changed, 195 insertions(+), 28 deletions(-) create mode 100644 content/articles/en/2022/09/working-with-constraints.md diff --git a/content/articles/2022/09/travailler-avec-contraintes.md b/content/articles/2022/09/travailler-avec-contraintes.md index b9ad17dbcb..6ceb08950b 100644 --- a/content/articles/2022/09/travailler-avec-contraintes.md +++ b/content/articles/2022/09/travailler-avec-contraintes.md @@ -1,95 +1,129 @@ --- id: "4" title: "Travailler avec des contraintes" -description: "Pour ce billet, j'ai envie d'aborder une leçon, parmi beaucoup d'autres, que j'ai tiré de LT lorsque j'y étais : l'importance des contraintes" +description: "L'importance des contraintes, ou comment stimuler la créativité et l'innovation en posant des limites" date: "2022-09-03" tags: - "lean" - - "startup" - "product" - - "side-project" - - "future-of-work" img: "mangrove.jpg" cover: "mangrove.jpg" ---- +book: "impactfulSoftwareEngineering" -J'ai une bien triste nouvelle, [Lateral-Thoughts](https://www.societe.com/societe/lateral-thoughts-538042649.html) a fermé récemment ([le site existe encore](http://www.lateral-thoughts.com/) mais la boite a bel et bien fermé). +language: "fr" +alternates: +- en: "https://eventuallycoding.com/en/2022/09/working-with-constraints" +--- -LT il y a des chances que vous ne connaissiez pas mais c'est une boite que j'ai participé à fonder en 2011 et qui a été un catalyseur pour moi. +Récemment, une page s'est tournée, car l'une de mes premières boites a fermé : [Lateral-Thoughts](https://www.societe.com/societe/lateral-thoughts-538042649.html), ou LT pour les intimes, petite entreprise dont j'ai participé à la fondation en 2011 et qui a été un catalyseur pour moi. Je pourrais citer les nombreuses personnes qui y sont passées et qui m'ont marqué. Celles avec qui j'ai continué de travailler chez Malt. Je pourrais passer un temps fou à expliquer le fonctionnement de cette boite, sans aucun management, avec que des devs et qui a contribué à semer les jalons d'un nouveau rapport au travail. -Mais pour ce billet, j'ai envie d'aborder une leçon, parmi beaucoup d'autres, que j'ai tiré de LT lorsque j'y étais : **l'importance des contraintes** +Mais pour ce billet, j'ai envie d'aborder une leçon, parmi beaucoup d'autres, que j'ai tiré de LT lorsque j'y étais : **l'importance des contraintes**. + +## Sans contraintes, pas d'alignement L'un des objectifs de LT c'était de faire du soft. Enfin, je reformule, l'un des objectifs de certaines personnes chez LT, c'était de faire du soft. -Oui, non, parce que c'était une entreprise collaborative basée sur les principes de la sociocratie. Donc il n’y avait pas un big boss qui disait que LT allait faire du soft mais plutôt un consensus global, discuté et voté que nous souhaitions financer le développement logiciel par la prestation de service. +C'était une entreprise collaborative basée sur les principes de la sociocratie. Donc il n’y avait pas un big boss qui disait que LT devait créer un software. Mais il y avait un consensus, discuté et voté et nous souhaitions financer le développement logiciel par la prestation de service. Nous mettions donc de côté des sous pour financer des projets internes. -Et il en est sorti plusieurs, certains plus proches [de sides projects que de vrais produits](https://eventuallycoding.com/2020/07/27/produit-versus-side-project/) mais il y a eu de supers idées qui ont fusé. L'un de ces sides projects, ce fut Malt. Mais ceci est une autre histoire. +Et il en est sorti plusieurs, certains plus proches [de sides projects que de vrais produits](https://eventuallycoding.com/2020/07/27/produit-versus-side-project/) mais il y a eu de superbes idées qui ont fusé. L'un de ces sides projects, ce fut Malt. Mais ceci est une autre histoire. -Toujours est-il que Malt n'est pas devenu Atlassian ou Basecamp. Mais pourquoi donc ? +Toujours est-il que LT n'est pas devenu Atlassian ou Basecamp. Mais pourquoi donc ? Je me rappelle encore des timeoffs incroyablement productifs et d'une session de travail en particulier chez l'un d'entre nous. -A l'époque, l'un des constats c'était que nous avions trop de side projects. Il existait plus d'un side project par membre de la boîte ! Si on voulait aller plus loin, il fallait réussir à fédérer plusieurs personnes sur le même side project. +A l'époque, l'un des constats, c'était que nous avions trop de side projects. Il existait plus d'un side project par membre de la boîte ! Si on voulait aller plus loin, il fallait réussir à fédérer plusieurs personnes sur le même side project. Chacun est venu présenter un lean canvas, inspiré en cela par [le format découvert grace à Camille Roux](https://www.camilleroux.com/2012/11/09/video-testez-votre-idee-en-quelques-heures-sud-web-2012/). -La journée a été super sympa, très productive. Et vous savez quoi. De nouveaux projets ont germé :) +La journée a été super sympa, très productive. Et vous savez quoi ? A l'opposé du plan prévu, de nouveaux projets ont germé :) En fait, ce jour-là, je me suis rendu compte d'une chose, pour faire ce fameux produit commun, il fallait qu'on ait faim. **En réalité nous n'avions pas l'inconfort, les contraintes qui nous poussent à aller plus loin.** -Le modèle financier de LT redistribuait la quasi totalité des revenus aux membres donc si vous prenez un TJM moyen entre 500 et 1000 pour la plupart des personnes, tout le monde s'en sortait très bien. +Le modèle financier de LT redistribuait la quasi-totalité des revenus aux membres donc si vous prenez un TJM moyen entre 500 et 1000 pour la plupart des personnes, tout le monde s'en sortait très bien. A quel moment, quand tu gagnes entre 5 et 10k par mois net, tu te dis que tu vas prendre un risque sur un side project ? Pourquoi se mettre dans une situation inconfortable dans ces conditions ? -J'ai des éléments de réponse puisque j'ai choisi de le faire pour Malt. Mais, c'est pas si évident que ça de franchir le pas. Ces projets dans LT ne pouvaient rester qu'un jeu, et un très bon moyen de veille malgré tout. +J'ai des éléments de réponse puisque j'ai choisi de le faire pour Malt. Mais, ce n'est pas si évident que ça de franchir le pas. Ces projets dans LT ne pouvaient rester qu'un jeu et un très bon moyen de veille malgré tout. Finalement, aucun de ces softs n'a vu le jour au sein de LT. Des produits sont nés avec les membres de LT, mais en dehors. Ce fut donc la première fois que je voyais l'importance de ces contraintes. +## Sans contraintes, pas de réelle innovation + Plus tard, dans une mission de prestation et toujours avec LT, j'ai rejoint un projet chez un grand groupe industriel. Le projet était très ambitieux, avec des finances très importantes (pas mal financé par la BPI). Il regroupait de multiples sociétés au sein d'un conglomérat, des universitaires etc... -A partir de là, je vais donner un point de vue d'une personne parmi des centaines d'autres donc sans doute qu'il me manque beaucoup d'éléments pour être objectif. +À partir de là, je vais donner un point de vue d'une personne parmi des centaines d'autres donc sans doute qu'il me manque beaucoup d'éléments pour être objectif. Ce projet semblait n'avoir aucune contrainte. Pas de date particulière fixée, pas de limites budgétaires, pas de limitations sur le scope, on en rajoutait sans arrêt avec des idées assez farfelues bien souvent. La boite pour laquelle je travaillais avait même racheté une startup US pour le soft et le contenu qu'elle avait produit. Bref, une débauche de moyens. -Et ce projet, eh bien, il n'a été nul part. La boite US rachetée n'a pas apporté de valeur et le produit a été tué. Plusieurs partenaires du conglomérat se sont progressivement désengagés. +Et ce projet, eh bien, il n'a été nulle part. La boite US rachetée n'a pas apporté de valeur et le produit a été tué. Plusieurs partenaires du conglomérat se sont progressivement désengagés. -Le problème principal, tout du moins ressenti par les équipes, c'était une direction totalement floue. **Car qui dit absence de contraintes, dit éparpillement**. Beaucoup de prestataires sont passés, on a bossé sur des problèmes très complexes qui en réalité n'existait pas car pour avancer on se fixait nous même des contraintes, totalement hors sol. +Le problème principal, tout du moins ressenti par les équipes, c'était une direction totalement floue. **Car qui dit absence de contraintes, dit éparpillement**. Beaucoup de prestataires sont passés, on a bossé sur des problèmes très complexes qui en réalité n'existait pas, parce que pour avancer on se fixait nous même des contraintes, complètement hors sol. Ce projet n'avait aucune chance d'aboutir. Ce fut la seconde fois que je voyais nettement en quoi l'absence de contrainte peut tuer un produit. -Car oui, des contraintes, c'est bénéfique. Ca force à faire des choix. Ca force à définir là où on s'investit ou non. Faire des choix fait partie des conditions les plus importantes pour créer un produit et plus généralement une entreprise. Ne pas en faire, ne se poser aucune limite, c'est l'assurance de s'éparpiller. +## Poser des contraintes dans une organisation engineering -Si je ramène ça au développement logiciel, c’est crucial de se donner des contraintes. Une date est une contrainte, un scope est une contrainte, un niveau de qualité est une contrainte, un objectif business chiffré est une contrainte (OKR). +Les contraintes sont donc bénéfiques. Elles forcent à faire des choix, à définir là où on investit ou pas. Ne pas faire de choix, ne se poser aucune limite, c'est l'assurance de s'éparpiller. -Ça va générer du stress mais cela va aussi provoquer l'émergence de solutions intelligentes pour tenir les contraintes. +Si je ramène ça au développement logiciel, c’est crucial de se donner des contraintes. Une date est une contrainte, un scope est une contrainte, un niveau de qualité est une contrainte, un objectif business chiffré est une contrainte. -D’ailleurs, j’en profite puisque je vous ai peut-être gardé jusqu’ici, votre agenda est un parfait exemple de vos contraintes ou de votre absence de contraintes. +Cela peut générer du stress, mais cela va aussi provoquer l'émergence de solutions intelligentes pour tenir les contraintes. -Trop de sujets différents dans votre agenda => symptôme d’éparpillement, les contraintes extérieures ne sont pas assez fortes pour forcer à faire des choix +Mais, en réalité, sauf cas exceptionnel, toute organisation a déjà des contraintes. Le rôle des Tech Leaders c'est de les faire ressortir. C'est justement parce que certaines organisations tech n'en ont pas conscience qu'elles finissent par échouer. -Trop de meetings => les contraintes extérieures ne sont pas assez fortes pour stimuler une recherche d’efficacité. +Elles n'ont pas conscience des contraintes financières, des attentes des utilisateurs ou des attentes du marketing. +Et tout cela mène systématiquement vers une situation désastreuse dont les symptômes ressemblent plus ou moins à cela : +- perte de confiance des équipes marketing (et produit parfois), qui prennent le contrôle complet sur la définition du produit +- perte de confiance de l'entreprise qui préfèrent se tourner vers des partenaires externes (agences de développement) +- manque d'investissement dans la tech qui n'est pas vu comme sérieuse dans sa gestion financière +etc... -Quand la solution devient de placer des meetings entre midi et 2 ou à partir de 18h, vous êtes en train de rater un truc. +Alors, qu'est-ce que j'entends par "poser des contraintes" ? -Pour conclure et parce que je trouve le lien avec ce billet plutôt pertinent, je vais citer un passage du livre "Rework". +Le ou la Tech leader doit aider à clarifier les contraintes, les rendre visibles. +Est-ce qu'il y a une contrainte temporelle forte ? +Quelles sont les contraintes technologiques ? +De quel budget dispose-t-on ? + +Clarifier c'est aussi être capable de confronter et d'expliquer que telle contrainte n'est pas compatible avec telle autre. +Par exemple la contrainte du mois prochain n'est pas compatible avec le contenu demandé et/ou le budget alloué. +L'organisation tech qui réussit à faire émerger ces contraintes, les formaliser et les partager, est une organisation qui instaure une relation de confiance et qui se met dans de bonnes conditions pour créer de l'impact. + +Pour conclure et parce que je trouve le lien avec ce billet plutôt pertinent, je vais citer un passage du livre "Rework". > Send people home at 5 -> +> > When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely -Bref, comment avoir des contraintes est in fine positif pour être plus productif. +## Questions + +Comment définiriez-vous les contraintes de votre organisation ? Sont-elles financières, temporelles, techniques, business, humaines ? + +Plutôt de les voir comme une contrainte, quelle est la dernière fois que ces contraintes vous ont forcé à trouver des solutions intelligentes ? + +## Ressources + +* [Accepter l'ennui](https://eventuallycoding.com/2023/03/accept-boredom) +* [Choisissez vos batailles](https://eventuallycoding.com/2023/03/choisissez-vos-batailles) +* [Rework](https://www.amazon.fr/Rework-Jason-Fried/dp/0307463745) +* [side projects vs real products](https://eventuallycoding.com/2020/07/27/produit-versus-side-project/) +* [le lean canvas](https://www.camilleroux.com/2012/11/09/video-testez-votre-idee-en-quelques-heures-sud-web-2012/) +::tip +Ce billet de blog fait partie du livre [Impactful Software Engineering](/2023/02/impactful-software-engineering). +N'hésitez pas à lire les autres chapitres. +:: diff --git a/content/articles/en/2022/09/working-with-constraints.md b/content/articles/en/2022/09/working-with-constraints.md new file mode 100644 index 0000000000..c0426f7fe0 --- /dev/null +++ b/content/articles/en/2022/09/working-with-constraints.md @@ -0,0 +1,130 @@ +--- +id: "4" +title: "Working with constraints" +description: "The importance of constraints, or how to stimulate creativity and innovation by setting limits" +date: "2022-09-03" +tags: + - "lean" + - "product" +img: "mangrove.jpg" +cover: "mangrove.jpg" + +book: "impactfulSoftwareEngineering" + +language: "en" +alternates: +- fr: "https://eventuallycoding.com/2022/09/travailler-avec-contraintes" +--- + +Recently, a page was turned, as one of my first companies closed: [Lateral-Thoughts](https://www.societe.com/societe/lateral-thoughts-538042649.html), or LT for those in the know, a small company I helped found in 2011 and which was a catalyst for me. + +I could mention the many people who have passed through its doors and left their mark on me. Those with whom I have continued to work at Malt. I could spend an inordinate amount of time explaining the workings of this company, with no management, all devs, and which has helped to lay the foundations for a new relationship with work. + +But for this post, I want to talk about one lesson, among many, that I learned from LT when I was there: **the importance of constraints**. + +## No constraints, no alignment + +One of LT's objectives was to create a software. Well, to rephrase, one of the objectives of some of the people at LT was to create a software. + +It was a collaborative company based on the principles of sociocracy. So there wasn't one big boss saying that LT had to create a software. But there was a consensus, discussed and voted on, and we wanted to finance software development by providing consulting services. + +So we set aside money to finance internal projects. + +And several came out, some more like [side projects than real products](https://eventuallycoding.com/2020/07/27/produit-versus-side-project/) but there were some great ideas that came out. One of those side projects was Malt. But that's another story. + +Still, LT didn't become Atlassian or Basecamp. But why not? + +I still remember the incredibly productive timeoffs and a particular work session. + +One of the things we realized at the time was that we had too many side projects. There was more than one side project per company member! If we wanted to go further, we had to manage to get several people working on the same side project. + +Everyone came along to present a lean canvas. + +It was a really fun, productive day. And do you know what? On the contrary to the plan, new projects sprang up :) + +In fact, one thing I realized that day was that, in order to make this famous joint product, we had to be hungry. + +**In reality, we didn't have the discomfort, the constraints that push us to go further**. + +LT's financial model redistributed almost all income to the members, so if you take an average daily rate between 500 and 1000 euros for most people, everyone was doing very well. + +At what point, when you're earning between 5 and 10k euros a month net, do you say to yourself that you're going to take a risk on a side project? + +Why put yourself in an uncomfortable situation under these conditions? + +I've got some answers, since I chose to do it for Malt. But it's not that easy to take the plunge. These projects in LT could only remain a game, and a very good way of keeping an eye on things. + +In the end, none of these softwares saw the light of day within LT. Products were born with LT members, but outside. + +So this was the first time I saw the importance of these constraints. + +## Without constraints, no real innovation + +Later, still with LT, I joined a project with a major industrial group. The project was very ambitious, with very substantial finances. It brought together multiple companies within a conglomerate, academics etc... + +Here, I'm going to give one person's point of view among hundreds of others, so I'm probably missing a lot of elements to be objective. + +This project seemed to have no constraints. There was no particular date set, no budgetary limits, no limitations on the scope, and we kept adding to it with ideas that were often quite far-fetched. The company I worked for had even bought out a US startup for the software and content it had produced. In short, plenty of resources were used. + +And this project, well, it went nowhere. The U.S. company we bought didn't add any value, and the product was killed. Several of the conglomerate's partners gradually withdrew. + +The main problem, at least as perceived by the teams, was a totally unclear direction. **Because where there were no constraints, there was scattering**. A lot of service providers came and went, and we worked on very complex problems that didn't actually exist, because in order to move forward we had to set ourselves constraints, completely out of nowhere. + +This project had no chance of success. + +It was the second time I saw clearly how the absence of constraints can kill a product. + +## Putting constraints on an engineering organization + +Constraints are therefore beneficial. They force us to make choices, to define where we invest or don't invest. If you don't make any choices, if you don't set any limits, you're guaranteed to waste energy. + +If I take this back to software development, it's crucial to set constraints. A date is a constraint, a scope is a constraint, a quality level is a constraint, a quantified business objective is a constraint. + +This can generate stress, but it can also lead to the emergence of intelligent solutions to cope with constraints. + +But, in reality, except in exceptional cases, every organization already has constraints. The role of Tech Leaders is to bring them out into the open. It's precisely because some tech organizations are unaware of them that they end up failing. + +They're not aware of financial constraints, user expectations or marketing expectations. +And all this systematically leads to a disastrous situation whose symptoms look more or less like this: +- loss of confidence on behalf of the marketing (and sometimes product) teams, who take complete control over product definition +- loss of confidence on behalf of the company, which prefers to rely on external partners (development agencies) +- lack of investment in tech, which is not seen as serious in its financial management + etc... + +So, what do I mean by "setting constraints"? + +The Tech leader must help clarify constraints and make them visible. +Is there a strong time constraint? +What are the technological constraints? +What budget is available? + +Clarification also means being able to confront and explain that one constraint is not compatible with another. +For example, next month's constraint is not compatible with the requested content and/or the allocated budget. + +The tech organization that succeeds in bringing these constraints to light, formalizing and sharing them, is an organization that establishes a relationship of trust and puts itself in the right conditions to create impact. + +To conclude, and because I find the link with this post rather relevant, I'm going to quote a paragraph from the book "Rework". + +> Send people home at 5 +> +> When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely + +## Questions + +How would you define your organization's constraints? Are they financial, temporal, technical, business or human? + +Rather than seeing them as a constraint, when was the last time these constraints forced you to find intelligent solutions? + + +## Resources + +* [Accept boredom](https://eventuallycoding.com/en/2023/03/accept-boredom) +* [Choose your battles vos batailles](https://eventuallycoding.com/en/2023/03/choose-your-battles) +* [Rework](https://www.amazon.fr/Rework-Jason-Fried/dp/0307463745) + + +::tip +This blog post is part of the book [Impactful Software Engineering](/en/2023/02/impactful-software-engineering). +Feel free to read the other chapters. +:: + diff --git a/data/books.ts b/data/books.ts index 27fea536b6..877a133d28 100644 --- a/data/books.ts +++ b/data/books.ts @@ -78,9 +78,11 @@ const tocEn = [ }, { title: "The benefits of constraints", + link: "https://eventuallycoding.com/en/2022/09/working-with-constraints", }, { title: "Fighting complexity", + link: "https://eventuallycoding.com/en/2023/07/fighting-complexity", }, { title: "Estimation and planning in efficient teams", @@ -208,6 +210,7 @@ const tocFr = [ }, { title: "Combattre la complexité", + link: "https://eventuallycoding.com/2023/07/fighting-complexity", }, { title: "Estimation et planification dans les équipes efficaces",