L’histoire de Jibble
La conception d’un logiciel qui se démarque, qui est performant et qui aura un impact est difficile. Beaucoup d’équipes peuvent en faire un, quelques-unes peuvent en faire deux, mais il est rare de voir une équipe se réunir et faire les trois.
C’est ce dont j’ai été témoin chez Jibble.
Une recherche rapide sur Google validera mon point de vue – le logiciel de l’entreprise a une note impressionnante de 4,8 sur GetApp et Capterra et une note de 4,7 sur l’App Store d’Apple.
Je suis sûr que l’entreprise peut améliorer beaucoup de choses, mais notre équipe fait quelque chose de bien si ce sont nos notes. Je voulais comprendre ce qu’ils faisaient exactement, et j’ai donc décidé d’essayer de comprendre comment et pourquoi l’entreprise obtenait ces résultats impressionnants.
Je sais que les logiciels de feuilles de temps et de suivi du temps ne sont pas très attrayants; ce n’est certainement pas la même chose que de travailler pour une société de jeux comme Activision, qui développe le nouveau jeu Spider-Man.
Cependant, Jibble se targue d’être « la nouvelle norme en matière de suivi du temps », une affirmation audacieuse, mais que j’ai trouvée ancrée dans les faits. C’est le résultat d’efforts acharnés pour rendre intéressant quelque chose de banal mais significatif.
Vous voyez, les industries traditionnelles sont ce que la plupart des startups vont changer, étant donné que l’innovation la plus immédiate et la plus visible a été réalisée.
C’est pourquoi je pense que Jibble se trouve dans une position unique pour saisir un marché qui a été longtemps négligé par les jeunes fondateurs et les capital-risqueurs chevronnés.
À première vue, Jibble peut ressembler à un concept banal qui se résume à « OK, vous avez trouvé un problème, faisons un peu de code, créons une interface utilisateur, ajoutons une passerelle de paiement et mettons le tout sur le marché ».
C’est du moins ce que j’avais compris au début, avant de rejoindre l’équipe, mais comme je l’ai rapidement appris, les entreprises SaaS qui développent des logiciels complexes comme les logiciels de feuilles de temps fonctionnent différemment.
Il y a BEAUCOUP de processus à suivre, et si Jibble n’est pas Google, elle peut se targuer d’avoir une équipe très impressionnante de personnes qui dirigent le développement. Ces héros passent souvent inaperçus.
Vous avez peut-être entendu dire que les ingénieurs logiciels ne sont pas de grands communicateurs – ce sont généralement des introvertis, maîtres de leur propre domaine, et ils veulent rarement être dérangés par une interaction humaine. Ce stéréotype est vrai dans une certaine mesure.
La plupart des ingénieurs, pour être bons dans leur métier, doivent passer d’innombrables heures blottis devant leur écran faiblement éclairé à affûter constamment leur clavier, et notre équipe n’est pas différente.
Ayant été des deux côtés du fonctionnement de l’entreprise, le rôle de consommateur face au client et le rôle de développeur face au logiciel, je me trouve dans une position unique pour pouvoir commenter les raisons pour lesquelles les choses ici… fonctionnent et pourquoi garder un œil sur cette startup vaut la peine d’y consacrer du temps.
Notre processus de développement
Notre équipe passe d’innombrables heures à affiner chaque centimètre de son processus de développement, qui est le suivant:
1. Création d’idées: Trouver un problème
Notre équipe passe un temps fou avant d’écrire la première ligne de code, afin de s’assurer qu’elle n’en passe pas le double une fois la conception commencée. Comme l’a dit Abraham Lincoln:
« Donnez-moi six heures pour abattre un arbre et je passerai les quatre premières à aiguiser ma hache ».
2. Recherche complémentaire
Une fois qu’un point faible a été identifié dans le cadre de notre logiciel de suivi du temps, notre équipe s’empresse de comparer les commentaires des clients existants, les tendances actuelles et prévues du marché et les technologies pertinentes afin de trouver des points communs qui aideront à la préparation des logiciels nécessaires pour prendre une décision en toute connaissance de cause.
3. Recherche interne: Discussions avec l’équipe
Une fois les données recueillies, les actionnaires concernés sont impliqués, notamment les propriétaires de produits, les responsables de produits, les directeurs techniques, les concepteurs principaux et les chefs d’équipe de toutes les sections. Une fois que l’équipe a eu un débat interne sur le pour et le contre, les ressources par rapport au temps, et le retour sur investissement attendu de la décision que nous sommes sur le point de prendre, il est demandé à chacun de prendre le temps d’exprimer ses préoccupations et d’exprimer la direction qu’il pense que nous devrions prendre et pourquoi ou pourquoi pas.
4. Prise de décision: Le faire maintenant ou le faire plus tard – quel sera l’impact sur l’entreprise?
Une fois que la situation s’est apaisée et qu’une conclusion a été tirée, l’équipe choisit la décision qui s’aligne sur la vision de l’entreprise et ses objectifs immédiats ou escomptés. Si la décision ne répond pas à ces critères, elle n’est pas retenue.
Les décisions sont souvent (mais pas toujours) liées à l’amélioration de fonctionnalités existantes ou au développement de nouvelles fonctionnalités. Une fois que le feu vert a été donné à l’une ou l’autre de ces décisions, il s’agit de savoir où la placer dans la feuille de route; devons-nous le faire maintenant, le mois prochain, le trimestre prochain, ou le mettre en attente?
Dans ce cas, nous examinons l’impact de notre décision sur les clients existants, les futurs intéressés et la capacité actuelle, puis nous prenons une décision.
5. Recherches sur la conception
Une fois que le délai de mise en œuvre de la fonctionnalité a été fixé, nous devons trouver des idées sur la façon dont elle se présentera. C’est un point sur lequel beaucoup de nouveaux entrepreneurs et de propriétaires de logiciels se trompent. Ils se focalisent trop sur la fonctionnalité du produit alors qu’ils devraient aussi s’assurer que toutes les fonctionnalités s’intègrent bien dans le puzzle visuel.
6. Spécification
L’étape suivante est le casse-tête des développeurs de logiciels: la documentation. La spécification est l’étape où l’on écrit la portée du projet que l’on est en train de développer. C’est là que l’idée est écrite et développée sur un document qui sera la source de vérité pour le développement, les tests et la vérification des bugs.
Elle précise ce que sera la fonctionnalité dans son ensemble, explique à quoi elle ressemblera et décrit l’objectif final (pour l’instant, nous ne nous intéressons pas beaucoup aux indicateurs). Il existe également une documentation technique rédigée par nos développeurs. Voici comment nous procédons actuellement pour rédiger les spécifications :
- Projet initial du chef de projet
- Les chefs d’équipe examinent les spécifications initiales et laissent des commentaires concernant la faisabilité technique ou des suggestions alternatives.
- Modifications apportées par le chef de projet
- Nouvelle discussion (les étapes 2 et 3 peuvent être répétées plusieurs fois en fonction de la complexité du projet).
Notre équipe s’assure que tous les cas de figure sont également pris en compte pendant cette période, mais si la conception est ponctuelle, nous mettons un terme définitif aux discussions sur les spécifications. D’ici là, les itérations sont possibles.
7. Conception du logiciel
Nos brillants concepteurs construisent plusieurs maquettes avec un assortiment d’options d’affichage. Tout est généré en gardant à l’esprit la palette de couleurs de Jibble.
Tous les écrans possibles et imaginables – mobile, web, tablette – ainsi qu’un large éventail de tailles d’écran, tout est pris en compte à ce stade.
8. Mise en place du backend et tests unitaires
La plupart des fonctionnalités commencent par le backend. Notre backend doit supporter la fonctionnalité avant que nous n’ajoutions l’interface utilisateur et la logique du côté des clients et que nous n’ajoutions notre API. Des sessions de toilettage sont donc organisées avec notre équipe pour affiner les tickets et les tâches sur la base des spécifications, puis l’affectation des tickets est effectuée lors de la planification du sprint du backend.
Notre équipe est également responsable du développement de tests unitaires pour le code qu’elle écrit afin de s’assurer que toutes les fonctionnalités fonctionnent comme prévu. C’est à ce stade que l’architecture des fonctionnalités est créée. Un bon modèle de fonctionnalité facilitera le processus de développement pour les clients.
9. Mise en place par le client et tests unitaires
Maintenant que notre backend a été mis en place, les équipes de développement mobile et web vont commencer leurs implémentations des exigences fonctionnelles respectives. Le processus est à peu près le même que pour le backend, mais l’affinage des tickets se fait principalement en dehors des appels de planification.
Les clients se réfèrent principalement aux spécifications, aux conceptions et à la structure du modèle backend de la fonctionnalité pour mettre en place leur code. Sur mobile, nous avons deux équipes différentes pour l’interface utilisateur qui suivent un ensemble logique partagé ; cela permet d’optimiser la livraison et de réduire la redondance. Les tests initiaux sont exécutés par votre équipe de développement, puis transmis à l’assurance qualité pour des vérifications manuelles.
10. Tests de qualité d’acceptation
Au fur et à mesure que les fonctionnalités sont développées, elles sont mises en place dans nos environnements de test, où l’équipe d’assurance qualité effectue des tests d’acceptation rigoureux. En d’autres termes, nous testons les fonctionnalités développées du logiciel de suivi du temps afin de nous assurer qu’elles fonctionnent conformément aux attentes. Si des problèmes sont détectés, nous retournons à l’atelier pour des révisions et des améliorations.
11. Tests de régression en assurance qualité
Si toutes les fonctionnalités fonctionnent comme prévu, elles sont alors envoyées en production où elles sont à nouveau testées, cette fois pour s’assurer que les correctifs existants ne mettent pas à mal ce qui fonctionnait auparavant.
Le test de régression est défini comme un type de test logiciel visant à confirmer qu’une modification récente du programme ou du code n’a pas eu d’effet négatif sur les fonctionnalités existantes. Ici, chez Jibble, nous effectuons deux types de tests de régression : L’un est un test de régression informel ou mineur, qui est effectué dans le cadre des tickets de test d’acceptation qui ont des problèmes et nécessitent d’être corrigés. L’autre est le test de régression par itération du cycle complet, qui est effectué vers la fin du sprint connu comme le cycle avec une plus grande couverture en se concentrant sur le chemin critique des fonctionnalités sélectionnées.
Pour l’instant, nous l’exécutons manuellement avant que les scripts d’automatisation ne soient complètement prêts.
12. Tests préliminaires
Notre équipe étant agile dans le développement de son logiciel de feuille de temps, tout ce qui précède se fait par cycles de deux semaines. En dehors de ces cycles, ou pendant les périodes où la charge de travail est relativement faible, notre équipe effectue des tests préliminaires – ce qui signifie simplement garder un œil sur tout et signaler les améliorations qui doivent être corrigées à chaud.
Nous effectuons également des tests préliminaires lors des tests d’acceptation, qui couvrent le champ d’application étendu du ticket lui-même.
13. Mise en production
Enfin, après tous ces efforts, notre projet est mis à la disposition du monde. Vous ne vous attendiez pas à ce que la création d’un logiciel de feuille de temps prenne autant de temps, n’est-ce pas?
À retenir
Pour créer un superbe logiciel, il faut avoir une superbe vision et ne pas s’en écarter lorsque le vent tourne. L’équipe de suivi du temps de Jibble comprend qu’il est sage de ne pas céder aux tendances trop rapidement ; elle est déterminée tout en procédant à des itérations constantes pour s’améliorer. En même temps, ils exécutent des stratégies dans le but de rester fidèles à leur vision de ce qui devrait être « le nouveau standard du suivi du temps ». Je pense que cela joue un rôle important dans leur récent succès.
La conclusion pour les équipes qui cherchent à reproduire le succès de Jibble dans la conception d’un logiciel de suivi du temps est la suivante: Créez rapidement, mettez en place des équipes solides et légères qui prennent le temps de faire des recherches fondées sur des données avant de prendre des décisions et employez des ingénieurs brillants qui utilisent les meilleures pratiques et la collaboration mondiale pour concevoir, tester, améliorer et livrer des fonctionnalités comme sur des roulettes. Ensuite, il faut s’asseoir et regarder la magie opérer.
