DivideConcept.net

le blog de divide.

Archive pour mai 2011

Ca fait quelques temps que j’avais envie d’écrire un article la dessus, et suite à ce sujet sur le forum je me suis dit qu’il serait intéressant de partager les points que j’ai pu noter au cours de mes projets indés et qui me semblent universels lorsqu’on se lance dans ce genre d’entreprise. Ce sont des conseils d’ordre généraux, si vous avez tenté (ou voulez tenter) le développement indé de votre coté n’hésitez pas à partager vos remarques à ce sujet.

C’est une révolution !

-Se poser la question du pourquoi: certains se lancent dans le développement indépendant à titre d’exercice personnel, pour améliorer leurs compétences dans un domaine. Il n’y a alors pas de contrainte de rendu, ni d’importance à cibler ou à innover.
Ce n’est pas la même chose si le projet est à vocation publique et/ou commerciale. Il est alors crucial de ne pas se lancer à l’aveuglette pour suivre une mode ou une tendance. Un projet doit naitre d’une envie de proposer quelque chose sans équivalent en général, ou sans équivalent dans un domaine en particulier. Etre familier avec le domaine dans lequel on se lance et les solutions deja existantes dans ce domaine est donc une obligation.
Il n’est pas nécessaire de proposer un concept complètement révolutionnaire, une seule “killer feature” peut faire la différence. Et c’est bien sur les fonctionnalités ou l’ergonomie que le développeur indépendant peut faire la différence comparé à un studio de 50 personnes, qui eux peuvent aisément miser sur la quantité de code ou de travail artistique.

-Savoir se limiter: lorsqu’on pense à son projet, on a facilement tendance à rêver loin et à vouloir proposer LE système universel qui peut tout faire. Avec ca on se retrouve embarqué pour un developpement de plusieurs années, et si on est pas persuadé à 200% que ce projet va changer la donne dans son domaine, alors la motivation ne tiendra jamais plusieurs années mais 6 mois au mieux. Il est donc important de savoir fixer des objectifs raisonnables, et s’y tenir.

Poser les bases

-Bien structurer en amont: il n’est pas interdit de restructurer légèrement en cours de projet, mais il faut vraiment dès le début cerner les tenants et aboutissants (cf point précédent) et structurer son système en fonction sur le papier. Tout ça est soumis à la loi de Murphy: si le moindre détail a été laissé volontairement de coté au début dans le design du projet, il se manifestera immanquablement en cours de développement.

-Choisir avec soin ses outils: comme le point précédent, le choix des outils/framework est aussi important que le design du projet (et ils doivent être définis en même temps). Choisir en fonction de l’envergure de son projet (temps réel/fonctionnalités avancées vs facilité de développement) et de sa destination (windows only, consoles, web, win/mac/linux). Pour du développement de projets temps réel avec des fonctionnalités avancées à destination win/mac/linux je recommande fortement l’écosystème Qt.

-Ne pas réinventer la roue: en lien direct avec le point précédent, refaire de son coté des outils qui existent déjà à l’identique (voire en mieux), c’est se tirer une balle dans le pied dès le début du projet. Dans le domaine du jeu vidéo les moteurs polyvalent et gratuit ne manquent pas (Unity, Ogre, Unreal Engine, CryEngine pour en citer quelques uns). C’est au bas mot un an de gagné sur le développement du projet. A moins d’avoir une très bonne raison pour faire son propre moteur bien sur. Il est aussi important de bien faire attention aux licences, selon la destination de son produit. Pour un produit commercial closed source utiliser du LGPL ne pose pas de problème, en ce qui concerne le GPL tout dépend de son lien avec l’application.

-Concevoir un design familier: en lien avec le point précédent, il faut aussi reproduire du coté de l’utilisateur toute les conventions qu’il connait déjà dans la mesure du possible, qu’il soit d’emblée familier avec des concepts qu’il connait déjà. C’est autant de temps de gagné pour expliquer votre projet et pour que celui ci soit adopté !

Travail en cours

-Se donner des micro-objectifs à court terme: il y a parfois dans le développement des “traversés du désert”, ces étapes où rien n’est concrètement visible pendant plusieurs mois. Il faut savoir subdiviser ces étapes en micro-objectifs tous les 2 ou 3 jours pour continuer à percevoir une progression, sinon c’est le découragement assuré. Il n’est pas interdit de faire des breaks mais jamais plus de deux semaines, sinon se replonger dans le projet peut être particulièrement difficile !

-Un projet commence souvent par une traversée du désert: pour limiter cette traversée au maximum et garder la foi en son projet, il est important de coder au plus vite les éléments visibles de son projet (si c’est possible bien sur), afin que chaque bout de code supplémentaire soit valorisé au sein de cette base visuelle (l’interface le plus souvent donc).

-Quand le projet est finit à 90%, il reste encore 90% à faire: on a très souvent tendance à sous estimer les temps de développement et les obstacles qui surviendront. Ne pas hésiter à doubler tout de suite ses premières estimations. En lien avec la loi de Murphy, le temps imparti aux imprévus sera systématiquement rempli et dépassé.

Des réalités matérielles

-Gérer son temps…: last but not least, voici les points les plus pragmatiques du développement. Quand on est salarié à plein temps, il n’est pas forcément facile de garder du temps de cerveau disponible et de l’énergie pour développer son propre projet quand on rentre après une journée de boulot. C’est une gestion assez délicate, et je n’ai pas beaucoup de conseils à donner sur ce cas précis. Le temps de projet personnel se gère beaucoup mieux à mi-temps, et à l’inverse lorsqu’on est a temps plein sur son projet, la problématique est assez délicate aussi: il faut savoir structurer sa journée pour garder l’efficacité du temps de développement. Et savoir fermer son browser internet de temps en temps.

-…et son argent: encore plus concret, ce sont des réalités à ne pas ignorer. Lorsqu’on est salarié, pas de soucis coté financier pour assurer le développement. Par contre il faut savoir trouver des sources de revenus quand on est à plein temps sur son projet: fortune personnelle, commandes freelance, RSA, famille, subventions (pro-tip: il faut être au moins deux sur le projet pour prétendre à des subventions). Ne pas négliger cet aspect, surtout que les développements on tendance à traîner sur la fin (voir plus haut).

-…et sa famille: il est important de savoir ménager du temps pour ses proches, surtout lorsqu’on est en couple. C’est bien sur du cas par cas, mais il suffit de se mettre d’accord avec eux sur la proportion temps de travail/famille, que chacun ai ses créneaux. J’ai déjà vu des collègues divorcer pour leur carrière, chacun ses priorités après tout, mais il est quand même dommage d’en arriver là.