tous cela vaudrait bien un petit sondage du genre : Comment vivez vous votre métier "d'ingénieur informaticien" ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
tous cela vaudrait bien un petit sondage du genre : Comment vivez vous votre métier "d'ingénieur informaticien" ?
Autre petite histoire (trop souvent vécue)
la partie commerciale décide que le marché veux que le produit "A" soit disponible a tel date (noel par exemple).
les équipes d'engeering calcule le planning par retropédalage et se rendent compte que cela ne rentre pas dans les clous, mais la date fixée par le marketing ne décale pas....
je vous laisse choisir les suites possible
- la date et tenue suite a une mise direct en prod sans phase de qualification...
- la date n'est pas tenue, les techos se font traiter de tous les noms....
- la date est tenue et tout marche nickel.... (on ne sais jamais, chez les bisounours peu etre)
je le trouve de plus en plus rigolloEnvoyé par william44290
tous cela vaudrait bien un petit sondage du genre : Comment vivez vous votre métier "d'ingénieur informaticien" ?, avec l'experience on apprend a prendre du recul....
Dans le même registre : c'est dans les périodes de famine qu'on voit qui est apte à survivre. C'est le genre de connaissance dont je me passe aisément, personnellement. Parce que finalement, faire réussir un projet de ce genre, ça revient toujours à faire le boulot de quelqu'un d'autre à sa place, en plus du mien, sans toucher un sous de plus. Non merci ! Le week-end, j'ai autre chose à faire que des réunions et des heures de debug (oui, c'est du vécu) !Qui a dit que l'évolution dans l'entreprise est longue?
Perso je pense que c'est dans les Projet cauchemar qu'on voit qui a les reins solide pour mener a bien a projet. (d'ailleurs c'est valable dans tous les domaines pas seulement l'informatique)
j'ai aussi connu et effectivement c'est quand un projet va mal qu'on vois ce qui peuvent redresser la barre.... malheureusement on finis souvent par les prendre pour des .....
Je suis très d'accord, c'est une espéce de masochisme aujourd'hui, il faut se tirer la bourre dans l'échec plutôt que de bosser normalement et réguliérement. Mais principalement si je regarde autour de moi, ceux qui ont une vie de famille et une vie "affective" stable bosse correctement avec des horaires normaux et n'ont pas de problèmes de coup de bourre, le job est fait proprement, les autres passent des heures au bureau à envoyer des mails, boire des cafés, refaire la boite, ne travaille pas vraiment, font dans le copinages, oublient de travailler.
Globalement, tous les problèmes dont nous parlons ne sont que l'agrégats de comportements sociaux déviants qui font qu'aujourd'hui, une majorité de gens confondent travail et lieu de vies principal.
La façon de travailler et de concevoir le travail est aussi la résultante d'une maturité.
D'un point de vue pshysiologique, c'est impossible d'être concentré pendant 8 H sur une tâche. Alors 12....
Tout à fait d'accord avec toi, mais le problème actuel est que beaucoup de boites essaient de faire faire le boulot de 2 personnes à une seule, donc forcément...
Par exemple, dans ma boite actuelle, ils tentent le coup à chaque départ, ils ne remplacent pas dans un premier temps pour voir, si ça passe c'est tout bénéf, sinon si ça gueule, finalement ils remplacent... affligeant !
Et le pire, c'est qu'après ils osent râler parce que le boulot a du retard !
Et oui, si tu as fait un petit bug, honte à toi mais quand tu remet à flot tout un navire en train de sombrer, c'est normal c'est ton job.
Sinon pour l'avoir vécu, un projet part en sucette quand on commence à te dire qu'il faut faire de la doc pour gagner du temps (sur un projet qui a déjà une dizaine d'année) mais qu'on a pas le temps de la faire.
En ce qui concerne, les horaires, à vrai dire je suis pas non plus un fana des 12h par jour, alors à présent je m'en fous desfois je fais 8h desfois j'en fait 9 ou 10 quand le projet en a besoin, desfois j'en fais même 7 si j'ai fait des grosses journées avant.
Et si la moindre personne a quelque chose à dire, j'ai toute la maturité nécessaire pour le remettre à sa place.
Le mieux que j'ai trouvé jusqu'alors et qui est de plus très apprécié de ces costards-cravate de la hiérarchie, c'est de faire les grosses journées au début, et le reste du temps quand tu a bien pris de l'avance, tu peux avancer cool cool. Ainsi tu fais jamais des trop grosse journées
oui c'est sur mais on est tous confronté un jour ou l'autre a un projet qui va nous forcé a faire ses 12h.Je suis très d'accord, c'est une espéce de masochisme aujourd'hui, il faut se tirer la bourre dans l'échec plutôt que de bosser normalement et réguliérement. Mais principalement si je regarde autour de moi, ceux qui ont une vie de famille et une vie "affective" stable bosse correctement avec des horaires normaux et n'ont pas de problèmes de coup de bourre, le job est fait proprement, les autres passent des heures au bureau à envoyer des mails, boire des cafés, refaire la boite, ne travaille pas vraiment, font dans le copinages, oublient de travailler.
Globalement, tous les problèmes dont nous parlons ne sont que l'agrégats de comportements sociaux déviants qui font qu'aujourd'hui, une majorité de gens confondent travail et lieu de vies principal.
La façon de travailler et de concevoir le travail est aussi la résultante d'une maturité.
D'un point de vue pshysiologique, c'est impossible d'être concentré pendant 8 H sur une tâche. Alors 12....
On peut avoir la meilleurs équipe du monde et/ou travailler dans une boite ou tout et bien définit et ou tout les projets se passe bien.
Cependant y'arrive toujours un jour ou on est sous pressions pour X raisons (délais trop court, budget serré ext...)
si on est habituer à travail dans un environnement cleans sa peut vite virée au projet cauchemar.
perso je pense (et c'est valable dans tout le travail) que c'est dans les projet merdique qu'on apprend a bossé. je dit pas que c'est motivant de bossé 12h par jour, mais juste que le meilleurs moyen de se sortir ou évité un projet cauchemar c'est d'en avoir déjà vécu et d'avoir de l'expérience.
quand tu est habituer a avoir un cahier des charges ultra détaillé (sa existe au moins?
bien sur sur j'exagère le truc (quoi que) mais un manager qui a déjà vécu se genre de situation aurra assez de cran pour dire :
(du moins si c'est un bon manager qui a pas peur de prendre des risque)"votre cahier des charges et inutilisable, veuillez s'il vous plait nous fournir une basse plus solide. En effet nous serons dans l'impossibilité de répondre a votre attendre dans la mesures ou nous ne pouvons les cernés avec le peu d'information que vous nous avez fournie
je me rappelle plus les mot exacte mais c'est un peu prêt les terme qu'avais formuler mon chef d'équipe lors de notre dernière projet. (forcement sa a fait grincer des dents mais c'est telement bon)
Mouais enfin bon quand t'arrives à ce point c'est que le chef de projet à merdé...quand tu est habituer a avoir un cahier des charges ultra détaillé (sa existe au moins?
Je vois pas pourquoi en tant que développeur on devrait assumer l'incompétence de certains.
Une fois de temps en temps ça peut arriver sinon faut bien que quelqu'un se rende compte d'ou vient le pb...
Il me semble que sans norme il est impossible d'évaluer une situation. Aussi la notion d'échec reste parfaitement subjective.
euh y'a plein de façon de voir l'echecIl me semble que sans norme il est impossible d'évaluer une situation. Aussi la notion d'échec reste parfaitement subjective.
le soft développé ne répond pas au cahier des charge ou au besoin des utilisateurs et n'est pas accepté/utilisé par ces derniers.
le projet dérive sur le budget ou les délais voir les deux, et pour jouer le financier bête et méchant coute plus cher que ce qu'il rapporte.
le soft ne fonctionne pas tout simplement, (plantage a chaque utilisation)....
Même si ce n'est pas décrit dans une norme iso ou autre y'a beaucoup de chose qui permettent de voir qu'un projet est à la dérive ou va dans le mur.
Ah bon ?
Par exemple cas vécu : une application développée par une équipe de 10 personnes pendant un an n'a au final jamais utilisée, car trop "rigide" et répondant pas suffisamment bien au problème à résoudre. Dans le même temps les utilisateurs ont résolu le probleme avec une feuille de calcul, ils ont décidés d'utiliser leur feuille dans le service concerné, et ils ont envoyés se faire voir le service informatique, ça te va comme notion d'échec ?
Disons que l'échec, contrairement au succès est hautement polymorphe.
Le mieux étant l'acharnement politique à transformer dans la forme des échecs monumentaux par des succès stratégiques.
J'ai connu un DSI qui avait organisé le ré-aménagement des bureaux pour masquer la flagrante inefficience des projets gérés par ses équipes. Ca a épaté pas mal de monde.
Une de mes connaissance travaille pour CAP depuis une dizaine d'années à l'entendre tous ces projets sont des échecs et pourtant cette entreprise ne fait toujours pas faillite.
Tous ces échecs ne finissent pas au tribunal. En général les compromis commerciaux sont trouvés avant. De fait les échecs réels me semble peux nombreux.
La réalisation d'un projet est pour moi un tout. Les facteurs techniques, humains et financiers sont à intégrer au même titre que l'analyse, la conception ou le codage.
Avec les années et un peu d'expérience, je me méfie des réactions égocentrique de tel ou tel intervenant. C'est un métier difficile qui peux tourner au cauchemard pour certain mais ce n'est pas une fatalité.
Pour finir je pense que 100% des projets vont foirer. Mon boulot c'est que cela foire le moins possible. Tant que je perçois mes émoluments c'est que j'ai réussi ma mission.
cela se discute : l'échec est pour qui ? le client ? s'il pouvait régler son problème avec une feuille excel pourquoi faire bosser 10 personnes ?Ah bon ?
Par exemple cas vécu : une application développée par une équipe de 10 personnes pendant un an n'a au final jamais utilisée, car trop "rigide" et répondant pas suffisamment bien au problème à résoudre. Dans le même temps les utilisateurs ont résolu le probleme avec une feuille de calcul, ils ont décidés d'utiliser leur feuille dans le service concerné, et ils ont envoyés se faire voir le service informatique, ça te va comme notion d'échec ?
sinon je vois pas. je dirais simplement que c'est du gaspillage.
Mais ça ils ne le savaient pas au départ, le projet ayant mis du temps à se faire, pendant ce temps un des membre du service à décidé de faire une feuille de calcul pour essayer d'informatiser le probleme avec une solution temporaire, qui est devenue à l'usage permanente...
Dans le cas présent il s'agit d'une équipe de développement en interne, pas d'une SSII.
Oui c'est un échec parce que 10 personnes ont été engagées sur un projet pour rien, après d'où viens l'échec c'est un autre problème : projet mal défini, mal réalisé, projet qui n'aurait jamais du être lancé... Ce qui est incontestable c'est que c'est un échec puisque l'appli n'est pas utilisée.
bon d'accord c'est un échec selon toi.
une dernière provocation avant de dormir. Si la direction n'a viré personne c'est qu'elle est incompétente : elle a donc ce quelle mérite.
Si la DSI à accepté un tel projet c'est qu'elle est incompétente.
Si le client interne accepte cette situation c'est que leurs demandes sont infondées.
Bref cette équipe de bras cassés est incapable de réussir quoi ce soit. il y a eu et il y aura encore beaucoup de gaspillage.
Amicalement bonne nuit
Non c'est pas de la provocation, ce que tu décris, c'est le syndrôme de l'ingénieur :
Dans la théorie économique, il serait logique de raisonner comme cela et sain de faire des changements
Dans la pratique, c'est une organisation humaine ou chacun tente de survivre et cherche un espace de liberté.
C'est en cela que les méthodes font "chier" : elles n'ont rien d'humain.
Pour faire les choses de façon mécanique, on a pas besoin d'organique.
La dernière fois que j'ai été intérogé sur le sujet, j'a irépondu la chose suivante :
"Prenez un enfant de 18 ans. Expliquez lui que sa vie sera strictement rythmée, et que toutes ses actions en plus d'être pré programmées, seront limitées et immuables. Que ses actions ne demande aucun libre arbitre, et que l'organisation générale de sa journée ne tient pas compte de son bio rythme mais de statistiques.
Il s'agit basiquement des fondements de l'esclavagisme. L'identité ne compte plus, puisque le libre arbitre n'est pas sollicité, la liberté non plus : tout est régis par un cadre rigide et sur lequel il n'a pas d'emprise.
Basiquement une entreprise qui abuse des process, des méthodes et du formalisme, transforme un capital humain indispensable à l'innovation industrielle en un rocher aux singes où chacun passera son temps à gravir le rocher pour retrouver une partie de sa liberté, sans pour autant oser ou pouvoir sortir du rocher. "
Essaie de construire quoi que ce soit d'un peu complexe sans process, méthodes ou formalisme... juste pour voir le résultat...
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.
Répondre avec citation
Partager