Constat d’Echec

Il m’arrive de temps à autre de relever la tête afin de regarder où j’en suis. C’est ce que j’ai fait hier soir et c’est un constat d’échec qui s’impose :

L’application ne sera pas prête dans les temps pour une participation au concours de google.

Le plus décevant est de voir l’état d’avancée actuel du projet par rapport au temps passé dessus.

J’avais pu atteindre quelque chose de presque démontrable pour le concours SFR. Cela n’est absoluement pas le cas pour le concours google. La partie serveur et backoffice ont pris énormément de retard. Aucun développement n’a été effectué sur la partie mobile.

A l’origine de ce constat d’echec, de mauvaises décisions prises en amont que je vais essayer d’analyser ici. Je me remonte le moral en me disant qu’un bon plantage correctement analysé vaut bien 10 réussites chanceuses.

J’ai inclu trop de nouvelles technologies

J’ai confondu projet avec un objectif précis et projet boite de pétri pour tester des technologies nouvelles qui m’attirent.

En soit, tout le projet WYDW est une boite de pétri pour tester et apprendre à développer sous android. Mais petit à petit, c’est également devenu un projet réel dans lequel je voyais un objectif de plus en plus précis. J’aurai donc du avoir une approche plus pragmatique.

J’avais eu  beaucoup de chances au cours de la première itération du projet (jusqu’au concours SFR). J’avais inclu plusieurs technologies que je connaissais pas avec beaucoup de succès (Android, et une connectivité au serveur très légère grace au design Rest). Le tout m’avait permis de développer une partie serveur très rapidement. Mise à part pour android et rest, j’étais dans les technologies que je manipule au quotidien et mon efficacité fut optimale.

Pour la seconde itération, j’ai voulu essayer d’utiliser la nouvelle infrastructure de serveurs proposée par Google : L’appEngine. Cette infrastructure possède l’énorme avantage de fournir gratuitement (jusqu’à un certain niveau) des serveurs java du même type que ceux utilisés par google. Cette infrastructure permet de répondre aussi facilement à 1 requete/seconde qu’à 10000 requête/seconde. Elle permet aussi d’avoir beaucoup moins d’arrêts de service que mon petit serveur loué sur dedibox. Son développement semblait également assez facile et son couplage très facile avec GWT (une technologie frontale très adaptée au backoffice que je souhaitais également utiliser) avait fini de me convaincre de l’utiliser.

Utiliser L’appEngine fut la plus grosse erreur du projet

Essayer l’appEngine était logique. Mais je n’aurai pas du insister face aux implications que l’utilisation de ce service imposait sur le projet. Cela m’a imposé de purement et simplement recommencer la partie serveur à zéro. Pire encore, j’ai plusieurs fois eu l’illusion de toucher au but avec des coeurs d’applications qui fonctionnaient mais au final une contrainte supplémentaire m’imposait de tout changer.

Quand j’ai finalement réussi, la semaine dernière, à avoir un backoffice prometteur qui fonctionnait sur ma machine de développement je me suis apperçu que cela ne fonctionnait pas sur les serveurs de google et ne pourrait pas fonctionner. J’ai du à nouveau tout changer.

J’ai le sentiment d’avoir passé mes dernières semaines à jongler avec les problématiques imposées par l’appEngine. C’est un peu comme d’essayer de recouvrir une grande table avec une nappe trop petite. Vous arrivez près d’un bord, vous tirez la nappe et ca découvre l’autre coté de la table. Vous en faites le tour, vous tirez la nappe et vous découvrez à nouveau l’autre coté. Après de nombreux essais, vous arrivez à tourner la nappe de façon à ce qu’elle recouvre toute la table. Mais au moment d’installer la nappe sur la vrai table, vous vous appercevez que la vrai table n’a pas la même forme que celle sur laquelle vous vous êtes essayé un certain nombre de fois.

Il y a quelques succès :

GWT fonctionne à merveille. Il me permet d’avoir un frontal web qui ressemble à une application executée par le système. Voici un exemple qui fonctionnait avec le code d’il y a quelque semaines (une contrainte supplémentaire a cassé le tout.) Cet exemple n’a rien d’impressionnant. Il s’agit juste de l’implémentation des mockup balsamiq dont je parlais dans un billet précedent. J’étais très enthousiaste après avoir réalisé cela car le code sous jacent à cet exemple est très simple à comprendre et possède beaucoup de potentiel. Je pensais arriver très rapidement à développer le reste. C’était faux car une contrainte n’ayant rien à voir avec la partie GWT m’a bloqué par la suite.

J’ai également pu découvrir gson, et dozer. Deux librairies que je ne présenterais pas ici mais qui m’ont agréablement surprises et qui sont un succès à garder.

Je n’ai pas mis assez d’effort dans le recrutement

Le billet sur le recrutement sur le site n’avait servit à rien. (en mm temps personne ne visite ce site ). J’en avais parlé sur twitter et mon post a été retwitté plusieurs fois. J’ai eu, suite à cette annonce, une vingtaines de visites inconnues sur le site. Pour recruter, j’ai surtout misé sur des gens de ma société de service (très portée sur les technos google) et j’ai effectivement eu une candidature interessée.

Après 3 semaines la personne n’avait toujours rien codé. Suite à une petite discussion il s’est avéré qu’elle preferait abandonner.

L’un des administateurs de Frandroid, un blog ayant plusieurs milliers de visites par jour, m’avais proposé de faire un post de recrutement sur frandroid. Je n’ai jamais saisi cette occasion et c’est un tord. J’aurai du.

De façon plus globale je me suis trop focalisé sur le développement et pas assez sur l’aspect managerial du projet.

Et maintenant ?

Même si le moral n’est pas vraiment là, je refuse de laisser partir en fumée tous les efforts que j’ai placés dans le développement de cette application. WYDW ne me rapportera toujours aucun copec, mais elle doit sortir pour que je puisse l’utiliser comme vitrine sur mon CV.

Coté développement, soit je continue à insister pour l’appEngine, soit je repasse sur mon ancien système et j’y ajoute GWT. Je pense que je vais choisir la deuxieme solution. Cela va engendrer des contraintes désagréables car GWT s’intègre assez mal à mon ancienne architecture, mais cela devrait avoir au moins l’avantage de fonctionner.

Changement de cap mon capitaine !

L’absence de spécifications commençait à se faire sentir avec WYDW.

J’étais donc prêt à me résoudre à sortir mon power point et à passer quelques heures avec des petites boites, des fleches et des zones de texte afin de pouvoir mettre en forme mes idées et avoir un objectif à atteindre. Pas toujours facile d’avoir quelque chose de précis et de compréhensible avec ce logiciel.

C’est là qu’est arrivé l’outil balsamiq. Spécialement fait pour créer des maquettes de sites, d’applications web et d’applications mobiles. J’ai pu mettre au point des maquettes stylisées de ce que je cherche à atteindre en quelques dizaines de minutes. L’outil est à utiliser en ligne, il est gratuit et à conseiller partout autour de vous.  (gratuit dans une version d’essai web qui possède déjà bcp de fonctionnalités)

Voici des maquettes réalisées avec Balsamiq décrivant l’organisation visuelle et comportementale de 2 pages du back-office de Web Your Daily Way. Ca me semble parlant…

Reste plus qu’à le coder…

La création de lignes est le point noir actuel de l’application. Il n’y a pour le moment en base qu’une branche du RER A, la ligne 1 et le T2. Je les ai rentrés à la main en utilisant des feuilles Excel mais il est nécessaire de développer un outil permettant de créer et d’éditer des lignes. Par ailleurs, comme je vise toute la France (dans un premier temps) il m’est impossible de rentrer les lignes entièrement par moi même.

Ancienne approche

Mon approche originelle était de dire : l’utilisateur rentrera lui même sa ligne. Mais arriver à rendre ergonomique cette fonctionnalité est un vrai casse tête. Créer une ligne doit prendre en compte les paramètres suivants :

• Il faut Géolocaliser chaque arrêt de façon précise
• Un arrêt est associé à une station. l’utilisateur ne fait pas la différence entre station et arrêt mais c’est pourtant bien différent. Un arrêt est associé à une seule ligne. une station peut contenir plusieurs arrêts de plusieurs lignes. (par exemple Chatelet-les-halles est une station composée de nombreux arrêts de différentes lignes. La ligne 4 possède même 2 arrêts associés à cette station ayant pour l’un le nom “chatelet” et pour l’autre le nom “les halles”)
  Le cas le plus généralement utilisé est pourtant que l’arrêt et la station soient confondus et qu’une station ne possède qu’un seul arrêt. 
• Le cas le plus simple est juste d’avoir une ligne composée d’une branche sur laquelle le moyen de transport fait l’aller retour. Il y a toutefois de nombreuses exceptions: La ligne peut se scinder en plusieurs branches, un trajet aller peut être différent du trajet retour (c’est très fréquent dans les bus qui passe par une rue à sens unique à l’aller et une autre rue à sens unique au retour). 
• Si on se base sur du communautaire, on s’expose à des erreurs et des sabotages. Il faut donc mettre en place un système de modération.

Mon approche d’il y a encore quelques jours était de chercher à créer cette fonctionnalité dans l’application. Or rentrer une ligne et ses arrêts sur un aussi petit écran de façon ergonomique et en gérant toutes les exceptions citées plus haut est un véritable casse tête.

Nouvelle approche

Suite à la soirée SFR, il m’a été soufflé une idée que j’avais éludé trop vite à l’époque de mes premières reflexions : 

Ne pas créer cette fonctionnalité dans l’application android et le faire en version WEB. En effet, sur un écran d’ordinateur, la gestion de toutes ces exceptions sera beaucoup plus facile.

Je vais donc retirer cette fonctionnalité de la première version de l’application et la créer en version WEB (en GWT vraissemblablement) 

Une fois cet outil web créé, j’aurai besoin de volontaires pour m’aider à remplir les différents réseaux des différentes villes de France. (des volontaires ?)

Autre approche

Utiliser un système d’insertion totalement automatisé en me basant sur des bases de données libres de droit.

Cette approche ne me permettra probablement jamais de tout couvrir d’un coup et nécessitera surement quelques ajustements avec l’outil web mais un préremplissage d’une grosse partie des données est une approche que je continue de creuser.

Je recherche à ce titre des gens qui pourraient m’indiquer où trouver de telles bases de données (API google??) Si vous avez des infos n’hésitez pas à commenter ce billet ou à m’écrire directement par mail.

Les fonctionnalités principales de l’application WYDW se basent sur l’aspect communautaire. Le concept actuel nécessite donc d’avoir une masse critique d’utilisateurs pour rendre ces fonctionnalités communautaires intéressantes.

Je me retrouve donc face à un dileme : Au démarrage de l’application, il n’y aura pas assez de monde pour que cette communauté soit présente. Or sans cette communauté, l’utilisateur risque de ne pas trouver l’application interessante.

Je suis à l’écoute de toute idée.

Voici les miennes :

Avoir une communauté déjà présente dès le départ

A l’aide de ce blog, de buzz au moment du lancement. Le concours SFR était un vecteur interessant mais le timing fait que ce vecteur sera froid au moment de la sortie de l’application.

Je suis à l’écoute de toute idée et d’aide sur ce point.

Par ailleurs, si vous lisez ce post, n’oubliez donc pas de vous abonner au flux RSS afin d’être tenu au courant et d’installer l’application sitôt celle ci sur la market place

Offrir des services ne necessitant pas de communauté d’utilisateurs

Afin de fidéliser les utilisateurs de lignes peu ou pas encore couvertes par la communauté, il serait interessant de leur fournir des services qui n’ont pas besoin de cette dite communauté.

• En fournissant des statistiques sur le temps mis par la personne
• En utilisatnt des webservices RATP/RTM ou autre afin d’avoir de façon non communautaire des informations clés sur la ligne
En partageant le trajet et les statistiques du trajet sur des réseaux sociaux. Par exemple en twittant automatiquement le temps de trajet mis lorsqu’il est anormalement lent ou anormalement rapide “Aujourd’hui, j’ai mis que 30 minutes (contre en moyenne 40 minutes) sur mon trajet Boulot” ou “Aujourd’hui j’ai mis 1h30 (contre en moyenne 40 minutes) sur mon trajet Boulot”

Simplifier l’utilisation

L’idée est de rendre l’utilisation la plus simple possible en diminuant au maximum la barrière de prise en main.

• En ayant un maximum de données déjà présentes au lancement. L’utilisateur n’aura donc pas à créer de ligne. elle sera déjà présente
• Travailler l’ergonomie de l’enregistrement du trajet. En utilisant notamment la géolocalisation et les cartes plutot que le nom de la station de départ.

Hier soir se tenait la soirée de cloture du concours SFR

A l’origine, ce concours m’avait donné l’impulsion pour démarrer le projet et j’étais convaincu que le concept de WYDW remporterait l’adhésion du jury. 

Cette soirée a donc réuni une grande partie des développeurs des 104 applications déposées pour le concours. Même si WYDW  n’a pas été retenue par les juges, elle a reçu beaucoup de soutien de la part des gens présents.

Cela fait chaud au coeur. Discuter et échanger avec les autres participants m’a permis de faire avancer ma reflexion sur plusieurs points qui viendront dans d’autres posts.