Hello,
TrĂšs bonne initiative, je suis content que Finary ait pris conscience de la situation, jâespĂšre que vous arriverez Ă prendre une bonne trajectoire.
Ce qui manque cruellement IMHO câest un bug tracker accessible qui liste les bugs et qui structure le suivi, parce aujourdâhui le suivi est tout bonnement impossible, entre les mails, les commentaires dans un thread qui parle dâun autre sujet, etc. perso je sais pas comment vous faites ^^
En tant quâutilisateur ce quâil faut bien comprendre, câest quâau delĂ du message de politesse « on va rĂ©soudre le problĂšme », ce qui compte câest le suivi et une idĂ©e de quand ca va ĂȘtre rĂ©solu. Câest comme sur github, on a en gĂ©nĂ©ral un flag qui indique la prioritĂ©. Si câest low, on sait quâil faudra ĂȘtre patient et on peut chercher une autre solution en attendant. Si câest high, on sait que ca va ĂȘtre pris en compte rapidement.
Et ça je pense que câest fondamental et que câest quelque chose que vous commencez enfin Ă comprendre, et ça fait vraiment plaisir. Je vois que le discours de Mounir est passĂ© du « Câest prĂ©vu » (lâart de ne jamais dire non, mais quand 16 mois aprĂšs le pb est toujours lĂ la confiance sâamenuise) à « On manque de dĂ©veloppeurs ». Câest un premier pas. Jâaimerais voir une plus forte transparence maintenant (ça câest pas prioritaire du coup, ça techniquement câest chaud on en parle dans 2 ans, etc.). Je fais ces remarques parce que vous vous revendiquez ouvert Ă la communautĂ© hein donc la transparence ne doit pas ĂȘtre une dissonance sur le discours, on ne veut pas entendre « oui » Ă chaque demande, on veut juste ĂȘtre tenu au courant car attendre dans le brouillard nâest agrĂ©able pour personne (comme un coup de fil au SAV, sans de temps dâattente annoncĂ© câest compliquĂ©).
Jâai personnellement mis en pause du coup la remontĂ©e de bugs sur lesquels je tombe tant quâun bug tracker ne sera pas mis en place (le dernier bug remontĂ© câĂ©tait justement le pb du & il y a 3 mois) parce que je sens que vous ĂȘtes complĂ©tement sous lâeau en ce moment.
Les gens devraient par ailleurs voter pour des nouvelles fonctionnalités, pas pour la correction de bugs.
Typiquement pourquoi je dois choisir dans la mĂȘme catĂ©gorie entre:
- « Nous affichons « amp » au lieu de « & » (ex : Amundi PEA S&500) = amĂ©lioration de lâaffichage »
- « [Bug] Le symbole « + » sâaffiche Ă la place du « % »
et
- " [Community] Permettre aux utilisateurs de se connecter Ă la communautĂ© depuis lâapp"
Ca nâa aucun rapport. Les 2 premiers sont des bugs/rĂ©gressions, ca devrait aller en haut du backlog et ĂȘtre gĂ©rĂ© en prioritĂ© par rapport au 3Ăšme qui est une nouvelle fonctionnalitĂ©.
2 autres points importants tant quâĂ rĂ©diger un texte long :
-
concernant lâapp VS mobile, je plussoie les remontĂ©es sur le fait de garder les fonctionnalitĂ©s synchrones. Comme Mounir interprĂšte Ă tort « 90% de nos utilisateurs utilisent la version mobile » par « 90% de nos utilisateurs nâutilisent pas la version web », jâai dĂ©sinstallĂ© la version mobile qui Ă©tait « gadget » dans mon utilisation, ca fera monter les stats.
-
le fait de vouloir automatiser lâimport de transactions ne devrait pas se faire au dĂ©triment dâavoir des donnĂ©es justes. Les problĂ©matiques toujours actuelles telles que:
devraient ĂȘtre prioritisĂ©es devant nâimporte quelle nouvelle fonctionnalitĂ©. Ca me fait penser au Monkey and the pedestal.
Bonne soirée!