Je viens de tomber sur la vidéo tout de suite, et j'ai pris mon temps de suite toutes la vidéo. J'ai vraiment gagné ma journée aujourd'hui c'était bien expliqué la compréhension très facile merci beaucoup et courage à toi
Merci à vous. N'hésitez pas à regarder les autres vidéos que j'ai uploadé sur la chaîné, et à faire un tour sur mon site internet pour d'autre contenu. :D
Mon Bonjour depuis Dakar, Sénégal. C'est ma première video sur la gestion de projet. C'est vraiment très bien expliqué. Merci infiniment. Ça me donne vraiment envie d'apprendre cette matière. Mais comment faire ?
Merci à vous. Vous pouvez regarder mes autres vidéos si ce n'est pas encore fait, mais si vous souhaitez vraiment continuer à apprendre, il existe bon nombre de contenu et de livre pour mettre en pied dans le domaine. Pour cela, je vous conseille quelques ressources : Pour un contenu plus généraliste, vous pouvez lire la dernière édition du PMBoK, qui traite le management de projet en général, avec une partie sur les approches adaptatives issues d'Agile. www.amazon.fr/standard-management-connaissances-Management-Knowledge/dp/1628256834/ref=sr_1_5?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3ECAJTUSG15TY&keywords=pmbok+7&qid=1672325109&s=books&sprefix=pmbok+7%2Cstripbooks%2C91&sr=1-5 Si vous souhaitez passer une réelle formation en ligne, vous pouvez regarder ce que propose le PMI (Project Management Institut) qui rédige ce PMBoK ou bien chez Axelos avec la certification PRINCE2 qui base leur pratique sur le PMBoK. Axelos propose également des formations sur ITIL pour l’informatique. Sur la partie Agile : Le livre sur Scrum de Claude Aubry www.amazon.fr/Scrum-Pour-pratique-vivante-lagilit%C3%A9/dp/2100828290 Les chaines TH-cam ScrumLife et La minute Agile qui sont très bien faites, avec beaucoup de contenu intéressant. th-cam.com/channels/MCnZGIOeLVO65-LBxkkHyQ.html www.youtube.com/@LaMinuteAgile En espérant que cela vous aide. :D
Bonjour un grand merci à vous pour cette excellente présentation. Je dois présenter une maquette pour créer une application de gestion d'inventaire de matériels informatiques. Il s'agit d'un projet étudiant. Pourrais-je utiliser votre plan d'action ? Je suis un peu perdu. Pouvez-vous m'indiquer comment faire ? Je vous remercie
Bonjour. Merci beaucoup pour votre retour. Pour votre projet étudiant, le plan que j'explique durant la phase du cahier des charges peut être utilisé, mais il faudra l'adapter. C'est un plan générique, mais qui reste une bonne base pour démarrer. Pour résumer : - Expression du besoin / Problème à résoudre. - Objectif à atteindre et bénéfices attendus - Description fonctionnelle du produit - Description technique du produit qui rentre en correspondance avec la description fonctionnelle - Comparatif, choix, et descriptif des solutions retenues - Planification pour le déploiement Et si vous devez mettre en application votre projet, et montrer des résultats, cela peut intervenir juste après la planification. Puis finir par une conclusion. Si vous le souhaitez, je propose du coaching pour ce genre de problématique. Nous pouvons, dans un premier, en discuter avec un rendez-vous gratuit, et voir si je peux vous aider. :) Donc n'hésitez pas à me contacter sur mon LinkedIn ou directement depuis le formulaire de mon site.
Avec plaisir. Vous avez le lien dans la description. Je vous le donne, au cas où : onedrive.live.com/?authkey=%21AMKHcxQY%2DZ8v3wM&cid=229719899153DBB4&id=229719899153DBB4%2126685&parId=229719899153DBB4%2120479&o=OneUp
Bonjour. Pour répondre à votre question, le Waterfall est un modèle pour cadrer et suivre toutes les étapes d'un projet. Il permet un contrôle à la fin d'une étape pour ensuite passer à la suivante, et cela jusqu'à la fin du projet. En cela, on ne livre la solution complète et finalisée qu'à la dernière étape du Waterfall pour passer sur une phase de maintenance et support. L'utilisateur ne voit pas le produit avant sa livraison définitive. Cependant, c'est un modèle qu'il faut adapter au contexte. Et cela à donné naissance à certaines méthodes dans des environnements spécifiques (MERISE pour l'informatique, GPP d'Airbus pour l'aéronautique et l'industrie). Le Waterfall permet de bien cadrer toutes les étapes, notamment parce qu'on sait la direction que l'on va prendre, le produit que l'on va développer, et pour bien répartir puis gérer le budget nécessaire à la réalisation du projet. Et cela pour chaque étape. L'itération est avant tout un cycle de développement du produit. Là où le Waterfall cadre le projet dans sa globalité pour donner une vision complète sur des aspects de gestion de projet (gestion du budget, des ressources, des risques, de la communication, etc.). Avec des itérations, on enchaîne les phases de développement pour obtenir un produit. Chaque fin d'itération emmène des tests (technique, fonctionnel, performance, avec l'utilisateur, etc.) pour voir si les objectifs fixés en début de projet en terme de qualité sont atteints. Sinon, on repart sur une itération pour améliorer le produit, jusqu'à l'atteinte des objectifs. Généralement, une itération de développement reste la plus courte possible, mais il n'est pas rare de devoir enchainer des itérations de plusieurs semaines à plusieurs mois. C'est le cas dans le domaine industriel au Japon pour réaliser des pièces avec "zéro défaut" (très employé par Toyota.) En soi, rien n'empêche d'utiliser une approche Waterfall avec des phases de développement par itération. On peut très bien rédiger un cahier des charges avec la liste des objectifs à atteindre, et développer les éléments du produit par itération, car les itérations se retrouvent dans les phases "conception/déploiement/validation" du Waterfall. Les itérations vont apporter cette souplesse dans le développement et permettre de livrer un produit de meilleur qualité que si on l'avait développé en une seule fois, sans tests de validation intermédiaire pendant les étapes. Et, généralement, c'est ce que font beaucoup d'entreprise. Car comme le Waterfall est un modèle, on peut très bien le moduler dans ces étapes pour en définir leur gestion. J'espère avoir été suffisamment clair et avoir répondu à votre question. :)
@@projectitpodcast merci beaucoup. En gros les 2 se font par séquence ou en jalon sauf que en waterfall le client ne voir que la fin alors qu’en itération souvent le product owner participe à chaque revu avant la rétrospective. Si je comprends mieux
Initialement, en Waterfall, la mise en œuvre se faisait en une seule fois, sans livraison ou validation intermédiaires. Bien évidemment, il y a d'énormes limites à cela. Mais comme le Waterfall ne reste qu'un modèle, on peut adapter sa structure. Et c'est comme cela que les entreprises, en fonction de leurs contextes, en sont venues à structurer les phases de conception/déploiement/validation en livrables avec des jalons et/ou avec des itérations. Cela permet au client/utilisateur de voir les avancées, et d'éviter ce qu'on appelle "l'effet tunnel". Airbus, avec son GPP, a minutieusement découpé les phases de conception, et de mise en œuvre, par itération. Mais l'utilisateur n'aura son produit que lorsqu'il sera terminé et qu'il aura validé tous les tests (fonctionnels, techniques, etc.). Voici un lien du schéma pour la méthode d'Airbus. On peut y voir les boucles d'itérations dans les phases Concept, Solution Definition et Solution Development : docplayer.fr/docs-images/44/23249179/images/59-0.png Lorsqu'on fait des itérations seules, il n'y a pas de livraison à la fin d'une itération. Juste des tests de validation pour voir si les objectifs sont atteints. Sinon, on continue les itérations jusqu'à ce que le produit réalisé les atteigne. C'est ce que fait Toyota dans une approche Lean avec la construction de ses voitures. Lorsqu'on est sur une approche vraiment Agile, il y a une livraison à la fin de chaque itération si possible (itération + incrémentale). Généralement, c'est une fonctionnalité très précise (incrément) qui est rendue accessible très rapidement, ce qui fait que les itérations sont très courtes (1 mois maximum). On reste dans une amélioration continue du produit qui, en théorie, pourra évoluer à l'infinie. Mais tout produit a un cycle de vie. Et, un jour, il sera obsolète, il faudra le sortir de son environnement, le "recycler", et le changer. Mais grâce à une approche Agile, on pourra livrer plus rapidement, régulièrement, améliorer le produit en impliquant l'utilisateur, et mieux prolonger le cycle de vie de produit grâce à cette amélioration continue. Mais comme je l'explique, les itérations, suivant le contexte, ne veulent pas forcément dire "livraison" à la fin. On est simplement dans une démarche de livrer un produit terminé et complet, mais qu'on va développer graduellement. Si on est vraiment dans une approche Agile, il y aura une livraison à chaque fin d'itération, et l'utilisateur pourra y avoir accès. J'espère avoir été assez clair. :)
Bonjour. N'hésitez pas à regarder mon contenu gratuit disponible sur ma chaine, ou sur mes podcasts. Voir à consulter ma formation pour devenir chef de projet, où j'y apprends les fondamentaux, et qui est disponible sur mon site. :)
Bonjour. Merci pour votre retour. N'hésitez pas à vous repasser la vidéo sur TH-cam, ou à télécharger le support du cours gratuitement (le lien est dans la description) Vous trouverez également une formation sur les fondamentaux de la gestion de projet Agile sur ma chaine. :)
Le "métier" d'ingénieur va au-delà de la gestion de projet, car un ingénieur intervient sur la création/architecture du produit en lui-même. Ce que ne fait pas un chef de projet qui s'occupe, avant tout, de toutes les étapes du projet, comme la gestion des activités de l'équipe pour réaliser le produit, du budget, des délais, ou d'assurer que la qualité demandée soit respectée. Les deux profils travaillent donc ensemble, et doivent se comprendre. Mais pour la gestion de projet, c'est une activité transverse, donc elle s'applique sur tous les domaines existants. Informatique, BTP, marketing, RH, etc. Et tous les profils doivent avoir des connaissances en gestion de projet.
Dans ce contexte, la réussite du projet dépend avant tout de sa planification et de sa gestion. Lorsque le budget est limité, la main-d'œuvre employée le sera forcément. Prolonger la durée des travaux permet de répartir équitablement les tâches entre les membres de l'équipe, et leur éviter une surcharge de travail. Il faut donc planifier qui fait quoi, mais aussi en combien de temps. Ainsi, on peut mieux gérer l'activité de l'équipe, et donc l'utilisation du budget associé. De plus, il faut concentrer les efforts sur les tâches prioritaires du projet afin d'obtenir un bénéfice minimum. On ne pourra pas tout faire avec très peu de budget, il en va de soi. Mais avant de lancer le projet, il est indispensable de définir clairement son périmètre pour estimer un budget initial adapté aux objectifs à atteindre. Toutefois, il faut savoir rester réaliste : exiger une qualité irréalisable avec des moyens très limités peut compromettre son succès. Dans ce cas, il vaut mieux reporter le lancement du projet jusqu'à ce que les ressources nécessaires soient disponibles, voir l'annuler complètement, plutôt que de risquer de dépenser du temps et de l'argent pour rien. Tout est histoire d'objectif à atteindre, du niveau de qualité nécessaire, et du périmètre.
Bonjour n'hésitez pas à regarder les autres contenus de ma chaine, ou visitez mon site internet. Je propose des formations vidéos pour apprendre l'ensemble des éléments de la gestion de projet.
Bonjour, merci pour votre commentaire. N'hésitez pas à visiter mon site pour d'autre contenu, ou prendre ma formation complète pour devenir chef de projet. Et si vous êtes abonné à la chaine, je vais proposer d'autre contenu à la rentrée. 😃
@@louisatongo8839 Pour la formation, il n'y a pas d'attestation ou de certification. Elle est vraiment focalisée sur l'acquisition des compétences, et la compréhension des outils ou des méthodes pour vous aider à gérer un projet en entreprise. Surtout si vous débutez ou si vous avez besoin de remettre à jour des compétences obsolètes.
Oopss, c'est quoi cette histoire que si le budget est serré on va alonger le délai? N'importe quoi! Le coút dépend principalement du périmètre, et plus ça dure plus ça coûte
Je ne dis pas qu'il faut allonger le délai parce qu'on n’a pas de budget. J'explique que si on n'a pas beaucoup de budget, on n'aura pas énormément de ressources, sous-entendu de main-d'œuvre ou de matériel, pour obtenir un certain niveau de qualité demandée. Mais cela reste valable pour des projets non prioritaires. Donc, si on a que trois personnes dans notre équipe parce qu'on n'a pas d'argent, mais qu'on a un projet à réaliser qui exige un minimum de qualité livrée, on va devoir allonger le projet dans le temps pour bien répartir les tâches de chacun pour éviter qu'ils se retrouvent en surcharge dus au manque de main-d’œuvre. Afin d'obtenir la qualité demandée dans un temps raisonnable. Et le périmètre est défini avant tout via la qualité que l'on souhaite obtenir. Donc les tâches qu'on va devoir effectuer pendant le projet pour obtenir cette qualité, mais aussi ce que l'on ne fait pas. Mais cela ne détermine pas le budget nécessairement. Selon le projet, un petit périmètre peut demander beaucoup d'argent, ou finalement très peu. Si on doit changer du matériel ancien par du matériel plus performant qui coûte cher, mais que cela ne nécessite pas forcément beaucoup de tâches de la part de notre équipe, le périmètre de notre projet sera réduit, mais le coût dépensé pour acheter le matériel peut être élevé, conséquence d'une qualité demandée qui est élevée.
![Hands-On Power BI Tutorial 📊Beginner to Pro [Full Course] ⚡](http://i.ytimg.com/vi/5X5LWcLtkzg/mqdefault.jpg)
Merci pour la clarté de votre explication.
Merci à vous
Je viens de tomber sur la vidéo tout de suite, et j'ai pris mon temps de suite toutes la vidéo. J'ai vraiment gagné ma journée aujourd'hui c'était bien expliqué la compréhension très facile merci beaucoup et courage à toi
Merci beaucoup pour ce commentaire. Du courage, il en faut, mais on y arrive. :D
Je reste sans voix. Simple , limpide et bonne compréhension de votre exposé
Merci pour ce retour ! :)
Vidéo très intéressante
Merci beaucoup pour ces informations très structurées
Avec grand plaisir. :D
Votre formation a changé ma vie.
Si elle a pu vous aider, j'en suis vraiment heureux. Merci beaucoup pour votre retour.
😊😊😊😊😊😊😊q!1😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊@@projectitpodcast
préentation très édifiante et facilement compréhensible. Merci. j'aimerais en savoir plus.
Merci à vous. N'hésitez pas à regarder les autres vidéos que j'ai uploadé sur la chaîné, et à faire un tour sur mon site internet pour d'autre contenu. :D
Mon Bonjour depuis Dakar, Sénégal.
C'est ma première video sur la gestion de projet. C'est vraiment très bien expliqué. Merci infiniment.
Ça me donne vraiment envie d'apprendre cette matière.
Mais comment faire ?
Merci à vous.
Vous pouvez regarder mes autres vidéos si ce n'est pas encore fait, mais si vous souhaitez vraiment continuer à apprendre, il existe bon nombre de contenu et de livre pour mettre en pied dans le domaine.
Pour cela, je vous conseille quelques ressources :
Pour un contenu plus généraliste, vous pouvez lire la dernière édition du PMBoK, qui traite le management de projet en général, avec une partie sur les approches adaptatives issues d'Agile.
www.amazon.fr/standard-management-connaissances-Management-Knowledge/dp/1628256834/ref=sr_1_5?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3ECAJTUSG15TY&keywords=pmbok+7&qid=1672325109&s=books&sprefix=pmbok+7%2Cstripbooks%2C91&sr=1-5
Si vous souhaitez passer une réelle formation en ligne, vous pouvez regarder ce que propose le PMI (Project Management Institut) qui rédige ce PMBoK ou bien chez Axelos avec la certification PRINCE2 qui base leur pratique sur le PMBoK. Axelos propose également des formations sur ITIL pour l’informatique.
Sur la partie Agile :
Le livre sur Scrum de Claude Aubry
www.amazon.fr/Scrum-Pour-pratique-vivante-lagilit%C3%A9/dp/2100828290
Les chaines TH-cam ScrumLife et La minute Agile qui sont très bien faites, avec beaucoup de contenu intéressant.
th-cam.com/channels/MCnZGIOeLVO65-LBxkkHyQ.html
www.youtube.com/@LaMinuteAgile
En espérant que cela vous aide. :D
Merci pour ces cours instructifs
Avec plaisir :)
Merci pour cet exposé, tres bien structuré pour apprendre et s'y retrouver 👌👏
Avec plaisir :)
Une excente explication j aimerais vous .
Merci. :)
Très bien expliqué ! Merci.
Merci à vous également. :D
Wahoo ! quelle clarté dans votre explication. Merci beaucoup
C'est moi qui vous remercie. :D
Vous êtes au top. Merci infiniment !
Merci à vous. :)
Bonjour à tous. Merci vraiment pour votre formation
Merci à vous. :D
Je vous empris monsieur
Bonjour un grand merci à vous pour cette excellente présentation.
Je dois présenter une maquette pour créer une application de gestion d'inventaire de matériels informatiques. Il s'agit d'un projet étudiant. Pourrais-je utiliser votre plan d'action ? Je suis un peu perdu. Pouvez-vous m'indiquer comment faire ? Je vous remercie
Bonjour. Merci beaucoup pour votre retour.
Pour votre projet étudiant, le plan que j'explique durant la phase du cahier des charges peut être utilisé, mais il faudra l'adapter. C'est un plan générique, mais qui reste une bonne base pour démarrer.
Pour résumer :
- Expression du besoin / Problème à résoudre.
- Objectif à atteindre et bénéfices attendus
- Description fonctionnelle du produit
- Description technique du produit qui rentre en correspondance avec la description fonctionnelle
- Comparatif, choix, et descriptif des solutions retenues
- Planification pour le déploiement
Et si vous devez mettre en application votre projet, et montrer des résultats, cela peut intervenir juste après la planification. Puis finir par une conclusion.
Si vous le souhaitez, je propose du coaching pour ce genre de problématique. Nous pouvons, dans un premier, en discuter avec un rendez-vous gratuit, et voir si je peux vous aider. :)
Donc n'hésitez pas à me contacter sur mon LinkedIn ou directement depuis le formulaire de mon site.
Bonjour , déja merci pour votre video très explicite et pertinente ,est ce qu'on pourrais avoir ces diapo par courriel svp?
Avec plaisir.
Vous avez le lien dans la description. Je vous le donne, au cas où : onedrive.live.com/?authkey=%21AMKHcxQY%2DZ8v3wM&cid=229719899153DBB4&id=229719899153DBB4%2126685&parId=229719899153DBB4%2120479&o=OneUp
Quelle est la vraie différence entre le waterfall(Approche cascade) et l'iteration? Merci quand même pour cette belle video
Bonjour.
Pour répondre à votre question, le Waterfall est un modèle pour cadrer et suivre toutes les étapes d'un projet. Il permet un contrôle à la fin d'une étape pour ensuite passer à la suivante, et cela jusqu'à la fin du projet. En cela, on ne livre la solution complète et finalisée qu'à la dernière étape du Waterfall pour passer sur une phase de maintenance et support. L'utilisateur ne voit pas le produit avant sa livraison définitive. Cependant, c'est un modèle qu'il faut adapter au contexte. Et cela à donné naissance à certaines méthodes dans des environnements spécifiques (MERISE pour l'informatique, GPP d'Airbus pour l'aéronautique et l'industrie). Le Waterfall permet de bien cadrer toutes les étapes, notamment parce qu'on sait la direction que l'on va prendre, le produit que l'on va développer, et pour bien répartir puis gérer le budget nécessaire à la réalisation du projet. Et cela pour chaque étape.
L'itération est avant tout un cycle de développement du produit. Là où le Waterfall cadre le projet dans sa globalité pour donner une vision complète sur des aspects de gestion de projet (gestion du budget, des ressources, des risques, de la communication, etc.). Avec des itérations, on enchaîne les phases de développement pour obtenir un produit. Chaque fin d'itération emmène des tests (technique, fonctionnel, performance, avec l'utilisateur, etc.) pour voir si les objectifs fixés en début de projet en terme de qualité sont atteints. Sinon, on repart sur une itération pour améliorer le produit, jusqu'à l'atteinte des objectifs.
Généralement, une itération de développement reste la plus courte possible, mais il n'est pas rare de devoir enchainer des itérations de plusieurs semaines à plusieurs mois. C'est le cas dans le domaine industriel au Japon pour réaliser des pièces avec "zéro défaut" (très employé par Toyota.)
En soi, rien n'empêche d'utiliser une approche Waterfall avec des phases de développement par itération. On peut très bien rédiger un cahier des charges avec la liste des objectifs à atteindre, et développer les éléments du produit par itération, car les itérations se retrouvent dans les phases "conception/déploiement/validation" du Waterfall. Les itérations vont apporter cette souplesse dans le développement et permettre de livrer un produit de meilleur qualité que si on l'avait développé en une seule fois, sans tests de validation intermédiaire pendant les étapes. Et, généralement, c'est ce que font beaucoup d'entreprise. Car comme le Waterfall est un modèle, on peut très bien le moduler dans ces étapes pour en définir leur gestion.
J'espère avoir été suffisamment clair et avoir répondu à votre question. :)
@@projectitpodcast merci beaucoup. En gros les 2 se font par séquence ou en jalon sauf que en waterfall le client ne voir que la fin alors qu’en itération souvent le product owner participe à chaque revu avant la rétrospective. Si je comprends mieux
Initialement, en Waterfall, la mise en œuvre se faisait en une seule fois, sans livraison ou validation intermédiaires.
Bien évidemment, il y a d'énormes limites à cela. Mais comme le Waterfall ne reste qu'un modèle, on peut adapter sa structure. Et c'est comme cela que les entreprises, en fonction de leurs contextes, en sont venues à structurer les phases de conception/déploiement/validation en livrables avec des jalons et/ou avec des itérations. Cela permet au client/utilisateur de voir les avancées, et d'éviter ce qu'on appelle "l'effet tunnel".
Airbus, avec son GPP, a minutieusement découpé les phases de conception, et de mise en œuvre, par itération. Mais l'utilisateur n'aura son produit que lorsqu'il sera terminé et qu'il aura validé tous les tests (fonctionnels, techniques, etc.).
Voici un lien du schéma pour la méthode d'Airbus. On peut y voir les boucles d'itérations dans les phases Concept, Solution Definition et Solution Development :
docplayer.fr/docs-images/44/23249179/images/59-0.png
Lorsqu'on fait des itérations seules, il n'y a pas de livraison à la fin d'une itération. Juste des tests de validation pour voir si les objectifs sont atteints. Sinon, on continue les itérations jusqu'à ce que le produit réalisé les atteigne. C'est ce que fait Toyota dans une approche Lean avec la construction de ses voitures.
Lorsqu'on est sur une approche vraiment Agile, il y a une livraison à la fin de chaque itération si possible (itération + incrémentale). Généralement, c'est une fonctionnalité très précise (incrément) qui est rendue accessible très rapidement, ce qui fait que les itérations sont très courtes (1 mois maximum).
On reste dans une amélioration continue du produit qui, en théorie, pourra évoluer à l'infinie. Mais tout produit a un cycle de vie. Et, un jour, il sera obsolète, il faudra le sortir de son environnement, le "recycler", et le changer. Mais grâce à une approche Agile, on pourra livrer plus rapidement, régulièrement, améliorer le produit en impliquant l'utilisateur, et mieux prolonger le cycle de vie de produit grâce à cette amélioration continue.
Mais comme je l'explique, les itérations, suivant le contexte, ne veulent pas forcément dire "livraison" à la fin. On est simplement dans une démarche de livrer un produit terminé et complet, mais qu'on va développer graduellement.
Si on est vraiment dans une approche Agile, il y aura une livraison à chaque fin d'itération, et l'utilisateur pourra y avoir accès.
J'espère avoir été assez clair. :)
bonjour, je suis étudiants en master 2 en gestion des projet. j'aimerais apprendre beaucoup de la gestion des projets
Bonjour. N'hésitez pas à regarder mon contenu gratuit disponible sur ma chaine, ou sur mes podcasts. Voir à consulter ma formation pour devenir chef de projet, où j'y apprends les fondamentaux, et qui est disponible sur mon site. :)
Vraiment merci
Avec plaisir. :D
Très bonne présentation. J'ai été pris autrement pour comprendre certains concepts.
Comment réécouter cette présentation ?
Bonjour. Merci pour votre retour. N'hésitez pas à vous repasser la vidéo sur TH-cam, ou à télécharger le support du cours gratuitement (le lien est dans la description)
Vous trouverez également une formation sur les fondamentaux de la gestion de projet Agile sur ma chaine. :)
super pour le travail. Grand merci
Avec plaisir. C'est moi qui vous remercie pour votre retour. :)
Bonjour, ca peut déboucher sur quel type de métier d'ingénieur ?
Le "métier" d'ingénieur va au-delà de la gestion de projet, car un ingénieur intervient sur la création/architecture du produit en lui-même. Ce que ne fait pas un chef de projet qui s'occupe, avant tout, de toutes les étapes du projet, comme la gestion des activités de l'équipe pour réaliser le produit, du budget, des délais, ou d'assurer que la qualité demandée soit respectée. Les deux profils travaillent donc ensemble, et doivent se comprendre.
Mais pour la gestion de projet, c'est une activité transverse, donc elle s'applique sur tous les domaines existants. Informatique, BTP, marketing, RH, etc. Et tous les profils doivent avoir des connaissances en gestion de projet.
Merci beaucoup!
Avec plaisir. ^^
Super exposé, merci beaucoup
Merci à vous pour votre retour également. :D
Est ce que le fait d'allonger le délais du projet permettrait de respecter le budget alloués aux travaux ? Personnellement je vois pas comment.
Dans ce contexte, la réussite du projet dépend avant tout de sa planification et de sa gestion. Lorsque le budget est limité, la main-d'œuvre employée le sera forcément.
Prolonger la durée des travaux permet de répartir équitablement les tâches entre les membres de l'équipe, et leur éviter une surcharge de travail. Il faut donc planifier qui fait quoi, mais aussi en combien de temps. Ainsi, on peut mieux gérer l'activité de l'équipe, et donc l'utilisation du budget associé. De plus, il faut concentrer les efforts sur les tâches prioritaires du projet afin d'obtenir un bénéfice minimum. On ne pourra pas tout faire avec très peu de budget, il en va de soi.
Mais avant de lancer le projet, il est indispensable de définir clairement son périmètre pour estimer un budget initial adapté aux objectifs à atteindre. Toutefois, il faut savoir rester réaliste : exiger une qualité irréalisable avec des moyens très limités peut compromettre son succès. Dans ce cas, il vaut mieux reporter le lancement du projet jusqu'à ce que les ressources nécessaires soient disponibles, voir l'annuler complètement, plutôt que de risquer de dépenser du temps et de l'argent pour rien.
Tout est histoire d'objectif à atteindre, du niveau de qualité nécessaire, et du périmètre.
Bonjour.je suis intéressé par le cours alors comment je peux les avoir en version PDF
Bonjour. Vous trouverez le lien dans la description de la vidéo. C'est un lien OneDrive, vous pouvez le télécharger directement.
Bonjour j'aimerais apprendre ça
Bonjour n'hésitez pas à regarder les autres contenus de ma chaine, ou visitez mon site internet. Je propose des formations vidéos pour apprendre l'ensemble des éléments de la gestion de projet.
bonjour a tous j'aimerais me faire forme en gestion de projet
Bonjour, merci pour votre commentaire. N'hésitez pas à visiter mon site pour d'autre contenu, ou prendre ma formation complète pour devenir chef de projet. Et si vous êtes abonné à la chaine, je vais proposer d'autre contenu à la rentrée. 😃
@@projectitpodcast Est-il possible d'avoir une attestation
@@louisatongo8839 Pour la formation, il n'y a pas d'attestation ou de certification. Elle est vraiment focalisée sur l'acquisition des compétences, et la compréhension des outils ou des méthodes pour vous aider à gérer un projet en entreprise. Surtout si vous débutez ou si vous avez besoin de remettre à jour des compétences obsolètes.
❤
:D
Oopss, c'est quoi cette histoire que si le budget est serré on va alonger le délai? N'importe quoi! Le coút dépend principalement du périmètre, et plus ça dure plus ça coûte
Je ne dis pas qu'il faut allonger le délai parce qu'on n’a pas de budget. J'explique que si on n'a pas beaucoup de budget, on n'aura pas énormément de ressources, sous-entendu de main-d'œuvre ou de matériel, pour obtenir un certain niveau de qualité demandée. Mais cela reste valable pour des projets non prioritaires.
Donc, si on a que trois personnes dans notre équipe parce qu'on n'a pas d'argent, mais qu'on a un projet à réaliser qui exige un minimum de qualité livrée, on va devoir allonger le projet dans le temps pour bien répartir les tâches de chacun pour éviter qu'ils se retrouvent en surcharge dus au manque de main-d’œuvre. Afin d'obtenir la qualité demandée dans un temps raisonnable.
Et le périmètre est défini avant tout via la qualité que l'on souhaite obtenir. Donc les tâches qu'on va devoir effectuer pendant le projet pour obtenir cette qualité, mais aussi ce que l'on ne fait pas.
Mais cela ne détermine pas le budget nécessairement. Selon le projet, un petit périmètre peut demander beaucoup d'argent, ou finalement très peu.
Si on doit changer du matériel ancien par du matériel plus performant qui coûte cher, mais que cela ne nécessite pas forcément beaucoup de tâches de la part de notre équipe, le périmètre de notre projet sera réduit, mais le coût dépensé pour acheter le matériel peut être élevé, conséquence d'une qualité demandée qui est élevée.