Un CP doit savoir juger du travail réalisé et donc de la performance du produit livré : il est bon qu'il puisse insuffler des méthodes ou pratiques qualitatives et qu'il puisse les contrôler (et donc de comprendre un code) et donc de savoir coder ou faire une analyse.
A+
Je ne le sais pas et je n'ai pas envie de le savoir, j'en parlais ironiquement car j'ai eu la joie (c'est ironique encore) il y a quelques années d'avoir une chef de projet qui sortait sans arrêt ses abaques pour compenser sa nullité technique. Cela dit, l'utilisation de ces abaques s'inscrivait dans les préconisations du groupe (un grand assureur français), mais on en arrivait à des situations irréelles : programme simple => 0,5 jour, programme moyen => 1 jour, programme complexe => 3 jours, profil débutant => + 50%, etc...
Ca c'est la théorie, mais c'est quand même bien que le chef de projet puisse le moduler en fonction de son vécu (à condition d'en avoir) et des technos sur lesquelles on bosse, et idéalement s'il peut s'en passer et faire confiance à son pif, pour un bon chef de projet, c'est encore la meilleure des garanties.
Parce que programme simple ou complexe, dans l'absolu ça ne veut strictement rien dire...
Des chercheurs qui cherchent, on en trouve, mais des chercheurs qui trouvent, on en cherche !
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
nan, c'est vraiment de cet ordre.....j'ai croisé des gens qui parlent de "découper un projet en unités élémentaires", et à 3 jours(tout compris, du devis à la mise en prod) par "unité élémentaire", les projets étaient "fiables".
sur un projet à 1000 unités proprement découpées, ça marche peut-être. Sur du plus petit, les surprises risquent d'être nombreuses...
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
ben alors ya vraiment un problème de vocabulaire dans l'industrie
complexe, c'est pas 3 jours tout compris
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Dans ma SSII, les projets sont systématiquement dirigé par un responsable technique (bibi ) et un chef de projet. Le responsable technique prend en charge la gestion des affectations et des tâches, la direction de la spécification, de la conception et de la réalisation. Le chef de projet prend en charge les aspects fonctionnels pur, le relationnel client et sous-traitant, l'administratif et le qualitatif.
Ca permet de bosser avec des chefs de projets qui n'ont pas de compétences technique (ou bien qui sont très mauvais -- comme on dit dans l'armée, on devient chef quand vous êtes trop incompétent sur le terrain).
Nos chef de projet on en générale un valeur ajouté : sectorielle (défense, énergie, santé), méthodologique (Analyse de la valeur, ISO, méthodologie agiles) ou bien ce sont de vieux briscard rompus à la guérilla de bureau.
Aux niveau des coups de pouce que l'un et l'autre peuvent donner à l'équipe (façon main dans le camboui) :
Chef de projet :
* Passer ces @#! de fiches de test fonctionnelles avec l'équipe de test
* Coder (mais alors que les méthodes toString )
Responsable technique
* Transférer la connaissance
* Coder des trucs de fou
* Auditer le code des collaborateurs
Tout ça pour dire que dans un tel fonctionnement il n'est pas utile de faire coder le chef de projet (J'aurai même tendance à le déconseiller dans le cas qui me concerne).
Un peu d'eau au moulin...
Et un chef de chantier ? Doit-il savoir monter un mur ?
Oui.
Et un architecte ?
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Justement, c'est là que ça devient compliqué...
Faut il avoir fait du béton pour savoir dire combien il en faut pour un mur... (abaques ?)
Autre remarque : l'intelligence 'technique' acquise (pas innée).
J'ai vu à plusieurs reprises des maçons être capables de 'savoir' justement calculer pression et poids subis... Sans être architectes. (anticipation, prévention)
J'ai vu des mécanos régler des moteurs (de motos, hein, des trucs d'hommes quoi... pardon... je m'égare) à l'oreille... Sans êtres ingénieurs. (diagnostique)
A mon humble avis, et au vue de ma petite expérience, cela dépend de l'intelligence 'pur' de la personne.
Certaines - rares - arrivent à réfléchir de manière abstraite sur des concepts qu'ils n'ont pas forcément pratiqués, et anticiper, prévenir et diagnostiquer.
D'autres sont obligés de passer par une phase de 'faisage' pour pouvoir ensuite prendre de la hauteur, consciemment ou non.
Chaque métier est composé de technique, sa maîtrise approfondie pour 'faire faire' n'est pas forcément obligatoire, tout dépend des personnes.
Enfin, sur le volet communication d'un CDP, les moteurs sont les mêmes : certains n'ont pas besoin d'avoir fait pour comprendre et convaincre, d'autres si.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager