Récemment, j'ai été chargé de tâches de planification de plus haut niveau en raison du départ du développeur principal de mon équipe. Je déteste la planification à long terme. Mon cerveau ne semble naturellement pas branché pour cela, et je ne m'y intéresse pas assez pour passer le temps de l'apprendre (c'est assez difficile de suivre le côté programmation de l'image).
Peut-on encore être un bon programmeur sans être aussi un planificateur de haut niveau?
En tant que programmeur senior, est-il censé être bon pour planifier l'ensemble du produit et choisir une date d'achèvement?
Réponses:
Les plans de projet détaillés à long terme sont connus pour être généralement extrêmement inexacts. La fonctionnalité du système changera inévitablement avant le lancement, et les gens passent généralement beaucoup de temps à travailler sur les spécificités qui entrent dans la spécification uniquement pour que les parties prenantes lui donnent un bref aperçu au mieux.
Vous devriez en savoir plus sur la planification Agile , vous trouverez peut-être qu'elle correspond mieux à votre état d'esprit. De nombreuses méthodologies Agile essaient de trouver des moyens de s'éloigner d'une planification détaillée et à long terme.
Les méthodologies agiles essaient de minimiser les spécifications techniques détaillées et la documentation en faveur du code auto-documenté et des histoires d'utilisateurs atomiques isolées et, finalement, des logiciels qui fonctionnent. Dans une équipe Agile efficace, il y aura un minimum de temps consacré à la planification.
Lisez le Manifeste Agile et examinez Scrum . Utilisez la méthode de développement itératif et de développement de systèmes dynamiques pour guider le projet.
Le principal inconvénient des approches Agiles est que vous devez admettre ouvertement que vous ne connaissez pas la portée exacte de votre projet , et obtenir l'adhésion de la direction à cette idée peut être extrêmement difficile et prend généralement un certain temps. Voir cette question et réponse et ce post pour quelques conseils à ce sujet.
Cependant, il est certainement vrai que si vous devenez un programmeur plus expérimenté, vous ferez probablement moins de codage, mais je pense que dans une équipe Agile au lieu de signifier que vous écrivez plus de spécifications techniques, cela signifierait que vous passez plus de temps à gérer et à tutorat les membres de votre équipe et la prise de décisions architecturales sur le code.
la source
Oui c'est possible. Cependant, si vous voulez être un bon ingénieur logiciel ou architecte logiciel, c'est là que votre planification de haut niveau entre en jeu. Pour moi, la principale différence entre un programmeur et un ingénieur a été la capacité de voir la situation dans son ensemble.
la source
Pendant un moment, oui. Est-il possible de le faire longtemps? Non.
Avec de nombreux employeurs de nos jours, il est normal de donner des
augmentationsconcurrentielles aucoût de la vie dans l'industrie. Si vous ne vous améliorez pas, n'essayez pas de résoudre des problèmes plus gros et plus difficiles, ces augmentations compétitives vous coûteront sur le marché dans cinq ou dix ans. Continuez ainsi et votre employeur finira par chercher une raison de se débarrasser de vous, et votre employabilité ailleurs sera également considérablement réduite.la source
Bien sûr, vous pouvez être un bon programmeur, du point de vue d'un programmeur. Du point de vue de la direction, c'est une toute autre question. D'après mon expérience, être impliqué dans le processus de planification est le meilleur moyen 1) d'obtenir des affectations de programmation plus intéressantes et 2) de les faire comme vous le souhaitez.
En d'autres termes, une fois qu'il est question de planification à court terme, de nombreuses options sont exclues. Si votre solution préférée prendrait six semaines mais qu'ils n'en avaient prévu que deux, vous êtes coincé avec ce qu'ils ont décidé. Si vous avez des inquiétudes au sujet de quelque chose dont ils ont déjà discuté dans la planification à long terme, ils ne voudront pas le ressasser.
Si vous êtes satisfait de cet état de choses, plus de pouvoir pour vous. La plupart des gens deviennent moins satisfaits de cette expérience lorsqu'ils acquièrent plus d'expérience.
Le sale petit secret est que personne n'est très bon en planification et en estimation à long terme. Les meilleurs planificateurs sont ceux qui sont conscients de leurs limites, alors croyez-le ou non, vous êtes en avance. Obtenez une formation sur la prise en compte de l'incertitude dans l'estimation. Regardez des techniques telles que la planification basée sur des preuves ou Scrum, qui s'appuient sur des données historiques pour montrer la précision de vos estimations. Vous serez plus heureux à long terme si vous avez un plus grand mot à dire dans votre travail.
la source
Réponse courte: Oui, c'est possible.
Cependant, plus vous acquérez de l'expérience avec le type de projets auxquels vous participez, meilleures seront les idées de planification que vous aurez. Idéalement, en tant que programmeur, nous avons une approche pour résoudre le problème ou nous en cherchons un. Ainsi, si nous connaissons l'approche, nous pouvons commencer à penser à la planification :)
Un autre itinéraire possible est qu'un programmeur qui devient un bon planificateur se dirige également vers la gestion de projet. Ainsi, si vous êtes intéressé par la gestion de projets, vous pouvez faire un effort supplémentaire dans cette direction.
la source
Oui et non sont vos réponses.
D'une part, vous êtes orienté vers la gestion de projet. OMI, tous les bons programmeurs ont un certain degré de capacité de gestion de projet, mais ce sont des compétences différentes. La capacité de planifier à long terme améliore votre capacité à communiquer avec la gestion réelle du projet. Donc «non», vous ne pouvez pas être un bon programmeur sans avoir la capacité de planifier à long terme.
Cela dit, la gestion de projet est un ensemble de compétences différent qui fait appel à des aspects liés mais différents de la programmation. Voici donc où le «oui» entre en jeu. Il n'est pas nécessaire d'être un chef de projet pour être un excellent programmeur.
Pour votre situation spécifique, essayez de devenir plus objectif sur les besoins de l'entreprise ainsi que sur ce que vous aimez faire. Il y a un peu trop d'ego reflété dans votre question et cela biaise votre capacité à regarder cette situation. Si vous pouvez trouver des moyens de contribuer davantage à votre employeur tout en faisant les choses que vous aimez, alors vous devriez les considérer et en discuter avec votre patron.
la source
La planification et le Bungie-Boss
Dilbert a de nombreuses bandes sur le bungie-boss. Nos défis et nos attentes en matière de planification peuvent être à la fois la cause et l'effet de la chute du leadership. D'après mon expérience dans une entreprise du Fortune 100, en un an, tous ceux qui ont commencé l'année en tant que chef de projet ont quitté. C'était peut-être dû au problème de planification. Je ne sais pas si votre ancien responsable est parti pour cette raison, mais lorsque votre rôle vous oblige à faire un plan avec un engagement, si cela ne se réalise pas, souvent, une sortie liée à la date limite est le résultat.
Contexte organisationnel de la planification
Si vous n'êtes pas à l'aise avec la planification, vous n'êtes peut-être pas à l'aise avec la responsabilité des engagements pris envers le marketing ou d'autres parties prenantes avant que les problèmes à résoudre soient documentés ou compris. C'est un bon instinct.
La planification est un outil important. Ne le néglige pas. Ne vous méprenez pas.
La planification est intimement liée aux engagements, à la responsabilité et au pouvoir de négociation. La planification agile a de nombreux avantages. Vous devez connaître ses techniques, ainsi que les techniques des méthodologies prévues. Votre organisation peut avoir sa propre approche et obtenir des conseils et travailler avec quelqu'un qui a survécu au leadership de nombreux projets peut être étonnamment utile.
Un exemple de planification simple - ne doit pas concerner un logiciel ...
Si une entreprise de toiture venait chez moi pour enchérir sur un remplaçant, si elle offrait trop bas, elle pourrait perdre de l'argent sur le chantier, mais si elle soumissionnait trop, elle n'obtiendrait pas du tout le travail. De toute façon, ils sont en faillite. Dans votre nouveau rôle, si vous mordez trop bas, vous exécuterez le projet jusqu'à ce que la responsabilité entre en jeu, puis vous aurez des problèmes. Si vous estimez un projet avec suffisamment de rembourrage pour assurer le succès dans les délais, ils choisissent simplement quelqu'un d'autre pour diriger. Le truc, c'est que vous n'êtes pas comme le couvreur. Il peut voir la taille du toit et dispose de données historiques sur la durée de la taille du toit.
Devenir un meilleur planificateur
Vous voudrez peut-être envisager une sorte de formation. Dans les méthodologies agiles et les méthodologies planifiées les plus récentes, l'estimation est une activité à l'échelle de l'équipe. Par conséquent, vous devriez également envisager de vous former pour votre équipe.
Par expérience, je peux vous dire qu'il peut être frustrant d'obtenir des estimations des membres de l'équipe qui la retarderont, de vous donner des estimations qu'ils font en deux minutes en fonction du nom de la tâche sans référence à une description d'exigence ou de fonctionnalité ou au code existant, ou qui insistent sur le fait que plusieurs des tâches que vous énumérez peuvent être effectuées en une fraction de journée, même si les projets antérieurs ont passé des semaines sur des questions similaires.
Il existe divers cours de formation et certifications de chef de projet, mais je surveillerais celui qui a été accrédité de manière indépendante. Il peut être utile de réfléchir avant de choisir de certifier avec des approches basées sur des méthodologies planifiées si vous prévoyez de travailler avec des équipes Agiles (ou l'inverse).
SLIM est une méthode inventée par Putnam après avoir travaillé chez GE et d'autres sociétés sur des projets DoD dans les années 1970. SLIM est influent, et son entreprise QSM propose une certification qui semble découler d'un outil qu'ils fabriquent. Selon que votre entreprise a adopté son outil, celui-ci peut n'avoir aucune valeur ou une valeur élevée.
Steve McConnell (auteur de Code Complete) a également écrit un livre sur l'estimation de logiciels, et sa société Construx enseigne deux classes de crédits PDU accréditées par le Project Management Institute. J'ai son livre, et si je voulais en apprendre davantage sur le sujet via une formation en classe, je choisirais probablement Construx. Ils font également de la formation Scrum et administrent diverses évaluations Scrum accréditées via Scrum.org.
Une autre source qui pourrait fournir une excellente formation académique sur l'estimation de projets logiciels, serait le groupe de Barry Boehm à l'USC , basé sur leurs travaux approfondis sur la modélisation des coûts constructifs COCOMO et COSYSMO qui a été utilisé à la NASA et d'autres grands entrepreneurs pour estimer de très grands projets. Je ne suis pas sûr de vraiment croire en COCOMO, mais j'aime le travail empirique qu'ils ont fait pour corréler les effets des facteurs d'échelle et des coûts sur la durée du calendrier.
J'ai également trouvé un chapitre d'un manuel publié par O'Reilly qui traite brièvement des principales méthodes d'estimation logicielle, notamment Watts Humphreys PROBE et le jeu de planification de Kent Beck. SONDE inclut une notion selon laquelle les ingénieurs suivent les mesures de leur propre productivité, puis les appliquent à leur partie affectée à de nouveaux projets. Planning Game est une collaboration très étroite entre les développeurs et les autres parties prenantes.
la source