segbedji.codes

Freelance: pourquoi majorer la durée des missions ?

Si tu es freelance, tu dois souvent donner des estimations de durées de missions pour des clients. Mon conseil: majores toujours tes estimations.

Estimer la durée d’une mission freelance

Quand tu es freelance, estimer la durée d’une mission est un passage obligatoire. Cela te permets de pouvoir aussi définir le coût de cette mission (bien que cela ne soit pas le seul élément à considérer).

Moi par exemple, je suis développeur WordPress. J’effectue en grande partie des missions de conception et de création de sites internet. Je calcule donc les estimations des durées de missions en fonction:

  • du type de projet sur lequel je dois travailler (en général, intégrer une maquette prendra plus de temps et demandera plus d’efforts que créer un site à partir d’un template existant)
  • de la taille du projet
  • de mes expériences passées en termes de durées de missions avec le même type de projet
  • de ma disponibilité à partir de la date prévue de commencement de la mission

Cette méthode a bien marché pour certaines de mes missions, alors que pour d’autres non.

L’erreur qu’on pourrait commettre

Au fil du temps, je me suis rendu compte que baser mes estimations sur les seuls critères cités plus haut était une grosse erreur. En fait, j’ai remarqué qu’il y a toujours des imprévus qui peuvent survenir.

Bien sûr, l’objectif d’une planification en amont, c’est d’identifier ces potentiels imprévus, afin de ne pas être pris au dépourvu. Mais les choses ne se passent toujours pas comme planifiées.

Toujours majorer la durée des missions

La solution que j’ai trouvée est toute simple. Je majore toujours légèrement mes estimations de durées des missions.

Supposons par exemple que je dois travailler sur l’implémentation de fonctionnalités sur mesure pour un e-commerce. Disons, une marketplace avec plus ou moins de custom integrations. C’est une mission que je pourrais typiquement estimer à 10-12h de temps de développement, de tests et d’intégrations.

Ça reste une estimation toute juste; faite à partir des informations que m’a fournies le client, et de celles que j’ai moi même recueillies à cet instant là.

Planifier mission freelance

Mais il peut par exemple arriver que l’un des services/solutions/API, etc… que j’espérais utiliser au début ne soit plus fonctionnel quand je commencerai le développement. Ou que je me rende compte qu’il y a un petit détail que je n’avais pas considéré dans mes estimations (c’est possible); et dont l’impact en terme de timing est énorme sur le projet.

Dans de tels cas de figure, je serais dans l’une des deux situiations suivantes:

  • Faire payer par le client le surplus qui a été généré par le dépassement de la durée initiale du projet,
  • Payer moi même les charges qu’impliquent ce dépassement

Dans l’une ou l’autre de ces deux situations, il y a une des parties qui ne sera pas contente. Le client, parce qu’il aura à supporter des charges non prévues. Ou moi, parce que j’aurai à supporter des charges non prévues 😀.

Ce qui aurait pu être évité en étant un peu plus objectif sur les estimations.

Avec le temps et l’expérience, viennent plus de flexibilité et de précision

Bien sûr, les majorations appliquées d’un freelance à un autre dépendent de l’expérience qu’il a; et aussi de sa faciliter à s’adapter à des changements de situations ou de plans.

Au fil des des missions, tu gagneras probablement plus en précision dans tes estimations. Tu pourras plus facilement t’adapter lorsque les plans initiaux de tes missions changent.


Et toi ? Tu es aussi freelance ? Comment tu estimes les durées de tes missions ? Est-ce que tu appliques aussi des majorations pour les imprévus ?

Dis-moi tout en commentaire 😉.

Public discussion

Les illustrations présentes dans ce mail proviennent du site undraw.co.

#100DaysOfCode: Ruby on Rails

Tomorrow I start the #100DaysOfCode challenge. I’m going to learn Ruby on Rails.

I’ve always wanted to learn Rails (well, for a while now). My first « real » contact with Rails was when I joined EtriLabs Cotonou in January 2019. Ruby on Rails is kind of the favorite technology of the house.

Many successful services/applications developed at EtriLabs have been created with Rails: Sewema, Botamp, Bidofi, Happierco.

So, learning Rails is a project I had on the go in my head. Let’s just say that the recent release of Hey by Basecamp finally convinced me to find some time to get into it.

So I spent the weekend learning the basics of the Ruby language. It was really fun. The object-oriented paradigm of the language is changing a bit (I’ve mostly used PHP so far).

Being able to do something like

100.times do
    puts "#100DaysOfCode: Ruby on Rails"
end

or

"#100DaysOfCode: Ruby on Rails".reverse

is really refreshing.

So, tomorrow, I’m going to start with it.

I’m going to document on my blog here my progress, my surprises, and what I’ll be learning and doing, etc…

Je rôde sur segbedji.codes

Bon, je me retrouve encore ici.

Pour ceux qui me connaissent, vous savez peut-être que j’ai un blog sur mon site principal (segbedji.com). J’y parle de WordPress principalement, et j’y tiens également un journal en ligne journalier. Alors…

Pourquoi un autre site ?

Oui, pourquoi un autre site ? Après tout, j’en ai déjà assez à faire avec le premier. Entre les notes quotidiennes, et les mises à jours des informations sur mes activités, il y a à faire.

Je cherchais un endroit où je pourrais expérimenter de nouvelles choses. Tout et n’importe quoi sans forcément avoir à m’imposer des limites à cause du caractère « professionnel » de segbedji.com

Donc je voulais essayer des choses nouvelles. Ecrire sur d’autres sujets, parler de nouvelles choses.

Mais pourquoi segbedji.codes ?

Tout ça c’est bien beau, mais pourquoi segbedji.codes. C’est vrai, j’aurais pu choisir un autre nom pour ce site.

D’abord, je voulais garder le “segbedji” dans le nom de domaine et celui du site. J’y tiens beaucoup, et en plus je reste dans la même lancée d’uniformité avec segbedji.com. Premier point.

J’ai pensé initialement à prendre un nom de domaine en “.dev” ou en “.io” pour rester dans l’esprit tech. Puis j’ai découvert le “.codes” et l’intention derrière l’existence de ce domaine. Du coup je l’ai pris 😀. Et il n’y a que quelques lettres de différence avec segbedji.com, donc c’est cool.

Ça s’est passé comment du coup ?

Je savais que je voulais un blog. Mais je voulais quelque chose d’autre que WordPress pour le propulser. Et je voulais essayer d’autres stack. J’ai donc commencé avec un site statique sur Hugo, le générateur de site statique. J’ai rapidement changé parce que j’avais du mal à m’y retrouver. J’ai quand même réussi à faire une page plutôt acceptable avec.

Screenshot segbedji-coddes

Puis, j’ai brièvement essayé un blog statique sur Next.js. Moi qui recherchais une solution lightweight, j’ai été vite déçu (en même temps je ne l’ai pas testé pendant longtemps). J’ai fait quelques déploIements avec Netlify; puis j’ai rapidement switché (encore). J’ai encore toutefois une version du site que j’avais commencé à cette adresse.

Je me suis finalement rappelé d’un article de Jack Lenox intitulé “Delivering WordPress in 7KB”. En gros, il y présente son thème Sutsy, extrêmement minimaliste et très performant. Du coup, je suis passé là dessus, et ça donne le résultat que vous voyez actuellement.

On doit s’attendre à quoi alors sur segebdji.codes ?

La tagline de segbedji.codes, c’est “writing about tech, open source, productivity and more…”. C’est plutôt clair. J’ai l’intention de partager ici de longs articles sur ces sujets là.

En termes de fréquence, ce n’est absolument pas précis actuellement. J’écrirai ici quand je pourrai, ou quand cela sera nécessaire. On verra bien ce que ça va donner par la suite.

Voilà! C’est donc mon quick launch de segbedji.codes :).