Bonjour,

Aujourd’hui et depuis toujours, je travaille dans l’univers du web/digital.
Ma société est éditrice d’un logiciel mais n’est pas une référence dans le marketing. Et pourtant lorsque l’on est spécialiste du web, faire appel à une agence webmarketing est-il une hérésie ?

Web-marketing

Certains pensent que oui, pour plusieurs raisons :

  1. Nous sommes spécialistes du sujet, pourquoi ne pourrions-nous pas le faire nous-mêmes ?
  2. Pourquoi devrais-je dépenser des sommes folles dans des agences externes, que ce soit des agences marketing généralisées, des agence seo, des agences dédiées au contenu, etc. alors que je peux recruter un responsable marketing ?

Mon expérience (10 ans dans cet univers) montre qu’on ne sait malheureusement pas tout faire et que même si on est touche à tout, on ne peut pas exceller dans tous les domaines.

Tout d’abord, il faut que la société reconnaisse l’importance du marketing. Un marketing sous-estimé (comme je l’ai trop souvent vu), mène à une communication qui peut être désastreuse, un manque de visibilité évident, et donc une crédibilité très limitée.
Lorsqu’une société désire acquérir des leads, il lui faut un marketing au top !

On dit souvent qu’une société qui démarre devrait consacrer 25% de ses ressources financières au marketing, et c’est bien vrai. A quoi sert d’avoir un service innovant ou un logiciel parfait si personne ne l’utilise ou ne le connait.

Alors que faut-il faire ?

Si vous avez une idée claire du webmarketing, de ce qui doit être fait pour attirer vos clients (SEO, Adwords, Campagnes mails, site web, contenu, etc.), alors vous pouvez le gérer au sein de votre société, mais dans le cas contraire, je pense qu’il est préférable de faire appel à une société qui fait ça toute la journée, qui en maitrise les enjeux, les aspects et qui connait les tendances actuelles.

Faites le test, au moins au début, il sera toujours temps d’arrêter lorsque vous aurez acquis les compétences.

Ce billet de blog n’est qu’une accroche, je pourrais développer davantage l’univers du webmarketing dans ce blog, si cela vous plait.

Bien cordialement,

John Doe

Bonjour,

Parmi les précédentes boîtes dans lesquelles j’ai pu travailler, toutes offraient une ou plusieurs évaluations au cours d’une année. Pour certaines, une évaluation était faite tous les ans, dans la société actuelle, il y a deux évaluations par an.

A quoi sert cette évaluation ?

  1. Cette évaluation permet de faire un point sur les 6 ou 12 mois qui viennent de s’écouler. Que s’est-il passé de notable ? Combien de projets se sont bien déroulés ? Dans quelle humeur abordez-vous cette fin de période (satisfait, frustré, triste, fatigué, etc.) ? Etc. ?
  2. Cette évaluation est aussi le bon moment pour demander une augmentation, demander une prime exceptionnelle car vos rendements ont été exceptionnels, demander une formation (PMP par exemple -ceci fera l’objet d’un prochain billet-), etc.
  3. Cette évaluation est surtout le bon moment pour définir les objectifs de la nouvelle période et c’est justement l’objet de ce billet.

Lors de votre recrutement, votre employeur vous a fourni une fiche de poste contenant bien souvent des éléments comme :

  • Réaliser des prestations d’avant-vente ;
  • Mener un projet depuis la signature du contrat jusqu’à sa livraison ;
  • Etre garant de la satisfaction du client ;
  • Réaliser des formations utilisateurs ;
  • Mettre en place une conduite du changement ;
  • Etc.

Malheureusement, cette liste de fonctions est très longue et surtout ne permet pas réellement d’évaluer si vous faites du bon travail ou du mauvais. Certes, le mauvais travail se voit assez rapidement, mais le bon est plus difficile à déceler.

Il est important que des objectifs soient définis lors du recrutement et lors de chaque évaluation de période. En effet, une société ne peut pas attendre la même « chose » d’un employé qui vient d’arriver, d’un employé confirmé ou d’un ancien employé mais aussi du contexte dans lequel la boîte se trouve au moment de la rédaction des objectifs (beaucoup de backlogs à terminer, beaucoup de retard dans les projets, ou si au contraire tout va bien, etc.).

Quoiqu’il en soit, en tant qu’employé, c’est votre droit (et même obligation) de demander des objectifs précis. Demandez à votre évaluateur de vous fournir des objectifs qualifié de SMART :

  • S : Spécifique
  • M : Mesurable
  • A : Acceptable
  • R : Réaliste (ou pertinent)
  • T : Temporel

Pour plus de détails, je vous renvoie vers la page Wikipédia correspondante.

Objectifs SMART

C’est un exercice difficile, surtout pour un chef de projet mais ce n’est pas forcément un exercice que l’employeur doit faire seul. Réfléchissez ensemble à une liste d’objectifs remplissants ces critères. Avec des objectifs clairs, vous saurez sur quels points vous devez accentuer votre travail et vos axes d’amélioration. Enfin, vous pourrez vous défendre plus facilement lors de votre prochaine évaluation.

Et vous, quels sont vos objectifs pour la prochaine période ?

Bien cordialement,

John Doe

Bonjour,

Il est important de prévenir ses clients lorsque l’on prévoit d’être absent pour plusieurs jours. Cela leur permet de s’arranger et de s’adapter. Personnellement, je préviens mes clients actifs lorsque mon absence dépasse 2 jours.

Pour éviter de perdre du temps, je me suis fait un template d’email que j’utilise tout le temps. Cela va plus vite de modifier un nom et ajouter des dates que de réécrire le tout à chaque fois. A noter que je vouvoie tous mes clients mais que je les appelle toujours par leur prénom.

Voici un exemple tout simple d’email que je pourrais envoyer (bien qu’en ayant un plus complet) :

Bonjour $Prénom $Nom,

Je serai absent du $date_debut au $date_fin.
Pendant mon absence et en cas d’urgence, vous pouvez envoyer un email à $Prénom $Nom : $adresse_email.

Cordialement,

Ce template est très minimaliste et vous autorise à l’alimenter en détails si vous le désirez, par exemple :

  • si vous partez en congés maternité ;
  • si vous êtes malade, vous vous faites opérer ;
  • si vous vous mariez ;
  • etc.

Cela dépend de votre relation avec vos clients.

L’important n’est pas de copier le template que je viens d’écrire (qui ne sera pas forcément adapté), mais d’écrire votre propre template et de l’utiliser à chaque fois pour gagner du temps.

Naturellement, cet email d’information ne remplace pas la réponse automatique à mettre en place lors de l’absence. Il n’est là que pour prévenir vos clients en amont. Ils en seront ravis.

Bien cordialement,

John Doe

Bonjour,

Aujourd’hui je souhaiterais vous parler de mon nouveau poste. Ayant changé d’entreprise, mon rôle dans ma nouvelle équipe est de suivre le développement d’un « logiciel » web. Pour ce faire, j’ai dû mettre en place une roadmap (processus toujours en cours).
Pour le moment, je me suis surtout appuyé sur mon expérience passée.

Succès d'une roadmap

Comment ai-je procédé ? Etant assez novice finalement dans ce domaine, si vous avez des remarques et des conseils, comme toujours, je suis preneur.

1/ Tout d’abord, j’ai étudié l’existant, de manière sommaire car mon manager était assez pressé.

2/ Il n’y avait pas de procédure de suivi des tickets et des commit (SVN, Git, etc.). J’ai donc écrit sur notre intranet la procédure à suivre quant au suivi des tickets. Mon but étant que tout travail doit être logué, tracké et donc faire l’objet d’un ticket. Nous utilisons un outil interne pour cela mais ma préférence dans les outils sur le marché vont vers Jira.
J’ai naturellement agrémenté mes procédures de schéma. Un apport visuel est toujours intéressant.

3/ J’ai ensuite réfléchi au cycle de développement de l’application. Entre la correction de bugs, les demandes d’amélioration prioritaires et rapides (hors roadmap) et les nouveautés liées à la roadmap, j’ai donc mis en place un cycle d’1 mois. Durant ce mois, les nouveautés liées à la roadmap ne pourront pas (ou peu) changer. Pourquoi 1 mois alors que les méthodes AGILE préconisent 2 semaines ? Tout simplement car je n’ai pas une équipe dédiée au projet…

4/ J’ai ensuite réfléchi au versionning de l’application, lié à la roadmap. Je me suis arrêté à 3 niveaux X.Y.Z :

  • X : Version principale de l’application. J’ai pris le parti d’1 version par an, en donnant un thème à cette version (sécurité, rapidité, nouvelle charte graphique, refonte du old core, etc.)
  • Y : Cette version est liée directement à la roadmap. Tous les mois, son numéro est incrémenté
  • Z : Cette version est donc liée à la correction de bugs et aux modifications rapides prioritaires

5/ Il est important d’avoir un roadmap meeting tous les mois. Ce meeting permet de confirmer les priorités de développement du cycle prochain (idéalement le meeting devrait se situer avant la fin du cycle en cours) et de définir les priorités du cycle suivant. Il permet aussi un retour sur l’actuelle version, sur les tests du précédent cycle.
N’oubliez pas d’avoir toujours un backlog à jour ! N’hésitez pas à demander à votre PO de le mettre à jour et confirmer les priorités !

Voilà le travail que j’ai effectué et qui semblait convenir. Cependant, une nouvelle est arrivée en cours de route, mettant en pause la roadmap… Du coup je n’ai pas encore de retour d’expérience de cette mise en place.

Bien cordialement,

John Doe

Bonjour,

Certaines sociétés ont une équipe dédiée à la recette des projets développés, d’autres non.
J’ai eu la chance (ou pas), de pouvoir tester les deux cas et chacun a ses avantages et ses inconvénients, sachant que les avantages de l’un sont souvent les inconvénients de l’autre…

  • Avantages d’une équipe dédiée :
    • Le principal avantage est que cela libère du temps au chef de projet pour se concentrer sur autre chose : la relation client, la résolution de conflits, les négociations, l’avant-vente, les réunions, l’écriture de tous les documents nécessaires (spécifications, comptes-rendus, etc.), etc. ;
    • Avoir une équipe dédiée permet aussi de progresser dans l’écriture des spécifications et des cahiers de tests. En effet, s’ils sont mal écrits, les tests ne seront pas bien effectués.
  • Inconvénients :
    • Les testeurs seront amenés à vous questionner sur les fonctionnalités développées car ils n’ont pas compris l’intégralité du raisonnement ou du fonctionnement ;
    • Finalement, le chef de projet reste celui qui connait le mieux le projet et la façon dont il a été réalisé et la manière dont il doit être testé. Il me semble évident qu’un testeur ne saura pas couvrir l’intégralité des usecases ;
    • Enfin, on n’est jamais mieux servi que par soi-même, et, avoir confiance en quelqu’un d’autre n’est pas évident.

Le dernier point est probablement l’argument le plus délicat et le plus fort contre l’utilisation d’une équipe de testeurs dédiée. En effet, le chef de projet est le garant du projet et donc de sa qualité. Il est très difficile de s’en remettre à autrui sur une tâche aussi importante que le testing.

J’ai déjà eu le problème sur un projet avec un client historique. J’avais prévu une démonstration de l’avancée des développements avec le client au bout d’un mois de développement. La veille, je prépare ma démonstration et teste rapidement les fonctionnalités. Ô surprise quand dès les premières fonctionnalités (qui avaient été testées et validées par l’équipe de tests), cela ne fonctionnait pas. J’ai été dans l’obligation d’annuler ma démonstration, de la repousser de 2 semaines, d’effectuer moi-même l’intégralité des tests et de suivre les développements de près.
Outre la perte de temps occasionnée, c’est aussi la perte de crédibilité, ma crédibilité face au client qui m’a le plus ennuyé.

Pour conclure cette réflexion, je pense que, peu importe la situation, le chef de projet doit être investi dans les tests de ses projets. S’il n’a pas le temps de les faire, alors il doit pouvoir en dégager (en parler à son manager peut aider), même si ce n’est pas évident.
Et vous, comment gérez-vous cette partie de vos projets ? Comment travaillez-vous avec vos équipes de tests si vous en avez ? Notre fonctionnement de l’époque n’était peut-être pas optimal et aurait nécessité d’être revu. N’hésitez pas à me faire part de vos remarques et de votre expérience sur le sujet.

Je dédierai un article complet à l’utilisation de SELENIUM, un outil qui vous facilitera le suivi des tests, surtout des régressions.

Bien cordialement,

John Doe

Bonjour,

Lorsque vous démarrez un projet, vous avez besoin de plusieurs serveurs.
Nous sommes tous d’accord que le serveur de Développement est indispensable. Sans ce dernier, les développeurs ne pourraient pas travailler… Ce serveur est nécessaire même si les développeurs travaillent localement. Il est indispensable de tester les développements dans l’univers mutualisé du projet.

Outre le serveur de Développement, si le client n’héberge pas lui-même son projet, il vous faudra un environnement de production.

Une fois ces deux serveurs indispensables mis en place, nous aurons besoin de 1 ou 2 serveurs de recette. J’ai une nette préférence pour 2 serveurs plutôt qu’1, mais je n’ai pas forcément eu le choix.
Ce que j’apprécie dans le fait d’en avoir 2 est de bien séparer les tests de mon équipe (testeurs ou chef de projet) et les tests du client.
Je n’aime pas du tout procéder à une mise en staging (recette) et que le client dès le début puisse constater des erreurs. Et c’est le risque d’avoir uniquement 1 serveur.
De plus, avoir 2 serveurs est censé, via les commits Git ou SVN, permettre de déployer uniquement ce qui est validé. De ce fait, la préproduction (recette client) doit être d’une qualité proche de l’état final.
Naturellement, ce système à 4 serveurs pose des soucis, notamment de délais. Car si on résume l’activité : Le développeur développe son sprint sur le serveur de Développement, puis il réalise une livraison en Staging. Le testeur ou le chef de projet teste sur cet environnement de Staging et remonte les bugs, s’il en trouve. Une fois les bugs corrigés, le développeur déploie en Préproduction afin que le client puisse tester.
A la moindre modification, il faut repasser par le processus Développement puis Staging puis Préproduction.
Ce fonctionnement est très sécurisé, permet de montrer de la qualité au client mais a un impact sur le planning.

Dans tous les cas, toute demande de serveur doit être loguée et trackée. Pour ce faire, je vous invite à utiliser un template de demande de serveur. En fonction de votre activité, il pourra être légèrement (voire sensiblement) différent de celui que je vais vous proposer ci-dessous.

  • Nom du client :
  • Code/Nom du projet :
  • Taille du projet :
  • Type de serveur demandé (Dev/staging/prod) :
  • Type d’installation (Drupal/Wordpress/autre) :
  • Authentification Apache :
  • Identifiants admin :
  • Date de début :
  • Date de fin :

Cette liste est loin d’être exhaustive et dépendra beaucoup du projet que vous avez à faire. Si votre projet est fait en java, vous pouvez par exemple ajouter une ligne pour JavaMelody, etc.

Bien cordialement,

John Doe

Bonjour,

Un élément que j’ai assez souvent oublié par le passé mais qui est pourtant capital dans un projet : la checklist des éléments.
Basons nous sur des exemples concrets. Au cours d’un projet, vous pourriez, par exemple, avoir besoin que le client vous livre un fichier .csv contenant les thématiques d’une des applications que vous développez pour lui. Ce .csv doit vous être retourné avant le dd.mm.yyyy.
Le client désire que son application soit accessible via un dns spécifique, il faut le planifier. Le fichier robots.txt doit lui aussi être fourni, etc. tant de petits éléments qu’il ne faut pas oublier, auxquels on pense régulièrement mais qui peuvent sortir de l’esprit au quotidien.
Naturellement, ces « tâches » peuvent être inscrites dans un outil type Jira ou Redmine, mais ces logiciels sont généralement réservés à un usage interne et il est plus simple d’avoir un document listant l’ensemble de ces tâches. Le client doit avoir accès à ce document, surtout qu’au fur et à mesure du projet, cette liste peut s’allonger.
Ce document devient réellement capital lorsque le projet implique des prestataires externes avec lesquels il faut se coordonner.

Dès le début du projet, je crée donc ce document, dédié au projet, me basant sur un template que j’ai réalisé. C’est un document très simple en soi, l’important est de toujours l’avoir à jour. Le document, de type spreadsheet contient 6 colonnes :

  • : L’ID de la tâche. Il est plus facile de faire référence à un ID qu’à une phrase. Tout le monde saura à quelle tâche fait référence le N°10 ;
  • Description de la tâche : La description doit être claire et concise. Ce n’est pas le travail de ce document de décrire la tâche en détails ;
  • Société en charge : Il est nécessaire de décrire la société qui doit réaliser la tâche, que ce soit du côté client, du côté prestataire ou encore intermédiaire ou partenaire ;
  • Nom du responsable : Connaître la Société en charge de la production est une condition nécessaire mais pas suffisante. Il est important et indispensable de nommer quelqu’un en charge de la tâche. Que ce soit lui/elle qui réalisera la tâche est un autre sujet. Néanmoins, c’est cette personne qui devra « rentre des comptes » ;
  • Date limite de livraison : Une tâche doit toujours être accompagnée d’une date limite de production. Outre le fait qu’une tâche sans limite de temps est une tâche qui ne sera pas faite ou très difficilement, la date est capitale dans la création de votre document et la gestion des statuts ;
  • Date effective de livraison : Cette date permet, a postériori de savoir quels éléments ont pu nous retarder dans notre projet et donc les anticiper lors d’un prochain projet. Elle donne aussi, tout simplement une information supplémentaire sur le déroulement du projet et permet le suivi des statuts.

Ces deux derniers points Date limite de livraison et Date effective de livraison sont donc obligatoires pour la mise en place de règles d’affichage particulières vous permettant d’avoir une vue claire et rapide des points critiques. Personnellement, une visualisation via des couleurs me plait énormément.
J’ai donc 4 règles explicites et une règle implicite :

  • Lorsque la Date effective de livraison est renseignée, la couleur de la ligne est vert ;
  • Lorsque la Date limite de livraison s’approche et que la Date effective de livraison n’est pas renseignée, la couleur de la ligne est orange ;
  • Lorsque la Date limite de livraison est dépassée et que la Date effective de livraison n’est pas renseignée, la couleur de la ligne est rouge ;
  • Lorsque la Date limite de livraison est éloignée et que la Date effective de livraison n’est pas renseignée, la couleur de la ligne reste blanc.
Description de la tâche Société en charge Nom du responsable Date limite de livraison Date effective de livraison
01
02
03
04
05
06
07
08
09
10

Utilisez-vous un document de checklist global au projet ? Inscrivez-vous ces informations dans le planning macro du projet voire dans le document Kickoff du projet ? J’ai toujours trouvé plus simple de faire un document dédié mais je suis ouvert à toute amélioration.

Bien cordialement,

John Doe

Bonjour,

L’un des éléments essentiels dans votre travail de chef de projet consiste en l’écriture de compte-rendus. A chaque rendez-vous avec votre client, vous devez, lui fournir, dans les heures qui suivent (il faut que cela reste frais dans votre tête et dans celle du client), le compte-rendu de votre réunion.
Ne négligez pas ce document, il est très important. Décrivez l’ensemble des discussions, inscrivez tous les détails possibles, les choix qui ont été pris, les remarques et réflexions. Au début de ma carrière, je me suis parfois posé la question de l’intérêt d’avoir un compte-rendu si détaillé.
Je me souviens d’une fois (et qui m’a marqué car je m’en souviens encore aujourd’hui), en cours de projet, j’ai eu à écrire un compte-rendu et mon manager m’avait demandé de le détailler davantage. Je lui ai, à l’époque, demandé la raison car de toute façon, j’allais écrire les spécifications liées à ce compte-rendu.
Sa réponse m’a permis de comprendre l’intérêt du compte-rendu :

  • Lors de l’écriture du compte-rendu, les (tous) éléments sont frais dans la tête, donc il est plus intéressant de les décrire au moment de l’écriture que plus tard, lorsqu’ils ne seront plus que des souvenirs, parfois lointain ;
  • Lors de l’écriture des spécifications, il est plus facile de faire un copier/coller et de modifier que de fouiller dans sa mémoire à la recherche des éléments passés.

Votre compte-rendu, outre la description de ce qui s’est dit durant la réunion, doit aussi lister les prochaines actions, principalement liées à ce qui a été discuté. Ces prochaines actions doivent être précises, doivent avoir un responsable nommé (ce responsable devra recevoir une copie du compte-rendu) et une date précise doit être donnée. On ne doit pas écrire ASAP ou à déterminer. Tout doit être daté !

Ci-après un exemple de compte-rendu que je propose à mes clients :

Compte-rendu de réunion

Informations

  • Objectif(s) :
  • Date :
  • Lieu :
  • Scribe :
  • Participants :
    • Ma société :
      • Participant 1
      • Participant 2
    • Société du client :
      • Participant 1
      • Participant 2

Points clés discutés

Sujet Temps forts
01
02
03
04
05
06
07
08
09
10

Plan d’action

Action Responsable Date de mise en service
01
02
03
04
05

Créez vous un template de compte-rendu, ne perdez pas votre temps à refaire la structure à chaque fois.

Et vous, à quoi ressemblent vos comptes-rendus ? Avez-vous des astuces qui pourraient nous aider à améliorer les miens ?

Cordialement,

John Doe

Bonjour,

Aujourd’hui, je souhaiterais faire une petite introduction à l’utilisation des Gantt Charts pour faire vos plannings.
Commençons d’abord par la lecture de l’infographie (en anglais mais très accessible et facile à comprendre) ci-dessous (cliquez sur la vignette pour afficher l’intégralité de l’infographie) qui explique historiquement l’apparition des Gantt Charts. J’ai toujours trouvé qu’apprendre en image était plus sympa et ludique que du texte.

What is a Gantt chart

Pour le moment, je n’ai jamais eu l’occasion de travailler sur Microsoft Projects dans mon travail, les différentes sociétés dans lesquelles j’ai travaillé n’ayant jamais acquis les licences nécessaires. Du coup, je me suis tourné vers un outil totalement gratuit et qui fait le boulot : Gantt Project. Certains outils permettent de générer automatiquement les Gantt charts à partir des différentes tâches, tels que Redmine ou jira mais parfois, un Gantt chart pourra être réalisé en amont du projet, pour définir les jalons et les grandes phases du dit projet.

Tout d’abord, pourquoi faire un Gantt Project ?
Tout projet qui se respecte et qui se veut être bien géré doit être inscrit dans un espace de temps. Cet espace doit être délimité : une date de début et une date de fin.
A l’intérieur se trouve votre projet et sa chronologie. L’utilisation du Gantt chart vous permet notamment :

  • Avoir une vue rapide des différents jalons du projet
  • Lister l’ensemble des tâches et les prioriser
  • Planifier les installations, les recettes et les demos aux clients

Il est assez simple de réaliser un Gantt chart pour un client, il suffit d’ajouter des tâches mais sans aller très loin dans le détail. Prenons un exemple. L’une des fonctionnalités attendues du projet est la réalisation d’un espace membre. Ce dernier nécessite donc le code :

  • Développement du profil utilisateur
  • Développement de l’inscription rapide
  • Développement de la connexion
  • Développement de la mise à jour du profil
  • Développement de la déconnexion

Admettons que tout ceci ait été estimé à 2 jours. Il n’est, à mon avis, pas nécessaire que le client sache qu’il faut 2h pour le premier item, 5 pour le second, etc. Une seule tâche de 2 jours est une information bien suffisante.
Par contre, en interne, votre outil de suivi des tâches doit être le plus détaillé possible et vous donner les informations manquantes.

Après cet aparté sur les tâches, lors de la réalisation de votre Gantt chart, vous devez définir des rôles, ajouter les vacances/congés/jours fériés, d’ajouter les équipes si on les connait, et assez rapidement, votre planning est prêt.
Il existe d’ailleurs un tutoriel assez clair sur la façon d’utiliser Gantt Project sur le site Developpez.com.

N’oubliez pas que les liaisons entre les tâches vous permettent de mettre à jour votre planning assez régulièrement et de proposer à vos clients une version toujours actualisée de ce dernier, et donc d’avoir une vue précise de l’avancement du projet, du respect des délais ou non.

D’un point de vue personnel, j’utilise Gantt Project en début de projet, pour proposer une version macro du planning avec les grandes phases et ses jalons, et tout au long du projet (lorsque les autres outils ne me permettent pas de faire mieux).

Bien cordialement,

John Doe

Bonjour,

Ce billet peut paraitre un peu étrange mais pourtant, l’un des soucis que j’ai eu à un moment donné, est la prise en charge de plus de projets que je n’étais capable de gérer, du moins dans l’immédiat.
Je me disais que pour avoir ma prime de résultats, il me fallait réussir un max de projets, je me suis mis une pression bien trop importante sur les épaules et je n’ai pas tenu. Sans parler de burn out, j’ai eu des difficultés physiques qui m’ont tenu à l’écart de mon travail plusieurs fois et à chaque fois plusieurs jours.
Mon manager de l’époque m’avait dit qu’il était possible d’orienter les clients vers un calendrier/planning qui me correspond. Il s’avère qu’en effet, j’essayais toujours de faire le mieux possible pour le client et donc de me surcharger alors qu’il me suffisait de proposer des plannings décalés. Attention, je ne parle pas de plannings avec six mois de décalage mais une ou deux semaines. Dans la majorité des cas, les clients ne sont pas réellement impactés et le chef de projet respire.
Un chef de projet qui respire est davantage concentré, prend le temps de bien faire son métier et est davantage satisfait.

Bien cordialement,

John Doe