Note Julien :
Ajoutez vos commentaires où vous voulez en cliquant sur "edit"
Ceci est un draft, une sorte d'endroit où on peut commencer à réfléchir sur l'offre de service de la coopérative. C'est pas parfait donc n'hésitez pas à ajouter vos réactions / doutes / commentaires…
pourquoi cette réflexion ?
Julien, le 09/11/2021 :
Mon souci au départ est qu'on va se retrouver à suivre et développer plein de projets différents, dans plein de temporalités différentes, avec des équipes elles aussi différentes… si on part ainsi sans y réfléchir on va se retrouver avec plein de développements qui n'ont rien à voir les uns avec les autres, et surtout on aura rapidement rien à apprendre les uns des autres au sein de la coopérative…
La problématique que je cherche à poser se décompose ainsi :
- "Comment rendre notre offre de service claire et cohérente ?"
- "Quelle(s) ligne(s) suivre pour garder une cohérence dans les développements ?"
- "Comment capitaliser sur les développements afin d'avoir des propositions de plus en plus convaincantes pour les clients, perdre moins de temps à chaque fois qu'on a un nouveau projet facturé ou à facturer, et permettre à d'autres membres de la coopérative de pouvoir contribuer et s'entraider ?"
En s'inspirant de la posture d' "éditeur" de logiciel, de quelle manière poser les bases d'une stratégie/méthodo lors de chaque nouveau projet ? Quel type de checklist / canevas d'analyse utiliser pour avoir une cohérence de projet en projet ? Comment s'assurer un peu contre le bus factor ?
Proposition à challenger :
une "ligne éditoriale" pour des briques logicielles (ou méthodo design) libres :
- quel que soit l'outil/produit il doit être divisible en modules interopérable/utilisable avec un ou plusieurs des outils/produits qu'on a ou qu'on sera appelé à développer ;
- les langages utilisés doivent pouvoir l'être par la majorité des devs, pas de trucs trop exotiques pour assurer le passage de relais : python, js, docker, doc en français/anglais… ;
- le socle admin sys doit être mutualisé au max ;
- on inclut une réflexion sur l'XP / UX ;
- pas de dev sans designer ;
- pas de produit sans une équipe d'au moins 2 personnes côté tech ;
- No fork / no forking way, on cherche à généraliser le problème
- pas de produit sans une stratégie de communication, une stratégie commerciale autour du produit, et une stratégie de pérennisation ;
- on se forme / on échange sur tous les outils / micro-produits réalisés par la coopérative ;
- on investit dans la documentation ;
des "collections" de méso/micro-produits interopérables :
- collection "basics" : gestion d'utilisateurs et de mots de passe, gestion ds groupes, proxies pour mailing, …
- collection "data" : outils de backend + BDD de gestion de données génériques ou semi-spécialisées (données tabulaires, séries temporelle, …) + gestion en frontend (datapatch, spreadsheep, baserow…)
- collection "dataviz" : web components front de dataviz se branchant à des micro-produits "data" ou "transformateurs"
- collection "connecteurs" : interfaces entre des micro-produits "data" et des API / services externes
- collection "transformateurs" : intermédiaires entre des micro-produits data et dataviz, calcul d'indicateurs (agrégation, …)
- collection "vitrines" : solutions pour la partie statique de sites et pas perdre de temps sur ça, voire CMS, pouvant accueillir des micro-produits front : basics, socials, dataviz…
- collection "socials" : outils de chat / de commentaires / de temps réel / …
- collection "sécurité" : authentification / pseudonimisatiion…
"produits" déjà développés (dont on possède un bon savoir-faire) :
Produits phares :
- Apiviz
- Validata
- Data patch
- Vitrine
- Odamap
- …
…