Question:
Comment savoir si un développeur fait son travail trop lentement?
Andrew
2018-08-19 12:59:37 UTC
view on stackexchange narkive permalink

Mon entreprise est composée d'un développeur iOS, d'un ingénieur électricien, d'un testeur, de deux ingénieurs firmware, d'un développeur d'algorithmes et d'une personne backend. Comme vous pouvez le voir, c'est diversifié.

L'application iOS est incomplète et est loin d'être prête à être expédiée. Le micrologiciel a pris deux fois plus de temps que prévu pour être complet et est toujours plein de bogues. Comment le PDG (le décideur) est-il censé savoir si les ingénieurs font leur travail trop lentement, se relâchent ou si le travail est vraiment difficile? Doit-il simplement embaucher plus d'ingénieurs et les tester par fractionnement sur les mêmes missions? Devrions-nous embaucher quelqu'un d'encore PLUS senior pour mesurer les progrès? Existe-t-il un moyen plus efficace?

EDIT: Plus d'informations:

  • Le chef de projet est parti il ​​y a 18 mois car maternité et n'a pas été remplacé
  • Je suis l'un des micrologiciels
  • Le PDG n'a aucune expérience en développement logiciel
  • les délais ont été fixés par des cadres supérieurs il y a 12 mois, mais ils ont été largement dépassés.
qui a calculé les délais au début?
Et sur quoi?
En tant que moitié de l'équipe d'ingénierie du micrologiciel, vous devriez avoir une idée de la raison pour laquelle le micrologiciel est plein de bogues.Il pourrait être utile de savoir pourquoi.(Se pourrait-il que vous sachiez très bien que les progrès sont aussi rapides que prévu et que vous voulez trouver un moyen de le montrer au PDG?) Il serait utile de savoir comment les délais ont été fixés.Ont-ils été fixés par quelqu'un avec une formation technique?S'agit-il de "c'est le temps que le projet est susceptible de prendre" ou "c'est à ce moment-là que le plan d'affaires dit que nous publions"?Dans quelle mesure le projet était-il défini au moment de la fixation des délais?
Devrait-il simplement embaucher plus d'ingénieurs et les tester par division sur les mêmes missions?9 femmes enceintes ne font pas d'enfant en 1 mois
pourquoi existe-t-il un firmware à écrire pour une application iOS?
C'est difficile à dire sans une formation technique et une connaissance du système.Le firmware n'est probablement pas facile, et cela ne m'étonnerait pas qu'il ait glissé.Je considère le firmware autant un art qu'une compétence.Surtout si le glissement est dû à une carte personnalisée et à de nombreux prototypes enveloppés de fil au fur et à mesure que la conception a changé avec le temps.Quant à l'application iOS, cela dépend encore une fois du système et de la compétence du développeur.La première étape devrait probablement consister à embaucher un chef de projet qui connaît bien les technologies impliquées dans le système.
Sept réponses:
#1
+16
gnasher729
2018-08-19 15:00:55 UTC
view on stackexchange narkive permalink

Eh bien, c'est le problème du PDG. Si vous ne connaissez pas le développement logiciel / matériel, vous ne pouvez pas vraiment juger si un problème est facile ou difficile, si les développeurs sont lents ou rapides, et s'ils travaillent dur ou paresseux.

Le moyen de le découvrir est de leur parler et de voir où se trouvent les problèmes. Les choses les plus susceptibles de causer des problèmes (autres que les développeurs médiocres) sont un PDG qui ne sait pas ce qui est réalisable et un PDG qui change toujours d'avis et / ou n'écoute pas.

Une autre chose est que si vous avez un développeur, vous en avez besoin d'un bon. Un bon développeur et quatre moins bons peuvent fonctionner, car il y a toujours beaucoup de choses faciles à faire qui coûtent du temps. Si vous n'avez qu'un seul développeur, il doit être bon et résoudre tous les problèmes qui surviennent sans aide. Le fait est que les bons développeurs ne sont pas bon marché. Si vous ne payez pas beaucoup, je peux vous garantir que vos développeurs ne sont pas bons. (Payer beaucoup ne garantit rien non plus).

(J'ai vu une fois une publicité où ils avaient besoin d'un développeur capable de beaucoup de choses, et un prix qui ne correspondait pas. Je savais à cent pour cent que pour l'argent, ils ne trouveraient personne capable de faire le travail. J'ai répondu à l'annonce que je pouvais faire ce travail, pour 80% de plus que ce qu'ils avaient annoncé. Aucune réponse.)

PS. Le développeur du logiciel aura un peu du problème si le matériel n'est pas prêt.

PPS. Puisqu'aucun chef de projet n'a été mentionné, j'ai supposé que le PDG s'occupait de la gestion du projet. S'il n'y a pas de chef de projet, vous avez besoin soit de très bons employés qui peuvent gérer eux-mêmes le projet (ce qui va prendre du temps à leur travail de développement), soit vous devez embaucher un chef de projet. De préférence celui qui ne répète pas cette question dans douze mois.

Même un bon développeur aura besoin d'une caisse de résonance, de quelqu'un pour discuter des choses et peut-être même de discussions animées pour éviter les angles morts ou se retrouver coincé dans la mauvaise solution.Donc, je pense qu'avoir un seul développeur n'est jamais bon, même si c'est un bon développeur.
À la rigueur, on m'a dit qu'une découpe en carton du capitaine Kirk pouvait être utile pour expliquer les choses.Parfois, le simple fait de mettre quelque chose en mots peut conduire à sa solution.
#2
+11
Kilisi
2018-08-19 15:55:10 UTC
view on stackexchange narkive permalink

Comment savoir si un développeur fait son travail trop lentement?

Le PDG doit avoir des experts de confiance qui supervisent le travail et en sont responsables, par exemple. gestionnaires / superviseurs / chef de file, etc. qui savent par expérience comment cela aurait dû se passer.

Même les personnes expérimentées et compétentes peuvent travailler à des vitesses complètement différentes pour de nombreuses raisons.

En fin de compte, la vitesse dev fait le travail, plutôt que «à quelle vitesse l'entreprise a-t-elle besoin de faire cela avant que cela n'affecte trop les résultats». Et quelqu'un avec un plan réel et les connaissances nécessaires pour mener à bien un projet dans un délai précis.

Si le délai n'est pas réaliste, il se peut que personne ne puisse le respecter.Ce n'est pas parce que quelque chose serait bon pour l'entreprise que c'est possible.Heck, là où je travaille, ce serait bon pour l'entreprise si nous ne causions jamais de bugs.
@DavidThornley si la date limite est irréaliste cela signifie que personne n'a eu l'expérience ou le plan au départ.J'ai couvert cela dans ma réponse.
#3
+8
Yuropoor
2018-08-20 13:52:31 UTC
view on stackexchange narkive permalink

Le chef de projet est parti il ​​y a 18 mois parce que la maternité et n'a pas été remplacé Je fais partie des gens du firmware

Comme Joe Strazzere l'a souligné dans les commentaires, ceci peut vous donner une idée des raisons pour lesquelles votre projet n'est pas géré correctement et vos délais glissent. 18 mois de "gratuit pour tous, faites ce que vous voulez" vont faire cela à n'importe quel projet.

les délais ont été fixés par des cadres supérieurs il y a 12 mois, mais ils l'ont été largement dépassé.

Dans quelles circonstances ces délais ont-ils été fixés? Ont-ils dit "un gars de niveau intermédiaire devrait terminer cela dans X temps" ou "cela devrait prendre 12 mois, étant donné une équipe de X personnes travaillant selon la méthodologie Y, utilisant les outils Z ...". Vous constaterez peut-être que la direction (à l'exclusion des chefs de projet, enfin, les bons) ne prendra "que 12 mois" à partir de ces deux déclarations, puis vous vous demandez pourquoi le travail ne se fait pas aussi vite qu'il le devrait dans leur esprit.

Devrait-il simplement embaucher plus d'ingénieurs et les tester par fractionnement sur les mêmes missions?

Lancer plus de corps sur un problème ne fonctionne qu'à court terme, si le problème est simplement «trop de travail». S'il y a des obstacles qu'un ingénieur ordinaire ne pourra pas éliminer, comme le fait que vos sous-traitants glissent les livraisons, la mauvaise hiérarchisation des tâches, le plan de version modifié chaque jour par la direction, etc., vous rencontrerez simplement des barrages routiers à une vitesse accrue.

Devrions-nous embaucher quelqu'un d'encore PLUS senior pour mesurer les progrès?

Pourquoi gaspilleriez-vous des projets de gestion de talents méga-senior? C'est le travail du chef de projet.

Y a-t-il un moyen plus efficace?

Je ne sais pas combien de temps dure le congé de maternité dans votre pays (ici, c'est 18 mois) - le PM revient-il? Sinon, engagez un remplaçant. Notez que si c'est vraiment aussi mauvais que cela puisse paraître (18 mois sans supervision du PM sonne comme ça), vous n'aimerez peut-être pas ce que le PM a à vous dire.

Travaillez avec lui pour lancer votre produit par étapes (fonctionnalité de base, agréable à avoir, intégration stratégique du client, etc.) et pas en même temps.

Arrêtez d'avoir un facteur de bus sur 1 - à la fois pour votre PM et votre seul développeur mobile. Que feriez-vous si votre développeur iOS quittait aujourd'hui? Même si vous embauchez son remplaçant le lendemain (indice: vous ne le ferez pas), vous envisagez encore plus de retards pendant qu'il essaie de comprendre ce qu'il est censé faire.

Enfin:

Comment le PDG (le décideur) est-il censé savoir si les ingénieurs font leur travail trop lentement, se relâchent, ou si le travail est vraiment difficile?

Il est censé embaucher des personnes qui peuvent gérer ces choses pour lui et ne pas laisser les choses empirer pendant 18 mois.

#4
+4
Sascha
2018-08-19 21:28:59 UTC
view on stackexchange narkive permalink

Que diriez-vous d'engager un chef de projet - ce que vous avez décrit n'est pas un problème en soi, c'est seulement un problème s'il n'y a pas de gestion de projet. Un développement de firmware prenant deux fois plus de temps que «prévu» pour un nouveau produit n'est pas inconnu ou «non attendu» du point de vue de la gestion de projet.

Selon les spécificités, vous pouvez choisir des méthodes agiles ou non, Mais c'est une autre histoire. Dans tous les cas, les attentes, les risques et les mesures d'atténuation des parties prenantes doivent être gérés.

#5
+3
Cris
2018-08-19 19:11:17 UTC
view on stackexchange narkive permalink

Si vous doutez que vos développeurs prennent trop de temps, vous devriez embaucher un auditeur externe (un sous-traitant avec des réalisations éprouvées qui ne seront pas bon marché du tout, mais moins chères que de recruter un autre développeur). L'auditeur examinera les choses et préparera quelque chose comme un diagramme de Gantt pour votre projet. Il devra également avoir accès à toute votre documentation car bien sûr vos développeurs pourraient avoir rencontré des problèmes inattendus.

Permettez-moi d'être clair, vous ne pouvez pas savoir de manière fiable si vos ingénieurs se débrouillent bien si vous n'avez pas de connaissances techniques et d'expérience pratique. Si c'est mauvais, ils pourraient se foutre tu. Mais à mon avis, le meilleur moyen serait d'avoir un bon ingénieur senior en qui vous pouvez avoir confiance pour les gérer. Bien sûr, vous ne pouvez pas toujours savoir ce qu'ils font si vous n'avez pas d'experts seniors dans votre entreprise (ce qui semble être le cas étant donné que vous lui poseriez ces questions au lieu d'être ici).

#6
+2
Geo C.
2018-08-19 15:14:13 UTC
view on stackexchange narkive permalink

De mon expérience de travail pour moi-même, directement pour des clients et dans une entreprise, je me suis rendu compte que, même pour moi, il est difficile d'évaluer un calendrier pour certains projets / fonctionnalités. En général, vous devenez meilleur dans l'estimation des délais à mesure que vous devenez plus expérimenté dans ce domaine. Pour moi, le champ est une pile complète de développement Web. Je me suis rendu compte, avec le temps, que je devenais meilleur pour arriver à des échéances appropriées.

Pour moi, cela m'a beaucoup aidé lorsque les clients me confiaient des tâches précises, le modèle commercial était très clair. Ce que j'ai réalisé, c'est qu'avec les startups, où les choses sont très floues du point de vue du modèle commercial, il est très difficile d'évaluer les exigences, il est donc difficile d'établir un délai approprié.

Vous devez donc vous demander, les exigences sont-elles en place? Changent-ils beaucoup? Si tel est le cas, la chronologie d'un projet peut changer radicalement.

Je vois que le travail dans votre entreprise est assez bien séparé. S'ils sont des employés expérimentés (minimum 5 ans) dans leur domaine, qu'ils sont spécialisés dans un domaine, il ne devrait pas être difficile pour eux de donner des délais raisonnables et précis.

Vous devriez vous demander qui est le bloqueur? Êtes-vous le bloqueur, vous êtes l'expert du domaine. Leur donnez-vous des exigences / besoins explicites pour le produit? Vous vous occupez de leurs besoins (accès aux outils, informations)?
Les besoins évoluent-ils assez rapidement (comme dans un environnement de startup)?

Maintenant, pour évaluer si c'est leur faute, à mon avis, ce que vous pouvez faire est d'établir un moyen d'organiser le travail en cycles et d'essayer de garder les cycles courts. Des cycles courts conduiront à des volumes de travail plus précis. Finalement, vous saurez également plus combien de temps il faut pour que les choses soient faites et vous saurez qui de votre équipe se relâche.

N'importe qui (développeurs / gestionnaires) doit avoir une certaine expérience du temps nécessaire pour qu'une fonctionnalité / un produit soit finalisé. Du point de vue du gestionnaire, comme je l'ai dit, je pense que la précision vient aussi lorsque de petits cycles de travail sont planifiés. Pas besoin de faire venir plus de monde, gardez simplement vos cycles petits.

Maintenant, si les cycles sont petits et que les développeurs continuent de donner des délais erronés, cela signifie qu'ils ne sont pas très expérimentés ou qu'ils se relâchent.
En savoir plus sur développement agile / mêlée

#7
  0
DigitalBlade969
2018-08-21 06:38:22 UTC
view on stackexchange narkive permalink

Qu'est-ce que cette sorcellerie?!

Le projet a donc duré 18 mois sans que personne ne s'en approprie, laissant le PDG débordé sans aucune haute direction ou au moins un développeur senior.

Cela ressemble à une insolvabilité en attente de se produire à moins que l'entreprise ne reste à flot avec les revenus des projets précédents.

Comme cela a été dit, un audit externe serait une bonne chose.
Personnel de développement senior, le moins un chef de projet est nécessaire de toute urgence.
Si c'est financièrement impossible, peut-être que l'ancien chef de projet pourrait revenir dans le jeu.
18 mois de congé parental semblent excessifs.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...