Mouais, m'enfin... Quelque part si il y a besoin de mise à jour c'est que le boulot rendu était pas très bien fini
Et j'imagine que le sav et les mises à jour sont loin d'occuper quelqu'un à 100%

(C'est encore moins mon domaine donc logiquement tu devrais être moins à côté de la plaque que moi, ceci dit )

Alors Tikim la vie active ça te plait?

Je sais pas si vous avez vu mais avec les points de la supercard (coop) on peut avoir la ps4

Tu as un appart' Tikim ou t'es encore chez papa-maman ?

Mouais, m'enfin... Quelque part si il y a besoin de mise à jour c'est que le boulot rendu était pas très bien fini

Et j'imagine que le sav et les mises à jour sont loin d'occuper quelqu'un à 100%

Tu oublies que le client sait pas ce qu'il veut en premier lieu, et vient TOUJOURS après-coup te réclamer que telles et telles fonctions soient modifiées/ajoutées.
Et si, quand tu fais un produit pour une grosse entreprise, faut être conscient que c'est pas juste "un" client, mais une pléthore de chefs de projets qui te bombardent de requêtes, donc t'as généralement une personne qui se retrouve assignée à plus ou moins 100% pour prendre en charge les besoins de cette entreprise.

J'aurais pensé que c'était l'affaire d'un petit mois à une seule personne dessus...

Tout dépend de l'ampleur du projet, mais pour avoir fait mon stage dans une boîte qui fait un truc similaire (non, je révèlerai rien de plus !), ils sont deux équipes d'une dizaine d'employés, dont le 3/4 font du SAV.

PiloteFou Ne demande JAMAIS à une personne seule de te coder quelque chose si tu veux de la qualité d'industrie.
Tout d'abord parce que cette personne va faire un logiciel qui lui est adapté à elle seule, ce qui sera une énorme source de frustrations pour tes utilisateurs.

(Expérience faite en étant cette personne seule. )

Norka Oui c'est pas mal mais j'ai pas encore complètement réalisé et c'est que le début. Phase d'essai, de formation, etc. Le vrai feedback faut le demander dans 4-5 mois

Denvel j'habite avec ma copine depuis plus de deux ans et avant ça j'ai vécu un an en studio (entre les deux j'ai fait un an de retour chez ma mère ). J'étais entretenu par ma mère et ma copine

Pour le logiciel c'est sérieux cette histoire de SAV, ça représente souvent plus que les coûts de développement pour la simple raison que c'est plus étalé dans le temps. Et la solution vite fait sera mal documentée, les bugs jamais corrigés (blabla boulot mal fait = irréaliste. Il y a TOUJOURS des bugs), aucune aide à l'utilisation, un process de développement à la ramasse (communication avec le ou les clients à l'arrache) et j'en passe.

C'est une chose de savoir coder, mais proposer une solution professionnelle c'est un ensemble de métiers bien différents, d'expérience de l'entreprise, de processus établis et reconnus, etc. Ça s'invente pas comme ça.

Pareil pour Sogelink qui parle de carte embarquée sur mesure. Si tu veux un truc dégueulasse avec des fils partout ça se fait, mais si tu veux un produit fini ça passe par plusieurs prototypes donc beaucoup de temps !

"Tu oublies que le client sait pas ce qu'il veut en premier lieu, et vient TOUJOURS après-coup te réclamer que telles et telles fonctions soient modifiées/ajoutées."

-> Mouais, c'est un peu un autre problème ça. Et dans le cas présent, ça me semble pas si improbable que le client sache ce qu'il veut en premier lieu. Des logiciels de gestion / compta il doit y en avoir déjà plein, donc si il en commande un, c'est peut-être parce qu'il sait ce qu'il veut par rapport à ce qui existe déjà.
Si effectivement il veut pouvoir réclamer des modifications, on est dans un autre cadre que celui que j'avais en tête (je commande précisément ça, on te donne ça. Si en fait tu voulais ceci, ben c'est une autre commande).

 
 "blabla boulot mal fait = irréaliste. Il y a TOUJOURS des bugs"

-> J'ai envie de dire que ça dépend de l'ampleur du projet, quand même. Si c'est suffisamment modeste, je pense que tu peux le tester suffisamment pour qu'il n'y en ait pas (ou qu'ils soient suffisamment improbables pour qu'on ne se rende jamais compte).
D'ailleurs, j'ose espérer que les mecs qui codent des trucs "importants" les testent suffisamment avant de livrer le produit, et n'ont pas cette réponse "blabla boulot mal fait = irréaliste. Il y a TOUJOURS des bugs".
"Le volant de la voiture s'est bloqué et votre fils a fini dans le ravin ? Oui, c'est un petit bug, notre SAV va s'occuper de ça, vous inquiétez pas."

Des logiciels de gestion / compta il doit y en avoir déjà plein, donc si il en commande un, c'est peut-être parce qu'il sait ce qu'il veut par rapport à ce qui existe déjà.

Heh, c'est le bon vieux pattern de "je veux que ça ressemble à XYZ". Auquel cas y a qu'une seule bonne réponse : achète une licence XYZ et contacte la société directement pour les modifications !

http://thedailywtf.com/articles/classic-wtf-the-net-bridge-to-nowhere

Le volant de la voiture s'est bloqué et votre fils a fini dans le ravin ? Oui, c'est un petit bug, notre SAV va s'occuper de ça, vous inquiétez pas.

Boeing et Malaysia Airlines ?

Tous les fabricants de voiture qui procèdent tous les 1-2 ans à des rappels de masse ? Les failles majeures qu'il y a eu dans quasiment TOUS les OS et TOUTES les technologies liées au web ?

Bien sûr que tout est testé mais il peut y avoir tellement de bugs différents dans des conditions tellement spécifiques... Beaucoup de bugs sont remontés par les clients !

Et puisqu'on en parle des tests, dans chaque grosse entreprise c'est un département entier qui s'occupe des tests, toute une équipe ! C'est pas les développeurs (sauf les tests unitaires bien sûr). Autant dire que confier le job à un unique individu c'est se passer de l'équipe de tests, donc du suicide informatique. Ah et quand je dis un département, c'est même souvent plusieurs ! (Tests de validation, white/black/grey box, tests sur client ou utilisateur final, tests unitaires, bancs de tests, stress test, etc etc.)

Les rappels de voiture c'est vraiment lié à des soucis logiciels ?
Non parce que personnellement, j'ai jamais subi ni connu personnellement quelqu'un qui a dû "subir" un rappel de sa voiture. Et il me semblait que c'était plutôt des défauts de fabrications matériels, qui souvent ne concernaient que certains lots
Pour les OS, on va dire que c'est moins important. Et puis OpenBSD était pratiquement sans faille, non ?

 
"Autant dire que confier le job à un unique individu c'est se passer de l'équipe de tests, donc du suicide informatique."

-> Euh... Je suis pas d'accord sur cette conclusion... Oui les tests sont un gros trucs, et quand t'as un gros projet nécessitant plusieurs personnes c'est là que les bugs/failles deviennent inévitables. Mais je pense justement que le meilleur moyen d'éviter les failles, c'est que ce soit une seule personne qui s'occupe du projet, parce qu'il aura une connaissance parfaite du fonctionnement du machin, et donc pourra identifier plus facilement ses failles.
Bien sûr, c'est possible que sur un petit projet (j'ai sans doute sous-estimé l'ampleur de la tâche ici, par contre ) et avec un mec polyvalent (spécialisé en tout).

 
"Auquel cas y a qu'une seule bonne réponse : achète une licence XYZ et contacte la société directement pour les modifications ! "

-> Ben si c'est possible (je sais pas si toutes les sociétés seraient disposées à ça, surtout si elle a fait faillite entre-temps ) ; c'est ce que je ferais à sa place, oui

Les entreprises qui font faillite, c'est un gros problème, oui ; surtout quand tu fais du consulting et que le client te demande une fonctionalité qui te fait tomber ta solution à l'eau parce que le logiciel de telle ou telle entreprise qui a fait faillite était pas open source.
(On peut d'ailleurs étendre à d'autres événements du type rachat de l'entreprise par une entreprise peu intéressée par le logiciel, etc.)

Bah récemment ya eu Fiat Chrysler qui a rappelé plus d'un million de voiture suite à un piratage (le pirate a prouvé la faisabilité de l'exploitation, le constructeur a pris ça au sérieux pour une fois).

Et non un mec ne connaît pas mieux son programme que plein de mecs car il n'a que sa vision des choses. Je peux t'assurer que quand t'as un projet et que tu prétends qu'il marche à 100%, que t'as pensé à tout et couvert tous les cas de test, si tu fais venir des gens random pour le tester ils vont tout faire déconner et tu comprendras rien de rien.

"ah mais ce bouton fallait pas appuyer il sert à rien " " il est là, j'ai appuyé, tout a planté ".

Oui c'est courant concrètement plus tu connais un projet plus tu omet des choses inconsciemment car tu as vite fait de fixer tes priorités et d'oublier le reste.

" "ah mais ce bouton fallait pas appuyer il sert à rien " " il est là, j'ai appuyé, tout a planté ". "

-> Pourquoi il y a un bouton si il sert à rien ? Là, ça pue le truc du mec qui a pompé des bouts de code sans les comprendre... Je parle d'un projet fait "from scratch". Si il y a un bouton, c'est parce que le mec l'a codé, donc qu'il sert à quelque chose...

 
"concrètement plus tu connais un projet plus tu omet des choses inconsciemment car tu as vite fait de fixer tes priorités et d'oublier le reste."

-> What ? Si ta priorité c'est la sécurité, tu vas au contraire dès que tu crées un truc savoir si ce genre de faille est possible ou pas, et aller la corriger là où il faut. Contrairement à quand tu bosses à plusieurs et où tu pars du principe que le mec qui a codé ce machin là a dû gérer ce cas là, alors que non.

Ah, j'ai oublié ça :
"Bah récemment ya eu Fiat Chrysler qui a rappelé plus d'un million de voiture suite à un piratage (le pirate a prouvé la faisabilité de l'exploitation, le constructeur a pris ça au sérieux pour une fois)."

J'imagine que ces conneries de voitures intelligentes ?
Et quoi qu'il en soit, j'ai pas dit que ça existait pas, j'ai dit que j'espérais que ça existait pas trop. Mais je suis qu'à moitié étonné de voir que le monde va mal...

C'est complètement idéaliste. Quand t'es tout seul tu dois penser à tout, tu peux pas te concentrer sur un seul truc. Tu fais tout moins bien que si tu avais une seule tâche. T'imagines même pas le nombre de bugs potentiels qu'il peut y avoir dans un programme de 2000 lignes, alors imagine un programme de 50k ou plus (et on y est vite). Et un bug est pas forcément entre deux lignes de codes fraîchement tapée, ça peut être une petite erreur de conception, un truc qui fait foirer un autre, un problème de mémoire à moyen terme, etc. Et ajoute une partie réseau, OS (serveur) et BDD et ça devient tellement complexe, ça dépend de tellement de facteurs, que tu peux absolument pas confier ça a une seule personne.

Le type qui peut gérer tout ça sans faute n'existe pas, ou alors il est consultant et code plus tant que ça, sans parler de son salaire.

Intelligente je sais pas, connectée en tout cas oui.

T'as vraiment une mentalité "la spécialisation c'est le bien".

Alors qu'il y a des avantages et des inconvénients à ça. Les avantages c'est évidemment pour les gros projets (enfin, ce que moi j'appelle gros projets, mais toi ce que t'appelles gros projets, c'est ce que moi j'appelle pharaonique, apparemment). Mais laisser une seule personne a aussi ses avantages. Typiquement :
"Et un bug est pas forcément entre deux lignes de codes fraîchement tapée, ça peut être une petite erreur de conception"
Oui, justement. Un problème de conception, ça devient un bug quand plusieurs personnes bossent sur le code. Si t'en as une seule, au moment d'implémenter elle se rendra compte du problème qu'il y avait et le corrigera de suite.
Quand tu dois penser à tout, tu sais comment tout est pensé. Quand tu ne dois penser qu'à ta partie, tu risque de faire de la merde parce que le mec qui fait l'autre partie ne pense pas comme toi.

 
" alors imagine un programme de 50k ou plus (et on y est vite) [...] Et ajoute une partie réseau, OS (serveur) et BDD et ça devient tellement complexe, ça dépend de tellement de facteurs, que tu peux absolument pas confier ça a une seule personne."

Sans blague. Là on est déjà sur du pharaonique pour moi, bien sûr que tu peux plus faire tout seul si t'as un machin aussi gros...

Je connais le mec qui a bossé sur my.epfl.ch durant 7 ans. Il était tout seul du début à la fin, le projet était en développement local pendant 5 ans et il est en ligne depuis 2 ans environ. Le mec a gérer TOUT (serveurs, BDD, code, OS). Après je ne suis plus à l'EPFL donc je n'ai aucune idée où en est le projet désormais. Et c'est vraiment un projet monstrueux. Y'avait un article sur le flash informatique de l'EPFL si vous êtes intéressés où il explique tout.

Le 02 septembre 2015 à 20:45:52 L-orgue-e-yeux a écrit :
" "ah mais ce bouton fallait pas appuyer il sert à rien " " il est là, j'ai appuyé, tout a planté ". "

-> Pourquoi il y a un bouton si il sert à rien ?

P'tain mec, t'as jamais maté le laboratoire de Dexter ou quoi?
Y'a toujours un gros bouton rouge qui va tout péter, c'est la base
Même moi qui fait pas trop d'info, je sais ça

"P'tain mec, t'as jamais maté le laboratoire de Dexter ou quoi?"
Non.

"Y'a toujours un gros bouton rouge qui va tout péter, c'est la base"
Non plus.

Le 02 septembre 2015 à 22:17:33 Wulfharth a écrit :
P'tain mec, t'as jamais maté le laboratoire de Dexter ou quoi?