![\"Swing-Software](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
Bildquelle: perfectdigital.com<\/em><\/p>\n Ich denke, es zeigt sehr gut, dass gro\u00dfe Diskrepanzen und ein Mangel an Visionen in den folgenden Bereichen auftreten k\u00f6nnen Software-Entwicklung<\/a> Projekte zwischen allen Beteiligten und Betroffenen.<\/strong> Probleme entstehen oft schon zu Beginn, wenn der Kunde mit einem (theoretisch) endg\u00fcltigen Angebot kommt. Produkt<\/a> Vision und stellt sie der Kommission vor. Team<\/a>. Es kommt zu weiteren Missverst\u00e4ndnissen, Fehlinterpretationen und schlie\u00dflich zu einer Projekt<\/a> schnell den falschen Weg der Entwicklung einschl\u00e4gt.<\/p>\n Bei der Analyse des obigen Diagramms werde ich Schritt f\u00fcr Schritt alle m\u00f6glichen Bedrohungen aufzeigen und Vorschl\u00e4ge machen, wie man sie bek\u00e4mpfen kann. Kommen wir gleich zur Sache!<\/p>\n Es wird Diskrepanzen geben in der Produktvision<\/a> von Anfang an. Und warum? Der Grund ist ganz einfach: Jeder interpretiert die Realit\u00e4t auf seine eigene Weise, hat eine Vorstellung von etwas im Kopf und kann diese Vision seinem Gegen\u00fcber nicht genau vermitteln. Wenn Sie mit Worten ein Produkt beschreiben, das Sie gerne bauen w\u00fcrden, ist die Wahrscheinlichkeit gro\u00df, dass die Entwicklungsteam<\/a> wird Ihre Vision anders verstehen, als Sie es beabsichtigt haben.<\/p>\n Das l\u00e4sst sich nat\u00fcrlich vermeiden. Sie sollten so fr\u00fch wie m\u00f6glich mit der Visualisierung beginnen und einzelne Elemente der Produktfunktionalit\u00e4ten anhand von Skizzen diskutieren. Interessanterweise haben die ersten Skizzen meist nichts mit dem Endprodukt gemeinsam. In diesem Stadium kommt es jedoch vor allem darauf an, die Vision koh\u00e4rent zu gestalten.<\/p>\n Sie fragen sich, warum das erste und das zweite Bild so unterschiedlich sind? Der Projektleiter wird sich die Produktvision immer etwas genauer ansehen. Wie auch immer, ist es wichtig, dass eine solche Person, die im Wesentlichen f\u00fcr die gesamte<\/strong> Software Entwicklungsprozess<\/a><\/strong>, das Problem und die Bed\u00fcrfnisse in Bezug auf das Produkt vollst\u00e4ndig versteht<\/strong>. Der Projektleiter muss ein klares \"Gesamtbild\" haben. Wie Sie sehen k\u00f6nnen, unterscheiden sich die beiden Bilder nicht in ihrer Funktionalit\u00e4t. Sie sehen nur anders aus. Um diesen Punkt besser zu verstehen, lassen Sie uns zum ersten Bild zur\u00fcckkehren. Zu Beginn des Projekts gab es keine Skizzen, und das f\u00fchrte bereits zu einem Missverst\u00e4ndnis. Die Funktionalit\u00e4t des Produkts ist richtig, aber das Design ist v\u00f6llig anders.<\/p>\n Manchmal kennen Analysten und Entwickler die Bed\u00fcrfnisse der Benutzer oder die festgelegten Gesch\u00e4ftsziele nicht. Sie sehen nur den kleinen Teil des Gesamtprojekts, der ihr Hauptaugenmerk einnimmt. Sie sind nicht in der Lage, das Projekt aus einer breiteren Perspektive zu betrachten. Dies ist insbesondere bei gro\u00dfen Projekten der Fall, an denen viele Entwickler gleichzeitig arbeiten.<\/p>\n Wir k\u00f6nnen auch ein anderes Beispiel verwenden. Es kann vorkommen, dass das zu l\u00f6sende Problem z. B. vom Produkteigent\u00fcmer falsch beschrieben wird. Dies bedeutet, dass unvollst\u00e4ndige Informationen geliefert werden, auf deren Grundlage die Entwickler<\/a> oder Designer kreieren ihre eigenen Interpretationen, und das Produkt weicht immer mehr vom vorgesehenen Entwicklungspfad ab.<\/p>\n Wie kann man das \u00e4ndern? Meiner Meinung nach besteht eine gute L\u00f6sung darin, daf\u00fcr zu sorgen, dass die Personen, die f\u00fcr das Projekt entscheidend sind, detaillierte Kenntnisse \u00fcber das Projekt haben - das so genannte \"Gesamtbild\". Im Falle von Missverst\u00e4ndnissen wird es f\u00fcr sie einfacher sein, die Software-Entwicklungsprozess<\/em> wieder auf den richtigen Weg zu bringen. Denken Sie also daran: Wenn jeder nur seinen winzigen Ausschnitt der entwickelten Funktionalit\u00e4t sieht, werden Missverst\u00e4ndnisse in der Vision zu einer wahrscheinlichen Bedrohung.<\/p>\n Hier ist die Sache einfach. Das Produkt muss sich verkaufen. Man muss sich irgendwie abheben, damit zum Beispiel eine einfache Schaukel f\u00fcr Ihren Garten au\u00dfergew\u00f6hnliche Elemente erh\u00e4lt. Es geht darum, einen potenziellen K\u00e4ufer zu \u00fcberzeugen. Die Marketing- und Vertriebsabteilung wird sicherlich alles tun, um zu zeigen, dass das Produkt einzigartig ist.<\/p>\n Fehlende Dokumentation ist ein sehr h\u00e4ufiges Problem. Manchmal ist die Erstellung der Dokumentation w\u00e4hrend Produktentwicklung<\/a> scheint eine unn\u00f6tige Zeitverschwendung zu sein. Das ist ein Irrtum. Ich sage sehr oft, dass \u00c4nderungen auf dem Papier schneller vorgenommen werden als in der Praxis. Code<\/a>und es ist etwas dran. Au\u00dferdem ist es einfacher, sich auf die Dokumentation zu beziehen, um eventuelle \u00c4nderungen nachzuvollziehen. Glauben Sie mir, ein Projekt ohne Dokumentation birgt ein sehr hohes Risiko, die Vision zu verfehlen.<\/p>\n In dieser Phase geht es darum, die Umgebung auf dem Server zu platzieren. Wie in dem Punkt \u00fcber Programmierer und Analysten, ohne vollst\u00e4ndige Daten<\/a> und bei Kommunikationsl\u00fccken kann sich herausstellen, dass nur ein Teil des notwendigen Umfelds geschaffen wurde.<\/p>\n Es ist das Ergebnis von schlechter Kommunikation, mangelnder UX<\/a> und so weiter. Das Auftreten von Fehlern verl\u00e4ngert die Entwicklungszeit. Und Zeit ist Geld, nicht wahr? Mein Tipp ist, das Projekt nach dem Agile-Prinzip durchzuf\u00fchren.<\/a><\/strong>halten Sie die h\u00f6chsten Kommunikationsstandards ein und halten Sie klare Budgetvorgaben ein. Ich habe keinen Zweifel daran, dass Sie auf diese Weise solche Probleme vermeiden werden.<\/p>\n Die Kunden konzentrieren sich h\u00e4ufig nur darauf, ein Produkt zu bauen und damit fertig zu werden. Wir leben jedoch in einer Zeit vieler Ver\u00e4nderungen und technologischer Innovationen, weshalb es notwendig ist, einen st\u00e4ndigen technischen Support zu leisten. Es geht darum zu vermeiden, dass etwas pl\u00f6tzlich nicht mehr funktioniert, weil es veraltet ist und das Produkt seinen Wert verliert. Auch dieser Aspekt sollte nicht vergessen werden.<\/p>\n Wir haben den letzten Punkt erreicht. Sehen Sie sich die Diskrepanz zwischen dem ersten und dem letzten Diagramm an. Beide beziehen sich n\u00e4mlich auf die Perspektive des Kunden. Warum ist das so? So einfach ist das nicht \ud83d\ude42 Umfrageergebnisse weichen immer von den tats\u00e4chlichen Bed\u00fcrfnissen der Befragten ab. Bei der Beantwortung der Fragen des Forschers wollen sich die Nutzer von ihrer besten Seite zeigen. Deshalb, SIE ANTWORTEN OFT NICHT WAHRHEITSGEM\u00c4SS<\/strong>sondern eher so, wie sie glauben, dass sie antworten sollten. Im Grunde wollen sie sich nicht der negativen Bewertung anderer aussetzen. Hier ein kleiner Tipp f\u00fcr Sie: Erw\u00e4hnen Sie in der Anleitung, dass es weder gute noch schlechte Antworten gibt.<\/p>\n Wo treten die Unterschiede noch auf? Die Menschen wissen oft nicht, was sie wirklich wollen. Nicht selten sagen die Nutzer anfangs, dass sie 10 Funktionen in einem Produkt ben\u00f6tigen, und sp\u00e4ter nutzen sie tats\u00e4chlich nur, sagen wir, 3.<\/p>\n Wie l\u00e4sst sich dieses Problem also l\u00f6sen? Fragen Sie nicht nur die Nutzer, was sie wollen und brauchen, sondern lassen Sie sie auch das Produkt testen, vorzugsweise an authentischen Gegenst\u00e4nden, um die Glaubw\u00fcrdigkeit zu wahren. Je mehr Tests bei der Erstellung von Produkten durchgef\u00fchrt werden, desto gr\u00f6\u00dfer ist die Chance, dass das Ergebnis korrekt ist.<\/p>\n Wenn Sie jemals Mitglied einer der folgenden Organisationen werden Software-Entwicklung<\/a> Projekt, denken Sie an meine Beispiele und ziehen Sie Schlussfolgerungen, um die oben genannten Fehler nicht zu kopieren. Und denken Sie daran, dass diese Konzepte sehr wichtig sind, um ein Produkt (eine Anwendung) von Grund auf zu entwickeln:<\/p>\n - gute UX und Tests, damit Sie erfahren, was Ihre Nutzer wirklich brauchen,<\/p>\n - Kommunikation innerhalb des Projekts, so dass die Schl\u00fcsselpersonen des Projekts ein tiefes Verst\u00e4ndnis f\u00fcr das Problem und die Bed\u00fcrfnisse haben,<\/p>\n - die Entwicklung des Produkts in \u00dcbereinstimmung mit Agil<\/a>,<\/p>\n - Vergessen Sie nicht den technischen Support.<\/p>\n Lesen Sie mehr:<\/strong><\/p>\n - Wie verwaltet man effektiv Remote-Entwickler? Der Leitfaden f\u00fcr CTOs<\/a><\/p>\nSie kennen dieses Bild, nicht wahr?<\/h2>\n
1. Wie hat der Kunde die Idee erkl\u00e4rt?<\/strong><\/h2>\n
2. Wie hat der Projektleiter es verstanden?<\/strong><\/h2>\n
3. Wie hat der Analytiker sie entworfen? und<\/em><\/strong> 4. Wie hat der Programmierer es geschrieben?<\/strong><\/h2>\n
5. Wie hat der Unternehmensberater es beschrieben?<\/strong><\/h2>\n
6. Wie wurde das Projekt dokumentiert?<\/strong><\/h2>\n
7. Welche Vorg\u00e4nge wurden installiert?<\/strong><\/h2>\n
8. Wie wurde dem Kunden die Rechnung gestellt?<\/strong><\/h2>\n
9. Wie wurde sie unterst\u00fctzt?<\/strong><\/h2>\n
10. Was hat der Kunde wirklich gebraucht?<\/strong><\/h2>\n
Zusammenfassung<\/strong><\/h2>\n