Process mise au clair idées projets

Salut,

Je suis en train de coucher sur papier toutes les idées qui me viennent à la tête concernant un projet que j’aimerais développer. Ces idées sont de natures diverses et variées, dont voici une liste non-exhaustives :

• fonctionnalités,

• failles de sécurité anticipées,

• failles d’utilisation abusive et de triches ou de résiliations d’abonnements abusifs anticipées,

• montants des abonnements et justifications de la notion d’abonnement en expliquant pour quoi l’utilisateur le paie (quels sont les services offerts pour lui par le site qui pourraient l’intéresser = arguments de vente),

• interactions entre les différents types d’utilisateurs,

• publics visés,

• présentations rapide et détaillée de l’ensemble du site puis de chaque fonctionnalité,

• arguments pour inciter les utilisateurs à rester sur le site s’ils veulent annuler leur résiliation

• une conclusion pour dire si oui ou non ce projet me semble économiquement viable,

• etc.

Mon doc fait 30 pages C’est beaucoup trop et plus ça va moins j’ai envie d’écrire. Comme j’arrive au bout, je vais cependant continuer de le faire. C’est un document qui me semble indispensable vu qu’il regroupe de façon structurée (= organisée par sections titrées) toutes les idées que j’ai. Idées que sinon j’aurais oubliées. Cependant, au vu de sa longueur, il ne me semble pas facilement exploitable pour directement passer à la phase de développement (= je risque d’oublier des idées pourtant écrites dedans).

La conséquence de cela est simple => Je dois selon moi rédiger d’autres documents reprenant des idées, par thème, de ce document. Ce qui devrait me simplifier la vie lors du développement pour retrouver telle ou telle idée à développer, par thème.

Pensez-vous que ce process est bien rôdé ? Vous y prenez-vous autrement ?

Bonne journée et merci d’avance !

Les outils type Trello, c’est pas mal pour ça aussi

Salut,

On ne sait pas comment ton document est structuré exactement, donc dur de donner des conseils ciblés.

Une séparation habituelle est de séparer le pourquoi et le quoi. Le pourquoi, c’est le besoin, c’est-à-dire le problème que cherche à résoudre tes clients. Le quoi, c’est le produit ou service que tu proposes pour le résoudre.

Par exemple, un besoin fictif pour un utilisateur lambda pourrait être « trouver du bon pain près de chez moi », et une manière de le faire, c’est « un annuaire des artisans boulangers sous forme de site web avec une recherche par localisation et une notation ».

On peut d’ailleurs adresser des besoins pour différentes catégories d’utilisateurs (ton cas). Un artisan boulanger sur la plateforme aura des besoins plutôt du type « augmenter ma clientèle » avec une manière de le faire du genre « avoir une visibilité auprès des utilisateurs de l’annuaire proche de ma boutique ».

Les fonctionnalités détaillées sont en général décrites dans des documents séparés et plus détaillés. On peut avoir une hiérarchie de documents qui décrivent ce qu’on veut. Après quand on fait du logiciel, il ne faut pas tomber dans l’excès de documentation avant de mettre les mains dans le cambouis, ça ne vaut pas le coup bien souvent.

Une autre séparation habituelle, c’est le modèle économique et le produit lui-même. On peut faire un produit relativement neutre vis-à-vis de son financement, et ensuite décider qu’on va se financer avec de la pub, ou alors les entreprises vont être abonnées et ce sera gratuit pour les particuliers, ou alors ça marche à la commission, ou alors il y a un système d’abonnement avec réduction pour les particuliers, etc.

Le public visé fait partie de cette partie modèle économique / étude de marché. On y définit précisément ce qu’on vise, ça permet ensuite de pouvoir effectivement vérifier l’adéquation du produit par rapport à la cible (et changer le cas échéant de cible ou de produit).

Bref, c’est un vaste sujet, je te conseille de jeter un œil sur comment on fait une étude de marché et comment on écrit une spécification de produit, ça pourrait te donner des idées sur ce qui marchera pour toi.

Le site BPI France Création a plein de ressources aussi.

Si ton document est trop gros, il me semble évident que c’est parce que tu ne priorises pas assez les éléments que tu y fais figurer. Dans ce que tu listes, je remarque énormément d’éléments qui sont des réponses à des questions qu’il est beaucoup trop tôt pour se poser.

Notamment :

• "failles de sécurité anticipées" : les failles de sécurité n’existent pas dans un logiciel qui n’est pas écrit, et dépendent essentiellement de la façon dont les fonctionnalités sont implémentées. Autrement dit, cette question n’a d’intérêt que lorsque tu sais comment tu vas implémenter telle ou telle fonctionnalité (quelle BDD, quel modèle d’authentification, que sais-je…), et donc tu ne devrais avoir besoin de te la poser qu’au moment où tu les conçois/implémentes. Ni avant (c’est trop tôt, ça revient à réfléchir sur du vent), ni après.
• "failles d’utilisation abusive et de triches ou de résiliations d’abonnements abusifs anticipées" : pareil.

Le problème de se poser ces questions dès maintenant, c’est que ça fige sur le papier quelque chose qui n’a pratiquement aucune chance de correspondre à la réalité une fois le projet implémenté. Quant aux fonctionnalités elles-mêmes, il est également beaucoup trop tôt pour chercher à les détailler. Ce qui devrait être clair dans ta tête avant de commencer à écrire du code, c’est plutôt :

• Savoir quel est le besoin très concret auquel tu cherches à répondre. Cela veut dire identifier tes utilisateurs (qui ?), et mettre le doigt précisément sur ce que tu veux les rendre capables de faire (quoi ?) avec ton projet, sans te fixer sur plus qu’une vague idée de comment ça se présentera pour eux.
• Avoir une idée de comment tu vas le monétiser : quel est le produit ou service que tu comptes vendre exactement ?

Tout le reste relève du "comment" et découle uniquement de ces questions. Ce sont des solutions qu’il convient de chercher seulement quand le problème se présentera concrètement devant toi, et qui ne devraient pas entrer en ligne de compte pour décider si ton projet est viable ou non. Typiquement, les fonctionnalités qui servent à répondre au besoin de tes utilisateurs vont forcément bouger dans le temps : tu n’auras jamais la bonne idée qui tue et qui résout parfaitement les problèmes du premier coup, par contre si tu te dis que tu pars en te concentrant d’abord sur l’app minimale qui soit déjà utile à tes utilisateurs, et que tu observes comment ça se comporte dans la pratique avant de corriger ta route et choisir quoi changer/retirer/rajouter, alors tu as l’assurance de converger vers un produit qui résout de vrais problèmes, tout en minimisant la quantité de travail inutile (du code qui ne répond au besoin de personne/ne sert à rien, de la doc qui ne décrit pas la réalité…).

Salut !

Merci à tous. Je prends note pour Trello et les suggestions d’arborescence de fichiers ainsi que le site de la BPI ;-)

@nohar

Pour résumer tes explications, il faudrait que je développe une app minimale répondant aux besoins utilisateurs élémentaires de manière simple, puis que je procède par itérations pour fortifier les fonctionnalités déjà présentes et en ajouter d’autres si les utilisateurs en ont besoin.

ça ne me semble pas incompatible avec ma façon de faire, qui m’a quand même ouvert les yeux :

• au niveau des failles d’utilisations&résiliations abusives, j’ai détecté 2 ou 3 soucis (auxquels aucune réponse technique n’impliquant aucune modération ne serait satisfaisante), c’était pas inutile sinon je n’y aurais pas forcément pensé. Ca ne remet pas en cause mon projet mais bon c’est relou car je sais d’avance qu’à l’avenir je rencontrerais ce souci pour peu que j’ai des utilisateurs pas piqués des hannetons éthiquement…

• au niveau des fonctionnalités : en amont j’avais bien identifié les besoins je pense (le site que je fais est simple, il met en relations des utilisateurs pour collaborer ensemble dans un thème déjà très exploité par de nombreux sites Web… mais aucun ne permet cette mise en relation/personnalisation que mon service, lui, offrira ===> donc forcément les besoins, je les connais déjà, cette étape était par définition pré-mâchée)

• "Quant aux fonctionnalités elles-mêmes, il est également beaucoup trop tôt pour chercher à les détailler. Ce qui devrait être clair dans ta tête avant de commencer à écrire du code, c’est plutôt" ===> oui c’est bien ce que j’ai fait, mais je suis aussi rentré dans les détails.

donc en résumé : tes suggestions et propositions ne sont pas incompatibles avec le contenu de mon document, qui les contient, mais qui va aussi plus loin. Et le fait d’aller plus loin ne me semble pas justement préjudiciable contrairement à ce que tu dis, car ça m’a permis d’affiner plein de trucs et de soulever des problèmes que je n’aurais pas vus sinon.

Au niveau des détails d’implémentation par contre ça n’a pas été abordé. Notamment pour les failles de sécurité => je ne faisais pas référence à des failles PHP ou que sais-je, je me suis mal exprimé.

Et le fait d’aller plus loin ne me semble pas justement préjudiciable contrairement à ce que tu dis, car ça m’a permis d’affiner plein de trucs et de soulever des problèmes que je n’aurais pas vus sinon.

Certes. Ça entre juste en contradiction avec environ 20 ans de littérature sur la question…

Ce que tu vois comme un avantage (le fait d’avoir soulevé des problèmes que tu aurais de toute façon fini par rencontrer et résoudre en temps voulu, mais cette fois en te basant sur du concret), c’est le fait d’avoir spécifié à l’avance un bon nombre de fonctionnalités qui n’ont qu’une chance infime de finir implémentées telles que tu les imagines, et donc du travail inutile.

Mais fais comme tu le sens, c’est ton temps et ton projet, et ce n’est que mon opinion.

@nohar ce que j’ai fait c’est juste un gros brainstorming pour ne pas oublier mes idées, ensuite j’ai juste creusé en cherchant à voir d’éventuels problèmes en fait. Il faut bien beaucoup réfléchir à un projet avant de se lancer dans le dev. Les fonctionnalités évolueront par la suite bien sûr.

ça me permet aussi de bien penser aux besoins utilisateurs et d’avoir des idées pour mieux y répondre. D’ailleurs pour l’anecdote, au bout d’une journée je dirais, j’ai compris que tout un ensemble de fonctionnalités ne seraient finalement pas désirables (les utilisateurs ayant forcément leur propre outil auquel ils sont déjà habitués). Si je n’avais pas écrit ce doc, je m’en serais rendu compte bien trop tard, durant la phase de dev ou pire : après.

Si je n’avais pas écrit ce doc, je m’en serais rendu compte bien trop tard, durant la phase de dev ou pire : après.

Non.

Un simple échange avec un utilisateur potentiel (ça, oui, c’est indispensable) t’aurait fait déterminer que ces fonctionnalités n’étaient ni utiles, ni prioritaires à implémenter, et tu ne les aurais même pas grattées dans ton document.

Il n’y a que les utilisateurs eux-mêmes qui savent ce dont ils ont besoin. Si tu n’es pas utilisateur, tu as toutes les chances de taper à côté (et même là tu ne sais pas si les autres vont adopter ton produit tant que tu ne les as pas rencontrés).

Il faut valider ses hypothèses le plus rapidement possible. A commencer par discuter avec les utilisateurs et développer une version minimale avec une approche type Minimal Viable Product en se concentrant sur la valeur que ton projet pourrait apporter (sur mon dernier projet, on a mis 2 mois avant de développer l’UI et encore 2 mois avant de réfléchir à une base de données parce que ça n’avait pas de sens pour les utilisateurs qu’on le fasse plus tôt)

Bonsoir,

Il y a détail, et détail.

Toutes les méthodologies de développement modernes te propose de fonctionner par itérations. ON commence par être très sommaire, et au fur et à mesure des itérations, les détails s’affinent. LE plus important, c’est de tester le plus vite possible, afin de te rendre compte au plus vite si ce que tu fais marche ou pas.

Au stade où tu en es, ça veut dire quoi tester ? Élaborer un prototype, mettre quelques utilisateurs dessus, observer ce qu’ils font et leur demander ce qu’ils pensent.

Dans un premier temps, on s’en fout du design, on s’en fout des failles de sécurité. Limite on s’en fout de comment tu vas gagner du fric aussi. On s’en fout même de la liste exacte des fonctionnalités, car il y a forcément des choses auxquelles tu n’as pas pensé, et d’autres que tu pensais utiles mais qui finalement ne s’avèreront pas l’être tant que ça.

Pour l’instant, contente-toi donc uniquement des fondamentaux, la plus petite chose que tu puisses montrer et faire essayer; le minimum de fonctionnalités qui font que ton produit peut être utilisable. C’est ce qu’on appelle le MVP déjà évoqué dans les posts précédents.

JE dirais même que pour te lancer dans un premier prototype, une page ou deux devraient largement suffire. La suite viendra progressivement. Tu te rendras très vite compte de ce qui marche ou pas quand tu auras les premiers reetours ou statistiques.

Moi-même, je ne compte plus le nombre de petits papiers que j’ai écrit pour faire des jeux. Par le passé, souvent j’allais jusqu’à décrire quelques bribes de l’environnement, des caractéristiques de monstres, ou comment est censée se passer une attaque. Verdict. aucun de ces jeux n’ont quitté mon PC. Ca ne sert à rien de tout théoriser. Ca ne marche jamais comme prévu.

Mon plus grand succès, dans sa première version c’était à peine 3 lignes de doc, et relativement peu de code plus ou moins buggé et absolument pas sécurisé. Et puis tout s’est enchaîné. Bon, la grosse différence avec toi c’est que je suis encore gratuit et que je pense le rester.

Maintenant il y a des trucs qui me font hérisser les poils…

• failles d’utilisation abusive et de triches ou de résiliations d’abonnements abusifs anticipées,
arguments pour inciter les utilisateurs à rester sur le site s’ils veulent annuler leur résiliation

Je trouve que ça sonne vachement dark pattern ! Pourquoi tu pars ? Si tu restes encore pendant au moins 2 ans on te fait une super promo.

Si un utilisateur veut partir, il part, point. Il a certainement ses raisons et tu n’as pas à lui casser les pieds avec ça. Paradoxalement on reste plus volontiers et plus longtemps chez ceux qui n’ont pas ce genre d’attitude. Ton but premier, est-ce que c’est offrir un service, ou bien entuber les utilisateurs ?

Je trouve que ça sonne vachement dark pattern ! Pourquoi tu pars ? Si tu restes encore pendant au moins 2 ans on te fait une super promo.

Si un utilisateur veut partir, il part, point. Il a certainement ses raisons et tu n’as pas à lui casser les pieds avec ça. Paradoxalement on reste plus volontiers et plus longtemps chez ceux qui n’ont pas ce genre d’attitude. Ton but premier, est-ce que c’est offrir un service, ou bien entuber les utilisateurs ?

C’est pas dans ce sens-là. Ce ne sont pas des arguments de contre-résiliation. J’ai juste listé des arguments de vente et de contre-résiliation. Ces derniers me permettent d’estimer la probabilité que les utilisateurs ne résilient pas leur abo.

Sinon oui ok pour les prototypes. Mais dans mon projet comme je l’ai dit, c’est prémâché au vu de l’existant.

Je ne vais pas rentrer dans les détails (et nan c’est pas du tout une copie de l’existant pour autant).

Mais oui effectivement pour mes futurs projets, d’une autre nature qure celui-ci, il est certain que votre méthode itérative sera bcp plus efficace.

Assure toi d’offrir un service utile, pertinent. Si ce que tu proposes est valable, les gens viendront, et ne partiront pas.

Si ta préoccupation, c’est que tes 'contacts’ s’enfuient, c’est que tu es conscient que le service que tu proposes n’est pas vraiment pertinent.

Développe quelque chose, propose un service, gratuit. Si sur ce service gratuit, tu n’as aucun utilisateur, c’est que le projet n’intéresse personne. Si tu as des utilisateurs, tu trouveras bien un moyen de gagner de l’argent avec ce service. Soit par les outils de publicité, soit en facturant toi-même tes utilisateurs.

Il sera temps de voir.

Non je cherche juste à trouver des trucs facilement anticipables. Bien sûr c’est minoritaire mais au moins c’est anticipé.

Le service est bien gratuit et recherché effectivement.

Plutôt que de "prototypes", il serait sûrement plus pertinent ici de parler de tracer bullet. Et encore, je pense que ces concepts sont tous connexes, mais distincts de ce dont il est vraiment question ici : un tracer bullet reste un code jetable qui sert à valider surtout des aspects techniques (notamment découvrir le plus tôt possible les problématiques d’intégration qu’on ne peut pas anticiper), ce qui le distingue d’un MVP qui permet de valider l’aspect fonctionnel du projet et de la réponse que l’on apporte aux besoins des utilisateurs, et par-dessus lequel on peut construire le reste.

Quoi qu’il en soit, puisque nous n’aurons visiblement aucune information supplémentaire sur le projet en question, ce thread est en train de tomber dans le travers spéculatif habituel.

• PO: demande un conseil en montrant sa première approche.
• Participants: Ton approche semble bancale pour telle et telle raison. Selon notre expérience et nos connaissances tu es en train de tomber dans un piège connu.
• PO: Mais non, pas du tout. (poursuit en montrant qu’il n’a effectivement pas saisi la réponse). De toute façon je ne donnerai pas plus de détails.

Sans détails concrets sur lesquels discuter et s’expliquer, il est strictement impossible de t’aider, car on est alors condamnés à rabâcher des généralités, à moins de se hasarder sur des présomptions et des hypothèses invérifiables.

Et nous sommes donc à nouveau face à un thread qui se termine avec le goût amer caractéristique du temps perdu.

En fait c’est ma faute, dans l’OP je n’ai pas pensé à préciser que mon projet reprend des sites déjà existants mais sous une approche différente, qui permet de mettre en relation les différents utilisateurs entre eux. Les besoins utilisateurs sont donc déjà connus, les fonctionnalités aussi => c’est pour cette raison que je parlais tout à l’heure de travail prémâché.

L’aspect "élaborer le CDC de manière itérative en parallèle d’un recueil des besoins utilisateurs" me semble ici dispensable.

Mais je suis totalement d’accord avec TOUT ce qui a été dit précédemment, juste dans un autre contexte quoi :-) .

Ma question a en fait été parfaitement répondue, si mon projet était autre que celui que j’ai actuellement…

PS : mon projet n’est pas une copie de projet existant cependant. Il apporte bien les mêmes fonctionnalités, mais au travers d’utilisateurs, et propose la mise en relation entre utilisateurs. C’est une façon de faire différente de ce qui est proposé actuellement sur Internet pour répondre aux besoins auxquels je prétends répondre et auxquels prétendent répondre les sites actuels.

Aabuu a semble-t-il apporté une réponse très intéressante qui s’applique à tout contexte de projets, notamment le mien.

PS : mon projet n’est pas une copie de projet existant cependant. Il apporte bien les mêmes fonctionnalités, mais au travers d’utilisateurs, et propose la mise en relation entre utilisateurs. C’est une façon de faire différente de ce qui est proposé actuellement sur Internet pour répondre aux besoins auxquels je prétends répondre et auxquels prétendent répondre les sites actuels.

J’ai l’impression de lire un peu "je veux faire X en mieux" de façon déguisée. Le problème c’est que souvent, vouloir "faire X en mieux", ça ne marche pas.

Assure-toi que ce que tu vas proposer est suffisament différent, ou couvre une autre région, que ce qui existe déjà. Sinon ça peut éventuellement être fun et formateur, mais c’est pas hyper utile.

Développe quelque chose, propose un service, gratuit. Si sur ce service gratuit, tu n’as aucun utilisateur, c’est que le projet n’intéresse personne. Si tu as des utilisateurs, tu trouveras bien un moyen de gagner de l’argent avec ce service. Soit par les outils de publicité, soit en facturant toi-même tes utilisateurs.

Commencer par être gratuit et devenir payant ensuite, ça peut aussi être un piège.

Je me suis senti trahi par le feu site du zéro quand ils ont pris leur virage à 180°, vers 2014.

Je me suis aussi senti trahi sur O-Game, un jeu auquel je jouais à l’époque qui était alors gratuit (en-dehors de la possibilité de supprimer la pub), lorsque les options payantes ont commencé à donner de très gros avantages aux joueurs. Ca devait être en 2005 ou 2006.

Moi-même j’ai aujourd’hui un jeu gratuit, que j’ai déjà pensé plusieurs fois à rendre payant avec plusieurs idées d’options facultatives, mais je n’ai jamais osé franchir le pas, entres autres raisons car je n’ai pas envie de pareillement trahir la communauté, quand bien même les dites fonctionnalités n’apporteraient pas d’avantages décisifs.

Au moins en étant payant dès le début, on annonce clairement la couleur et il n’y a pas de surprise. Ce qui n’empêche bien évidemment pas de proposer des offres de lancement, ou de définir une date butoire au-delà de laquelle le service ne sera plus gratuit, du moment que c’est bien écrit clairement et pas caché au fond d’une page de conditions que personne ne lit jusqu’au bout.

J’ai l’impression de lire un peu "je veux faire X en mieux" de façon déguisée. Le problème c’est que souvent, vouloir "faire X en mieux", ça ne marche pas.

non pas du tout, c’est la même chose mais d’une façon différente, c’est de la mise en relation que je propose, je ne m’occupe pas du fonctionnel contrairement à ces sites. (en gros)

et cette approche, différente, n’existe actuellement pas, dans le marché sur lequel je m’apprête à m’insérer

Commencer par être gratuit et devenir payant ensuite, ça peut aussi être un piège.

non c’est et sera tjrs gratuit pour les utilisateurs comme toi et moi. Ce sont les professionnels créateurs de contenus, mis en relation avec les utilisateurs comme toi et moi, qui paieront.

Je me suis senti trahi par le feu site du zéro quand ils ont pris leur virage à 180°, vers 2014.

idem haha

En fait c’est ma faute, dans l’OP je n’ai pas pensé à préciser que mon projet reprend des sites déjà existants mais sous une approche différente, qui permet de mettre en relation les différents utilisateurs entre eux. Les besoins utilisateurs sont donc déjà connus, les fonctionnalités aussi => c’est pour cette raison que je parlais tout à l’heure de travail prémâché.

L’aspect "élaborer le CDC de manière itérative en parallèle d’un recueil des besoins utilisateurs" me semble ici dispensable.

Source:HerbeQuiBenchEtSquat

Si les besoins utilisateur sont connus, ils sont aussi adressés.

Qu’est-ce qui t’assure que les utilisateurs adopteront une approche différente ? Pourquoi ont-ils besoin de faire différemment ? En quoi est-ce suffisamment dimensionnant pour venir chez toi ? En quoi tu seras plus attractif que les autres ? Et encore plein de questions…

C’est sur ces aspects que tu dois valider tes hypothèses.

A mon avis, une approche itérative est indispensable dans ton cas : tu vas adresser un marché sur lequel tu as du retard sur tes concurrents ; qui capturent en ce moment tous tes futurs potentiels utilisateurs (et plus tu mettras de temps à être en prod, plus ce sera compliqué).

Tu as besoin d’adresser exactement les pains des utilisateurs pour les attirer et te démarquer de la concurrence. Et pour ça, tu as besoin de leur feedback et de pouvoir t’adapter rapidement

Quand on parle d’approche itérative, on ne parle pas de rédaction du cahier des charges mais du développement lui-même