Bejarid a écrit :



Tout logiciel complexe (et celui-là l’est, on a voulu fusionner un très grand nombre de besoin dans un seul soft) est un nid à emmerdes.

   Ce n'est pas pour rien que les ERP dans les grosses boites sont presque toujours les mêmes (SAP et consort). Je suis vraiment pas persuadé que le faire en interne aurait aider, si le presta a pu autant se viander, c'est aussi car le pilotage de projet au niveau de l'état a totalement échoué et a fait n'importe quoi.         

   L'intéret d'avoir un presta c'est que ça rajoute une deuxième couche de gestion de projet qui habituellement limite la casse, pas de peau ici il n'a pas joué son rôle... Mais il n'est en aucun cas le seul, ni le premier, responsable.

Pour bosser pour administration en tant que presta sur un progiciel, je suis assez d’accord sur les problèmes de fonctionnement du pilotage de projet.



Sur celui sur lequel je bosse, le chef de projet MOA change tout les ans, parce qu’allant vers de plus hautes fonctions. Comme le seul moyen d’être augmenté est de monter hiérarchiquement, tout le monde le fait. Du coup, on se retrouve avec des personnes qui n’y connaissent jamais rien et qui, le temps de s’impregner du projet et du fonctionnement produit, se barrent pour d’autres horizons.



Résultats, on est sans cesse à la bourre, on est même en tant que MOE obligé d’écrire des spécifications fonctionnelles nous-mêmes parce qu’il n’y en a pas, ou parce qu’elles sont pourries et inapplicables.



Pour autant, je serais pour dans certains cas internaliser certains projets.



Par exemple, le progiciel sur lequel je bosse ne fais rien d’extraordinaire, et pourait largement être développé en interne, surtout qu’il y a eu des embauches récentes d’architectes systèmes et de développeurs contractuels qui ont vraiment le niveau et l’envie de faire bien les choses.

Et surtout, quand tu vois le prix des licences pour un soft extrêmement compliqué à faire évoluer et à maintenir à cause de la fermeture du code, le prix des prestas (dont moi " />) pour développer ce qu’ils ne peuvent pas développer sans les sources, et, il faut le souligner, la qualité plus que déplorable du soft de base sans les customisations qui pose de gros problèmes de performances et de disponibilité, franchement un dév interne serait bien plus rentable, et une partie du code serait réutilisable sur d’autres projets.







Capitaine dobbey a écrit :



Les boîtes privées ne sont pas meilleures que la fonction publique, c’est juste que l’état où les collectivités n’ont pas vocation à reinventer la roue.

Par contre les marchés posent le problème que les conditions ne permettent pas de choisir le meilleur logiciel pour réaliser une tache, il faut dire quelles fonctionnalités sont attendues et celui qui répond le mieux en étant le moins cher gagne. 

Et on se retrouve ainsi avec un logiciel incapable de gérer le volume parce que la boite n’a jamais essayé d’injecter autant de données et donc elle bidouille pour que ça tourne. Et vu que c’est la moins chère des boite qui gagne, c’est aussi les informaticiens les moins chers qui y travaillent. Donc de fortes chance d’avoir des gentils gamins sortant d’école (souvents pleins d’espoirs et de prétentions) incapable de gérer correctement les exigences du client et les délais du commercial. 

Et ensuite effectivement on rajoute à ça un gestionnaire d’application qui ne sait pas correctement utiliser le produit bancal qu’on lui livre.





Quand j’ai débuté la mission, il y avait des customisations développées par une boîte externe que je devais reprendre, et le mec qui est venu pour faire le transfert de connaissances était un ancien stagiaire en école d’ingé qui venait tout juste d’être embauché, et la partie qu’il a dév a été faite durant son stage " />

Et je dirais même qu’en mettant en place un pôle de développement informatique public (avec une vraie gestion de ressources), on ferait des économies monstrueuses en développant des applis utilisables par toutes les administrations, ça éviterait les milliards d’euros en dev/licence qui vont aux éditeurs américains.

Z-os a écrit :



Il n’y a pas que dans le public, je te rassure. ;-)





Oui, c’est clair, ce n’est pas ce que j’ai voulu dire.



L’incompétence n’est pas l’apanage du public. Mais il faut avouer que la gestion des carrières dans l’administration publique ne convient pas des masses à la gestion de projet informatique, car trop de monde change trop souvent.

C’est d’ailleurs en partie pour ça (en fait c’est surtout pour ne pas créer de nouveaux fonctionnaires) que les nouveaux sont souvent recrutés en tant que contractuels.

Capitaine dobbey a écrit :



Le seul moyen d’être augmenté est de changer de grade, en passant des concours ou en étant promu. 

La fonction n’a en général aucun avantage sauf une bonification de point très legere.





Oui, c’est ce que je voulais dire par là " />



Pour changer de grade plus vite, ils changent de poste.







kras a écrit :



Encore heureux, faut arrêter de croire que ce sont aux développeurs d’écrire les spés fonctionnelles.

C’est pas parce que vous avez un énorme salaire que vous avez juste à vous tourner les pouces.

Faut arrêter de considérer les devs comme les esclaves.





Ca tombe bien, je suis dev " />







Zerdligham a écrit :



Vu ce que tu racontes, ça me donne plutôt l’impression que celui qui arrive réalise que c’est un tas de merde et fuit au plus vite. Même pas sûr que ce soit lié au salaire.





Pour les nouveaux, il y a un peu de ça, oui. Ils sont assez vite découragés par l’ampleur du chantier laissé par les prédécesseurs.



Mais ça reste surtout un moyen de prendre un grade, et ça se vérifie dans d’autres services que la MOA.