Comment gérez-vous les API / technologies au-dessus de la tête


11

Je suppose que la plupart des gens ont été dans cette situation.

La planification initiale du projet commence. Les exigences sont décrites. Après une revue architecturale et un tri via les API / Frameworks, la technologie d'ajustement est choisie. Le développement commence.

Et puis ça commence. Dès que vous devez faire des choses supposées simples, le framework / API commence à se retourner, et au lieu de faire n'importe quel travail, vous finissez par vous battre contre la technologie. Le temps de recherche monte en flèche, les forums sont silencieux, rien ne semble être fait, et même lorsque vous faites fonctionner quelque chose, vous n'êtes pas vraiment sûr que ce soit bien fait.

Comment gérez-vous dans ces situations? Allez-vous faire des hacks, recherchez-vous plus loin, que dites-vous à la direction?


+1: Quelle bonne question. Digne d'un +10. J'ai eu la même expérience.
Jim

C'est une grande question. Tellement de fois j'ai vu où des mots comme "effet de levier" et "synergie" ont été utilisés pour vendre des trucs tiers. Alors vous vous y enfermez, et ils vont le retirer de dessous vous. (MS aime faire ça.) Pendant ce temps, les évangélistes originaux sont partis depuis longtemps.
Mike Dunlavey

Réponses:


9

Prototype, Prototype, Prototype !!

Si votre équipe n'est pas familière avec un cadre particulier, créez un prototype pour évaluer où se trouvent les points douloureux.

Matt Raible (type de comparateur de framework Web Java) suggère de travailler avec un framework pendant une semaine si possible.

Le prototypage comprend l'étude du soutien de la communauté derrière un cadre et d'autres facteurs


+1 pour le prototype. Avoir quelque chose qui fonctionne réellement, même s'il est assemblé avec du ruban adhésif et soutenu avec des bâtons, et plantera si vous le laissez seul pendant cinq minutes, est une étape inestimable à atteindre.

si la planification initiale du projet commence, comme indiqué dans la question, cela signifie que le feu vert pour le projet a déjà été donné et qu'il a DÉJÀ été vendu au client. Donc ... s'il n'y a pas de "prototypage" et que les coûts en heures sont pris en compte dans ce WBS alors il n'y a pas de prototyper en place. Idéalement, vous voudriez que cela se produise avant même de vendre la solution. Donc, avant qu'un ou plusieurs projets en sortent. Donc, bien avant ce projet, vous voulez mettre le "prototypage" dans le cadre des heures nécessaires et de l'évaluation. C'est difficile avec la plupart des clients car ils veulent une solution.
edelwater

en dan willen ze ook nog de exacte server specs van te voren ....
edelwater

6

La gestion des dépendances externes est le fléau de nombreux projets informatiques. Il y a de nombreuses années, les programmeurs expérimentés avec qui j'ai travaillé se sont toujours assurés qu'ils contrôlaient leurs dépendances - généralement en insistant pour que des licences de code source soient achetées.

Personnellement, cela n'a pas été mon approche. J'ai tendance à être sous-promis, à livrer une école de pensée. Il y a des moments où j'ai dû me tendre le cou, mais je fais des recherches privées à l'avance pour être sûr à 99% - généralement en faisant un projet privé souvent à mon propre rythme pour m'assurer que la technologie peut fonctionner. En effet prototype, testez, validez puis promettez.

Il y a des situations où je me fais prendre - et je dois faire marche arrière ou être inventif. Avoir un esprit créatif avec une vaste expérience aide ici, mais il en va de même pour parler à d'autres personnes. - et pas toujours des programmeurs. Parfois, les solutions viennent de lieux vraiment étranges.

Quant à la gestion, la clé est l'honnêteté. Parlez tôt et souvent. Ne laissez pas cela à la dernière minute car laisser tomber les gestionnaires / clients la veille d'une grosse livraison vous fait ressembler à des amateurs. Pouvoir dire 2 mois avant la date limite que les gestionnaires doivent choisir entre abandonner quelques fonctionnalités et / ou retarder la livraison peut ne pas être populaire à l'époque, mais cela permet au reste de l'organisation de faire son travail et de planifier . La clé pour y parvenir est d'avoir un bon système de gestion des tâches qui suit les temps et les estimations des tâches. Le fait d'avoir des preuves solides pour étayer votre point de vue rend beaucoup plus probable votre écoute.


J'ai fait beaucoup des choses que vous avez mentionnées ici et cela a très bien fonctionné pour moi. À ma connaissance, les clients avec lesquels j'ai travaillé ont été très satisfaits de ce que j'ai livré car j'ai généralement dépassé les attentes qu'ils avaient. Ils ont également beaucoup apprécié la communication sur la façon dont les choses progressaient et quand il y avait des problèmes, ce qu'elles étaient et l'impact.
Ken Henderson

2

"Comment gérez-vous dans ces situations?". Ce que j'ai vu / vécu:

le point numéro 1 je suis d'accord avec Ptolémée: soyez honnête:

Si c'est vraiment un problème: allez dans cette pièce, dites le problème, asseyez-vous pour attendre la réponse de la colère et ensuite ... travaillez vers un nouveau plan / solution. (le gars n'est pas en colère contre toi personnellement).

Il existe des cours d'informatique qui ne traitent que de cette situation. Vous êtes placé avec des acteurs et ils placent le client en colère qui entend cette nouvelle. Vous obtenez beaucoup de conseils à ce sujet. Cela semble stupide, mais probablement seulement après l'avoir fait, vous en remarquez la valeur. Je suis parti avec une feuille avec 80 points à retenir dans ces situations ... (et pratique).

Cette situation est sans doute encore plus typique aujourd'hui où les budgets sont serrés, les ventes se font sur "l'offre la plus basse", le planning que vous avez donné est découpé 5 fois avant d'être accepté par le client ... (y compris ce prototype car "il embauche" vous parce que vous êtes l'expert et sinon c'est 10 autres qui attendent ") etc ...

- Une autre chose pourrait être la réflexion latérale: si cela ne peut pas être fait de cette manière, essayez de proposer quelque chose de complètement différent qui offre la même valeur pour le client. Si la technologie ne fonctionne pas du tout / est cassée / saute de l'accord / etc ... Si le client achète, il peut livrer la même valeur à la fin. Mais l'apporter est également assez difficile. (pour certains et totalement pas pour d'autres). Vous avez besoin de gars vraiment expérimentés pour cela. Une situation similaire est que la technologie n'est PAS ENCORE à la hauteur ... cela prend quelques mois ... Vous devez donc convaincre le client de replanifier et d'accepter la replanification et l'impact sur son organisation ...

- Une autre «leçon apprise» consiste à invoquer les seniors seniors dès que vous remarquez que cela va dans ce sens. Ils ont souvent traité des projets en difficulté et sont vraiment utiles dans ces situations. Souvent, ils ne voyagent que d'un projet en difficulté à un projet en difficulté.

- Une autre leçon apprise est de laisser vos trucs architecturaux passer par les canaux de vérification, en particulier sur les grands projets. Une signature peut couvrir ton cul. (enregistrez tous vos e-mails LOL)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.