Concevoir un projet — la passion du code.
Je vois tellement de projet archivés ou abandonnés, ce qui en soit revient au même c'est juste un autre mot pour dire qu'un projet est mort dans le film. Cela peut se traduire par plusieurs choses — envie de passer à autre chose, une mauvaise implémentation ou surement la perte de la motivation. Si tu es déjà passer par là, tu peux rompre la malédiction même si le projet au départ semble ambitieux.
La preuve par 3
Premièrement, tout projet à commencer avec une preuve du concept simplifiée. Il suffit de regarder le premier commit des projets pour comprendre qu'on part d'un prototype qui évoluera par la suite. C'est la bonne approche et celle qu'il faut suivre. Dans le cas d'un langage de programmation, tu n'es pas obligé d'aller jusqu'à la génération du code machine. J'en parle ici.
Ensuite le reste repose sur l'effort et ton intérêt. L'Open Source est un monde difficile, un grand nombres utilisent des librairies qui leur sauve la vie, leur font gagner du temps mais ne vont pas pour autant avoir le réflexe pour leur donner une étoiles pour les soutenir. Il en sera de même pour toi et ton projet. Rien de méchant, mais ne prends pas cette métrique comme un gage de qualité. D'autant plus, l'Open Source a besoin de voir que tu ne vas pas abandonné ton projet dans 6les six mois qui viennent.
C'est pourquoi un minimum de un an de charbon est néecessaire avant de parler de ton projet autour de toi. Biensûr, tu peux en parler à tes amis, collègues, sur ton twitter, blog, etc — c'est justement conseiller pour avoir des retours. Mais attends que ton projet soit mature pour en parler sur Reddit, Hackernews et leurs comparses.
En une année de charbon, plein de choses peuvent changer, comme par example perdre la motivation ou l'intérêt sur le problème que tu essayes de résoudre. Tu vas aussi apprendre énormément de chose car tu te seras focus sur un sujet sous tous ces angles. Ce qui te donnera des compétences de niche.
La mental de Shikamaru
Deuxième, il faut mesurer l'ensemble des tâches qui doivent être terminées avant de demander aux utilisateurs d'utiliser ton produit. L'utilisateur n'a pas le temps, n'aime pas lorsqu'un programme, logiciel, site ne fonctionnent pas et surtout généralement ne donne pas plusieurs chances à un nouveau produit. C'est-à-dire que lors du premier essai l'ensemble des features mise à disposition doivent fonctionner. Cela ne veut pas dire qu'il n'y a pas de la place aux bugs, bien au contraire mais tu dois t'assurer que le minimum syndical fait son job correctement.
Toujours dans l'idée de mesurer, tu dois aussi mesurer les tâches alternatives :
- Ai-je une documentation est complète et à jour ?
- Est-ce que l'installation est simple et clairement documentée ?
- Ai-je fourni des examples ?
- Est-ce que je veux open sourcer mon projet ?
- Si oui, ai-je un document qui explique l'architecture ?
- Comment les utilisateurs reportent un bug ?
- Le site internet ? A quoi il va ressembler ? Quels informations je veux donner ?
- Je te laisse, l'imagination pour les autres questions critiques.
En répondant à ces questions, tu vas avoir des tâches concrètes à réaliser. Tu ne crées pas un produit POUR les utilisateurs mais POUR toi. Cependant, si celui-ci est mise à disposition sur les internets. Tu ne pourras pas aller à l'encontre du fait que d'autres personnes pourront l'utiliser. C'est pourquoi, tu dois t'assurer au mieux de chaque scénario. Prends le temps de planifier, d'être le stratège de ton produit comme Shikamaru dans Naruto.
Les fondations
Troisièmement, je parlerai de l'univers. Je le vois souvent, c'est le manque d'univers dans un projet. Cela passe par l'imagerie, le champ lexical, etc. Le tout est d'offrir une expérience utilisateur exclusive et différente. Ça m'arrive souvent de passer une à deux journées pour redéfinir un mot clé dans mon langage afin que la compréhension soit clair ou encore de réfléchir au nom de mon projet, si il va être accompagnés de projets satellites — quels vont être leurs noms ? N'y a-t-il pas un moyen de leur trouver des points communs afin de consolider l'univers de mon projet.
J'insiste dessus, car aujourd'hui utiliser un projet c'est faire parti d'une communauté. On rejoins un Discord, on suit les règles de cette communauté, on créer des liens (pas toujours mais ça arrive) avec des gens de la communauté. C'est important d'avoir ces choses en tête. Même si ce n'est pas pour tout de suite, avoir des notes va t'aider à ne pas réfléchir à tout cela dans la précipitation. Il te faut des fondations, un socle solide sur lequel les utilisateurs peuvent se poser, contribuer et avoir un sens. Plus il y aura de la transparence, plus les visiteurs, utilisateurs te feront confiance.