De quels services de développement MVP devraient vous dissuader
Recherchez ceci et les pages sont interchangeables. Stratégie produit, conception UX, ingénierie, assurance qualité, déploiement, analyses, disposés dans une grille de six icônes, suivis d'une promesse sur le nombre de semaines que cela prendra. Lisez-en quatre et vous les avez tous lus, ce qui est la première chose à remarquer : tout le monde vend la même liste parce que la liste est l'unité facturable.
Ce n’est pas malhonnête, mais cela signifie que personne sur cette page n’est incité à répondre à la question sous la recherche. Une première version est définie par ce qu'elle laisse de côté, et une entreprise payée par fonctionnalité est la partie la moins bien placée pour vous dire ce qu'il faut laisser de côté. C'est donc plutôt l'argument de soustraction : ce qui sort d'une première version, ce qui doit rester même si c'est toujours la première chose coupée, et ce qui change lorsqu'il y a un modèle dans le produit.
Si la question préalable pour vous est toujours de savoir qui doit construire la chose, c'est une autre pièce : avant d'embaucher une société de développement de logiciels d'IA trie les cas où la chose que vous voulez est une fonctionnalité des cas où il s'agit d'un système.
Le minimum est une décision concernant l'apprentissage, pas la taille
La raison d'expédier tôt est de découvrir quelque chose que vous ne pouvez pas découvrir en en discutant. Cela rend le test assez restreint pour chaque élément du champ d'application : est-ce que garder cela à l'écart nous empêche d'apprendre ce que nous essayons d'apprendre ? La plupart de ce qui est intégré dans une première version échoue à ce test et est quand même construit, car c'est évident et peu coûteux et l'équipe peut voir comment le faire.
Le piège, c’est que « petit » et « minimum » ne sont pas le même mot. Une première version peut être petite et ne répondre à rien, ce qui se produit lorsque la coupure passe au milieu de l'élément testé plutôt qu'autour de celui-ci. Les coupes utiles sont celles qui suppriment tout ce qu'un utilisateur tolère être absent et laissent la partie qui le ferait revenir.
Les trois coupes avec lesquelles personne ne conteste après
Comptes et rôles. Tout ce qui est multi-utilisateur est une grande construction cachée derrière un mot à consonance petite. Des équipes, des invitations, des autorisations, un administrateur qui peut agir sur les données de quelqu'un d'autre, un propriétaire de facturation distinct d'un utilisateur. À moins que ce que vous testez ne soit une collaboration, un compte par personne répond à la question, et la version mono-utilisateur ne représente qu'une fraction du travail.
Paramètres. Chaque préférence est une branche, et chaque branche est un état dans lequel le produit doit être correct. Une première version peut faire l'objet d'une opinion. Choisissez le comportement que vous jugez correct, expédiez-le uniquement et laissez les plaintes vous indiquer quelle préférence était réellement souhaitée. Les plaintes sont des données ; un écran de paramètres construit à l’avance est une supposition avec maintenance attachée.
Étendue des contributions. C'est la plus chère et la moins visible. Les produits promettent discrètement de gérer tout ce que l'utilisateur peut leur remettre : n'importe quel type de fichier, n'importe quelle langue, n'importe quelle longueur, n'importe quelle forme de données. Chaque ajout est son propre ensemble d’échecs. Soutenir correctement le cas commun et refuser clairement le reste est une meilleure première version que de tout accepter et de ne pas être fiable d'une manière que l'utilisateur ne peut pas prédire.
Bien refuser est d’ailleurs une caractéristique. Un produit qui dit "ce fichier n'est pas encore pris en charge, voici ce qu'il est" se lit comme délibéré. Un produit qui accepte le fichier et produit quelque chose de mal est considéré comme cassé, et l'utilisateur ne revient pas pour savoir de quoi il s'agit.
La coupure qui ne devrait pas être faite : la porte de sortie
Voici celui qui est supprimé dans presque toutes les premières versions et qui ne devrait pas l'être. La sortie. Exportation et chemin de migration pour les données accumulées par le produit.
Il est supprimé parce qu'il est invisible dans une démo, parce que personne ne le demande la première semaine et parce que cela ressemble à une fonctionnalité destinée aux personnes qui partent. La raison pour laquelle il faut le conserver n’est pas la générosité. Le fait est que la forme des données est décidée dans la première version, que quelqu'un en décide ou non, et la première version est le moment le moins coûteux pour savoir si ce que vous stockez peut être restitué sous forme de quelque chose de cohérent. Créez l'exportation et vous découvrez immédiatement que trois champs sont ambigus, qu'une relation n'a jamais été enregistrée et que ce qu'un utilisateur appellerait son travail n'est en réalité assemblé nulle part.
Il n’est pas non plus nécessaire qu’il soit grand. Une simple exportation des enregistrements principaux, dans un format ennuyeux, déclenchée manuellement, suffit. L'interface utilisateur, les options de format, la planification et la sélection des champs sont eux-mêmes de bons candidats pour les trois coupes ci-dessus. Ce qui compte, c'est que le chemin existe et qu'il ait été exécuté une fois sur des données réelles, car une exportation écrite ultérieurement sur un schéma qui s'est développé par accident est un projet plutôt qu'un après-midi.
La même logique couvre le chemin de migration. Vous n'avez pas besoin d'un outil de migration dans la première version. Vous devez savoir, avant d'avoir des utilisateurs, comment les enregistrements que vous écrivez aujourd'hui seraient déplacés si le stockage en dessous changeait, et avoir noté cette réponse.
Quand il y a un modèle dedans, l'inconnu se déplace
Une première version conventionnelle comporte des risques liés aux fonctionnalités : pouvons-nous la construire, est-ce que quelqu'un l'utilisera. Une première version contenant un modèle contient cela plus un autre différent, à savoir que la chose peut fonctionner sur les exemples que vous avez essayés et se tromper assez souvent sur l'entrée réelle pour être inutilisable. Ce n’est pas une question de portée, et aucune fonctionnalité de coupe n’y touche.
Ce qui inverse l’ordre habituel du travail. Le premier artefact n'est pas une feuille de route, c'est un ensemble de cas réels avec les bonnes réponses écrites à côté, assemblés avant la construction plutôt qu'après. Sans cela, il n'y a aucun moyen de distinguer une amélioration d'un changement, et chaque décision ultérieure concernant le produit devient une question d'opinion quant à savoir si le résultat s'est amélioré. Comment évaluer l'un de ces systèmes explique d'où viennent les cas et pourquoi un benchmark public ne peut pas répondre à une question sur vos contributions.
La conséquence pratique pour la portée : la partie du produit qui dépend du modèle doit être plus étroite dans une première version que vous ne le souhaiteriez, car l'étroitesse est la seule condition dans laquelle la précision peut être mesurée. Un produit qui effectue une tâche sur un type d’entrée peut être soumis à une norme. Le même produit ne peut pas tout pointer, et vous ne pourrez pas dire s'il fonctionne.
Si vous avez déjà commencé à définir la portée et que vous êtes encore en train de décider sur quel flux de travail il convient de s'appuyer, l'évaluation de l'état de préparation à l'IA suit le même chemin qu'un engagement de cadrage s'ouvre, à travers les données, les cas d'utilisation, les compétences et l'infrastructure. C'est gratuit, et un résultat indiquant que rien n'est encore prêt est une véritable réponse obtenue à moindre coût.
Nos propres premières sorties, et le montage sur lequel nous nous sommes trompés
Nous exploitons nos propres petits produits, répertoriés sur [la page des applications] (/apps), et c'est la raison pour laquelle cet article porte sur la soustraction. Chacun d’eux a été expédié plus étroit qu’il ne l’est actuellement.
Clara, l'optimiseur de photos, a été expédiée en faisant une chose pour une photo. Les lots, l'ajustement des couleurs et la suppression des objets sont arrivés plus tard, et dans l'ordre que les vrais utilisateurs les ont demandés, ce qui n'était pas l'ordre que nous aurions deviné. Focable, l'application ciblée, est livrée sans la majeure partie de la structure qu'une application de productivité est censée avoir, car la chose testée était de savoir si un compagnon qui s'assoit à côté d'une tâche aide quelqu'un à la démarrer, et les séquences et les tableaux de bord ne nous auraient rien dit à ce sujet. LogiCI a été livré sous forme de page de destination et de politique de confidentialité alors que la question de demande était encore ouverte, ce qui ne coûtait presque rien et constituait le bon montant à dépenser pour une question sans réponse.
La coupe sur laquelle nous nous sommes trompés était celle ci-dessus. Sur plusieurs d'entre eux, l'exportation et le chemin des données sont arrivés plus tard qu'ils n'auraient dû, et c'est plus tard que vous découvrez qu'un champ que vous écrivez depuis des mois signifie deux choses différentes selon le moment où il a été écrit. Il s’agit d’un rangement sans résultat visible par l’utilisateur, qui constitue le type de travail le plus coûteux à planifier et le plus facile à éviter.
Que demander sur la portée avant de signer
Une proposition est conçue pour montrer combien est inclus. Ceux-ci atteignent l’autre côté.
Demandez quelles parties du périmètre ils supprimeraient si le budget était réduit, et dans quel ordre. Une liste qui arrive immédiatement signifie que quelqu'un a pensé au produit. Le refus de nommer quelque moyen que ce soit signifie que le champ d'application est additif et que rien n'y est défendu.
Demandez ce que la première version ne fera pas, par écrit, en tant que section du document. Les absences annoncées à voix haute constituent des engagements. Les absences non mentionnées se transforment en demandes de changement.
Demandez comment les données sortent et si l'exportation aura été exécutée sur des enregistrements réels avant le lancement. C’est la question qui sépare une construction d’un produit.
Si un modèle est impliqué, demandez quel est l’ensemble d’évaluation, qui l’assemble et quand. Si la réponse est postérieure au lancement, le projet n'a pas de définition du fonctionnement, et toute conversation ultérieure sur la qualité sera un désaccord sur la mémoire.
Demandez qui détient les comptes et l’infrastructure au moment du transfert. La distinction entre un livrable et une dépendance est la chose la plus facile à laisser ambiguë et la plus coûteuse à découvrir par la suite.
Aucune de ces questions n’est hostile, et un bon partenaire répond à toutes les cinq sans broncher, car ce sont les questions sur lesquelles débattent leurs propres ingénieurs en interne. Un fournisseur qui ne peut pas y répondre n'est pas nécessairement mauvais dans la création de logiciels. Ils vendent la grille de six icônes, et vous êtes venu ici pour savoir quoi en retirer. Si vous souhaitez que cette conversation avec la soustraction soit incluse, comment une petite entreprise devrait utiliser un consultant en IA est la forme d'engagement qui commence là plutôt qu'avec une liste de fonctionnalités.