Le métier d'informaticien, c'est ça ?

[Bernard_DRANEB]

Bonjour,

Ma question ne concerne pas vraiment la recherche d'emploi, mais se destine aux personnes qui ont pas mal tournées dans le métier

Je suis employés depuis pas tellement longtemps (quelques mois) dans une petite entreprise. Je travail en petite équipe sur un plus ou moins nouveau projet.
Ce qui m'étonne, c'est le manque total (je dit bien total) de conception et de structuration des projets de cette société (il paraît que "on a pas le temps"...), à part des normes de développement qui portent essentiellement à des prefix à utiliser pour les noms des variables et un standard de présentation des GUI.

Tout est fait oralement.
La conception de la BDD est faite à chaud et change de façon intempestive et sans préavis en raison d'incohérences (je tentes de maintenir un schéma de cette base de donnée au fùr et à mesure de ses modifications afin d'arriver à suivre)
Les fonctionnalités qui doivent être couvertes ne sont pas clairement établies.
Il n'y a pas de structures définies dans les différentes couches des différents programmes( il n'y a même pas de couche du tout), aucun RoadMap.
Evidemment, les fonctionnalités des programmes doivent eux aussi être changé fréquemment (c'est à rendre fou).

Cerise sur le gateau, cette société est certifié, les Dossiers Programmes sont fait en fin de projet s'il reste du temps.

Bon, j'en passes, je penses que ça donne idée.

Si j'aborde la question, le CP me réponds qu'il a tout en tête, que son projet est génial et qu'il sait où il va.

Tout ça pour en arriver à ma question: c'est comme ça partout ?
Dois-je changer de boite ou directement de métier ?

D'avance merci.

[tidou]

Ce type de problèmes est commun à pas mal de société qu'elle soit petite ou très grande d'après mes quelques expériences malheuresement mais avoir autant de mauvais côtés fait que ta société est sûrement une des pires que j'ai pu voir d'après ta description

Faut-il changer de société pour autant ? Je ne pense pas même si le marché est ouvert en ce moment. Essaye déjà dans un 1er temps de convaincre tes collègues ou supérieurs des avantages de la modélisation, des tests automatisés etc. (moins de bugs, facilité de la maintenance, etc.).

[Sahaqiel]

Je suis d'accord avec Tidou. Malheureusement, le fonctionnement que tu décris est loin d'être un cas particulier et est, je pense, assez fréquent, y compris dans certaines grosses boites.
La cause principale est (je crois) que beaucoup d'entreprises cernent mal les bonnes pratiques en ingénierie logicielle et ont du mal à voir le bénéfice de celles-ci. Je te donnerai le même conseil que Tidou, essaies d'abord de montrer l'intérêt des tests automatisés, d'une modélisation "carrée", etc... Il faut leur montrer que l'usage des bonnes pratiques fera gagner du temps et donc de l'argent à l'entreprise.
Enfin, si tes supérieurs s'avérent totalement hermétiques à tes explications, n'hésite pas à changer de société, parce que les sociétés où on travaille proprement existent quand même malgré tout !!

Bon courage

[Sphax]

Je suis assez d'accord avec mes camarades plus haut, tu pourrais essayer d'améliorer leur méthodologie avant d'aller voir ailleurs tout de suite. Le pb c'est qu'en tant que nouvel arrivant peu expérimenté, si tu essaies de changer les choses de manière trop brutale ça peut être mal pris, essaye peut être d'organiser de ton mieux ton propre travail et de montrer les avantages de ton organisation dans un premier temps, ça fera peut être tâche d'huile .
Si tu sens que rien ne va changer au bout d'un certain temps (donne toi par exemple 3-6 mois) je te conseille vivement d'aller voir ailleurs, il existe des boîtes plus organisées que ça et où tu apprendras certainement plus...

[Bernard_DRANEB]

Merci pour vos réponses.

Je me vois mal en tant que nouvel arrivant dans le métier et dans cette boite avoir le poid nécessaire à provoquer des changements. Cette "méthode" est une habitude prise par tout les quelques directeurs techniques et CP de la boite.

La situation avec le CP deviens de toute façon très complexe...

Ma décision est donc aujoud'hui prise de changer de société.

[xpander]

Une question c'est quoi comme projet (language) & combien il y a de table dans votre base ?

[Mat.M]

Envoyé par Bernard_DRANEB

Ce qui m'étonne, c'est le manque total (je dit bien total) de conception et de structuration des projets de cette société (il paraît que "on a pas le temps"...), à part des normes de développement qui portent essentiellement à des prefix à utiliser pour les noms des variables et un standard de présentation des GUI.

Tout est fait oralement.

Faut pas s'inquiéter c'est partout pareil sauf un peu moins dans les grosses structures et gros projets ou des spécifications techniques, une analyse fonctionnelle sont développés
De par mon expérience et de toutes les boites que j'ai faites c'est pareil tout est fait en dépit du bon sens sauf sur un gros projet auquel j'ai participé sur Grenoble ( qui mobilisait tout une équipe ) et un autre dans le 92.

La chose qui se passe aussi c'est que les commerciaux prennent des projets à développer, demandent une avance sur acompte ou arrhes au client 2 pour le projet pour en fait...financer le développement d'un projet déjà en cours pour le client 1

[PetitChat73]

Je relance ce sujet car j'ai moi aussi eu à bosser dans une boite de ce genre et je ne pensais pas que c'etait aussi répandu.
DG et Dir qui sont des commerciaux avec du bagou, un peu tyranniques, se voyant comme des rois au milieu de leurs vassaux.
CP, qui avait un peu bidouillé en info, mais franchement incompétent, mais CP, donc ce qu'il avait décidé etait ce qu'il fallait absolument faire, dans les temps que lui meme avait prévu, meme si ca nous demandait deux fois plus de boulot.
DT tres bon programmeur, comme ca au fil de l'eau, mais veut tellement arriver à un seul et unique produit pour tout faire qu'on en arrive a des trucs completement débiles et comme il est DT et autodidacte ne supporte pas la moindre remarque d'un sous-fifre, un tant soit plus rigoureux organisé et diplomé (mais ca ne veut pas dire grand chose) que lui.

Donc ces messieurs décident, nous balancent tout a l'oral, car de l'ecrit c'est genant, ca laisse des traces, si jamais ils font des merdes (et ils en font), et nous on se debrouille.

Bases de données pas reflechies pour deux sous, on part d'un projet de base et on rajoute des champs, des tables, des liaisons en fonctions des nouveaux projets, on scinde des tables ... et on se retrouve avec un bordel monstrueux.

Des balises developpées en interne, du code a reutiliser et/ou modifier ... et sur toutes ces choses de la doc ? que nenni, ces messieurs qui avaient développé cela connaissaient le truc et n'avaient pas l'intention de transmettre l'info a qui que ce soit, ou alors seulement par toutes petites bribes qu'il fallait leur arracher quand ils daignaient lever la tete de leur ecran pour nous répondre.
Aucune doc, aucune description de l'organisation des serveurs, des bases, du fonctionnement global. On etait sensés avoir la science infuse ou dégager.

Je vous avoue avoir eu beaucoup de mal a bosser dans une boite comme celle la. J'ai tenu un an et ouf .... maintenant je revis.

[souviron34]

Bah...

En dehors du fait que les choses que vous mentionnez ne soient pas réfléchies (c'est là que le bât blesse), pour le reste, non seulement c'est très répandu, mais encore je dirais avec mon expérience que c'est mieux (je sais je sais je vais me faire incendier )....

Par expérience, tout projet sur lequel j'ai travaillé qui suivait les règles déontologiques a échoué (après avoir gaspillé une énérgie, une passion, et un nombre de sous inimaginable). Parallèllement, 2 projets/3 développés sans cadres particuliers, mais avec de la réflexion, a abouti...



Tirez-en les conclusions vous-mêmes....


En gros, l'important n'est pas d'avoir un cadre ou pas, c'est de bien penser.

Et j'ai vu des dizaines de jeunes dans des projets très structurés, très encadrés et organisés, voir leur passion s'évaporer au fur et à mesure que la production de leur logiciel ne trouvait pas acheteur... pour la simple raison que l'organisation avait oublié que c'était un produit qu'ils fabriquaient.... Ah oui !! Tous les documents étaient à jour, tous les tests unitaires étaient faits, tout était fait suivant les règles.... Mais personne n'en voulait, de leur logiciel... Ils y avaient mis leur coeur, leur passion (certains depuis plus de 10 ans)... Et finalement la boîte a fermé..... car zéro clients... car mauvaise conception....

[badjojo]

hello! je viens pour appuyer l'avis de souviron34, qui me parait assez judicieux, et le nuancer par la même occasion...

Je pense que suivant la nature et la taille du projet, il peut s'avérer judicieux de ne pas être trop tatillon sur l'organisation projet... à quoi sert de doubler le temps de développement en respectant toutes les normes (normes de dev, processus CMMI....) pour un petit logiciel jettable par exemple, alors que le client veut surtout un logiciel assurant parfaitement 90% des fonctionnalités définies dans le cahier des charges mais au prix minimum?

Le tout est d'être censé, et d'avoir toujours en tête l'objectif économique. Des chefs qui sont là pour recadrer les techos fous rêvant d'un produit immaculé. Oui, c'est bien de faire un beau logiciel pour fidéliser le client, mais ça ne sert à rien de le fidéliser si c'est pour se faire 0 € de marge... 0 + 0 = la tête à ?

Je sais, personne n'a dit le contraire.

Maintenant, je trouve qu'un minimum vital est d'avoir des spécifications fonctionnelles détaillées, un cahier des charges clair et bien rédigé, et un ensemble de documents contractuels sans ambiguité. Sinon, je ne sais même pas comment font les gens pour s'en sortir.

Par contre, je ne comprends pas qu'un CP puisse déclarer qu'il a tout dans la tête, de ne pas s'inquiéter et sait où il va... passe encore qu'il dise qu'il n'a pas le temps de formaliser certaines choses, et qu'il en va de sa responsabilité en cas de problème. Mais c'est vrai que ça ne doit pas être agréable de travailler avec ce genre de personnes.

[madfu]

Je pense que suivant la nature et la taille du projet, il peut s'avérer judicieux de ne pas être trop tatillon sur l'organisation projet... à quoi sert de doubler le temps de développement en respectant toutes les normes (normes de dev, processus CMMI....) pour un petit logiciel jettable par exemple, alors que le client veut surtout un logiciel assurant parfaitement 90% des fonctionnalités définies dans le cahier des charges mais au prix minimum?

Entièrement d'accord. Je pense aussi qu'il faut voir les choses de manière progressive et s'adapter à la finalité.

Maintenant il ya un autre aspects connexe au cadre de développement c'est l'architecture du code et le choix des technos à employer. Avoir un cadre c'est bien mais (et c'est peut être ce que soulignait Souviron) mais une bonne conception c'est primordial !

Bernard_DRANEB j'ai donné aussi dans le pure-code-écrit-tout-de-suite-apres-la-lecture-du-cahier-de-charges à mes débuts car "pas le temps, trop pressé", ça a donné des logiciels impossibles à maintenir par d'autres personnes que moi - puis par moi - et donc abandonnés.

Aujourd'hui pour des projets "sérieux" (de l'ordre de 6 mois de dév. minimum) je demande que sois progressivement mis en place un cadre (qui s'étoffera en fonction des ressources et de la durée du projet) et une méthodologie et je deviens peu à peu "intraitable" sur l'organisation du code...

Des chefs qui sont là pour recadrer les techos fous rêvant d'un produit immaculé. Oui, c'est bien de faire un beau logiciel pour fidéliser le client, mais ça ne sert à rien de le fidéliser si c'est pour se faire 0 € de marge... 0 + 0 = la tête à ?

Dans un projet à long terme il ya des objectifs à court, moyen et long terme. Avoir une architecture stable et *suffisamment* évolutive est aussi un gage de qualité qui va engager le logiciel sur les années à venir, ça a un coût malheureusement, et les logiciels mal conçus ont également un coût quand vient le temps des maintenances diverses. Les techos capables de fournir cette archi ne sont peut être pas toujours les plus enclins à se concentrer sur le besoin c'est vrai mais au final ce n'est pas leur métier. Aux responsables (ou en tout cas aux personnes réellement concernées par le besoin - ou compétentes fonctionnellement) de recadrer les objectifs.