Dans la technique du monde industriel, on constate l'influence des "coûts réduits" ainsi que des "délais courts".
L'argent est passé au centre des préoccupations, le produit est un mal nécessaire, le but des entreprises a évolué de "faire un bon produit" à "faire de l'argent" (ou bien cela a toujours été le cas?).
L'ingénieur classique, artisan professionnel et consciencieux ayant un brin de créativité "se fait plaisir" en cherchant systématiquement à faire un produit innovant ou d'une qualité supérieure à celle demandée.
Finalement il est devenu un "centre de coût" pas trop bien vu…
La créativité est souvent "recadrée" pour en limiter la dépense.
La technique guidée par les coût est donc peu motivante ni vraiment créatrice, la valeur de l'open-source réside justement dans l'absence totale de considération de coûts et de délais.
Dans ce contexte je vous encourage à créer votre propre open-source à coût
exorbitant (sur votre temps libre) pour laisser enfin votre créativité
s'exprimer. Et pas besoin de faire la doc! Vous êtes le décideur!
# Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 04 octobre 2013 à 23:37.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bien vu ;-)
Posté par clownix (site web personnel) . Évalué à 4.
Entièrement d'accord sur la doc nécessaire pour le partage mais le libre permet de faire ce que l'on veut quand on le veut, et parfois coder est une obsession qui mange les autres activités…
Le code résultant du travail sans préparation (sans spécs) est assez brouillon mais il avance vite et quand on construit et lance des tests automatiques scriptés en parallèle, les tests génèrent une boucle d'amélioration du code et donnent une bonne idée de la spéc.
En bref une doc peut être fournit par les scripts de tests…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
# Leurre, moi je dis "non !"
Posté par Guillaume Camera . Évalué à 10.
Oui, du "vite fait mal fait" c'est le quotidien de plus d'un développeur, mais n'oublions pas que limiter sa créativité et du coup la qualité de son travail, ça a des coûts câchés. Situation vécu, certains étaient étonnés que je passe plus d'un jour à documenter une fonctionnalité. Ouais sauf qu'une doc mal faite ça sert à que dalle, on comprend rien et c'est une perte de temps pour celui qui passe après.
Je ne pense pas qu'il faille (ça se dit ça ?) être fataliste à ce sujet et au contraire, se battre le plus possible pour qu'on nous oblige pas à bacler notre taf. Ca me revolte vraiment de passer sur du code dégueulasse et qu'on me dise: "Non mais tu comprends il fallait que ça sorte." Ouais, sauf que maintenant il me faut trois semaines pour comprendre trois fonctions imbriquées les une dans les autres , pouvoir décorèler unitairement les fonction pour enfin, soit fixer un bug soit rajouter une feature. Alors qu'à l'époque ça aurait prit deux jours. Je parle même pas de la fatigue que ça peut entraîner et de la démotivation, qui peuvent jouer sur le temps de sortie d'un produit.
Bon bref, je m'arrête là, mais tout ça pour vous dire, que quand on vous dit d'aller vite et qu'il faut que ça sorte, battez vous pour obtenir du rabe si vous êtes limite et au pire, un délai après la sortie pour bien ré-architecturer et bien documenter ce que vous avez dégueulé en une demi journée.
Cela dit, ça ne doit pas vous empêcher de contribuer activement au libre \o/ (ce que je ne fais pas parce que je suis pas trop créatif et et trop mauvais)
[^] # Re: Leurre, moi je dis "non !"
Posté par Anonyme . Évalué à 4.
de ce que je vois dans pas mal de domaine d'activité : le mauvais bosse comme il peut, le bon corrige ce que fait le mauvais \o/.
et pour les cout caché, a ce jour je n'ai JAMAIS vu un manager/dirigeant prendre en compte des cout ou à la fin du mois il n'y a pas une facture avec TVA.
[^] # Re: Leurre, moi je dis "non !"
Posté par Guillaume Camera . Évalué à 1.
Il est vrai que c'est assez rare, mais une fois la situation vécue ( trois mois de formation pour un nouvel arrivant, des vagues de départs des "bons".), si le mec est pas débile, il arrive à remettre en question son management. Un projet sur lequel il est agréable de travailler, c'est bon pour le morale et la productivité.
Mais oui c'est regrettable que ça se passe souvent à la marge net de la facture de la fin du mois.
[^] # Re: Leurre, moi je dis "non !"
Posté par lolcat . Évalué à 1.
Les coûts de maintenance sont souvent une variable qui n'est pas prise en compte dans les projets informatiques.
Pourtant c'est quelque chose de capital, et si le code est de mauvaise qualité, cela peut faire exploser les coûts de maintenance.
Ne pas bien évaluer les coûts de maintenance peut complètement ruiner l'aboutissement et la viabilité d'un projet.
cf : http://www.cairn.info/le-genie-logiciel--9782130548928.htm
[^] # Re: Leurre, moi je dis "non !"
Posté par ckyl . Évalué à 7.
Pas totalement d'accord sur l'approche de gratter du temps. Pour un projet il existe quatre variable d'ajustement: l'ensemble de fonctionnalités, la date de sortie, la vélocité, la qualité.
En général un produit est créé pour répondre à un besoin et il est totalement stupide d'utiliser la qualité comme variable d'ajustement. C'est assez facile à expliquer dans tout contexte qui n'est pas borné au court terme (coût du support, vélocité après quelque années, perte de clients, évolutions). Bref si on arrive pas à faire immédiatement oublier cette variable, il faut soit se remettre en question, soit partir direct. Attention on ne parle pas de faire quelque chose de parfait, mais quelque chose de viable dans le temps. Sortir un produit qui marche et qu'on pourra maintenir.
La vélocité étant assez difficile à maîtriser et à faire évoluer. C'est un objectif à long terme mais certainement pas une variable pour un produit. On cherche à la maximiser, et on l'ajuste pour la vision à long terme mais on ne s'en sert pas pour du court terme.
Il reste donc deux variables possibles et cohérentes: la date mais surtout les fonctionnalités.
Bien souvent il est plus facile et raisonnable de négocier les fonctionnalités qu'une date. On peut facilement expliquer ce qui coûte, pourquoi, comment on pourrait faire moins cher et laisser les gens choisir. On maintient la qualité constante, et on fait au mieux pour une date fixe. On pourra toujours compléter en gardant la même vitesse. Réussir à calculer une date pour une large ensemble de fonctionnalités contractuelle est beaucoup beaucoup plus difficile et plus mauvais pour le produit: obligé d'utiliser la qualité comme variable, ou prévoir des marges énormes. Mais dans ce cas, ça coûte très cher pour rien…
Il existe des cas ou ce n'est pas possible et où on va devoir fixer les fonctionnalités: Première livraison du sous ensemble de fonctionnalité minimum par exemple, contrat pourri etc. De mon expérience, c'est souvent douloureux pour toutes les parties. Ça marche vachement moins bien que l'autre sens.
Bref impliquer toutes les parties concernés par le produit pour construire l'histoire au mieux avec eux pour un coût donné me semble souvent une meilleure idée que de jouer à perpétuellement gratter du temps et donc utiliser le coût comme variable d'ajustement. Ceux qui payent ont une raison de le faire et ne sont généralement pas stupides. Si ils sont content de ce qui est livré, ils remettront du pognon pour ce qui est à rajouter. Il vaut souvent mieux livrer une ou deux fonctionnalité tout les mois, que toutes dans 2 ans (ou 4, ou 6 mois, ou 3 mois mais ca marche pas…).
# but de l'entreprise
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 05 octobre 2013 à 10:07.
J'avais entendu dire que le but d'une entreprise était de donner du travail à la personne, ou dit autrement, de permettre le travail de la personne en le rentabilisant. Le profit étant alors un des moyens permettant à l'homme de travailler.
Moué, « faire un bon produit », « faire de l'argent », dans les deux cas l'homme est servile, et le travail de l'homme un mal nécessaire au lieu d'être un bien recherché.
La réflexion devrait être :
- Je veux travailler, inventer, fabriquer, faire des choses passionnantes !
- Bien, on va créer une entreprise et trouver un modèle économique pour te permettre de vivre et te permettre de faire tout cela en t'en donnant les moyens ! Super non ? Tu pourras te glorifier de tes œuvres ! Ta vie sera passionnante ! Ah au fait, l'argent sera monnayable et sera une variable d'ajustement.
au lieu d'être :
- Je veux de l'argent !
- Bah on va créer une entreprise et te trouver un truc à faire, n'importe quoi ! Ça sera pas passionnant mais l'argent n'a pas besoin de passion (et n'a pas d'odeur) ! Tu pourras te glorifier de l'argent gagné ! Ton argent sera passionnant, ou pas. Ah au fait, ta vie sera monnayable et sera une variable d'ajustement.
Ça me rappelle une discussion entendue récemment entre un gars un peu lourd avec une autoentrepreneuse :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: but de l'entreprise
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 0.
Personne ne t'empêche de monter une telle boîte. Le truc, c'est que créer une boîte c'est comme le libre : chacun fait ce qu'il veut. Et il se trouve que ceux qui montent de grosses entreprises sont en général attirés par l'argent ou le pouvoir. C'est comme ça.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: but de l'entreprise
Posté par Antoine . Évalué à 7.
On ne monte pas une grosse entreprise. On monte une petite entreprise qui parfois deviendra grosse.
Ensuite, "attirés par l'argent et le pouvoir", je pense que c'est une grossière simplification. Ceux qui sont attirés par l'argent et le pouvoir, ce sont surtout ceux qui rampent jusqu'au poste de manager et prennent en main des entreprises déjà établies. La motivation d'un fondateur d'entreprise est probablement beaucoup plus complexe.
[^] # Re: but de l'entreprise
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
s/grossière/grosse/Là, d'accord.
Par ailleurs, le fait de vouloir faire grossir son entreprise dans des proportions qui l'amènent à devenir une grosse entreprise, c'est souvent lié à l'ambition du créateur. Si tu prends des grosses boîtes comme M$, Oracle et autres, ce n'est pas par philanthropie qu'elles sont devenues grosses, ni par perfectionnisme. Le sens de mon message était surtout de mettre en relief cela.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: but de l'entreprise
Posté par clownix (site web personnel) . Évalué à 3.
Bonne différentiation des profils: le côté conventionnel, opportuniste et profiteur pour les grands chefs de grandes entreprises existantes et le côté aventurier original créatif et courageux des vrais créateurs de sociétés.
Le problème: ils sont souvent mis dans le même sac!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.