Publicité
+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 36 sur 36
  1. #21
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 778
    Points
    1 778

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    Dans le deuxième type de boîte (qui a dit SSII ? ^^) il n'est que logique de mesurer les temps passés le plus finement possible pour pouvoir identifier les problèmes et les corriger au moindre écart. Encore faut-il que 1/ les mesures soient fiables, 2/ analysées correctement, 3/ que les bonnes actions soient décidées derrière et 4/ qu'il y ait des retours pour éventuellement adapter ou modifier celles-ci. D'après ce que j'ai vu, ça tient plus souvent de la théorie que de la réalité et les décisionnaires sont tellement éloignés du terrain que les actions menées sont souvent contre-productives.
    Et même la, tu as pas d'infos utiles. Comment tu mesures par exemple les écarts de productivité avec les gens que tu n'as embauché qui serais venu dans ta boite si les conditions y étaient meilleures ? Comment tu mesures l'adhésion des troupes aux objectifs de la boite, leur motivation ? La créativité des solutions trouvées, et ce que ça va te coûter/t'économiser par la suite ?

  2. #22
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    Personnellement je ne travaillerais pas pour une société qui me demande de me justifier tous les quarts d'heures, ni même toutes les deux heures. C'est du flicage, et si on veut me fliquer on n'a qu'à le faire en se passant de ma propre complicité.

    Question : "oui, mais non, gros Troll, t'as rien compris, ça sert pas à fliquer..."

    Réponse : Mon expérience (qui est discutable) m'a appris que toute chose pouvant servir à fliquer les gens (que cela soit sa vocation première ou non) finit par ne servir qu'à cela.

  3. #23
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 813
    Points
    12 813

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    Il pourrait être interessant de mettre une balise [TROLL] [/TROLL] sur le forum qui apparaitrait dans un cadre spéciall avec des poils autour.

    Cela permettrai au lecteur d'etre averti sur les intentions de la personne qui post.
    Citation Envoyé par el_slapper Voir le message
    C'est à l'appréciation des modérateurs. Je le fais parfois. J'ai été rappellé à l'ordre une fois.

    J'aime la proposition de Jabbounet(les poils autour du texte assumé trollesque) : celà permettrait de rendre plus visuelle - et donc perceptible par un lecteur qui ne s'y attend pas - l'ironie.
    ça existe déjà, si on regarde bien :

    []
    ..
    [/]




    Bon, les crochets sont de moi ..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  4. #24
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 697
    Points : 6 226
    Points
    6 226

    Par défaut

    Pour en revenir au sujet, j'ai été amené à faire cela mais ce n'était pas pour du flicage. Un problème qui arrive vite lorsqu'on développe un progiciel et qu'on offre des contrats de maintenance c'est de contrôler ce que ça nous coûte.
    Style une personne téléphone pour un souci, on passe le développeur, on essaie des trucs... Tout ça paraît faire partie des petits à côtés quotidiens mais cela peut finir par chiffrer assez sec.

    Résultat, chez mon précédent employeur nous avions décidé que dorénavant les appels de support seraient mentionnés dans un document par tranche de 15 minutes arrondis au dessus avec le nom du client concerné (sauf si vraiment c'est la bricole qui prend 1min).
    A cause des observations que nous avons faites alors, nous avons décidé de modifier le contrat de maintenance pour passer de support illimité à "juste" 1/2 journée gratuite par année. Car si on prenait toutes les questions qui auraient été répondues en lisant le manuel ou en demandant au collègue à qui on avait déjà expliqué en détail, on avait des gens qui nous coûtaient 3 à 5 fois le prix du contrat de maintenance. Dès que cette limitation du crédit temps a été introduite, les clients à problème ont soudainement cessé leur recours quasi-systématique au support et le contrat de maintenance est redevenu profitable.

    Bref, maîtriser les coût est indispensable dans la majorité des cas. Après obliger le développeur à justifier toute sa journée, c'est peut être quelque peu contre productif car il risquerait de se mettre à faire des mauvaises économies (négliger un peu le test) qui nous retomberaient dessus ou alors s'il règlerait plus rapidement que prévu un souci, d'allonger ses pauses clopes ou de ventiler le temps gagné sur autre chose ce qui tuerait le concept. Sans compter que ça entraînerait des réfléxes défensifs, comme doubler ou tripler le temps réel lorsqu'ils évaluent la durée d'un projet, donc on s'en sort pas toujours gagnant.

    Pour ce qui est du temps passé *sans produire*, un exemple bien connu d'un produit dont la boîte a coulé à cause du temps de support, c'est vistaDB en .net. Le produit coûtait quelque 300 dollars, le support gratuit pour les souscripteurs était illimité et fait aux US, ben ça leur a été fatal. Ce n'est pas une déduction que j'ai faite, c'était le propriétaire de la société qui le mentionnait clairement comme cause majeure de son échec sur son blog.

  5. #25
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 778
    Points
    1 778

    Par défaut

    Et si en premier lieu, le support, ce n'était pas les gens du dev, et que ça ne remonte à eux que si le problème le nécessite vraiment ?

    Même sans une petit boite, c'est justifié d'avoir une personne pour cela.

    Cette personne peut en effet reporter combien de temps elle a passé avec chaque client pour le contrôle des coûts. Mais le travail de dev n'est pas du tout compatible avec des interruptions répétées. Le coût, rien qu'en motivation/productivité dépasse largement le temps d'appel au client, même arrondis au dessus.

  6. #26
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 131
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 131
    Points : 9 089
    Points
    9 089

    Par défaut

    Ca dépend. Certains considèrent que c'est un choix judicieux, histoire de motiver les développeurs à améliorer leur bidule.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #27
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 778
    Points
    1 778

    Par défaut

    Tu as du tu tromper d'article. Le liens que tu fournis explique un fonctionnement similaire à celui que je décris.

  8. #28
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 697
    Points : 6 226
    Points
    6 226

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    Et si en premier lieu, le support, ce n'était pas les gens du dev, et que ça ne remonte à eux que si le problème le nécessite vraiment ?

    Même sans une petit boite, c'est justifié d'avoir une personne pour cela.

    Cette personne peut en effet reporter combien de temps elle a passé avec chaque client pour le contrôle des coûts. Mais le travail de dev n'est pas du tout compatible avec des interruptions répétées. Le coût, rien qu'en motivation/productivité dépasse largement le temps d'appel au client, même arrondis au dessus.
    Dans un monde idéal, effectivement il y aurait quelqu'un qui ne fait que du support, qui a les compétences techniques et le métier nécessaire qui filtre au moins le plus gros des demandes.

    Sauf que dans certaines structures, il y a juste pas assez de support pour justifier un salaire à temps plein, donc c'est un collaborateur qui s'en charge selon le schéma suivant :

    • La secrétaire ne connaît pas suffisamment le métier, ni le logiciel
    • Le commercial est soit absent en prospection, soit rapidement dépassé et il ne connaît pas toujours le logiciel en profondeur.
    • Le technicien s'y connaît en routeur et en système mais le métier c'est pas son fort.


    Et il reste plus que le développeur, qui connaît le métier ET le logiciel, sait distinguer une anomalie d'un comportement normal dû à une configuration foireuse etc...

    Mais bon à la décharge de tout ce petit monde, le support est très souvent un truc délicat. On peut certes investir dans une équipe qui fait que cela mais à partir de là les coûts augmentent autant pour le client que pour l'employeur avec les formations, les salaires etc... Au risque que le produit se retrouve niqué par rapport à la concurrence moins chère (car ce qu'un client demande très souvent c'est "combien?").
    On peut aussi essayer de le sous-traiter là où c'est pas cher comme le font presque tous les *gros* (Asie, pays de l'est) mais avec les risques qui vont avec.

    Ou alors on espère qu'il y en aura pas trop et on fait avec les gens qu on a sous la main. Il y a beaucoup de sociétés qui n'atteignent pas les tailles suffisantes pour avoir un support dédié.

    Enfin pour revenir au sujet, même en dehors des cas de support, nous avons besoin de maîtriser ce que ça nous coûte pour savoir où on va. Et cela concerne également (voire particulièrement) les prestations non facturées, typiquement mon entreprise offre les évaluations gratuites au client, ça nous demande du boulot, on veut savoir combien... C'est naturel.

  9. #29
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 131
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 131
    Points : 9 089
    Points
    9 089

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    Tu as du tu tromper d'article. Le liens que tu fournis explique un fonctionnement similaire à celui que je décris.
    Sauf que l'auteur, lui, trouve ce fonctionnement normal.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  10. #30
    Membre Expert Avatar de Kearz
    Homme Profil pro Rémi
    Etudiant - Dev. E-Commerce (Contrat pro)
    Inscrit en
    mai 2012
    Messages
    556
    Détails du profil
    Informations personnelles :
    Nom : Homme Rémi
    Âge : 22
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Etudiant - Dev. E-Commerce (Contrat pro)
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 556
    Points : 2 124
    Points
    2 124

    Par défaut

    Au choix:

    1-Très répétitif
    9h00 - 9h15: Allumer le PC. Démarrer tout les outils.
    9h15 - 9h30: Travail sur la X destinait faire Y
    9h30 - 9h45: Travail sur la X destinait faire Y
    9h45 - 10h00: Travail sur la X destinait faire Y
    10h00 - 10h15: Travail sur la X destinait faire Y
    10h15 - 10h30: Pause
    10h30 - 10h45: Travail sur la X destinait faire Y
    10h45 - 11h15: Travail sur la X destinait faire Y

    2-Précis
    9h00 - 9h15: Allumer le PC. Démarrer tout les outils.
    9h15 - 9h30: Travail sur la X destinait faire Y. Analyse du problème [...]
    9h30 - 9h45: Travail sur la X destinait faire Y. Choix de l'algorithme, initialisation des variables.
    9h45 - 10h00: Travail sur la X destinait faire Y. Erreur d'analyse, recommence.
    10h00 - 10h15: Travail sur la X destinait faire Y. Mise en place dans brique A, B, C.
    10h15 - 10h30: Pause. Toilette-Cafe
    10h30 - 10h45: Travail sur la X destinait faire Y. Test A,B,C.
    10h45 - 11h15: Travail sur la X destinait faire Y. Test D,E,F.


    Avec la méthode 1, c'est une perte de temps autant tout regrouper.
    Avec la méthode 2, et pourquoi pas coder directement dans la grille?

    Franchement je comprends trop l'intérêt. A la journée ou demi journée c'est compréhensible. (Pour savoir où en est le projet, ce qui a été fait, etc.)

    ça pourrait être utile pour les contrats de maintenances mais c'est pas précis non plus au final: tu passe 20 à régler le problème du client, t'en marque combien? 15 ou 30?
    Pour la maintenant, c'est mieux d'avoir un compteur et de dire: tel client, je viens de passer XX minutes.

    Bref,
    Contrôle des temps = normal
    Contrôle du temps tout les 15 minutes = flicage, outils de pression, stresse, pas bien, etc.

  11. #31
    Membre confirmé Avatar de Faereth
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Bâtiment

    Informations forums :
    Inscription : janvier 2007
    Messages : 92
    Points : 270
    Points
    270

    Par défaut

    Le contrôles des temps est important pour pouvoir évaluer le temps de développement de nouvelles fonctionnalités ou de corrections d'anomalies.

    Dans ma boîte on a un logiciel qui nous permet d'affecter un temps à des tâches qui nous sont affectées, temps que nous devons saisir à chaque fin de journée (normalement) pour avoir une synthèse en fin de mois du temps réellement passé sur tel ou tel dev.

    Au début je me disais, ouais pourquoi pas, cela peut être bien, et à la limite je comprends que ma boîte désire pouvoir mieux gérer ses coûts/temps de développement. Mais bon premier problème, ce logiciel découpe les journée en 1/8ème, 1/8ème qui équivaut à peu près à une heure... Bon déjà il faut commencer à feinter quand tu as des petits dev qui te prennent 5 minutes (genre corrections de mini-bug)... OK c'est pas grave, on nous répète que de toute façon cet outil c'est pour l'équipe pour que l'on puisse avoir une meilleur visibilité de qui fait quoi...

    On prenait une marge de 30% non affecté dans le mois, pour pallier aux-bugs-ultra-urgent-que-tu-dois-traiter-tout-de-suite... Mais bon il y en avait pas toujours (et heureusement ^^) mais du coup tu te retrouvais à ne pas remplir tous ton mois. Quand je n'ai plus de tâches, je cherche à aider des collègues, faire de la veille, etc...

    Mais un beau jour, un mois où tous mes temps n'étaient pas remplis, je reçois un mail de la DRH (dans ma boîte c'est une espèce de nébuleuse, tu ne sais pas qui ils sont mais eux savent ce que tu fais), me demandant ce que j'avais fais tel jour à telle heure et pourquoi cela n'était pas renseigné dans le logiciel. Et là j'ai commencé à me dire que le : "Cet un outil pour nous développeur, pour nous aider dans notre organisation" ressemblé à un gros flicage déguisé par la DRH.

    Résultat? Des collègues créent des tâches bidons pour saisir des temps dans cet outils alors que l'on travaille hein, mais quand tu passes du temps à former un nouveau et que tu n'es pas cencer le faire tu te fais taper sur les doigts... Alors tu commences à gonfler les temps de dev en prévision, etc...

    Moi je continue à laisser des mois "à trou" et ne me justifie pas. Pour le moment je n'ai pas eu de mauvais retour, mais je pense que ca va venir, et de toute façon j'ai de quoi leur répondre.

    Tous ca pour dire que bien géré je pense que la saisie des temps et une bonne chose, mais qu'il faut rester dans un aspect "humain", tu vas pas être efficace toute la journée, mais tant que le taf est fait...
    Un sage se distingue des autres hommes, non par moins de folie, mais par plus de raison.

    Emile-Auguste Chartier, dit Alain

  12. #32
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 052
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 052
    Points : 4 212
    Points
    4 212

    Par défaut

    Là où je bosse, je suis en moyenne uniquement à 50% de mon activité prévue la semaine précédente....

    Cependant j'ai toujours des tâches qui correspondent à mes activités réelles : formation, support fonctionnel, support Oracle, etc. Par contre la chose qui fait défauts ce sont les activités transverses, je dois les répartir sur les différents projets sur lesquels j'interviens.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  13. #33
    Modérateur
    Avatar de h2s84
    Homme Profil pro Holty Samba SOW
    Développeur .NET
    Inscrit en
    mars 2007
    Messages
    3 021
    Détails du profil
    Informations personnelles :
    Nom : Homme Holty Samba SOW
    Âge : 29
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2007
    Messages : 3 021
    Points : 5 847
    Points
    5 847
    Consultant .Net chez SoftFluent
    Découvrir notre produit CodeFluent Entities

    Adhérer à l'association Fier d'être développeur
    Les FAQ sur les technologies .Net voir ici
    Les cours et tutos sur les technologies .Net voir ici
    Les critiques sur les livres parlant des technologies .Net voir ici
    Pensez à la balise [CODE]
    Pensez au tag si votre problème est résolu

  14. #34
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 813
    Points
    12 813

    Par défaut

    Que je trouve (ainsi que la conclusion MIT/harvard) pas mal fausse...

    Car, basé sur des chiffres, ni Renault, ni André Citroen, ni Marconi, ni Bell, ni Ford, ni Jobs, ni Gates, ni Péladeau, ni aucun des grands entrepeneurs industriels n'aurait fait quoi que ce soit..

    Ils partaient tous perdants : petits, avec des concurrents gigantesques ayant l'oreille des gouvernants ou des autres grandes industries, avec peu - voir pas du tout - de moyens, pas de marchés.. Juste des idées, des passions, et 1 ou 2 copains même pas de la partie au max...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  15. #35
    Membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2012
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2012
    Messages : 30
    Points : 67
    Points
    67

    Par défaut

    Citation Envoyé par tssi555 Voir le message
    Bonjour,

    ....tenir à jour un fichier (excel) d'activités journalières 15 minutes par 15 minutes! de manière quotidienne...? .
    Selon le théoreme de Shannon sur l'échantillonnage, faire un relevé de temps toutes les 15 minutes suppose que la tâche ait une durée prévue (ou contractuellement planifiée avec la hiérarchie) de 150 minutes (2 h 30) et que le dérapage autorisé est de 15 minutes... et aussi que le manager n'ait pas plus d'un quart d'heure de retard (disons 5 minutes) lorqu'il viendra faire la recette de la fourniture.

    Dans ce contexte on peut admettre qu'un suivi au quart d'heure peut permettre de rectifier le tir pour éviter une livraison de la fourniture avec une demi heure de retard (ou une demi heure d'avance !).

    hors de ce contexte , c'est une connerie comme cela a déja été dit.

  16. #36
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 131
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 131
    Points : 9 089
    Points
    9 089

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Que je trouve (ainsi que la conclusion MIT/harvard) pas mal fausse...

    Car, basé sur des chiffres, ni Renault, ni André Citroen, ni Marconi, ni Bell, ni Ford, ni Jobs, ni Gates, ni Péladeau, ni aucun des grands entrepeneurs industriels n'aurait fait quoi que ce soit..

    Ils partaient tous perdants : petits, avec des concurrents gigantesques ayant l'oreille des gouvernants ou des autres grandes industries, avec peu - voir pas du tout - de moyens, pas de marchés.. Juste des idées, des passions, et 1 ou 2 copains même pas de la partie au max...
    Je pense que ce sont des choses différentes. L'intuition des dirigeants, ça joue sur la stratégie. Genre, je vais faire fortune grâce à un site web qui permet à une niche pauvre(les étudiants) de glander(Facebook).

    Le DDD, c'est un avantage tactique : est-ce que mon avion doit passer la nuit à Vancouver ou à Seattle, suivant les conditions météo? Ca ne permet pas de passer outre une mauvaise stratégie, mais, à stratégie similaire, ça permet d'optimiser les rendements. Sur des marchés à faible marge, ça peut être déterminant. Jobs ou Gates ont créé de nouveaux marchés, le DDD aurait été au mieux d'in interêt marginal pour eux. Pour Air France ou pour Wizzair, par contre, ça peut vraiment faire la différence.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •