CTO

Journaux liées à cette note :

Journal du jeudi 10 octobre 2024 à 18:08 #pensée, #management

Je pense que l'utilisation du framework CommunityRule et Loomio peut être très efficace pour travailler en équipe.

J'aurais aimé expérimenter ces deux outils quand j'étais CTO chez Spacefill.

Première itération de mon aventure Malt #freelance, #place-de-marché-freelances, #malt, #JeMeDemande, #JaiDécidé

Il y a quelques mois, j'ai envisagé de créer plusieurs profils sur Malt pour me présenter sous différentes "casquettes". Par exemple :

Cette idée m'est venue en 2022, lorsque j'étais CTO chez Spacefill et que je recrutais des freelances pour des missions très spécifiques.

Je m'étais alors rendu compte que la sélection des profils était fastidieuse et que je passais à côté de candidats intéressants simplement à cause de problèmes liés aux mots-clés.

C'est à ce moment-là que je me suis dit que si un jour je m'inscrivais sur une place de marché de freelances, il serait judicieux de créer plusieurs types de profils pour contourner ces limitations de filtres.

En août dernier, j'ai fait quelques recherches sur la possibilité de créer plusieurs profils sur Malt et je suis tombé sur cette page (webarchive):

Créer plusieurs profils dans Malt ?

Vous pouvez créer plusieurs profils dans Malt. Chaque compte doit être associé à une adresse e-mail différente.

Chez Malt, nous déconseillons de créer deux profils différents sur la marketplace sauf si vous avez deux activités très différentes, par exemple si vous êtes développeur et graphiste.

Vos filleuls et gains cumulés seront alors répartis entre plusieurs profils.

Si vous exercez deux activités indépendantes très différentes, nous vous conseillons de créer deux comptes distincts en prenant soin de télécharger les documents liés à votre(vos) activité(s).

Nous ne pourrons pas fusionner vos notes et projets entre vos deux profils.

Création de mon compte Malt

Je me suis ensuite dit qu'avant de mettre en place une stratégie complexe, qu'il serait plus judicieux de commencer par créer et publier un simple profil.

En remplissant ce profil, j'ai constaté que je pouvais renseigner une longue liste de compétences. J'ai alors pensé que l'idée de créer plusieurs profils n'était finalement plus nécessaire.

Premier point de difficulté, le choix de la catégorie :

J'ai opté pour une catégorie générique, celle de "Ingénieur logiciel".

Cependant, je doute fortement que ce soit le premier choix d'une personne que utilise le recherche de Malt 🤔 :

'ai fait un test en choisissant l'intitulé "Développeur". Après avoir filtré par mon tarif journalier exact et mon niveau d'expérience, je suis présent en page 6 des résultats.

Si je sélectionne la catégorie "Développeur Web Back-end" ou "Développeur Web Front-end" je ne suis plus présente dans la liste des résultats 😟.

Bilan Malt après 25 jours

Mon bilan Malt après 25 jours ? Pour le moment, personne ne m'a contacté. J'observe que mes statistiques sont plutôt mauvaises. De plus, je pense que les 3 personnes qui ont vu mon profil sont des amis.

Un ami freelance m'a confié qu'il n'avait reçu qu'une seule proposition de mission sur Malt en plus de trois ans.

Un autre ami freelance m'a confié avoir eu, sur un an, sur Malt, environ 40 propositions de mission, 5 échanges constructifs et signé deux missions.

Suite de stratégie Malt ?

Il est clair que mon profil Malt n'est pas optimisé.

J'ai visé trop large en listant mes compétences, et je pense que ce n'est pas la meilleure stratégie.

Le problème, c'est que si je veux rendre mon profil plus spécialisé, je vais devoir faire des choix et retirer des compétences que je ne souhaite pas supprimer 😞.

Pour éviter cela, je vois deux stratégies :

  • Modifier mon profil chaque semaine, en ajustant les technologies, les catégories et le tarif journalier ;
  • Créer plusieurs profils.

#JeMeDemande si l'étape de vérification des documents d'entreprise va m'empêcher de créer plusieurs profils 🤔.

#JeMeDemande s'il est préférable que je consacre prioritairement du temps à l'optimisation de mon profil Malt ou alors de travailler sur ma Stratégie de promotion de mon activité freelance sur LinkedIn 🤔.

#JaiDécidé de reporter l'optimisation de mon profil Malt.

Journal du samedi 06 avril 2024 à 20:00 #software-engineering

Article publié sur https://sklein.xyz/fr/posts/2024-04-06_spike-and-learn-day/

Concept que mon équipe et moi avions nommé "Spike and Learn day"

Quand j’étais CTO chez Spacefill, en mai 2021, j’ai mis en place avec mes collègues un rituel que nous avons nommé “Spike and Learn day”.

Un vendredi sur deux — soit 10 % du temps de travail — chaque développeur pouvait librement décider de consacrer sa journée à l’apprentissage d’une nouvelle chose, tester une idée, travailler sur de la dette technique, ou implémenter en autonomie des choses qu’il pensait utiles pour la société.

Pendant cette journée, le développeur n’avait pas à suivre le sprint, ni la roadmap, c’était un espace de liberté.
Les sujets pouvaient être aussi des initiatives d’amélioration produits.

Limites : les sujets devaient être en rapport avec des stacks technologiques utilisés ou potentiellement utilisable par la société (exemple, l’étude d’un moteur de jeu vidéo n’était pas autorisé, car il y avait peu de chance que ça soit utile au business de la société).

Précision importante : l’intégration du résultat de ces journées « Spike and Learn » pouvait être refusé ou non priorisé par l’équipe produit ou non accepté lors de la phase de review par les autres développeurs. Cela faisait partie du jeu de l’expérimentation.

Si un “Spike and Learn day” tombait un jour férié ou pendant les congés d’un développeur, la journée était considérée comme perdue.

Cette idée était largement inspirée de l’initiative de Google nommée “20% Project”.

Pourquoi le mot “spike” ? J’ai puisé le concept de Spike dans le Extreme Programming — qui m’avait été souflé par Ronan —, pour en avoir une définition, je vous conseille l’article What is Spike in Scrum? (archive).

Initialement, j’avais prévu mettre à disposition des projets bootcamps dans lesquels les développeurs auraient pu puiser pour la partie “learn” de leurs journées.
J’envisageais, par exemple, des sujets DevOps, exploration de Docker, déployer un serveur de A à Z via Vagrant, ou alors de recontruire les bases de la stack web employé par la société depuis zéro…
Mais malheureusement — et Claire me l’a souvent rappelé 😉 — en 2 ans, je n’ai produit aucun bootcamp 😭 !

Ajustement au cours du temps

Avec l’expérience, nous avons décidé — quand c’était possible — de placer cette journée en fin de sprint afin de ne pas “casser” sa dynamique.

Ce qui donnait l’emploi du temps théorique suivant :

  • Travail sur les issues du Sprint Scrum du lundi de la semaine 1 au jeudi matin de la semaine 2
  • Jeudi après-midi de la semaine 2 : Sprint rétrospective et Sprint planning
  • Vendredi de la semaine 2 : “Spike and Learn day”

Quels ont été les effets de cette initiative ?

D’après ce que j’ai pu observer ou ce qui m’a été dit, je pense que cette initiative était plutôt appréciée des développeurs.

J’ai pu noter que la plupart des développeurs avaient leurs préférences :

  • Certains privilégiaient fortement des activités de dette technique
  • D’autres préfèraient terminer une issue en retard du sprint
  • Et d’autres préféraient explorer de nouvelles choses, tester des fonctionnalités

Les développeurs m’ont remonté une frustration concernant le défi que représente la réalisation d’un projet nécessitant plusieurs jours de travail avec seulement deux jours alloués par mois. De plus, le délai de quinze jours entre chaque session rend difficile la reprise du travail sur le sujet.

J’ai été agréablement surpris de voir que ce rituel ait été respecté sans difficulté majeure pendant plusieurs années. Je n’ai pas souvenir de suppression exceptionnelle de cette journée par l’équipe produit ou de management.

Si j’en ai un jour la possibilité, si je suis à nouveau en responsabilité, je pense que c’est une initiative que je proposerai à nouveau de mettre en place.