Wie kann ich mein Unternehmen davon überzeugen, unseren Softwareentwicklungsprozess zu verbessern? [geschlossen]

Ich arbeite als Embedded-Software-Entwickler für ein wachsendes Unternehmen, das physische Produkte herstellt und meiner Meinung nach aufgrund seines schnellen Wachstums einige Wachstumsschmerzen durchmacht. Jahrzehntelang war es ein ziemlich kleines Unternehmen mit nur ein paar Dutzend Ingenieuren in allen Disziplinen, nicht nur Software, und brachte eine relativ kleine Anzahl von Produkten heraus

Das typische Produktentwicklungsmodell bestand darin, ein Team von Ingenieuren aus allen Disziplinen (Software, Elektrik, Mechanik, Marketing, Fertigung usw.) zusammenzustellen, und das Team arbeitete dann daran, das Produkt agil zu liefern. So soll es zumindest theoretisch funktionieren.

In Wirklichkeit ist die Arbeit extrem isoliert, da ich als Software-Ingenieur nicht in der Lage bin, CAD-Modelle zu aktualisieren oder eine Leiterplatte zu layouten, und meine anderen Teamkollegen ebenfalls keine Ahnung haben, wie man Software schreibt. Anstelle eines zusammenhängenden Teams ist es am Ende eine Art Gruppe von 1-Mann-Teams, die alle ihrer disziplinspezifischen Arbeit nachgehen und während unserer Stand-up-Meetings einen Statusbericht einholen.

Bis vor kurzem gab es kein wirklich gemeinsames Softwaremodell, jedes Projekt würde im Wesentlichen die Codebasis von einem ähnlichen Produkt abzweigen und alle notwendigen Änderungen für das zu entwickelnde Produkt vornehmen. Wie erwartet führte dies zu einer Fülle unterschiedlicher Variationen sehr ähnlicher Implementierungen, aber einige Entwickler haben sich mehr Mühe gegeben, eine gemeinsam genutzte Bibliothek zu erstellen, um dieses Problem zu entschärfen.

Die meisten Entwickler sind sich einig, dass dies die Richtung ist, in die wir uns bewegen sollten, aber jeder hat seine eigene Vorstellung davon, wie es erreicht werden sollte, und es gibt kein Mandat auf die eine oder andere Weise, also wird nie etwas daraus. Es gibt insbesondere eine interne Bibliothek, die von einem Senior-Entwickler erstellt und verfochten wird, die am vielversprechendsten ist und am weitesten verbreitet ist, aber einige der anderen Entwickler mögen ihren architektonischen Stil nicht und verwenden sie daher nicht. Dieser leitende Entwickler ist auch in einer anderen F&E-Abteilung, getrennt von der Produktentwicklung, wo ich und die anderen Produktentwickler sind, also hat er auch keine Befugnis, irgendwelche Mandate zu erteilen.

Unser Software-Manager hat lange keine eigentliche Entwicklung mehr durchgeführt und ist eher ein Personalmanager als ein echter technischer Leiter, und die eigentlichen Produktleiter kommen normalerweise aus anderen Disziplinen als der Software, sodass ihre Augen bei Software tendenziell glasig werden Gespräch kommt. Und da jedem Produkt normalerweise nur ein Softwareentwickler zugeordnet ist, gibt es nicht viel Verantwortung, einen einheitlichen Stil oder eine konsistente Architektur aufrechtzuerhalten.

Die Anzahl der Produkte, die wir entwickeln, sowie ihre Komplexität sind in den letzten Jahren enorm gewachsen, und ich habe das Gefühl, dass wir gefährlich nahe an einer Klippe der Katastrophe fahren, wenn unser aktuelles Modell so weitermacht, wie es bisher war.

TLDR : Wir haben ungefähr ein Dutzend Ein-Mann-Software-Shows in derselben Abteilung ohne wirklichen Auftrag darüber, wie unsere Software strukturiert sein sollte.

Wie kann ich mich am besten für eine bessere Organisation einsetzen, in der die Softwareteams kollaborativer und weniger isoliert arbeiten? Einige von uns haben vorgeschlagen, dass das Softwareteam Projekte als ganze Einheit angeht, anstatt nur einen Entwickler pro Produkt zu haben, aber die aktuelle Organisationsmethode wird von der VP-Ebene gesteuert, und ich bin mir nicht sicher, ob mein eigener Softwaremanager überhaupt die Macht hätte eine solche Änderung vorzunehmen, selbst wenn er es wollte.

Ich bin erst seit ein paar Jahren im Unternehmen, daher bin ich mir nicht sicher, ob ich die beste Person bin, um solch radikale Prozessänderungen vorzuschlagen, aber gleichzeitig habe ich das Gefühl, dass mit der richtigen Struktur so viel verbessert werden könnte Ort.

Was genau nervt dich im Solo-Entwicklungszyklus? Fehlende Hilfe von anderen/älteren Entwicklern oder Verantwortlichkeit, weil Sie der einzige Entwickler im Projekt sind? Vielleicht wäre der erste Schritt eine flache Codeüberprüfungsrichtlinie, bei der Ihr Code von jemand anderem auf Ihrer Ebene in der Entwicklungsabteilung geprüft wird.
Mangelnde Konsistenz, Isolation, Menschen, die das Rad neu erfinden, jedes Projekt ist völlig anders formatiert. Einige von uns machen Code-Reviews miteinander, aber auf freiwilliger Basis. Niemand ist verpflichtet, Code-Reviews durchzuführen oder zu akzeptieren.
Das kann der erste Schritt sein, die Codeüberprüfung als Teil des Prozesses. Meiner Erfahrung nach minimieren eingebettete Projekte aufgrund von Speicherbeschränkungen die Codebasis. Könnte dies ein Grund dafür sein, keine übergewichtigen generischen Bibliotheken zu verwenden?
Ja, das gehört definitiv dazu. Einige unserer Projekte müssen in 32 KB Flash passen, die größeren sind mit 256 KB gesegnet, und es gibt einen absoluten Kompromiss zwischen generischen Bibliotheken und Codegröße. Es ist eigentlich einer der anderen Senior-Entwickler, der möchte, dass alles generisch ist und seine persönliche Bibliothek verwendet. Ich versuche, eine ausgewogenere Meinung zu vertreten. Das Problem ist, dass niemand mit Autorität den Anruf auf die eine oder andere Weise tätigen wird, und die jr-Entwickler wissen nicht, auf wen sie hören sollen, wenn sie widersprüchliche Ratschläge erhalten.
Was auch immer Ihnen einfällt, untermauern Sie es mit einem Business Case. Zeigen Sie, wie es Zeit oder Geld oder beides spart, wenn Sie versuchen, dem Management eine Idee zu verkaufen.

Antworten (2)

Sie erwähnen, dass Ihr Manager nicht sehr technisch versiert ist, daher wäre dies eine gute Gelegenheit für jemanden aus dem Team, sich zu verbessern. Es scheint, als hätten Sie ein Interesse und einige Ideen, also können Sie das vielleicht selbst übernehmen. Wahrscheinlich möchten Sie Ihrem Vorgesetzten eine Vorwarnung geben, aber Sie müssen ihn oder sie an dieser Stelle nicht zu sehr einbeziehen. Ein guter Manager wird die Tatsache schätzen, dass Sie sich kümmern und die Initiative ergriffen haben, um das Team und das Unternehmen zu verbessern, wenn Sie sich verstärken und die Führung übernehmen, insbesondere angesichts der Tatsache, dass Ihrem Manager möglicherweise das technische Wissen dafür fehlt persönlich.

Der erste Schritt besteht darin, Ihre Recherche durchzuführen und die Ergebnisse zusammenzustellen. Identifizieren Sie die Probleme, wie Sie sie sehen, und erklären Sie, wie sie sich negativ auf das Unternehmen auswirken. Es ist völlig normal, dass ein wachsendes Unternehmen auf diese Weise kämpft, also suchen Sie nach anderen Beispielen und Fallstudien, um Ihre Behauptungen zu untermauern. Als nächstes müssen Sie mögliche Lösungen finden. Erläutern Sie ausführlich Kosten und Nutzen. Beachten Sie, dass Sie vielleicht Ihre Teammitglieder hier einbeziehen möchten, da es so klingt, als hätten sie auch Ideen, sowohl zu den Problemen als auch zu den Lösungen. Achte nur darauf, die Dinge konzentriert zu halten und lass es nicht zu einer Ablenkung werden.

Sobald Sie einige Probleme und potenzielle Lösungen identifiziert haben, auf die reagiert werden kann, würde ich empfehlen, daraus eine Präsentation zu machen. Planen Sie ein Meeting mit Ihrem Team (einschließlich Manager). Das Ziel dieses Treffens ist es, a) Feedback zu erhalten und b) alle auf die gleiche Seite zu bringen. Am Ende dieses Meetings ist es wichtig, dass Sie mit der Planung beginnen, wie die vereinbarten Änderungen und ein Zeitplan dafür implementiert werden sollen. Wenn Sie eine Genehmigung von oben benötigen, benötigen Sie in diesem Fall die Hilfe Ihres Vorgesetzten. An diesem Punkt haben Sie die Arbeit getan, um Ihren weniger technischen Manager zu stärken, und ihm hoffentlich die Werkzeuge an die Hand gegeben, die er benötigt, um den Ball ins Rollen zu bringen.

Das letzte, was Sie tun müssen, ist sicherzustellen, dass das, was Sie als Team beschlossen haben, auch tatsächlich umgesetzt wird. Es wird wahrscheinlich Dinge geben, auf die Sie und Ihre Teammitglieder sofort reagieren können, und andere, die möglicherweise größere Änderungen/Käufe usw. erfordern, die die Hilfe des Managements erfordern. Ich empfehle, ein wiederkehrendes Treffen einzurichten, um den Fortschritt zu überprüfen und Hindernisse zu identifizieren, die Sie möglicherweise aufhalten. Konsistenz und Rechenschaftspflicht sind der Schlüssel zur erfolgreichen Implementierung dieser neuen Prozesse.

Eine letzte Anmerkung: Wenn Sie das Gefühl haben, dass Sie noch nicht lange genug im Unternehmen sind, um dies persönlich zu übernehmen, kann es bei einem leitenden Teammitglied angewendet oder als Gruppe übernommen werden. An Ihre Bedürfnisse anpassen.

Ergreife die Initiative und finde und behebe ein wiederkehrendes Problem, das das Team hat

Sie sagen, alle Entwickler sind sich einig, dass die derzeitige Art, Geschäfte zu machen, nicht funktioniert, aber niemand ist sich einig, was zu tun ist. Sie müssen ein wiederkehrendes Problem finden und eine Lösung implementieren.

Sprechen Sie mit anderen Entwicklern, die Sie kennen, und holen Sie sich mindestens 3 oder 4 von ihnen in Ihren Plan. Dann führen Sie Ihren Plan aus. Sobald es fertig ist, erzählen Sie dem Rest des Teams und Ihrem Chef davon.

Wenn Sie anderen erzählen, was Sie getan haben, konzentrieren Sie sich auf die Tatsache, dass Sie wegen eines schlechten Prozesses Zeit verschwenden. Etwas wie...

Nachdem ich Termin/Termin XYZ verpasst habe, habe ich beschlossen, dieses Problem zu beheben. Das Problem mit dem Einfügen brachte mich in eine wirklich schlechte Position, in der ich ein wichtiges Lebensereignis/eine wichtige Frist verpassen musste. Ich würde wirklich gerne hören, was jeder von dieser Lösung hält.