Les délais manqués sont-ils courants dans les emplois de programmation? [fermé]

18

C'était mon travail d'indépendant chez oDesk. J'ai fait plusieurs travaux plus tôt dans le temps imparti, mais c'était la première fois que je manquais la date limite. C'était un travail très long et j'ai fait de mon mieux, mais j'ai quand même manqué la date limite. Maintenant, j'ai très peur. Parce que c'est ma faute si j'ai manqué le délai.

Ma question est la suivante: est-ce une grande préoccupation ou les délais manqués sont-ils courants dans les emplois de programmation, donc je ne devrais pas trop m'inquiéter à ce sujet?


la source
1
Dépend complètement de l'environnement. Par exemple, mon dernier emploi était dans une agence numérique qui facturait les clients en fonction des estimations. Si vous avez manqué le délai, l'entreprise a perdu de l'argent. Mon travail actuel est tellement dynamique qu'il n'y a pas de délais réels du tout .. si mon attention est requise ailleurs, on me donne le temps de m'y consacrer. Peut-être que l'inclusion de cela dans votre question vous aidera avec les réponses.
Simon Whitehead
3
les échéances manquées sont courantes dans tous les emplois
Steven A. Lowe
2
J'espère vraiment que vous communiquiez avec le client au sujet du délai non respecté. Des échéances manquantes se produisent, mais cela ne devrait pas être inattendu quand il le fait - vous devriez pouvoir le voir venir et communiquer à ce sujet. Il est généralement plus facile que de simplement dire "Non, pas encore prêt".
Bobson
6
Faites-le rapidement, faites-le bon marché, faites-le bien: choisissez-en deux.
Reactgular

Réponses:

45

Oui. Les délais manqués sont courants dans le développement de logiciels.

De nombreux pigistes respectent les délais en contractant des dettes techniques ou en cachant la saleté sous le tapis.

Paraphrasant le Mois de l'homme mythique de Frederick Brooks :

Frederick Brooks, auteur du Mois de l'homme mythique

  • Les délais sont souvent manqués car les chefs de projet continuent d'estimer les tâches logicielles de la même manière que les tâches de génie civil, ce qui est une approche erronée car le logiciel est une nouvelle industrie artisanale sans corps clair de normes. Cela est si vrai que vous ne pouvez pas révoquer le «permis» d' un programmeur pour coder pour faute professionnelle, ni poursuivre quelqu'un pour avoir programmé sans titre.

  • Le développement de logiciels présente une complexité inhérente qui fait défaut à d'autres disciplines. Un grand programme peut avoir plus de composants qu'une voiture, et ces composants peuvent interagir de différentes manières.

  • Le logiciel est difficile à visualiser, donc différents types de diagrammes sont utilisés pour voir différents aspects d'un projet, et ces aspects peuvent ne pas être orthogonaux. Le génie civil, d'autre part, a des plans vous permettant de voir la plomberie, le câblage, etc. dans le même graphique (ou couches) de manière orthogonale.

  • Il n'est pas courant, après la construction d'un pont ou d'un bâtiment, que le client change complètement la portée du projet. C'est souvent le cas dans les projets logiciels.

  • L'état de l'art dans le développement de logiciels n'a pas atteint le point où les projets logiciels sont reproductibles et presque sans risque. Même les plus grandes sociétés de logiciels comme Microsoft peuvent manquer des délais de plusieurs mois ou années.

  • La plupart des vaporwares ne sont que des projets logiciels qui ont été supprimés à cause de ce genre de problèmes.

En conclusion:

Les mauvaises estimations et la sous-estimation de la complexité, en raison de la nature artisanale du processus de développement logiciel, signifient qu'il reste une discipline immature.

Tulains Córdova
la source
11
+ Bonne réponse, mais ayant eu une certaine exposition au génie mécanique et civil, il est amusant de voir comment les programmeurs font des comparaisons faciles avec la construction de ponts et d'autres choses, quand ils n'ont pas la moindre idée de la façon dont ceux-ci sont construits.
Mike Dunlavey
3
Je souscrirais à l'idée que le logiciel est plan (en termes de plan en ingénierie - décrivant chaque détail du projet). En cas d'ingénierie, le temps de la construction physique domine, de sorte qu'une grande variance dans la planification ne joue aucun rôle. Cependant, comme le logiciel ne consiste qu'en un plan ... "L'état de l'art dans le développement de logiciels n'a pas atteint le point où les projets logiciels sont reproductibles et presque sans risque" - dans ces cas, pourquoi le projet le fait-il? Si quelque chose est répétitif et peut être automatisé, il n'est pas nécessaire de le faire à plusieurs reprises, mais il peut être effectué une fois et copié.
Maciej Piechotka
2
@ user61852: Vous m'avez mal compris. Le «plan» de l'ingénierie est comme «source» pour l'informatique - c'est-à-dire une description détaillée de chaque composant - mais une fois que nous l'avons, nous pouvons le construire (entrer makeou autre). Qu'est-ce qu'un «plan» en informatique serait un «plan» de plan »en ingénierie. La différence est qu'en makeinformatique, cela prend au maximum quelques heures tandis que l'écriture du code source (y compris les tests et l'intégration) prend des mois tandis qu'en ingénierie, la planification peut prendre des mois (y compris le calcul structurel) tandis que la construction prend des années. sur ce dernier.
Maciej Piechotka
1
@ user61852: Concernant la répétitivité - une chose dans laquelle les ordinateurs sont excellents est l'automatisation. Supposons que vous ayez besoin de créer un blog simple - au moment où vous auriez des `` estimations '' précises, vous obtiendrez un wordpress (ou tout autre système de blog) en place afin que vous n'ayez pas besoin de le faire (en cas de pont vous avez toujours un environnement différent, vous devez donc vous adapter plus soigneusement car la roche peut être différente ou il peut y avoir un habitat d'oiseau ou cela peut détruire la vue) - les programmeurs peuvent être plus responsables de la création des outils (le modèle de pont standard).
Maciej Piechotka
2
Bonus pour avoir cité le mois de l'homme mythique; Frederick Brooks résiste après toutes ces années parce qu'il se concentre sur les gens et non sur la technologie.
Michael Shopsin
3

Les délais non respectés ne devraient pas devenir une pratique courante si vous souhaitez continuer à trouver un emploi.

Cela dit, vous voulez généralement vous laisser une marge de manœuvre supplémentaire dans vos estimations au cas où des choses se produiraient (et c'est toujours le cas). Vous n'avez pas besoin de révéler que vous avez ajouté du temps supplémentaire, mais ne le rendez pas déraisonnable. Peut-être entre 5 et 10% du temps total? La seule façon de le savoir est de le faire plusieurs fois.

Pour être vraiment bon dans les estimations, vous devez savoir combien de temps il faut pour coder un certain type de widget ... par exemple, disons que vous devez créer un widget de défilement infini pour le client X. Si cela vous prend une semaine pour le déployer en production sans bogues, vous pouvez l'utiliser comme référence pour vos estimations de défilement infini.

TJ Trapp
la source
2
Je donne toujours 20% de place lors de l'estimation. 5-10%, c'est trop peu. Je suppose que cela dépend à quel point vous êtes distrait. Le développeur solo ne doit pas du tout être distrait
BЈовић
Je suis développeur solo et je prends habituellement 10% de marge pour mes projets.
Konsole
Hmmm ... voir Hofstadter's_law
Philip
1
Par rapport à 5-20%, je pense qu'une marge de 100% est meilleure. Sérieusement. Il vous permet d'explorer vos options beaucoup mieux. Et répondez à plus de questions sur Stack Exchange.
Acumenus
Oh ouais, c'est la faute du développeur quand un chef de projet vétéran de 15 ans fait pression sur un ingénieur logiciel recrue depuis 1,5 an pour lui donner une estimation puis ajuste qu'il soit encore plus agressif et agit comme si le développeur se relâche lorsque le projet est désossé . Je n'ai jamais travaillé pour un gestionnaire ou un PM qui pourrait écrire du logiciel, et vous me dites que les délais manqués ne devraient pas devenir une pratique courante si vous voulez continuer à trouver un emploi? Les délais manqués sont endémiques car la plupart des PM sont littéralement incompétents dans leur travail. Mon meilleur manager n'était toujours pas ingénieur logiciel, connaissait juste ses limites.
Downbeat
3

Les délais manquants ne sont pas rares dans le développement de logiciels. Il est presque impossible d'estimer avec précision la durée d'un projet logiciel.

Le professionnalisme se manifeste dans la façon dont vous y faites face. Lorsque vous savez que vous manquerez un délai, informez-en votre client le plus tôt possible afin qu'il puisse planifier en conséquence.

Philipp
la source
2

C'est assez courant, mais vous pouvez vous améliorer. Vous voudrez peut-être étudier l'estimation en utilisant quelque chose d'abstrait comme des points d'histoire , et garder une trace de votre vitesse pour calculer vos estimations réelles. Ces concepts sont le plus souvent associés à la mêlée, mais peuvent être utilisés même si vous ne faites pas de mêlée.

La chose étonnante à propos de la vitesse est qu'elle englobe toutes les choses intangibles comme les interruptions et la complexité inattendue que les développeurs ont du mal à prendre en compte dans leurs estimations. Toutes les probabilités s'étalent dans le temps. En moyenne sur 10 semaines, nos estimations de vitesse ont été précises à environ 5%. Pourtant, lorsque nous estimons les mêmes tâches en heures, la même équipe exacte sous-estime constamment de 30 à 50%.

Karl Bielefeldt
la source
1

Ma théorie (non prouvée) est que les humains ont évolué pour sous-estimer les emplois compliqués par deux ou trois pour un. Chaque fois que le Congrès demande à la NASA quelque chose comme: combien cela coûtera-t-il pour construire une navette ou se rendre sur la lune, ils reviennent dans la semaine avec un numéro. Après avoir épuisé tous les coûts attendus, ils découvrent que cela coûtera trois fois plus.

Nous avons eu une blague dans les années 1970: prenez n'importe quelle estimation de programmeur, doublez le nombre, puis déplacez-la vers l'unité de temps suivante. Par conséquent, si un programmeur dit que cela peut être fait en deux semaines, il le terminera en quatre mois.

Si quelqu'un a remodelé une cuisine, il pense généralement: «Eh bien, je le ferai dans deux semaines». Ils le terminent environ six semaines plus tard.

Meredith Poor
la source
1
Qu'est-ce que la NASA a à voir avec ma question?
1
Plus précisément, qu'est-ce que l'évolution humaine a à voir avec votre question? La NASA est un exemple clairement documenté dans le dossier public de personnes formées et expérimentées sous-estimant les grands projets. Bref, votre expérience est «naturelle».
Meredith Poor
Bien que je convienne que les estimations de la plupart des gens sont au moins doublées, mais la prochaine unité de temps ... hmmmm. Quoi qu'il en soit, la NASA est très bonne pour estimer les tâches qu'elle sait déjà faire. Le problème est que les gens ne sont pas très bons pour estimer les tâches lorsqu'ils ne savent pas ce qu'ils ne savent pas. Étant donné que la NASA fait beaucoup de travaux vraiment pionniers, il n'est pas étonnant que les gens ne sachent pas grand-chose de ce qu'ils font jusqu'à ce qu'ils commencent à le faire. Ainsi, la raison de la sous-estimation initiale. De plus, certaines personnes sont prédisposées à être optimistes et d'autres pessimistes. Pas sûr que l'évolution soit impliquée.
Dunk