Die wichtigsten Punkte, die Ihnen niemand gesagt hat, bevor Sie mit dem Erstellen dieser App begonnen haben

Seit fast 50 Jahren - seit Frederick Brooks den Klassiker „The Mythical Man-Month“ veröffentlicht hat - haben Softwareentwicklungsteams Probleme damit, ein Projekt pünktlich und gemäß den Spezifikationen zu erstellen. Es ist keine leichte Aufgabe. Folgendes vergessen sie zu sagen, bevor Sie mit dem Erstellen dieser neuen App begonnen haben…

Das Endprodukt entspricht nicht den ursprünglichen Spezifikationen

Das Erstellen einer App sollte einfach genug sein. Sie setzen sich ein paar Leute in einen Raum, einigen sich auf ein paar Spezifikationen und lassen dann die klügsten Leute im Raum an die Arbeit gehen, um zu programmieren, was Sie gerade besprochen haben. Einfach genug, oder? Falsch. Es besteht eine sehr hohe Wahrscheinlichkeit, dass das Endprodukt nicht den ursprünglichen Spezifikationen entspricht. Dafür gibt es eine Reihe sehr guter Gründe, die nichts mit der „Inkompetenz“ des Softwareentwicklungsteams zu tun haben. Fristen ändern sich. Pläne ändern sich. In einigen Fällen ändert sich sogar das ursprüngliche Problem, das Sie zu lösen versuchten. Tatsächlich ist es ein Wunder, dass am Ende tatsächlich alles gebaut wird.

Je mehr Stakeholder Sie an einem Projekt haben, desto chaotischer ist das Endergebnis

Oberflächlich betrachtet scheint dies durchaus sinnvoll zu sein, um die Anzahl der Köche in der Küche zu begrenzen, aber Sie wären überrascht, wie viele absolut vernünftige Leute dies ignorieren. Stattdessen müssen nicht nur das Entwicklungsteam, sondern auch das Verkaufsteam, das Marketingteam und vielleicht sogar der Typ im Flur, der einen funky, erfundenen Titel auf seiner Visitenkarte hat, schnell einbezogen werden. Und was als nächstes passiert, ist wie das altmodische Telefonspiel, bei dem jede Person, die ein Gespräch hört, es etwas anders wiederholt als die nächste Person in der Kette. Nach dem heutigen Brooks'schen Gesetz (zu Ehren von Frederick Brooks) macht es das „Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt später“.

Es wird immer einen Teil des fertigen Produkts geben, von dem niemand genau weiß, was es tut

Im besten Fall gibt es immer eine direkte Eins-zu-Eins-Zuordnung zwischen allen Funktionen, die ursprünglich vom Softwareentwicklungsteam erstellt wurden, und den endgültigen Funktionen, die in der App oder Software angezeigt werden. Aber hier ist das Problem: Die meisten Softwareentwicklungsteams stehen unter so großem Druck, das Projekt auf den Markt zu bringen, dass sie die Dokumentation darüber, was jede Codezeile eigentlich tun soll, sparen. Wiederholen Sie dies oft genug, und es führt unweigerlich zu einem „Feature“, von dem niemand wirklich weiß, was es tut oder wie es überhaupt aufgetaucht ist. (Und was auch immer Sie tun, nennen Sie es nicht "Bug" - es ist immer ein "Feature"!)

Eine Person in Ihrem Team ist für die Bewegung der Torpfosten verantwortlich

So sehr die Leute gerne davon sprechen, „in Ausrichtung zu sein“ (oder was auch immer der neueste MBA 101-Jargon ist), so selten sind Menschen in Ausrichtung. Das macht uns zu Menschen, nicht zu Maschinen. Und einer dieser Leute wird sich (natürlich inoffiziell) als die Person ernennen, die für das Bewegen der Torpfosten verantwortlich ist. Sie wissen, die Person, die am Montagmorgen auftaucht und aus dem Nichts bekannt gibt, dass der Termin für das Projekt um einige Wochen verschoben wurde oder dass eine lange vergessene Funktion jetzt „geschäftskritisch“ ist und sofort hinzugefügt werden muss .

** **.

Fazit

Wenn Sie sich also das nächste Mal mit Ihrem Team zusammensetzen und die Fristen und Spezifikationen für Ihr nächstes Softwareprojekt festlegen, sollten Sie diese Punkte berücksichtigen. Es könnte Ihnen viel Blut, Schweiß und Tränen ersparen.

Hallo! Ich bin Tomer, ein Unternehmer und Macher. Sie kennen mich vielleicht unter anderem von Mevee, Crane, Shots, Slides und jetzt vonvestorintelligence.io! Dieser Artikel ist Teil einer umfangreicheren Reihe, die ich hauptsächlich aufgrund meiner Erfahrungen schreibe. Er besteht hauptsächlich aus mir und den Meinungen meines Teams.

Ich hoffe, dies hilft Ihnen dabei, die gleichen Fehler zu vermeiden, die ich gemacht habe, und denke daran, den Versand fortzusetzen!

Bitte klatschen Sie, wenn Sie dies wertvoll fanden, und folgen Sie mir, um mehr darüber zu schreiben, während ich Geschichten darüber teile, wie Softwareentwicklung und Unternehmertum im wirklichen Leben aussehen.