De débutant à Tech lead, tous les développeurs ont dans leur repositories des projets personnels. Certains sont le fruit d’idées ayant des ambitions disruptives, d’autres sont de simples bacs à sable pour s’entraîner qui ne verront jamais la lumière d’une requête provenant de l’internet !
Quelle que soit la raison de sa création, les projets perso naissent, parfois vivent et souvent meurent. Dans cet article, je vais vous partager mes meilleurs conseils pour que vos projets voient le jour et aient une chance de se confronter à de vrais utilisateurs !
Ces projets ont pour vocation de vous faire pratiquer une techno en particulier. Il n’a pas vocation à apporter une valeur ajoutée à des utilisateurs et souvent pourra vivre en local avant de mourir oublié dans votre répertoire de travail.
Ces projets existent pour montrer à d’éventuels employeurs (ou client si vous êtes freelance) ce que vous savez faire. Il peut avoir un intérêt à être déployé si vous voulez montrer vos compétences en devops ou si l’interface et l’expérience utilisateur sont aussi importantes que le code lui-même. Ce qui peut être le cas si vous êtes développeur Frontend ou intégrateur.
Suivant où vous en êtes dans votre projet entrepreneurial, vous pourriez être amenés à développer un projet à des fins lucratives (ou caritatives). Ce projet peut être à vocation de « Proof of Concept » ou au stade de MVP en vue d’être en V1. Suivant où vous en êtes dans la découverte utilisateur, le projet pourra avoir pour but uniquement de découvrir un besoin ou, si celui-ci est déjà identifié, de construire une première version fonctionnelle d’un produit.
Rome ne s’est pas faite en un jour, votre projet non plus. Lorsqu’on démarre un projet perso, on peut être tenté dès le départ d’avoir une liste de features qui nous paraissent essentielles à implémenter. Le plus souvent ce n’est que votre esprit qui s’emporte par enthousiasme. Il est fort probable qu’au démarrage vous n’ayez pas besoin de système d’authentification par Google ou d’envoyer des notifications à tout va.
Listez toutes vos idées avant qu’elles vous échappent. Que ce soit sur papier, je vous conseille de prendre en photo vos notes si c’est votre choix de prédilection, sur une app de prise de note type Evernote ou directement dans le Readme du projet Github, lister puis prioriser les fonctionnalités que vous souhaitez implémenter sont des étapes à ne pas sauter.
Dans le cadre d’un projet veille techno, votre priorité est d’arriver au plus vite à l’élément que vous voulez mettre en pratique. Par exemple vous essayez d’apprendre à implémenter ElasticSearch, inutile de démarrer un serveur web complet avec une architecture MVC et une base de donnée SQL ou MongoDB.
Dans le cadre d’un projet portfolio ou un projet entrepreneurial, les priorités sont différentes puisque vous cherchez à avoir un produit fonctionnel en ligne. Pour ce faire, prenez la liste de fonctionnalités que vous avez établie en étape 2 et classez-les en 3 catégories:
Imaginons que votre projet soit une app de liste de course partagée. Voici à quoi ressemblerait votre répartition:
Metier:
Technique:
Autre
La liste métier va regrouper les gestes « utilisateurs » sans prendre en considération les implications techniques. L’utilisateur d’une app de liste de course n’a que faire de savoir quelle base de données vous avez choisie et comment vous l’avez implémenté.
La liste technique va lister les contraintes techniques que vous aurez pour réaliser les gestes métier.
La liste « autres » va englober le reste.
À partir de cette liste, prenez toutes les fonctionnalités sans quoi votre application ne peut pas exister et enlevez toutes les autres. Par exemple, vous n’avez peut être pas besoin d’un système complet d’authentification. Pour démarrer une clé par utilisateur à mettre dans les paramètres de l’url peut faire l’affaire, quitte à créer les utilisateurs à la main pour les beta testers ou pour un compte demo.
Pour finir, classez les fonctionnalités par ordre de valeur ajoutée. La plus importante devrait être celle qui ferait le plus la différence pour un utilisateur. Par exemple, « ajouter un produit » à une seule liste est plus important que « créer plusieurs listes » ou même que « barrer un produit ».
À ce stade, vos fonctionnalités sont encore sous forme de gros blocs. Avant de commencer à développer, prenez le temps de découper vos fonctionnalités en tâches les plus petites possible.
En prenant la fonctionnalité « ajouter un produit à ma liste de course », elle pourrait se décomposer en:
Ce découpage de vos fonctionnalités en micro tâches est tiré de la méthode Kaïzen. Le fait d’avancer par petite étapes préserve le moral et vous donne le sentiment d’avancer. Chaque tâche complétée est une petite victoire, que vous pouvez accomplir le plus rapidement possible.
Lorsqu’on démarre le projet, on se retrouve bien souvent devant une montagne dès lors qu’on a créé le répertoire de travail et le repository sur github. Dans la continuité de l’étape précédente, toute petite avancée est une victoire à prendre.
Commencez par les pièces les plus évidentes, les tâches les plus basiques à réaliser. Faire le Hello World est souvent la première.
L’erreur que j’ai souvent commise est de penser qu’il faut attendre d’avoir une version un minimum fonctionnel de son app pour la déployer. C’est faux ! Il arrive que des problèmes ne surviennent qu’au moment où vous déployez votre application alors que tout semblait fonctionner sur votre environnement local.
Pour éviter les surprises et les debuggings à rallonge, déployez le plus tôt et le plus souvent possible. J’ai pris pour habitude de créer un « Hello World » et de le déployer immédiatement.
Ensuite à vous d’arbitrer sur la fréquence de vos déploiements. Si vous avez bien découpé vos fonctionnalités en microtâches, déployer à chaque fois que vous complétez l’une d’entre elles peut être trop fréquent. Dans ce cas regroupez quelques tâches puis déployez.
Mais vous ne devriez probablement pas attendre d’avoir fini une fonctionnalité complètement pour déployer. Ce geste doit être un non-événement. Vous deviez pouvoir déployer votre application et revenir en arrière sans que ce soit trop laborieux ni chronophage. Ainsi vous ne procrastinerez pas et vous ne serez pas intimidé par cette étape.
Même si ça n’est que rarement explicitement mentionné, gérer un projet est une compétence qu’on attend d’un développeur. Suivre l’avancement de votre projet est une étape dans sa gestion.
Plusieurs outils sont à votre disposition pour vous aider. Trello, Asana, Github, il existe une multitude de solutions. Je vous conseille d’avoir un board public sur Trello ou de créer un projet dans votre repository sur Github. Vous y listerez les fonctionnalités et les microtâches sous forme de colonnes et vous pourrez faire avancer vos tâches au fur et à mesure que vous les complétez.
Sur un projet portfolio, il est important de garder ce board public et accessible à un potentiel employeur. Il va servir d’appui à votre candidature.
Vous trouverez dans l’Academy Practical Programming un template Notion à dupliquer pour assurer le suivi de l’avancée de votre projet
À moins que vous soyez développeur Frontend avec une forte orientation UX/UI et intégration, ne vous formalisez pas avec la finition esthétique. Votre projet MVP a le droit d’être aussi moche qu’il veut, tant qu’il est utilisable.
Pour ne pas perdre de temps avec l’apparence, je vous conseille d’utiliser des librairies CSS comme Tailwind, Bootstrap ou Bulma. Il vous suffira d’ajouter quelques classes à votre HTML pour avoir un rendu présentable mais là encore, il ne faut absolument pas perdre de temps a essayer d’harmoniser les couleurs, aligner les boutons ou mettre en place une navigation responsive.
Cette étape est un bonus bourré de valeur, réservé à ceux qui auront eu le courage de lire l’article jusqu’au bout.
On sous estime trop souvent l’histoire d’un projet, qui est souvent aussi importante que celui-ci. Si vous travaillez sur un projet entrepreneurial, c’est grâce à ces histoires sur votre projet que vous trouverez vos premiers utilisateurs. Si c’est un projet portfolio, c’est là que vous piquerez l’intérêt des recruteurs.
Créez un compte sur Medium et forcez-vous à poster une fois par semaine sur l’avancement du projet. Parlez technique, parlez du problème que vous voulez adresser, parlez de vos défis que vous surmontez en construisant le produit, racontez les échanges que vous avez eus cette semaine lorsque vous avez parlé de votre projet à un autre dev ou à un potentiel utilisateur.
Postez ces articles sur votre Facebook perso et votre Linkedin. Vous serez surpris de voir à quel point les gens autour de vous sont curieux des vraies histoires plutôt que des photos de la dernière sortie au resto italien ou de vidéos de chatons.
Pour qu’un projet ait une chance de servir son but, il faut faire preuve de persévérance. Vous allez plus d’une fois être tenté de vous orienter vers un nouveau projet, une nouvelle techno, une nouvelle approche. Si vous cédez à cette tentation, c’est la mort de votre projet.
Continuez à travailler uniquement sur ce projet et évitez tout autre engagement qui pourrait vous distraire de votre objectif.
Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…
Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…
En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…
On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…
La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…