Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

  • Croire que c'est pas grave

    Une diférence entre l'exploitation d'un site web en B2C par rapport au B2B réside dans le niveau de confiance que le client peut avoir.

    Prenons l'exemple de failles de sécurité : c'est un problème grave qu'il faut absolument corriger.

    D'une manière générale, faire confiance sur internet est difficile et des sites buggés et peu fiable il en exsite à la pelle. Seulement en b2b l'exploitant prend seul la responsabilité, et le danger est souvent restreint à l'infrastructure et au données éventuellement stockées des utilisateurs. La plupart des services web sont modestes en visiteurs, en revenus, donc en ressource.

    Quand on travaille en B2B2C (les services de forum sur les sites web des média tv ou papiers), le client payant un service à l'utilisateur finale, le livrable est un contrat de confiance. Le fournisseur ne peut pas ignorer les vis de fonctionnement, ni les failles de sécurité. S'il s'agit d'un client grand compte il aura d'autant plus de facilité à se retourner qu'il a de moyen de faire pression. Son image est en jeu, il n'aura aucune pitié.

    Il y a quelques années, j'avais installé le soft de ma société sur l'infrastructure d'un client. En général, l'hébergement restait dans notre périmètre de sorte que nous maîtrisons mieux certains paramètres. Une nouvelle version logicielle était mise en place car nous avions passé l'applicatif de php4 à php5. Pour limiter les coûts et éviter de déployer le soft et réinstaller les serveurs à quelques mois d'intervalle, nous avons livré la nouvelle version tout juste terminée (fonctionellement oui mais tous les tests de sécurité non). Ils étaient content mais une fois notre job terminé, le client a commandé un audit de sécurité. Toutes les failles de sécutité ont été corrigées en une semaine, mais la négociation commerciale qui s'en ait suivi à été très houleuse (pénalité, ...).

    Depuis, quand je suis sur un nouveau projet, je fais des tests, et à tous les coups, je trouve quelques choses. Depuis quelques temps, j'ai élargis les vis de sécurité à tous les vis fonctionnels (bugs critiques) de sorte d'évaluer de manière binaire ce qui marche vraiment sur un service web... Seule 30% des projets informatiques sont des succès (répond au besoin, à été livré à temps en respectant le budget) d'après une étude récente, maintenant, je le comprend.

  • Les courriers électroniques

    A l'occasion d'un changement d'ordianteur, j'ai réinstallé ma messagerie et voici quelques statistiques sur 3 semaines :

    • nombre d'emails traités : 1333 soit 89 emails par jour
    • nombre de clients : plus de 35 dossiers clients différents dont un dossier qui qui apporte plus 10% des emails

    Je n'ai pas le temps de faire le tour des stats qui me semblerais intéressantes de détailler mais celle-ci ammène plusieurs réflexions.

    90 mails par jour sur une journée de 8 à 10h, ça fait un mail toutes les 6 minutes en continue qui arrive et demande de l'attention, de juger s'il faut traiter à l'instant ou non, ... A mon sens cela fait beaucoup, voire trop. Pour être franc, certain mail sont lu en diagonal.

    Globalement, cela veut dire qu'une journée est constamment en poitillé à telle point que certains jours je suis obligé de ne pas recupérer mes mails le matin pour me permettre de me concentrer sur un dossier. Il n'est pas rare non plus de s'apercevoir que la journée peut commencer à 18 heure pour la simple raison que le flot de mails se ralenti !

    Je m'aperçois également de plusieurs difficutés pour une équipe produits et projets :

    • envoyer un mail qui pourrait attendre parasite la concentration d'un développeur.
    • un chef de projet a pour job de qualifier les emails des clients. Un transfert sans explication n'apporte aucune valeur ajoutée.
    • le fait de faire un mail ou un transfert est une manière de se dégager du problème : la balle n'est plus dans mon camp. Or ce qui est important c'est d'assurer le suivi du mail ou du dossier. Stratégiquement, il peut être intéressant d'utiliser cette méthode dans le cas d'une validation, cela peut permettre de gagner du temps, mais en général il faut savoir relancer.

    Exemples de solutions pour adapter sa communication à son besoin :

    • mettre en place un tableau visuel des taches à faire (kanban, excel, ...) peut permettre d'éliminer une communication par email mal appropriée
    • passer par de la messagerie instantanée ou un coup de téléphone pour tracker un sénario utilisateur qui mène sur un bug est plus simple que de se comprendre par email ... (ping-pong)
    • imposer à ses collègues de mettre dans le titre du mail "[nom du client]" permet de cibler directement le mail.

    Il existe des tas d'astuces pour améliorer la fluidité de la transmission d'informations (vous pouvez en ajouter dans les commentaires). A mon sens, la maitrise des outils de communicatione est primordiale, passé un certain volume d'échange.

  • L'histoire du con qui dit "non"

    Dominique84124605287775_gros.jpg

    - Vous connaissez l'histoire du con qui dit "non" ?

    - Non !

    Et voilà le piège s'est refermé.

    Attention : l'humour de cette introduction est là pour présenter le côté délicat de certaine situation de gestion de projet pour lequel il est nécessaire de flairer le chausse trappe... pour ne pas passer pour un con. Quant à l'illustration, j'aime beaucoup Geluck et son chat !

    En tand que fournisseur de service web, vous avez déjà travaillé comme prestataire d'une webagency elle-même missionnée par une agence de communication sous-traitante d'une agence de relation publique qui répond à l'appel d'offre du client final ?

    Ca aussi c'est un peu une histoire à la con, mais quand on gère un tel projet, il y a plusieurs dificultés :

    1. L'accès au besoin du client final est difficile. Au moins un des acteurs de la chaîne doit trancher pour le client car il a pas l'info, ou qu'elle n'est pas remontée jusqu'à lui. Bref la communication avec autant d'intervenants c'est pas simple.
    2. Le client remonte des infos, mais il a l'impression de ne pas être entendu. Le prestataire final ne reçoit aucun signal, il a l'impression d'avoir des fourmies dans les jambes, juqu'à ce que le client se mette à râler à force de ne pas se faire entendre.
    3. Il est difficile de voir le périmètre de la webagency et celui du prestataire, fournisseur de service. En général, le fournisseur de service réalise peu de travaux spécifiques mais est tributaire de la réalisation de la webagency qui elle s'occupe du projet spécifique. Si la webagency ou le fournisseur de service se "plante", le client ne sera pas content.
    4. C'est un projet qui prendra plus de temps qu'un projet où le client est en contact direct. La récolte des "entrées" nécessaires au démarage du projet doit passer et être validée par toutes les mains. Les conf call avec la webagency qui ne maîtrise pas le produit que vous commercialisez gaspillera du temps à l'équipe technique qui devra assurer le débug de l'application de la webagncy.
    5. Si un maillon de la chaine coule, c'est tout le monde qui plonge, chacun rejetant la faute sur l'autre.

    Pour maîtriser un tel projet :

    1. Essayer d'avoir accès à un contact chez le client final pour recueillir son sentiment tout au long de la mise en place du projet.
    2. Travailler avec une webagency avec qui on a déjà travaillé est un plus. On a pas toujours le choix, mais parfois il peut être orienté par "copinage", pourquoi s'en privé.
    3. Une attention partculière doit être fourni par le chef de projet qui doit analyser le moindre signal. Un chef de projet sénior n'est pas un luxe.
    4. Le prestataire de service maîtrisant son produit se doit d'apporter un conseil en intégration irréprochable auprès de la webagency. Mieux vaut se froisser avec l'équipe technique de votre partenaire, en la bousculant un peu, plutôt que gérer un client mécontent. Mais il faut être filou pour ne pas se faire taxer d'ingérence !
    5. Une documentation complète, des procédures claires et un formalisme rigoureux assureront vos arrières ! En pratique, valider les conf call par un compte rendu envoyé par mail ou la rédaction d'un rétroplanning avec les éléments attendus montrera que vous maîtrisez le projet et les délais, que vous êtes sérieux et irréprochable.

    Ne le regrettons pas, ce sont ces situations périlleuses qui font la joies de l'entreprise et du web !

  • La solution à bascule

    shadok-probleme-solution.jpgCette solution, je l'ai déjà un peu abordé. Vous savez, la solution a bascule, c'est la fausse bonne solution, celle dont on croit que l'on penche d'un côté alors qu'un petit vous a fait basculer de l'autre côté.

    Exemple :

    Vous avez développé votre service web et avez besoin de mettre en place une solution d'authentification centralisée car d'autres clients utilisent votre service. Comme votre projet doit être livré hier (ce n'est pas une faute de français), vous montez en vitesse une solution opensource qui existe et pas trop mal documenté. Vous tombez sur SAML avec un truc tout fait en java, alors que le reste est en PHP, mais bon, c'est déjà fait alors vous croyez gagner du temps. Mais là, catastrophe, c'est trop lourd, mal adapté, vos clients galèrent pour mettre en place votre système ... Alors vous décidez d'assouplir quelques règles de sécurité, ou "bidouiller" dans le coeur de l'outil pour simplifier ce que vous n'avez pas le temps de comprendre.

    C'est un exemple flagrant où détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Ça vous le saviez déjà car je vous l'avais dit !

    Mais alors comment s'en sortir car on a tous envie de ne pas réinventer la roue à chaque fois. J'ai deux exemples qui me viennent naturellement en tête qui soutiennent activement des projets open source en participant à leur développement.

    1°) Synfony reprend Swift Mailer et intègre des éléments développés pour dailymotion dans sa version 2.0.

    On pourrait dire que l'on a à faire à du partage de connaissances Open Source. Finalement là où les compétences sont rares, se serrer les coudes en mutualisant ses développements peut être d'un vrai intérêt. Pour éviter l'écatombe de l'exemple précedent, Synfony a décidé d'adosser synfony sur un autre projet tel que Swift Mailer, Doctrine, ... Il intègre la communauté de développeurs légèrement démotivé (sic), devient maître de la road map sans tout redévelopper de zéro. Belle opération pour la communauté.

    2°) CNet développe le moteur de recherche Sol'R

    CNet a choisi Lucene / Sol'R et enrichi le projet Open Source de moteur de recherche Sol'R pour en faire un des meilleurs ! Sa technologie de "facet" permet de faire des affinages par fitre, ...

    3°) J'étais récement en contact avec une entreprise qui utilise aujourd'hui Piwik comme solution de statistique web via des API. Le problème, c'est que passé un certain trafic, Piwik ne tient pas la charge. Plusieurs hypothèses :

    • Développer son propre outil, mais ce peut-etre long.
    • Utiliser un autre outil, mais cela peut couter chère.
    • Contribuer / investir dans un projet open source.

     

  • Les Temps Modernes informatisés

    C'est vendredi alors petite vidéo pour introduire le thème.

    Quand on dispose d'une chaîne de production de sites internet, comme c'est le cas des start up qui disposent d'un parc de plate-forme en modèle SAAS (OVH par exemple), il est difficile de distinguer clairement le produit du service, d'autant plus si le produit est un service. Pour un ingénieur en mécanique comme moi, il faut une bonne dose d'immersion virtuelle pour définir les contours d'un produit complètement immatériel. Quel idée saugrenue, aussi ?! Disons que pour auditer une chaîne de production, il faut bien commencer par un bout.

    Adapter la chaîne de production au produit :
    Prenons l'exemple d'un produit chargé de délivrer des mails, le besoin est que le destinataire soit informé du contenu du mail. Dans certaines entreprises, la secrétaire imprime les trois emails reçus par semaine et les présente sur papier au patron. Le contrat est remplit de manière efficace. Prenons maintenant le produit GMail, disons que je vois mal une armée de petites mains faire le facteur des millions de mails des utilisateurs.

    Pourtant, il est rare de constater que la mise en place de la chaîne production soit parfaitement adaptée aux contraintes que le produit et ses développements vont imposer (par exemple la communication auprès des clients que telle fonctionnalité est mises à disposition, son déployement à travers les environnements de travail ou la customisation aux couleurs du client). Pourtant, on aurait pas idée de construire la Citroen C3 sur la même chaîne de production que celle d'une 2CV. Et pour reprendre le film de la naissance d'une voiture, la chaîne de la citroen C3 a tourné 6 mois à vide sans voiture, juste pour répéter les gestes et prévoir les moindres défauts. C'est pousser l'anticipation à l'extrême ? Oui, et alors, faut-il le regretter ?

    C'est justement en intégrant les contraintes de la chaîne de production que l'on gagne l'efficience. Des amis m'ont dit la semaine dernière qu'il faisait construire une maison en bois. Ils font confiance au charpentier, qui fait son devis sans étudier à fond le dossier. Au moment du montage il s'est aperçu que son atelier était trop petit pour monter l'assemblage ! Il a dû louer un atelier pour les travaux. Je doute que le projet ait été rentable pour le charpentier. Quel gaspillage !