Démarche légère de résolution de problèmes - Historique des versions

Fabrice Aimetti le 22 août 2018 à 17:12

2018-08-22T17:12:25Z

← Version précédente		Version du 22 août 2018 à 17:12
Ligne 2 :		Ligne 2 :
	[[Category: Portail Lean]]		[[Category: Portail Lean]]
	[[Category: A3]]		[[Category: A3]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Henrik Kniberg<br /> Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br /> Date : 23/08/2012<br />		Auteur : Henrik Kniberg<br />
			Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br />
			Date : 23/08/2012<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 24/08/2012<br />		Traducteur : Fabrice Aimetti<br />
			Date : 24/08/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du [http://www.crisp.se/gratis-material-och-guider/a3-template A3 de résolution de problème] et de [http://en.wikipedia.org/wiki/Toyota_Kata Toyota Kata].<br /> <br /> Au fait, la keynote que je ferai la semaine prochaine à [http://ale2012.alenetwork.eu/ ALE2012] est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé".<br /> <br /> 1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez :<br /> </span><span style="display: block; text-align: justify"><br /> 6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez :<br /> <br /> 7. Faites une analyse des causes racines en utilisant la technique des [http://en.wikipedia.org/wiki/5_Whys 5 Pourquoi] ou un [http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000 Diagramme de cause à effet] ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème.<br /> <br /> 8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu.<br /> <br /> 9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible.<br /> <br /> 10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents.</span><span style="display: block; text-align: justify"><br /> 12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente.<br /> <br /> 13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion.<br /> <br /> 14. Expérimentez-le ! Et planifiez une date pour le suivi.<br /> <br /> 15. ... (expérimentation) ...<br /> <br /> 16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ?<br /> <br /> 17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau.<br /> <br /> Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du [http://www.crisp.se/gratis-material-och-guider/a3-template A3 de résolution de problème] et de [http://en.wikipedia.org/wiki/Toyota_Kata Toyota Kata].<br /> <br /> Au fait, la keynote que je ferai la semaine prochaine à [http://ale2012.alenetwork.eu/ ALE2012] est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé".<br /> <br /> 1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez :<br /> </span><span style="display: block; text-align: justify"><br /> 6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez :<br /> <br /> 7. Faites une analyse des causes racines en utilisant la technique des [http://en.wikipedia.org/wiki/5_Whys 5 Pourquoi] ou un [http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000 Diagramme de cause à effet] ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème.<br /> <br /> 8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu.<br /> <br /> 9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible.<br /> <br /> 10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents.</span><span style="display: block; text-align: justify"><br /> 12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente.<br /> <br /> 13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion.<br /> <br /> 14. Expérimentez-le ! Et planifiez une date pour le suivi.<br /> <br /> 15. ... (expérimentation) ...<br /> <br /> 16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ?<br /> <br /> 17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau.<br /> <br /> Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)

Fabrice Aimetti le 19 juillet 2018 à 06:34

2018-07-19T06:34:15Z

← Version précédente		Version du 19 juillet 2018 à 06:34
Ligne 1 :		Ligne 1 :
	[[Category: Henrik Kniberg]]		[[Category: Henrik Kniberg]]
	[[Category: Portail Lean]]		[[Category: Portail Lean]]
			[[Category: A3]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Henrik Kniberg<br /> Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br /> Date : 23/08/2012<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Henrik Kniberg<br /> Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br /> Date : 23/08/2012<br />
	----		----

Fabrice Aimetti le 26 juin 2018 à 11:37

2018-06-26T11:37:14Z

← Version précédente		Version du 26 juin 2018 à 11:37
Ligne 1 :		Ligne 1 :
	[[Category: Henrik Kniberg]]		[[Category: Henrik Kniberg]]
	[[Category: Portail Lean]]		[[Category: Portail Lean]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : ~~[/Henrik%20Kniberg~~ Henrik Kniberg]<br /> Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br /> Date : 23/08/2012<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Henrik Kniberg<br /> Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template]<br /> Date : 23/08/2012<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 24/08/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 24/08/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du [http://www.crisp.se/gratis-material-och-guider/a3-template A3 de résolution de problème] et de [http://en.wikipedia.org/wiki/Toyota_Kata Toyota Kata].<br /> <br /> Au fait, la keynote que je ferai la semaine prochaine à [http://ale2012.alenetwork.eu/ ALE2012] est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé".<br /> <br /> 1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez :<br /> </span><span style="display: block; text-align: justify"><br /> 6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez :<br /> <br /> 7. Faites une analyse des causes racines en utilisant la technique des [http://en.wikipedia.org/wiki/5_Whys 5 Pourquoi] ou un [http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000 Diagramme de cause à effet] ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème.<br /> <br /> 8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu.<br /> <br /> 9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible.<br /> <br /> 10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents.</span><span style="display: block; text-align: justify"><br /> 12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente.<br /> <br /> 13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion.<br /> <br /> 14. Expérimentez-le ! Et planifiez une date pour le suivi.<br /> <br /> 15. ... (expérimentation) ...<br /> <br /> 16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ?<br /> <br /> 17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau.<br /> <br /> Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du [http://www.crisp.se/gratis-material-och-guider/a3-template A3 de résolution de problème] et de [http://en.wikipedia.org/wiki/Toyota_Kata Toyota Kata].<br /> <br /> Au fait, la keynote que je ferai la semaine prochaine à [http://ale2012.alenetwork.eu/ ALE2012] est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé".<br /> <br /> 1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez :<br /> </span><span style="display: block; text-align: justify"><br /> 6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez :<br /> <br /> 7. Faites une analyse des causes racines en utilisant la technique des [http://en.wikipedia.org/wiki/5_Whys 5 Pourquoi] ou un [http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000 Diagramme de cause à effet] ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème.<br /> <br /> 8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu.<br /> <br /> 9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible.<br /> <br /> 10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues.<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents.</span><span style="display: block; text-align: justify"><br /> 12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente.<br /> <br /> 13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion.<br /> <br /> 14. Expérimentez-le ! Et planifiez une date pour le suivi.<br /> <br /> 15. ... (expérimentation) ...<br /> <br /> 16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ?<br /> <br /> 17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau.<br /> <br /> Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)

Fabrice Aimetti : Page créée avec « Category: Henrik Kniberg Category: Portail Lean
Auteur : [/Henrik%20Kniberg Henrik Kniberg]
Sour... »

2018-06-26T11:37:01Z

Page créée avec « Category: Henrik Kniberg Category: Portail Lean <div id="content_view" class="wiki" style="display: block"> Auteur : [/Henrik%20Kniberg Henrik Kniberg] Sour... »

Nouvelle page

[[Category: Henrik Kniberg]]
[[Category: Portail Lean]]
<div id="content_view" class="wiki" style="display: block"> Auteur : [/Henrik%20Kniberg Henrik Kniberg] Source : [http://blog.crisp.se/2012/08/23/henrikkniberg/problem-solving-template Light-weight problem solving template] Date : 23/08/2012 
----
Traducteur : Fabrice Aimetti Date : 24/08/2012 
----
''Traduction :'' Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du [http://www.crisp.se/gratis-material-och-guider/a3-template A3 de résolution de problème] et de [http://en.wikipedia.org/wiki/Toyota_Kata Toyota Kata]. Au fait, la keynote que je ferai la semaine prochaine à [http://ale2012.alenetwork.eu/ ALE2012] est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé". 1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un. 2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant. 3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre. 4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être. 5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez : 6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez : 7. Faites une analyse des causes racines en utilisant la technique des [http://en.wikipedia.org/wiki/5_Whys 5 Pourquoi] ou un [http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000 Diagramme de cause à effet] ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème. 8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu. 9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible. 10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues. 11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents. 12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente. 13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion. 14. Expérimentez-le ! Et planifiez une date pour le suivi. 15. ... (expérimentation) ... 16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ? 17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau. Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)

Démarche légère de résolution de problèmes - Historique des versions

Fabrice Aimetti le 22 août 2018 à 17:12

Fabrice Aimetti le 19 juillet 2018 à 06:34

Fabrice Aimetti le 26 juin 2018 à 11:37

Fabrice Aimetti : Page créée avec « Category: Henrik Kniberg Category: Portail Lean Auteur : [/Henrik%20Kniberg Henrik Kniberg] Sour... »

Fabrice Aimetti : Page créée avec « Category: Henrik Kniberg Category: Portail Lean
Auteur : [/Henrik%20Kniberg Henrik Kniberg]
Sour... »