Intéressant, le sondage de Developpez.com n'obtient pas du tout les mêmes résultats que celui de Quora. Je me demande pourquoi?
Rédiger un cahier de charges
Recenser et documenter les fonctionnalités
Concevoir une solution
Ecrire les tests
Rédiger la documentation
Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord
Travailler avec le code de quelqu'un d'autre
Traiter avec d’autres personnes
Estimer le temps nécessaire pour effectuer des tâches
Expliquer ce qu'on fait (ou ne fait pas)
Nommer correctement les choses
Intéressant, le sondage de Developpez.com n'obtient pas du tout les mêmes résultats que celui de Quora. Je me demande pourquoi?
Estimer le temps nécessaire :
Je commence par faire l’estimation honnête de mon travail. Ensuite j’applique une surcote de 30% (coefficient de sécurité)
Développeur Java
Site Web
Toutes les decisions de groupe.
Déterminer le resto où aller à midi
Déterminer la dose de café a mettre dans le filtre de la cafetière
Retrouver la tablette de test
Nettoyer les tables après le lunch
Vider le lave vaisselle
Les choses les plus difficiles pour moi en tant que programmeur pour moi c'est travailler sur un projet déjà fait et surtout vérifier les bugs du projet déjà entamé. Mais c'est vrai que respecté les délais c'est la chose le plus délicate.
La tache la plus compliquée pour un développeur en France c'est de se faire payer correctement pour son travail.
Nullius in verba
Pour moi, c'est l'estimation du temps nécessaire pour effectuer les tâches, c'est pour cette raison il faut penser toujours à faire des macro-chiffrages des tâches avant de communiquer officiellement l'estimation finale au client.
Cordialement,
Je suis content qu'il y ait l'option "Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord" parce que je trouve ça vraiment frustrant. Quand ça touche vraiment à la technique ça ne me dérange pas, parfois je ne suis pas forcément d'accord avec la solution de l'architecte ou de mes collègues devs, et à ce moment là on discute, et même si ma solution n'est pas retenue et bien ce n'est pas dramatique : au moins on en a parlé. Par contre, quand vient "d'en haut" une demande clairement contre-productive, stupide, ou myope, et que toute discussion sur le sujet est impossible, bref quand on m'impose de faire ce qui serait considéré par n'importe quel professionnel comme du mauvais travail, j'ai un peu de mal.
Je pense qu'il manque un choix:
* Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.
De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.
Pour ma part:
- Estimer le temps nécessaire pour effectuer des tâches
- Expliquer ce qu'on fait (ou ne fait pas)
L'estimation du temps nécessaire est un classique contre lequel on se heurte beaucoup, surtout en début de carrière où l'on est souvent plein de bonne volonté, on veut absolument bien faire et dans un temps donné court, et un peu trop naïf car on ne voit souvent qu'une partie de l'iceberg quand on s'interroge sur la charge de travail.
Je suis assez content de voir que l'option "Expliquer ce qu'on fait". C'est bien plus complexe pour moi d'expliquer par des mots ce que je fais de manière naturelle en codant. Surtout quand on est pris à froid et qu'on ajuster son discours à quelqu'un d'externe au projet. A mes yeux, c'est bien plus difficile à faire que de la documentation par exemple.
Pensez à mettre votre sujet et un petit au passage pour ceux qui vous ont aidé.
Passionné d'Automobile - http://www.encyclauto.com
Personnellement je pense que bosser sur le code de quelqu'un d'autre et définir un délai de livraison précis et chose ardue, durant le développement tout peut se passer à merveille et le temps estimé peut se raccourcir mais si les choses se compliquent, on perd du temps pour rien et les soucis relatif au fait de bosser sur le code de quelqu'un d'autre arrivent durant cette phase.
Rédiger une documentation ? Oui aussi, cela prend du temps pour pas grand chose parfois mais il faut y passer.
Je pense aussi au fait de versionner son code, tout le monde n'y pense pas forcément mais cela prend du temps en fin de compte si on compte les heures passés à coder suivi des heures passées à signaler ce que l'on a fait, les changements de branches, les ajouts, les suppressions, c'est peu pratique au final si on y pense et cela prend du temps qui pourrait être utilisé de façon plus utile.
La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant
Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2% Il n'y que des archi qui ont répondu au questionnaire ou quoi ?
Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme
Développeur Java
Site Web
Je vais faire froncer les sourcils, mais pour ma part, aucune difficulté à évaluer le temps nécessaire ! {^_^}
Comment voulez-vous trouver difficile une tâche qu'on ne fait pas ?
Ça fait longtemps que je ne fais plus d'évaluations de ce genre (et quand on me demande combien de temps il me faut, je propose une date pour voir où ça en est). Quand la tâche est simple, pas besoin d'évaluer sa durée, ça se fera entre deux tâches pour se changer les idées, sinon on se met d'accord sur une date de contrôle pour évaluer l'avancée des travaux (c'est pourquoi je préfère parler de milestone plutôt que de deadline), et on se dit si oui ou non ça a l'air de valoir le coup de continuer, de reporter ou d'oublier tout simplement.
Mais je l'avoue, je triche : je fais de la recherche. {^_^}v
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
Sortant d'une expérience en SSII assez douloureuse, je ne me sens pas assez objectif pour participer à ce débat
Juste que les réponses proposées sont très très limitées, on pourrait rajouter par exemple :
- "Assumer les manques de responsabilités de la hiérarchie"
- "Assumer de coûter un peu plus de 3 pesos"
- "Assumer de jouer avec la merde que le commercial a vendu"
- "Assumer le fait de ne rien pouvoir dire car le client est roi, le commercial rapporte, toi tu coûtes et trop cher pour juste faire joujou avec des ordinateurs"
- Et bien d'autres avant de parler de notre métier de développeur / d'ingénieur qui n'a strictement plus rien à voir dans ce contexte là.
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de
comprendre précisément le métier du client dans le service informatique
si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.
pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...
de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.
reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.
ce qui quelque part rejoint les avis précédents.
Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique
des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI
Pour ma part, c'est surtout travailler avec le code d'autres développeurs, surtout dans mon cas, celui de mes prédécesseurs qui ont codé un peu comme des cochons
- Code pas clair et peu mis en forme
- Aucune documentation sur le code et les schémas de données
Il n'y a pas pire pour perdre un temps énorme pour faire des choses simples.
Mon Site
Ma bibliothèque de gestion des chaînes de caractères en C
L'imagination est plus importante que le savoir. A. Einstein
Je ne répond à aucune question technique par MP, merci d'avance !
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