Développement produit: dans quel paradigme travailler?

Il arrive que des personnes proches du sujet du développement logiciel se demandent: en quoi le travail de projet est-il différent de la création d'un MVP (Minimal Viable Product)? Il est clair que dans ce cas, chaque interrogateur a son propre contexte de la question - par conséquent, il est nécessaire d'y répondre de différentes manières. Cependant, pour résumer, la conception et le développement de produits sont très différents les uns des autres. En général, tout le monde. Ce n'est pas si facile à comprendre, alors essayons de comprendre la problématique.

Problématisation: développement de projet ou de produit

En apparence, le développement logiciel est un développement logiciel, que ce soit un projet ou un développement produit. Il existe des exigences fonctionnelles - pas toujours formalisées. Certaines exigences non fonctionnelles sont souvent négligées. Il y a des développeurs, il y a un certain gestionnaire conditionnel et il y a une méthodologie. Les développeurs ont vu à travers le code, le gestionnaire élimine les obstacles sur leur chemin, résout les problèmes avec le client final / utilisateur / client. À la fin, ils montrent une sorte de résultat. Parfois, comme ils aiment plaisanter dans l'industrie, le résultat répond même aux exigences.

Si vous regardez un peu plus loin, il s'avère qu'il y a au moins deux grands domaines de développement qui sont fondamentalement différents l'un de l'autre dans tout: de la définition des objectifs et de la formulation des exigences aux processus de mise en œuvre et à la livraison du résultat.

Ce sont les approches de développement dites «conception» et «produit». Chaque approche a ses propres caractéristiques, que nous reviendrons un peu plus loin. Ainsi, si vous approfondissez encore davantage l'approche produit, vous pouvez également mettre en évidence le développement de MVP. La création de MVP, faisant partie du développement de produit, a en même temps ses propres caractéristiques et diffère fortement du développement d'un produit déjà à part entière dans le but de l'améliorer et de l'étendre. Outre MVP, MMF (Minimum Marketable Feature) peut également être mis en évidence. MMF n'est pas le sujet de cet article, il faut juste noter que ce sont des choses différentes. Malheureusement, ils sont souvent confus, disant que tout est MVP.

Et maintenant, ayant une idée de l'existence de toutes ces différences, vous pouvez creuser plus profondément dans les détails et examiner en quoi exactement les approches diffèrent.

Projet vs produit

. , , .

: , , . “ ”, , .

, , .

, , , .

. , , . — , , , .

, , .

— -. , , : , , , , .

, . , , . — .

— 20% — 10%, — . , , — . — .

, .

, , - : , , . . : , , , .

. , , , , , . , V-model , .

, . , , . — , . — . — . ( ) — , .

. , , , . , , , , .

. . , : . , , , .

— . , . : . , , , . , .

: , , — . - “ ”. — , , , .

: . “” — , , . , “ ” .

. , , , , , , . , , , . , , .

, — . , , MVP . , — , , ..

. — “”.

— killer , . .

, , .

-, “ — — — — ” - . , , ( , ) , . — , . — — . , , — , . , “” : . , , , .

, — . , .

-, , , . — , — . — , . .

, , . , , , . . , - , full-stack .

— — . , , .

Back to MVP

, .

, MVP.

Minimal Viable Product — , “ ”, : , . , , MVP, — , .

- .

MVP — . , — , , !

, .

, , .

, , . , , , , , , . — , , , .

, , , . , , , , — . , — .

- , , , , — , !

, - ? - , . , , UX- , .

. . , , , , , ? , - . , - , , . — , .

— . - . , — . .

— , , .

, , . , .

, , MVP . — .

, . ?

. , , — . , , , , , , . , — .

— , , . , . . .

? .

. , , Scrum .

, MVP. : - ? , , -, , , , .

, Easy First, . . , , - — . , .

, — — . — , . . , - , . - , , , killer-features.

— . , . , — . Minimal Marketable Feature ( ).

MVP: , V-, . , , , . , .

use-cases , — . , — , . , . , , .

, MVP — , .

MVP — (shit and bricks). — . , “” — . -, , .

, MVP — . MVP , MMF . , . “ ”. - . — . , , .

, — — , . , , — . — , — . , , .

. , - MVP MMF. — , — , , . , , . , - , , , . , — , , . , , - , .

, , . — . . . , , , .

— , . .

, — — MVP . . — .

Mais en même temps, personne n'essaie même de penser au résultat qui serait obtenu si l'équipe abordait le problème dans le paradigme du produit. De plus, souvent ni l'équipe ni le manager ne sont simplement prêts à travailler dans ce paradigme, ils ne le comprennent pas. Et, par conséquent, ils ne savent tout simplement pas comment travailler différemment.

Mais pourquoi cela se produit et ce qu'il faut pour comprendre, être prêt et être capable d'appliquer une approche produit au développement est une autre grande conversation. Écrivez dans les commentaires si ce sujet est intéressant et les questions auxquelles vous aimeriez recevoir des réponses.