ZURÜCK
Die Jagd nach Einhörnern ist ein verdammt teures Hobby. Jedes Jahr verschlingen Start-ups Milliarden, damit nur eines von zig oder hunderten einen Millionengewinn einfährt. Gründer und Produktverantwortliche sammeln Geld von Investoren und opfern ihre Unabhängigkeit, um den Markt schneller zu erobern. Letztlich bekommen sie aber meist nicht genug Geld zusammen. Vielleicht war es richtig, im richtigen Moment zu sagen: "Halt die Klappe und nimm dein Geld"?
Bargeld regiert alles um mich herum. Das können selbst die türkissten Organisationen nicht leugnen. Die Entwicklung von Projekt Managementmethoden, die Optimierung von Prozessen oder die Motivation der Mitarbeiter wird im Wesentlichen durch das allgemeine Bedürfnis nach Geld ausgelöst. Agilität bei der Gestaltung birgt gewisse Risiken.
Wir alle wollen schlank sein und wendig damit das Ergebnis unserer Aktivitäten, gemessen in Zahlen, so hoch wie möglich ist. Auch wenn wir den größten Teil unserer Energie darauf verwenden, Verluste zu reduzieren, berücksichtigen wir am Ende den Gewinn, der dank der erzielten Einsparungen gestiegen ist.
Diese Einsparungen fallen in die gleiche Tasche wie die übrigen Faktoren und bleiben nur den Neugierigsten zugänglich. Auf diese Weise verlieren wir den Fokus und lassen unbeabsichtigt eine Menge wertvoller Daten und letztlich Informationen aus.
Aus eigenen Fehlern zu lernen ist eine besonders nützliche (wenn auch teure) Fähigkeit, aber die Organisationskultur und die mit dieser Fähigkeit verbundene Diplomatie sind nicht immer hilfreich. Oft verbergen wir die negativen Auswirkungen der Finanzen mit "Nebelwörtern". Wenn ein Anleger schreit: "Ich habe mein Geld verloren!", teilt der Manager dies dem Team indem wir sagen: "Wir sollten effektiver sein", und wir alle suchen standardmäßig nach neuen Lösungen und Verbesserungen - statt zurückzublicken, suchen wir ständig nach Möglichkeiten, vorwärts zu gehen.
Dabei sind Verluste oft der Schlüssel, um die richtigen Schlüsse zu ziehen. Wenn wir bestimmte Ablaufschritte im Prozess unbedacht übergehen, werden die nächsten Lösungen höchstwahrscheinlich mit denselben Fehlern behaftet sein.
Beispiel:
Ein kleines Team erfahrener JS-Entwickler kann die Funktionalität nicht in der erwarteten Zeit bereitstellen. Der Investor, der die Entwicklung beschleunigen will, ordnet die Einstellung eines neuen Programmierers an. Die Einführung einer neuen Person in das Projekt lenkt das Team ab, was den Projektfortschritt noch weiter verlangsamt.
Würde der Investor die Gründe für die Ineffektivität des Teams besser verstehen, käme er zu dem Schluss, dass es sein Potenzial nur in 60-70% nutzt. Eine bessere Ausrüstung und ein paar Arbeitstage, die der Automatisierung der Arbeit gewidmet sind, würden das Problem lösen.
Leider muss er nun für einen anderen Entwickler bezahlen, der mit denselben Geräten arbeitet und dessen Effizienz ebenfalls bei 60-70% liegt.
Lösung A:
Ab sofort kostet das Projekt $20,200 / Monat
Gesamtausgaben in 12 Monaten: 12 * 20.200 + 10.000 = $252.400
Lösung B:
Ab jetzt kostet das Projekt: $30.000 / Monat
Gesamtausgaben in 12 Monaten: 12 * 30.000 = $360.000
Zwei Entwickler, die mit 100% arbeiten, leisten ungefähr dasselbe wie drei Entwickler, die mit 60-70% arbeiten. Der Investor zahlt über $ 100.000 mehr für die gleiche Verarbeitungskapazität pro Jahr aufgrund einer fehlerhaften Designentscheidung!
Agilität im Prozess bedeutet nicht unbedingt, eine Testabdeckung von 100% anzustreben oder den Leistungsrekord zu brechen. Diese Metriken geben zwar einen Überblick über den technischen Zustand des Projekts, sind aber aus Sicht des Endkunden so unbedeutend, dass sie in einem wirklich agilen Prozess nicht auf einen Idealzustand gebracht werden müssen, da sie keine wirklichen Vorteile bringen. Markt Wert.
Die Entwicklung perfekter technischer Lösungen erfordert ein großes Engagement des Teams und eine viel umfangreichere Kommunikation. Dies hat zur Folge, dass Patches langsamer arbeiten und das Projekt aufgrund von Überentwicklungen schwerfällig wird.
Bei der agilen Entwicklung geht es um die Bereitstellung eines funktionierenden Code mit minimalem Aufwand. Das Testen von Code ist zweifellos eine gute Praxis, und die Tests sagen viel über die Funktionsweise des Codes aus, aber sie sollten nicht nur um ihrer selbst willen durchgeführt werden, um damit zu prahlen - die optimale technische Qualität von Lösungen liegt irgendwo zwischen dem Minimum, das durch die Entwicklungsteam und der Höchstbetrag, der durch das Budget begrenzt ist.
Perfektion bringt Sie letztlich nicht weiter. Interessanterweise gilt diese Regel auch für das Thema Sicherheit - theoretisch kann jedes System gehackt werden. Allerdings muss das erwähnte Entwicklungsminimum entsprechend höher sein und dem Gewicht, dem Umfang und den Kosten potenzieller Folgen von Code-Fehlern entsprechen. Anstatt das Anmeldemodul von Grund auf neu zu schreiben, was immer mit einem hohen Risiko von Fehlern und der Einführung von Sicherheitslücken behaftet ist, ist es oft besser, z. B. die Schaltfläche "Mit Google anmelden" zu verwenden, deren ordnungsgemäße Implementierung relativ schnell und sicher ist.
Solange das Ziel eine kurze Markteinführungszeit ist, erweisen sich zu ehrgeizige Annahmen als kontraproduktiv. In einem scheinbar perfekten Prozess kann übermäßiger Enthusiasmus eine Verschwendung von Ressourcen sein.
Benutzerzentriertes Design ist cool. Wichtiger ist die menschenzentrierte Zusammenarbeit. Wenn das Team auf der gleichen Wellenlänge kommuniziert, kann es spontan weitere potenzielle Verluste reduzieren.
Ein UX-Designer, der auf dem neuesten Stand der Frontend-Technologien ist, wird keine Lösung vorschlagen, die MVP Phase, die in der Umsetzungsphase unverhältnismäßig viel Zeit in Anspruch nehmen wird.
Ein Frontend-Entwickler, der sich mit Usability-Heuristiken auskennt, ist in der Lage, die Benutzeroberfläche an eine bestimmte Bildschirmauflösung anzupassen, ohne den UX-Designer einzubeziehen - schnelle Korrektur, Vorschau, Akzeptanz.
Die Arbeit an einer Anwendung erfordert die Synchronisierung der Aktivitäten von Menschen mit völlig unterschiedlichen Kompetenzprofilen. Sie müssen wissen, wie die Kompetenzen in Ihrem Team verteilt sind, um Ihren Kunden effektiv einen Mehrwert zu bieten.
Eine so verstandene gute Teamleistung ist äußerst schwierig zu erreichen, insbesondere im Zeitalter der Fernarbeit. Unternehmen, die schon seit Jahren "fernbedienungsfreundlich" sind, haben in diesem Bereich einen erheblichen Vorteil gegenüber denjenigen, die gezwungen waren, die Organisation während des Lockdowns einzustellen und sich erst jetzt mit neuen Methoden und Formen der Kommunikation vertraut machen.
Im Zusammenhang mit dem wachsenden Kommunikationsbedarf verzeichnen Tools wie Whimsical, Miro, Mural, Figma und Balsamiq einen beeindruckenden Anstieg der Popularität.
Sicherlich haben die Abschottung und die Notwendigkeit, aus der Ferne zu arbeiten, ihren Teil zu dieser Explosion der Nutzerzahlen beigetragen. Ich bin der Meinung, dass die Auswahl des Tools den individuellen Vorlieben entsprechen sollte, aber sehen wir uns Miro an:
Die Popularisierung solcher Tools führt natürlich dazu, dass auch die Methoden selbst immer beliebter werden. Jemand, der Miro gekauft hat, um an Personas zu arbeiten, erhält Zugang zu Dutzenden von anderen Vorlagen, die sich als interessant erweisen und die tägliche Arbeit des Teams positiv beeinflussen können.
Sie sollten sich immer mit Instrumenten ausstatten, die den Informationsfluss im Projekt rationalisieren. Offenheit für neue Werkzeuge und Methoden ist auch eine der Grundlagen für eine effektive Produktentwicklung.
Erfahrene Gestalter sowohl der Oberfläche als auch der Software-Architektur sehen in der Regel zu Beginn der Zusammenarbeit mehrere Lösungsmöglichkeiten, die es zu prüfen gilt, und suchen effizient nach entsprechenden Inspirationen oder sogar fertigen Lösungen auf dem Markt. Ein gutes Beispiel ist das Material UI-Framework, das im Prototypenstadium in der Regel eine sichere Sache ist..
Manchmal reicht es aus, sich ein paar Umsetzungen auf Behance oder Dribble anzuschauen und die Inspiration zu nutzen, um ein Moodboard zu entwickeln und es dann an den Entwickler weiterzugeben. Dieser stellt daraus einen klickbaren Prototyp zusammen, der frühen Anwendern präsentiert werden kann, um Feedback einzuholen. Dieses organische Streben nach einem effektiven Prozess bei designorientierten und engagierten Menschen ist ganz natürlich.
Wenn Sie digitale Produkte effizient anbieten wollen, müssen Sie die Menschen ihre Arbeit machen lassen. Sie wissen, welchen Wert/Dienst Sie Ihren Kunden bieten wollen - das reicht. Ein kompetentes und gut geführtes Projektteam wird am besten wissen, wie man diesen Wert/diese Dienstleistung so schnell wie möglich und mit der erforderlichen Kosteneffizienz bereitstellt.
Zeigen Sie Vertrauen, teilen Sie die Verantwortung und öffnen Sie sich für eine echte wechselseitige Kommunikation, damit Ihre Produkt wird besser sein, und die Last, alles selbst zu machen, wird von Ihren Schultern genommen, was sich für Gründer und Unternehmer oft als sehr anstrengend erweist! Unter Der CodestWir setzen dieses Prinzip nicht nur in Projekten, sondern auch in internen Prozessen um - das ist wahrscheinlich der Grund, warum wir sowohl bei Kunden als auch bei Mitarbeitern hohe Bindungsquoten haben (wahre Geschichte, beides> 90%).
Gönnen Sie sich ein bisschen Faulheit, übertragen Sie mutig Verantwortung und lassen Sie überflüssige Arbeiten los, die nicht notwendig sind, um voranzukommen - Funktionen, die "nice to have" wären, können immer warten.
Der Entstehungsprozess eines digitalen Produkts ist ein ständiges Aufeinanderprallen verschiedener Perspektiven, Erfahrungen und Informationsquellen - jeder dieser Zusammenstöße birgt das Risiko, eine falsche Designentscheidung zu treffen.
Eine gute interne Kommunikation verringert dieses Risiko, aber das ist nur eine Seite der Medaille. Die Frage, wie man mit dem Markt in Kontakt bleibt, muss noch beantwortet werden.
Business Intelligence, Customer Support, UX-Forschungsabteilungen und viele andere - genau wie die EntwicklungsteamSie sollten sich um das Minimum bemühen, das notwendig ist, um spezifische Antworten auf Fragen des Product Owners oder des UX-Teams zu geben.
Auch das Branding selbst und die Strategie der Markenkommunikation sind wichtig. Sie dienen dazu, eine qualitative Beziehung zu den Kunden aufzubauen, die sich dann in deren Engagement niederschlägt. Wenn Sie den Kunden Fragen stellen wollen, sollten Sie sicherstellen, dass sie bereit sind, diese Fragen zu beantworten. Der Ton Ihrer Stimme ist wichtig.
Es ist sicher, dass ein ständiger Kontakt mit dem Markt es ermöglicht, die richtigen Weichen für das Projekt zu stellen, um es zum Erfolg zu führen. Weniger offensichtlich ist die Tatsache, dass die Notwendigkeit dieses Kontakts bereits zu Beginn des Projekts berücksichtigt werden sollte, um die richtigen Kompetenzen im Team zu antizipieren (um die richtigen Fragen zu stellen und zu beantworten) und eine Produktstrategie zu entwickeln, die die Zielgruppen einbezieht.
In Anbetracht der oben genannten Punkte können wir mehrere Probleme feststellen, die regelmäßig im Entwurfsprozess auftreten:
- übermäßige Gewinnorientierung und Vermeidung von Misserfolgen,
- Ungenauigkeit und nicht das Röntgen der eigenen Fehler,
- die Verfolgung eines perfekten Produkts, das Sie im Kopf haben, das aber nicht den Bedürfnissen des Marktes entspricht,
- Übereifrige Umsetzung von Lehrbuchprozessen - Überentwicklung und Übergestaltung,
- Unflexibilität der Teamarbeit und Zwang für die Mitarbeiter, nur in ihrem Spezialgebiet zu bleiben,
- ineffiziente Kommunikation,
- die Tendenz, das Rad neu zu erfinden.
Die Prozessoptimierung auf der Makroebene umfasst die Summe der Einsparungen. Um die oben genannten Herausforderungen zu meistern, müssen Sie Ihre Kollegen einbeziehen, damit sie offen ihre Ideen zur Verbesserung des Prozesses einbringen können.
Manchmal reicht es aus, weniger zu reden und Untergebenen, Kunden und Partnern besser zuzuhören - je nach Rolle und Verantwortung des Einzelnen -, um Erfolg zu haben.
Wenn Sie nicht genug haben, sind Sie wahrscheinlich überinvestiert.. Haben Sie zu viel Geld?
Lesen Sie mehr:
CTO-Herausforderungen - Skalierung und Wachstum von Softwareprodukten
Welche DB für Ihren spezifischen Datentyp in Ihrem Softwareprojekt zu wählen ist
German 
English 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean 
Polish