+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 12 PremièrePremière 123456 ... DernièreDernière
  1. #21
    Membre habitué
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    223
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 223
    Points : 196
    Points
    196

    Par défaut

    C'est souvent ca quand le client veut du résultat "visible", c'est pas évident de lui montrer du code ... Parfois je me dit qu'on est des incompris
    Quand c'est trop, c'est pas bon !

  2. #22
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 96
    Points : 91
    Points
    91

    Par défaut

    Bienvenu au club !

  3. #23
    Membre régulier Avatar de Anto03
    Inscrit en
    octobre 2005
    Messages
    153
    Détails du profil
    Informations forums :
    Inscription : octobre 2005
    Messages : 153
    Points : 82
    Points
    82

    Par défaut

    Intéressant comme sujet ! ça fait tellement peur que des fois on préfère en rire (avec le recul... beaucoup de recul).

    Pour ma part j'ajouterai "l'architecte fou" : l'architecte qui développe couche sur couche d'une grande complexité (ne fonctionnant pas mieux voir moins bien généralement) et qui démissionne... La complexité de la chose fait que personne ne peut reprendre l'existant et c'est le drame
    Antony, développeur .Net
    http://www.flecheinthepeche.fr/blog/

  4. #24
    Rédacteur
    Avatar de jsd03
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    août 2008
    Messages
    1 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : août 2008
    Messages : 1 220
    Points : 6 781
    Points
    6 781

    Par défaut

    Quand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà
    ça vient justement de m'arriver. Alors à quoi ça sert de refaire l'appli sinon de dépenser des milliers d'euro pour avoir quelque chose d'équivalent voir même de moins bien (sachant que la nouvelle appli n'a pas la même maturité que l'ancienne)... ça fait réfléchir quand même
    Google est ton ami mais ton voisin aussi

    Modérateur BI - Responsable Talend
    Mes tutoriels - FAQ Talend - FAQ SQL*Plus

    Avant toute chose : lire le mode d'emploi du forum et ses règles.
    Suivez @Developpez sur twitter !

  5. #25
    Membre habitué
    Profil pro
    Inscrit en
    avril 2008
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : avril 2008
    Messages : 91
    Points : 190
    Points
    190

    Par défaut

    Un jour les spécifications étaient celle-ci :

    Cela doit être beau et agréable à regarder !
    Uniquement cela !

    Donc j'ai renvoyé le mail avec ceci ...



    C'est beau et agréable à regarder non ?



    Ben ils n'ont pas trouvé cela drôle à Paris ...


  6. #26
    Membre habitué Avatar de zabibof
    Inscrit en
    février 2007
    Messages
    168
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 168
    Points : 187
    Points
    187

    Par défaut



    J'ai vécu un truc très similaire à celui raconté par pseudocode, vraiment dans le même style, résultat, jour après jour, on développe plus de bugs que de fonctionnalités

  7. #27
    Rédacteur

    Avatar de millie
    Profil pro
    Inscrit en
    juin 2006
    Messages
    6 937
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 6 937
    Points : 9 550
    Points
    9 550

    Par défaut

    Ou des POC/simples prototypes qui se retrouvent déjà à moitié vendu alors que c'était juste censé être un prototype jetable (notamment si le prototype est pas si mal que ça).

    Du coup, le code continue sur le code de l'ancien prototype au lieu de tout recommencer correctement car on met des délais intenables...
    Je ne répondrai à aucune question technique en privé

  8. #28
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 999
    Points : 15 976
    Points
    15 976

    Par défaut

    Citation Envoyé par millie Voir le message
    Ou des POC/simples prototypes qui se retrouvent déjà à moitié vendu alors que c'était juste censé être un prototype jetable (notamment si le prototype est pas si mal que ça).
    Déjà vécu aussi. Des commerciaux qui ont vendu un produit uniquement disponible en image de synthèse sur les plaquettes publicitaires.

    Du coup, le code continue sur le code de l'ancien prototype au lieu de tout recommencer correctement car on met des délais intenables...
    Grand classique ! Le prototype de R&D qui passe direct en Industrialisation après une courte pose au service informatique le temps de "finaliser le logiciel".
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  9. #29
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 4 983
    Points : 11 468
    Points
    11 468

    Par défaut

    Amusant à lire mais tellement vrai !!

    Ce n'est pas un hasard si 80% des projets informatiques sont voués à l'échec..

    Pour moi l'une des raisons les plus importantes et qui fausse tout dès le départ :

    - Le cahier des charges du client n'est pas un cahier des charges ... Quand on gratte un peu le client en fait ne sait pas bien ce qu'il veut. J'ai déjà eu à faire à un cahier des charges avec une diapo powerpoint !! C'est votre cahier des charges ? oui oui

    ++

  10. #30
    Membre chevronné Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    mars 2005
    Messages
    727
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : mars 2005
    Messages : 727
    Points : 2 234
    Points
    2 234

    Par défaut

    Bah encore ça va si on compare au cahier des charges sur un post-it
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  11. #31
    Membre à l'essai
    Profil pro
    Développeur informatique
    Inscrit en
    juillet 2009
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juillet 2009
    Messages : 17
    Points : 23
    Points
    23

    Par défaut Incroyable

    Bonsoir tout le monde

    le lien vers cet article m'a été envoyé par un Ex collègue, qui s'est fait licencier pour les motifs évoqués dans les diverses réponses ci-dessus.
    Ce que je trouve incroyable, c'est que nous devons tous bossé dans la même boite.
    La je suis en plein dedans, ce qui est effrayant c'est que ce sont toujours les mêmes qui morflent, et toujours les même qui tirent les marrons du feu, alors que ce sont eux les responsables du désastre.
    Tout ce que je viens de lire est exact (dans mon cas) pourtant nous ne sommes qu'une petite boite de 35 employés, mais nous sommes gérés comme si nous étions une multinationale, avec cadre, super cadre, comité de direction etc, et ou est l'organisation dans tout ça ??, le cahier des charges (c'est le rouleau de PQ), les Specs (ça marche au téléphone) et de toute façon tu les comprend pas ( en fait le mec qui te les dit comprend pas ce que son client veut).
    Alors a part continuer en se disant "Après moi le déluge", monter sa boite, chercher une bonne boite (28 ans que je cherche) que faire???
    si quelqu'un à une idée a faire partagé je suis preneur.

    Bonsoir a tous

  12. #32
    Membre éprouvé
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 640
    Points : 1 065
    Points
    1 065

    Par défaut

    Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  13. #33
    Membre régulier
    Inscrit en
    juillet 2005
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : juillet 2005
    Messages : 94
    Points : 78
    Points
    78

    Par défaut

    En fait, on est pas tous dans la même boite, mais on fait tous le même métier ^^

    Les spécs ça m'as toujours étonné aussi, les faire en parallèle des dévs, après les dévs, voire jamais... c'est comme si un architecte faisait son plan après la construction.

    Je vais parler de ce que je connais, c'est à dire le développements d'application web, j'ai l'impression que l'informatique est un monde que vie en autarcie, il y a des gens qui créer des frameworks, censé simplifié la création de nouvelle application, mais au final souvent complexe, demandant de solide formation et de l'expérience.
    On les met en place dans de nouveau projet(souvent parce que c'est vendeur d'utiliser tel ou tel techno), et on se rend compte (toujours après coup) qu'au vu de la taille du projet, qu'on a galèré à l'utiliser, on a fait plein de contournement parce que ça faisait pas exactement ce qu'on voulait, ça engendre plus de bug, ça engendre des problèmes de performances... etc.
    C'est le ressenti que j'ai après 3 ans de développement, mais cela ne tient peut être que de mon expérience.

    Mais si on prend du recul (beaucoup de recul) le temps qu'on perd a développer, souvent plus que prévu, fait qu'on a du boulot ^^ et qu'on est payé au temps passé, pas au temps perdu (heureusement)

  14. #34
    Rédacteur
    Avatar de benwit
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 1 676
    Points : 3 671
    Points
    3 671

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
    Il existe des entreprises où :

    Les clients savent ce qu'ils veulent et font un cahier des charges très exhaustif.

    Les chefs de projets estiment correctement les ressources nécessaires pour le périmètre fonctionnel à accomplir ...

    Les chefs de projets arrivent à convaincre le client de restreindre son périmètre, d'augmenter les délai et/ou son budget

    Les développeurs peuvent choisir les technologies qu'ils veulent car ils ont le temps de faire de la veille, de recevoir les formations qu'ils souhaitent

    Les clients testent sérieusement l'application durant la phase de recette et exprime clairement les petits problèmes rencontrés

    Les clients ayant clairement défini ce qu'ils voulaient, il n'y a pas de mauvaise surprise.
    Et lorsqu'ils ont oublié un petit truc qui paraît plus grave à leurs yeux qu'à ceux des développeurs qui n'en auront que pour quelques secondes à le corriger, ils ont tellement honte qu'ils vous amènent des croissants chauds ...


    ....



    et là, je me réveille !

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  15. #35
    Membre confirmé Avatar de ypicot
    Profil pro
    Inscrit en
    mai 2004
    Messages
    400
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : mai 2004
    Messages : 400
    Points : 547
    Points
    547

    Par défaut

    Ben à lire ca, je suis content d'être indépendant.
    Ma spécialité, c'est le petit projet, de 1 jour (si si, ca existe) à 3 mois, pour ne seule personne, éventuellement 2 si ca tape en partie sur un domaine que je connais mal.

    Je suis en direct avec le client, ou bien je passe par une SSII qui me laisse dialoguer avec le client et me laisse gérer ma barque (ce sont des conditions sine qua non). Cela évite 2 des principaux écueils cités : un service commercial qui transmet (mal) les demandes du client, et les chefs arbitraires et incompétents. Par contre, je me cogne les changements d'avis du client, ou le CdC powerpoint (que je préfère renommer en "expression des besoins").

    Bien sûr, j'ai des sueurs froides, mais pas les mêmes qu'un salarié (client qui dépose le bilan, ou bien variation très importantes dans le revenu : -45% entre 2007 et 2008)

    En fait ma question est celle-ci : je pense qu'il y a un rapport direct entre la taille du projet et les problèmes générés. Ce n'est pas visible à mon niveau, mais est-ce que certains pourraient confirmer / infirmer ce point ?

    Yvan
    Une solution n'est valable que dans un contexte donné

  16. #36
    Membre éprouvé Avatar de 10_GOTO_10
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    802
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2004
    Messages : 802
    Points : 1 182
    Points
    1 182

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
    Non. Des fois c'est pire. J'ai vu:

    La "maquette" présentée aux clients, qui était en fait un fichier PPS, avec des screenshots bricolés avec paint shop pro. Et fait pas une ligne de code n'avait encore été écrite.

    Le commercial et le patron qui impose à l'équipe de développement les outils à utiliser (et pas les moindres: l'EDI de développement). Bien sûr, ni l'un ni l'autre n'ont de connaissances en informatique.

    Le commercial (le même) qui vend des nouvelle fonctonnalités aux clients avant même que ce soit développé (et avant même de savoir si c'est faisable). Démerde-toi après à développer ça. Il faut que ce soit fini pour vendredi.
    Sondages gratuits : Le troc d'opinions

  17. #37
    Membre chevronné
    Avatar de stailer
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2003
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

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

    Informations forums :
    Inscription : mars 2003
    Messages : 1 105
    Points : 2 092
    Points
    2 092
    Billets dans le blog
    3

    Par défaut

    « Décembre!!! », hurle BB. Les personnes baissent leur tête comme s'il leur pointait un fusil d'assaut vers eux. « Décembre est absolument hors de question. Chefs d'équipe, je veux de nouvelles estimations sur mon bureau pour demain matin. Je déclare dorénavant les semaines de 65 heures obligatoires tant que ce projet n'est pas fini. Et il a intérêt à finir pour le 1er novembre! »
    Moi je baisse pas la tête... je l'attends à la sortie, quand c'est un "mec comme tout le monde" et je lui explique ma façon de voir les choses.
    Je me fais virer, mais on me parle pas comme ça... Et ce serait bien que personne ne se laisse parler comme ça, que personne ne baisse la tête et que tout le monde se lève pour lui expliquer la vie.

    Mais ça... c'est l'esprit d'équipe, et dans vos grosses boites, on connait pas trop
    .o0o__St@iLeR__oOo.

    Chef de projet / Développeur

    ASP.NET MVC - MCP/MCSD ASP.NET
    PHP Zend Framework
    Cordova IOS/Android
    Kendo UI - ExtJS - JQwidgets
    SQL Server / MySQL

  18. #38
    Membre régulier
    Inscrit en
    juillet 2005
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : juillet 2005
    Messages : 94
    Points : 78
    Points
    78

    Par défaut

    Citation Envoyé par ypicot Voir le message
    En fait ma question est celle-ci : je pense qu'il y a un rapport direct entre la taille du projet et les problèmes générés. Ce n'est pas visible à mon niveau, mais est-ce que certains pourraient confirmer / infirmer ce point ?
    Pour moi il y a un rapport direct, entre la taille d'un projet et les problèmes, surtout si le nombre développeur sur le projet est important.
    Imaginons que sur un projet de 2 personnes, un problème est détecté, que un des développeurs prend un jour de retard, cela retarde de 1 jour le second développeur s'il est dépendant des dévs du premier.
    Prenons maintenant un projet de plusieurs dizaine de développeur, même situation, un problème est détecté et un des développeurs prend un jour de retard, si dix personnes sont dépendantes des dévs de celui-ci, on a 10 jours de retard... (c'est une explication simpliste, mais ça met en évidence ce qui peut se passer)
    C'est là la difficulté des grosses équipes, rendre les développements les moins dépendants des autres pour éviter ce genre de situation.

  19. #39
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 048
    Points : 1 617
    Points
    1 617

    Par défaut

    Quand le client n'a pas de culture de projet ça veut dire quand tu lui envoie les specs pour validation, il t'appelle et te dis bah moi je valide pas ça, ce que je veux c'est voir une 1ere version dans laquelle je peux valider le fonctionnelement de l'appli.
    Ce n'est pas complètement stupide. Le client, ce qu'il souhaite au final, ce n'est pas un bout de papier lui expliquant comment fonctionne le logiciel, mais un logiciel fonctionnel.

    Je commencerai par dire que je reconnais ma situation dans tous ces témoignages, en affirmant que malheureusement, c'est une terrible fatalité. La (trop) faible percée des méthodes agiles ces dernières années ne permet pas de changer les mentalités en profondeur. Trop de gens sont encore persuadés qu'un projet logiciel se construit comme une maison, avec d'abord des plans, des fondations, le terrassement, etc. Il n'en est (presque toujours) rien. Le malheur, c'est que beaucoup de gens le savent (beaucoup d'autres l'ignorent aussi), mais ne veulent pas changer les habitudes de travail, et de son côté le "client" ne veut pas faire l'effort de s'intégrer dans le déroulement du projet, dans lequel il tient pourtant un rôle central.

    Je ne prendrais qu'une sous-partie d'un projet comme exemple : celui du cahier des charges, considéré comme l'élément indispensable par tous, et quasiment toujours responsable des échecs. Dans le déroulement d'un projet "construction de maison", les développeurs ont besoin du cahier des charges pour analyser d'abord, puis concevoir et enfin développer... Le problème c'est que : le client ne sait pas exactement ce qu'il veut, et même s'il le sait, est-il en mesure de le coucher sur papier ? EN admettant même qu'il soit suffisamment explicite, l'équipe de développement sera-t-elle à même de le comprendre ? D'implémenter exactement les bonnes fonctionnalités ? De décrypter la vision du client ?

    Tellement d'études démontrent que cette approche de projet est erronée dans 99% des cas. Ces études mettent en corrélation ces évidences (vos témoignages apportent encore des preuves !), à savoir que le taux d'échec est très élevé dans les projets gérés "en cascade" (mode construction de maison). Un jour, j'ai expliqué à mon boulot comment les méthodes agiles permettaient de résoudre une grande partie de ces problèmes, bien que n'étant pas la panacée. On m'a répondu : "commençons par travailler en mode projet" (extrait texto des bouches des décideurs). Au secours. Désarroi. Le mode projet, ça veut dire quoi exactement ?

    Le jour où les décideurs, mais aussi les équipes de développeurs/architectes/chef de projets, prendront conscience que les échecs ne sont pas dus à l'incompétence de leurs équipes de développement ou au client qui fait des caprices du genre "je veux voir un logiciel fonctionnel pour valider" (ce qui est parfaitement légitime, c'est ce pour quoi il paie !), et que le principe de base de réussite d'un projet, la COMMUNICATION, sera l'élément central de tout projet, alors on (tout le monde d'ailleurs) vivra des jours meilleurs.

    Je finirai en citant Alistair Cockburn : "Le développement de logiciel est un 'jeu collaboratif' dans lequel les participants utilisent des marqueurs pour se souvenir, se stimuler et s’informer mutuellement au cours de chaque mouvement du jeu. La fin du jeu est la 'production' et le 'déploiement' d’un système ; le résidu de ce jeu est un ensemble de marqueurs destinés à informer et assister les joueurs dans la partie suivante qui consiste à modifier le système existant ou à produire un système similaire." Le titre d'un de ses livres est : "Agile software development : the cooperative game", livre dans lequel il décrit cette activité comme "a cooperative game of invention and communication". Je conseille à de nombreuses personnes de méditer sur cet aspect (j'y médite toujours moi-même...).

    Pour terminer, je précise qu'il n'y a aucune forme d'arrogance, de mépris ou de complexe de supériorité dans me propos. Je tiens juste à ouvrir un champ de réflexion nouveau, fort intéressant (je conseille la lecture du manifeste agile - agile manifesto -) à ceux qui ignorent de quoi je parle. En référence, documentez-vous sur des méthodes telles q'Unified process, Scrum, XP, Crystal. Je vous garantis que vous y trouverez des solutions à tous ces problèmes. Après, et c'est la tâches sans aucun doute la plus difficile, il vous reviens de convaincre et de changer les mentalités. Après avoir vous-mêmes été convaincus (ce qui, je l'avoue d'expérience, est franchement pas simple).
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  20. #40
    Membre éprouvé
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 640
    Points : 1 065
    Points
    1 065

    Par défaut

    Dans ma boîte, le commercial, que le projet marche ou pas, il ne s'en fou qu'à moitier, les com des différents paiements sur différents lots sont déjà tombés. Donc on vend, c'est le principal, après la faisabilité c'est pas son problème, si le projet réussit, ça ne fera que plus d'argent dans sa poche, s'il échoue, ça fera toujours plus que s'il était réaliste et que le client refuse. Surtout que sa com porte sur le prix de vente, et non sur le bénéfice, c'est à dire que s'il vend pour 1 millions d'euros, que ça nous a couté 1,2 millions d'euros à développer, il aura toujours sa com sur un pourcentage de ce qui a été vendu, dans mon cas 10% de la vente soit 100 000 €, ce qui fait passer la perte de 200 000 à 300 000 euros sur le projet. Il ne va pas s'en plaindre, la différence tombe dans sa poche...

    J'ai pas mal entendu parler des méthodes agiles, pour casser le mur commercial entre le client et l'éditeur afin d'avancer communément vers un objectif commun et pallier ensemble aux problèmes.
    Est-ce que ces méthodes sont en voie de développement ou la croyance envers la rentabilité et les indicateurs prime ?

    J'ai remarqué également un autre "fléau", celui ci interne. C'est cette peur qu'un employé apporte quelque chose afin que l'entreprise devienne dépendant de ses travaux et que par conséquent celui-ci devienne indispensable et garantisse sa sécurité d'emploi. De ce fait, l'entreprise n'est ouverte à aucune proposition des "ouvriers", créative ou non, évolutives ou non, rentable ou non, et en reste à ses méthodes soit disant "fiables". Vous avez déjà rencontré ce genre de problème ?
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

Discussions similaires

  1. Un URL qui ressemble a un GET alors que c'est un POST
    Par neoncyber dans le forum Formulaires
    Réponses: 2
    Dernier message: 27/05/2007, 18h20
  2. Réponses: 5
    Dernier message: 14/04/2007, 18h47
  3. Réponses: 10
    Dernier message: 21/03/2007, 18h11
  4. Réponses: 4
    Dernier message: 17/10/2006, 08h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo