Software / MVP-Entwicklung
MVP-Entwicklung
Eine erste Version, gebaut, um eine konkrete Frage zu beantworten, und keine verkleinerte Kopie des Produkts, das Sie am Ende haben wollen. Software, und Hardware, wo die Idee davon abhängt: Wir haben unser eigenes Gerät vom Schaltplan bis zum Messergebnis gebracht, deshalb muss ein MVP für ein vernetztes Produkt nicht auf zwei Anbieter verteilt werden.
Wofür ein MVP da ist
Ein MVP ist ein Experiment. Wenn es nicht so angelegt ist, dass es Sie enttäuschen kann, ist es keins.
Die nützliche Frage ist nie „Lässt sich das bauen?“; bauen lässt sich fast alles. Die Frage ist, ob eine bestimmte Annahme stimmt: dass Menschen es nutzen, dass die Physik auf der nötigen Entfernung funktioniert, dass die Integration möglich ist, dass jemand dafür bezahlt. Ein gutes MVP ist das Kleinste, was diese Frage beantwortet, und es wird von der Frage aus rückwärts entworfen.
Die meisten MVPs scheitern am Umfang, nicht an der Technik. Funktionen sammeln sich an, weil man ihnen leicht zustimmt, der Aufbau zieht sich, und wenn es fertig ist, ist es zu teuer, um es wegzuwerfen. Genau dafür muss ein Experiment aber günstig genug bleiben. Die Disziplin besteht darin, vorher festzulegen, was Sie nicht bauen.
Zwei Arten, die wir bauen
Software-MVP
Eine Produktidee, die echte Nutzer braucht
Eine funktionierende Anwendung, in der der eine Weg, auf den es ankommt, sauber gebaut ist und alles andere bewusst fehlt. Echte Daten, echte Konten, echter Betrieb, denn ein Experiment auf einem Prototyp, der mit einem echten Nutzer nicht zurechtkommt, beantwortet die falsche Frage.
MVP für vernetzte Geräte
Eine Idee, die es erst mit Hardware gibt
Sensor, Platine, Firmware und der Dienst dahinter, von allem so viel, dass sich die Annahme prüfen lässt, auf der das Produkt beruht. Das ist der schwierigere Fall, und der, in dem es am meisten zählt, Hardware und Software in derselben Woche ändern zu können.
Bei der zweiten Art hören die meisten Agenturen auf, und die meisten Hardware-Dienstleister haben noch nicht angefangen. Braucht Ihre Idee beides, wird bei zwei Anbietern jede Unsicherheit zu einer Verhandlung darüber, wessen Problem sie ist.
Wir haben das an uns selbst gemacht
Wavegrasp ist unser eigenes MVP, bis zum Ende durchgezogen: eigene Erfassungsplatinen, ein synchronisiertes Mikrofonarray mit acht Kanälen, Echtzeit-Firmware, Richtungsschätzung direkt auf dem Gerät (Direction of Arrival), ein um das Array herum konstruiertes Gehäuse und die Taktverteilung zu einem zweiten Knoten. Gebaut wurde es, um eine Frage zu beantworten: ob passive akustische Sensorik eine Drohne im Tiefflug genau genug orten kann, um nützlich zu sein.
Die bisherige Antwort ist gemessen und mit ihren Grenzen veröffentlicht: 1,44° mittlerer absoluter Peilfehler über 197 kontrollierte Messungen und 2,3° medianer Fehler gegenüber einer per RTK-GPS verfolgten Drohne im Nahbereich. Eine frühere Array-Geometrie wurde gebaut, charakterisiert und verworfen, als eine einfachere bessere Messwerte lieferte. So sieht ein sauber durchgeführtes Experiment aus.
Ablauf
- 01
Die Frage benennen
Was muss wahr sein, damit das funktioniert, und welche einzelne Annahme ist am ehesten falsch? Alles Weitere dient dazu, genau das zu prüfen.
- 02
Festlegen, was nicht dazugehört
Die Ausschlussliste wird aufgeschrieben, und sie ist länger als die Funktionsliste. Dieser Schritt sorgt dafür, dass ein MVP ein MVP bleibt.
- 03
Den schmalen Weg bauen
Ein Weg durch das Produkt, gebaut in einer Qualität, die den Kontakt mit einem echten Nutzer oder einer echten Umgebung übersteht, und keine Demo, die nur funktioniert, wenn man sie richtig hält.
- 04
Ergebnis holen und entscheiden
Es dem aussetzen, was darüber urteilt, und das Ergebnis als Daten behandeln. Weitermachen, die Richtung ändern oder aufhören: Alle drei sind erfolgreiche Ausgänge eines Experiments.
Was Sie bekommen
- Quellcode, wo nötig Hardware-Dateien, und den Betrieb in Ihren Konten und Ihren Repositories, nicht als Pfand in unseren.
- Dokumentation, die während des Aufbaus entsteht, damit das nächste Team keine Archäologie betreiben muss.
- Eine ehrliche Darstellung dessen, was das MVP gezeigt hat und was nicht, einschließlich der Teile, die schlecht liefen.
- Eine Einschätzung, was es bräuchte, um von hier zu einem echten Produkt zu kommen, und ob der Code diesen Übergang überleben oder weggeworfen werden sollte. Manchmal sollte er weggeworfen werden.
Verwandte Leistungen
Haben Sie eine Idee, die geprüft werden muss?
Bringen Sie die Annahme mit, bei der Sie am unsichersten sind. Sie bekommen eine ehrliche Einschätzung, wie sie sich am günstigsten prüfen lässt, auch wenn die Antwort lautet, dass Sie uns dafür nicht brauchen.
Projekt besprechen →