Techno vs Livrable
Constamment confronté devant les deux aspects: Livraison en urgence et utilisation de la techno, je me questionnais à savoir pourquoi autant de projets informatique pouvaient souvent dépasser les délais, et même être abandonné. Est-ce là un problème causé par des chefs de projets trop ambicieux qui proposent des temps de livraison que les équipes de développement ne peuvent assumer ce sous des besoins fonctionnels plus ou moins clair ? Où est-ce que ce sont les équipes de développements qui s'attardent trop souvent à la beauté de l'utilisation de la dernière techno et de toute les "best practices" à la mode ?
Je crois que la prise de conscience doit se faire des deux côtés. Un bon chef de projet, sera à l'écoute de son équipe de développement, et saura bien guider son client afin de lui donner l'heure juste sur la charge de travail possible afin d'en arriver à répondre aux différents besoins du client.
Par ailleurs, une bonne équipe de développement, saura ce poser les questions suivantes: Qu'elles sera la méthode de travail qui nous permettra de pouvoir réellement fournir un gain sur l'échéancier du projet tout en livrant un produit de qualité ?
Ou est-ce que trop souvent les équipes tombent dans le piège de faire de faire de la techno pour faire de la techno sans ce préoccuper de répondre aux besions clients ?
Parallélisation du travail
Mon collègue
Alexandre Brisebois me fait souvent parvenir des articles fort intéressant sur divers sujets et aspects du métier de Consultant. Aujourd'hui, il me faisait parvenir un article traitant du
mythe de la parallélisation, écrit par LaurentLC.
Parfois dans notre métier de consultant, nous pouvons être vendu à la journée, à la tâche accompli ou même à la journée (basé sur 8hres de travail). En France par exemple, la norme est plutôt de facturer une ressource à la journée, d'où le terme: Jour-Homme. Dans la pratique réelle, souvent les journées dépassent largement les 8hres de travail, surtout lors des fins de projet sont a échéance, bref passont.
L'auteur de l'article y explique qu'en fait si une tâche de dévelloppement doit prendre 30 jours-homme à une personne, elle devrait en prendre 15 jours-hommes à deux personnes. Avec un raisonnement aiguillé sur cette forme de pensé, nous pourrions dire que si nous mettons neuf femmes enceintes en même temps, un enfant sous un mois. Dans le cadre d'un projet informatique, il est certe vrai qu'avec deux personnes se divisant les tâches, le terme du projet devrait venir plus rapidement, mais pas deux fois plus.
Ce qui semble être de plus en plus la norme chez les chargés de projets d'appliquer cette forme de penser. Dans un mode de fonctionnement de ce type, l'employé se rapproche à la machine et pourrait même devenir une immobilisation dans une ligne budgétaire au même type qu'une machine à fabriquer des pièces de métal.
Sauf que dans ce cas concret, imaginons que deux développeurs doivent livrer un projet dans l'urgence d'ici les 20 prochains jours ouvrable. Mais que les gestionnaires voulant être certains que le tout soit livré en temps et en heure, ajoutent deux nouveaux pigistes développeurs, afin d'aider les deux développeurs. Est-ce que le tout pourrait être livré en 10 jours ?
Non, plusieurs facteurs entre en ligne de compte: Le temps de formation des nouvelles personnes. Le temps d'adaptation au mode de travail entre les collègues. Le temps d'acquérir une sinergie entre les gens ne se fait pas en criant "ciseau", parfois une chimie entre des collègues de travail peu prendre quelques jours, quelques mois, voir quelques même années.
Selon vous, est-ce que trop souvent le facteur humain est oublié dans l'aspect d'évaluation des charges des projets informatique ?
Où est l'informations juste ?
Je me rappel bien qu'à un moment au début de ma carrière, à titre de Technicien Programmeur, certains employeurs désiraient couper l'accès à l'Internet. Un choix judicieux à cette époque ? Sans doute justifiable par le coût de la bande passante. Est-ce que nous pourrions imaginer à l'heure d'aujourd'hui de nous restreindre l'accès à l'Internet dans notre travail ?
La question ne se pose même plus. Avec la prolifération de l'informations depuis ces 10 dernières années, Internet est l'encyclopédie vivant du 21e siècles. Biensûr, on repassera sur les aspects moins utiles de l'Internet dans le cadre du travail. Au fil des années, nous avons développez nos propres méthodes d'archivage et de recherche de l'informations. Soit pas des agrégrateurs de flux, liste de diffusion, abonnements à des forums technique et/ou recherche et personnalisation de page d'accueil sur des portails de recherche.
Ce que j'ai souvent remarqué, c'est la quantité d'informations pour une recherche donnée sur un problème technique très pointue. Utilisant Google pour tout et n'importe quoi, je me lance à la recherche d'une ou des solutions à mon problème. Effectuant des contre validation de l'informations obtenue, je retrouve à 99.9% la solution à mes problèmes, mais parfois... non ? Que faire ?
Les resources sont disponible, il suffit de savoir s'en servir. Ressemment, faisant face à un problème de taille, je me suis inscrit sur un forum payant soit: Expert-Exchange.com. C'est un site spécialement dédié à la résolution de problèmes technique. Des experts/membres sont amené à soumettre des opinions réponses aux différents problèmes soumis. C'est sans aucuns doute le site d'informations le plus précis qui soit, mais que ce site soit payant, risque fort de me faire annuler mon abonnement d'essai de 30 jours. L'aspect qui est fort positif, c'est que l'informations et les solutions qui y sont posées sont vérifiés. Pour ma part, j'y vois un gain de temps considérable dans la recherche de l'informations juste.
Mais n'est-ce pas déjà le cas avec d'autres sites Internet du même genre, tel que: www.asp.net, msdn.microsoft.com, et j'en oublie plusieurs autres qui eux sont gratuit ?
La valeur d'un candidat ?
Qu'elle est ma valeur sur un marché ?
C'est une question que l'on peut souvent se demander, lorsque nous sommes en processus de recherche d'emploi, et même chez un employeur. Qu'elles sont les facteurs qui peuvent influer sur notre valeur sur le marché technologique. Comme une pièce de viande chez le marché, notre valeur flutuera en fonction de l'offre et la demande pour certains types de compétences technique, certe. Nous sommes loin de cette époque de bulle techno qu'il y avait jusqu'en 2001-2002.
Qu'est-ce que les compagnies recherche d'abords et avant tout d'un profil d'un programmeur ? Est-ce un candidat devant connaitre sans cesse les nouvelles technologies sous toutes ses coutures ? Ou plutôt un candidat ayant une connaissance général, maitrisant différent domaine d'expertise cerné et étant au fait des prochaines technologies ?
En ce sens, est-il juste de sans cesse d'exiger de la part de nos chefs de projets et de la direction que les projets utilisent les dernières techno, sous peine que l'équipe de développeur perdre de la valeur, sur un marché en constante évolution, au sens du sujet "Ressources Humaine" ? Tout est une question de rentabilité sur une période de temps estimé...
Je pose ces questions, parce qu'avec les dernières évolutions des languages de ces dernières années, il est facile d'être dépasser par ces connaissances. Est-ce qu'il est Humainement possible de nos jours de maitriser toutes les dernières évolutions d'un languages ou plutôt d'une technologie, ce tout en ayant une vie. Un des exemple que je puisse avoir est celui du passage .Net 2.0 à .Net 3.5. Microsoft avait fortement amélioré le .Net Framework et lancé de nombreuses nouvelles "façon" d'utiliser les possibilitées technologique.
Pour en revenir à la question de départ: Qu'elle est ma valeur sur un marché ?
Je dirais que notre réelle valeur sur ce marché, passerait par la combinaison de nos différentes expériences personnel et professionnel. En oubliant l'aspect des technologies, toutes ces expériences de vie (quotidienne et professionnel) forge un caractère et nous amène a penser d'une certaines façon dans notre travail, l'attitude. Des attitudes ou plutôt des aptitudes à l'ouverture d'esprit et la capacité de savoir remettre en question le travail et savoir comment faire face aux différents problèmes sans stress.
N'ayant pas la science infuse, le débat est ouvert...
Migration ERP
Bonjour à vous, je viens de passer les deux dernières semaines chez un client pour une migration de personnalisation d'un ERP version A vers une version B.
Plusieurs questions sont sur mes lèvres lorsque j'entame un projet de migration de version voir de ERP d'un Éditeur X vers Y:
- Qu'elles sont les types de modifications ayant été apporté à l'ERP en place ?
- De quelle façon mes modifications ont été mis en place ?
- Est-ce que les besoins doivent évoluer ou devront évoluer lors de la migration de la version de l'ERP A vers B ?
- De qu'elles façon le client veut-on procéder pour effectuer la migration ?
- Y-a t'il des procédures de migration déjà en place chez le client ?
- Doit-on mettre en place une stratégie et en établir les standards pour le client ?
Pour une première migration sur un environnement en clientèle, se sont ces points qui sont venue à mon esprit afin de mieux me positionner dans les prochaines semaines. Puisque l'on peut jamais prétendre a avoir une connaissance parfaite et que même le plus savant doit toujours apprendre de jours en jours, je développerai sur le sujet dans les prochains jours.