Was kann man als Entwickler tun, wenn das Team jahrelang keine Produktinnovation hat, keine Projektmanagementmethoden verwendet und schlechte Softwareentwicklungspraktiken beibehalten hat? [geschlossen]

Ich bin daran interessiert zu wissen, wie man mit einem aktuellen Softwareentwicklungsprozess umgeht, der seit Jahren unverändert ist und letztendlich zu Produkt- und Teamfehlern führen wird. Ja, wahrscheinlich ist der einfachere Weg, dies zu lösen, ein Jobwechsel, aber mit dieser Wirtschaft ist das leichter gesagt als getan. Wenn Sie jedoch konkrete Beispiele haben und mehrere Male dieselbe Situation gesehen oder erlebt haben und der Meinung sind, dass die beste Lösung zur Behebung dieser Probleme darin besteht, das Unternehmen zu verlassen, unterstützen Sie bitte Ihre Antwort. Der Punkt ist, dass diese Frage wirklich eine Antwort hat, insbesondere wenn mehrere Experten auf diesem Gebiet darauf hinweisen, dass der beste Weg zu gehen ist: Weg A.

Ich weiß, dass Tonnen von Entwicklern in ähnlichen Situationen waren oder sind. Dies ist einer der Hauptgründe, warum Unternehmen von der Nr. 1 in ihrem Markt auf die letzte oder gar nicht mehr auf dem Markt sind. Hoffentlich helfen die Antworten in diesem Beitrag anderen Entwicklern, die mit ähnlichen Hindernissen konfrontiert sind. In einem kleinen oder großen Entwicklungsteam geschieht dies normalerweise:

• Einige Entwickler scheinen sich nicht darum zu kümmern und beschließen, mit dem Fluss zu gehen und Code mit viel Code-Geruch so zu belassen, wie er ist, und den Entwicklungsprozess so, wie er ist.
• Andere werden es leid, nichts mehr zu ändern und treten zurück und ziehen in eine andere Firma,
• Andere scheinen Angst zu haben zu reden und lieber still zu bleiben,
• Manchmal versuchen nur sehr wenige Entwickler oder nur einer, für die Verbesserung des Produkts einzutreten, und teilen dem Team mit, wie wichtig es ist, die besten Codierungspraktiken und -vorteile für Kunden, Benutzer und das Team zu befolgen. Diese Art von Entwicklern entscheiden sich in der Regel aus Gründen, die für das Team sprechen, zum Beispiel, weil das Unternehmen Vorteile bietet, die nur sehr wenige Software-Unternehmen bieten, oder weil das Produkt ein großes Potenzial hat.

Das Produkt in unserem Team ist nur ein Bruchteil dessen, womit das Unternehmen seinen Umsatz erzielt, da es über ein Produktdach verfügt (dieses Unternehmen ist kein Software- / Hardwareunternehmen; daher zumindest vorerst kein ständiger Patentstreit, der Arbeitsplätze schafft) Instabilität). Was ich in diesen Jahren aus den Erfahrungen anderer Entwickler gelernt habe und meine Erfahrung ist, dass es Zeit braucht, nicht Tage, noch Wochen, sondern ein paar Monate, um ein Entwicklerteam wirklich zu kennen. Während des Interviewprozesses, wenn das Team Sie einstellen möchte oder braucht; Sie lassen alles großartig klingen und sagen Ihnen vielleicht, was Sie hören möchten. Die Realität sieht jedoch anders aus, wenn Sie anfangen, in diesem Team zu arbeiten, den Code zu durchsuchen und sich dem vollständigen SDLC-Prozess zuzuwenden. Dies ist der Moment, in dem Sie als Entwickler beginnen, die Realität des Jobs zu erkennen, in den Sie eingetreten sind. Diese Realität macht es schwierig, von einem Unternehmen in ein anderes zu wechseln, da es schwierig ist zu wissen, ob das Unternehmen, in das Sie wechseln, besser oder schlechter wird. Ja, Sie können Glassdoor-Bewertungen usw. lesen. Aber wie viele dieser Online-Bewertungen sind echt und nicht von HR?

Was wäre der beste Weg, um die im Folgenden beschriebenen Probleme zu lösen, wenn man bedenkt, dass Manager von Anfang an sich Änderungen widersetzten und frühere Entwickler dies seit Jahren auch tun?

• Seit Jahren mangelnde Produktinnovation: Das Produkt hat viel Potenzial und bringt dem Unternehmen gute Einnahmen, aber das Produkt sieht so aus, als wäre es vor 20 Jahren hergestellt worden. Einige Benutzer haben sich darüber beschwert, dass das Produkt weder benutzerfreundlich noch intuitiv ist, und andere haben erwähnt, dass Apps wie Google Mail bei der Verwendung des Produkts frustriert sind, weil sie keine ähnlichen Funktionen aufweisen. Das Hauptproblem hierbei ist, dass Sie, wenn Sie als Entwickler versuchen, Änderungen am Produkt vorzunehmen und die Hauptelemente des Produkts nur ein paar Pixel (um es benutzerfreundlicher oder intuitiver zu gestalten) zu verschieben, in Panik geraten und es Ihnen mitteilen um es wieder dorthin zu bringen, wo es war. Wenn Sie versuchen, eine Funktion hinzuzufügen, die der Produktivität der Benutzer zugute kommt, werden Sie vom Manager aufgefordert, sie zu entfernen, da "Benutzer daran gewöhnt sind, den Vorgang so wie er ist usw." Ich denke, Sie sind auf den Widerstand gegen Veränderungen, Verbesserungen und Innovationen gestoßen (der Manager ist nicht offen für Veränderungen, auch wenn Sie als Entwickler starke Argumente für Vorteile vorbringen). Das Unternehmen hat einige Konkurrenten auf dem Gebiet (die Produkte weniger von ihnen sind viel wettbewerbsfähiger), aber irgendwie hat das Unternehmen die gegenwärtigen Kunden über Jahre hinweg gepflegt.

• Mangelnde Koordination des Projektmanagements: Infolgedessen werden einige Projekte verspätet geliefert, und einige Kunden beschweren sich (Kunden melden die Fehler ebenfalls), oder das Budget wird zu schnell verwendet, bevor Projekte usw. bereitgestellt werden. Ich habe sie bereitgestellt Einige Tipps zur Projektkoordination und die Ideen werden nun regelmäßig verwendet, um den Fortschritt der zu erledigenden Projekte und Aufgaben zu verfolgen.

• Schlechte Softwareentwicklungspraktiken: Code-Geruch tritt auf den meisten, wenn nicht allen Dateien auf, keine Dokumentation, Code-Redundanz, Front-End-Schicht und Back-End in derselben Datei gemischt, veraltete Entwicklungstools, keine echte Testumgebung oder Testtools (einfach kopieren und einfügen Dateien von der Entwicklungsumgebung bis zur Produktion und dann manuell testen, ob die Dinge gut aussehen und freigeben). Die meisten Entwicklungstools, die ich für die Entwicklung und das Testen verwende, sind dem Team unbekannt, da das Team nur zwei IDEs für die Codeentwicklung verwendet und die Quellcodeverwaltung nur für die Entwicklungsumgebung verfügbar ist. Andere Entwickler haben versucht, die neuesten Frameworks zu verwenden, um aktuelle Probleme zu beheben, aber der Manager mag dies nicht, weil "Was passiert, wenn Sie den Code verlassen, und wer ihn dann beibehalten wird? Lassen wir ihn so, wie er ist". Einige dieser Entwickler haben es bereits getan verließ und zog zu einem anderen Unternehmen.

Zusammenfassend kann ich sagen, dass viele Entwickler in anderen Unternehmen mit ähnlichen Situationen konfrontiert sind. Aufgrund anderer Umstände möchte ein Entwickler jedoch möglicherweise lieber im Team bleiben als zu einem anderen Unternehmen, und zwar aus Gründen wie der Bequemlichkeit der Arbeit, der Flexibilität der Arbeit, den Vorteilen des Unternehmens oder nur weil eine bessere Gelegenheit nicht gekommen ist). Es gibt kein perfektes Unternehmen, von dem ich weiß, aber wie würden Sie sich als Entwickler verhalten und alle diese Themen angehen, um die Dinge positiv zu halten und letztendlich den Wandel zur Verbesserung des Produkts und zur Verbesserung des Softwareentwicklungsprozesses voranzutreiben (ob Sie nun viele haben) Jahre Entwicklungserfahrung oder nur wenige? Ich weiß, dass dieser Beitrag lang ist, aber ich habe es vorgezogen, zusätzliche Details anzugeben, um die Chancen auf ein nützlicheres Feedback zu erhöhen.

Vielen Dank für Ihr Feedback und Ihre Zeit

Das Zitat von Martin Fowler ist relevant: "Sie können Ihre Organisation oder Ihre Organisation ändern." Da Sie anscheinend beschlossen haben, Ihre Organisation zu ändern (zu verbessern), anstatt Ihre Organisation zu ändern (für eine andere Organisation zu arbeiten), sind hier einige Vorschläge.

Erstens hängt ein Großteil Ihrer Vorgehensweise von Einzelheiten zu den Machtstrukturen und der Politik ab, die am Werk sind. Gibt es einen oder mehrere Softwareentwicklungsmanager? Wenn mehrere, gibt es welche, die nicht veränderungsabgeneigt sind? Wie viele Softwareentwickler gibt es? Interessieren sich die Entwickler für Veränderungen? In diesem Fall gibt es einige Änderungen, die Sie auch ohne Genehmigung des Managements vornehmen können sollten. (Wie Fowler in Refactoring vorschlägt , müssen Sie dem Management möglicherweise nicht einmal Bescheid geben. Vermutlich werden Sie beauftragt, Software so gut wie möglich zu entwickeln. Wenn es also eine bessere Möglichkeit gibt, tun Sie es einfach.)

Denken Sie zweitens daran, dass das Management möglicherweise gute Gründe für seine Aktivitäten hat. Sie sind ein Softwareentwickler. Ihre Aufgabe ist es, gute Software zu entwickeln und gute Techniken dafür zu kennen. Die Aufgabe des Managements besteht darin, allgemeine Probleme und geschäftliche Überlegungen zu verstehen, die möglicherweise außerhalb Ihres Einflussbereichs liegen. Selbst wenn Sie Recht haben und sich in geschäftlichen Aspekten irren (Ihre Bedenken in Bezug auf mangelnde Innovation, verspätete Lieferung, Kundenbeschwerden usw.), hilft Ihnen das Verstehen, woher das Management kommt, bei der Kommunikation in Bezug auf deren Bedingungen ihre Bedenken und so weiter.

Drittens (und damit zusammenhängend) stellen Sie sicher, dass Sie die Geschäftssprache sprechen können. Ein Unternehmen ist (zu Recht) nicht direkt mit guten Softwareentwicklungspraktiken befasst. In einem Unternehmen geht es darum, die Bedürfnisse der Kunden zu bedienen und Gewinne zu erzielen. (Und viele Unternehmen werden offensichtlich so wenig wie möglich für die Erzielung eines Gewinns tun.) Sie können Veränderungen effektiver fördern, wenn Sie erklären können, wie schlechte Softwareentwicklungspraktiken und mangelnde Innovation den Gewinn oder die Langzeitwirkung des Unternehmens beeinträchtigen Gesundheit.

Viertens ist es äußerst schwierig, eine Unternehmenskultur von der Position eines einfachen Arbeiters zu ändern. James Shore (ein agiler Berater und Autor) hat ein Change Diary geschrieben, in dem er seine eigenen Anstrengungen beschreibt. Ich kann nur empfehlen, das Ganze zu lesen. Einige relevante Punkte:

• Versuchen Sie nicht, alles auf einmal zu ändern. Finde die größten Schwachstellen und beginne dort. Holen Sie sich alle an Bord, indem Sie ihnen zeigen, wie Ihre Änderungen diese Schwachstellen beheben.
• Verstehe die Perspektiven anderer. Shore spricht darüber, wie die Änderungen, die er aus der Perspektive der Softwareentwicklung vorantreibt, vom Projektmanager abgelehnt wurden, weil er (Shore) nicht berücksichtigt hat, wie sich die Änderungen auf den Projektmanager auswirken würden.
• Irgendwann werden Sie brauchen eine gewisse Unterstützung von höheren, auch wenn Sie die meisten Änderungen sind aufgefordert , sich. Shore spricht über seinen Champion ("Jemand, mit dem ich zusammenarbeite, der mehr Einfluss als ich hat und im Allgemeinen genau so denkt wie ich").

Die naheliegende kurze Antwort lautet, das Unternehmen zu verlassen. Andere sind bereits gegangen, und Ihr Vorgesetzter ist ein aktives Hindernis für den Fortschritt. Wenn Sie in dieser Position bleiben, verfallen Sie langsam (sowohl in der Moral als auch in den Fähigkeiten). Einen neuen Job zu finden ist nicht immer einfach, aber in diesem Fall ist es notwendig.

Nur für den Fall, dass Sie das Unternehmen nicht verlassen möchten (die erste Zeile Ihrer Frage hat dies verraten):

Hat Ihr Manager einen Chef? Wenn ja, wie sieht dieser Chef das Produkt? Können Sie (wage ich es überhaupt zu sagen?) Über den Kopf Ihres Managers gehen und sich seinem Chef nähern? Nörgeln Sie ihn nicht mit technischen Details, sondern drücken Sie nur Interesse und Enthusiasmus für das Wachstum innerhalb des Unternehmens aus. Präsentieren Sie konkrete Ideen für Verbesserungen, die sich messbar auf das Endergebnis auswirken würden. Sie könnten unter dem Hindernis heraus befördert werden.

Seien Sie jedoch gewarnt - während einige quietschende Räder gefettet werden, werden andere ersetzt. Sie werden Ihren Manager veranlassen, Sie stark zu mögen. Er wird darüber hören, und er wird zu seinem Chef über Sie unfreundliche Dinge sagen. Gehen Sie vorsichtig vor, aber denken Sie daran - kein Risiko, keine Belohnung.

Das Schlimmste, was passieren kann, ist, dass Sie nach einem neuen Job suchen, den Sie sowieso tun sollten.

Klingt so, als ob es Zeit für Sie ist, etwas über Cash Cows zu lernen. Gehen Sie hier und hier . Und werfen Sie einen Blick auf die Growth Share Matrix . Das GSM bietet einige zusätzliche Informationen darüber, warum Cash Cow ein guter Zustand ist.

Investopedia (zweiter Link) hat in diesem Fall wahrscheinlich das beste Zitat.

1. Eine Cash Cow benötigt nur wenig Investitionskapital und liefert ausdauernd positive Cashflows, die anderen Unternehmensbereichen innerhalb des Unternehmens zugeordnet werden können. Diese Geldgeber können ihr Geld auch zum Rückkauf von Aktien am Markt oder zur Ausschüttung von Dividenden an die Aktionäre verwenden.

Wie Sie bereits bemerkt haben, hat es einige Vorteile, an einem Cash-Cow-Projekt teilzunehmen.

• Es ist stabil
• Ein bescheidener Neuentwicklungsgrad ist garantiert
• Das Beheben von Fehlern ist immer eine Aufgabe.

Und wie Sie auch bemerkt haben, haben diese Projekte einige Nachteile.

• Es ist stabil und die Codebasis dreht sich nicht viel
• Neue Technologien werden im Allgemeinen ignoriert (zu teuer zum Anschrauben)
• Und die Dinge werden ... abgestanden.

Ich habe einmal an einem Projekt gearbeitet, bei dem ich ähnliche Beschwerden hatte wie Sie. Ich erinnere mich noch genau, wie ich meinem damaligen Chef meine Bedenken hinsichtlich der Codebasis mitteilte. Seine Einsicht war nicht besonders aufschlussreich, deshalb werde ich sie nicht teilen. Aber ich habe das Projekt durchgehalten und ehrlich gesagt, es war eines der besseren Projekte, die ich gesehen habe. Nein, es war nicht auffällig. Ja, wir haben Termine verpasst. Ja, ich habe ein paar Todesmärsche gemacht. Nein, die Code-Technologie war nicht allzu innovativ, aber wir haben einige erstaunliche Lösungen generiert.

Das Problem war ich. Ich hatte nicht genug Perspektive, um zu verstehen, was eine Codebasis wirklich benötigt, um zu überleben. Ich hatte nicht die Erfahrung zu sehen, wo die Innovation wirklich stattgefunden hat. Ich verstand die Marktgrundlagen nicht, die vorschrieben, wie hoch die angemessene Finanzierung für dieses Cash-Cow-Projekt war.

Ich möchte Sie ermutigen, dies als Lernmöglichkeit zu betrachten, um besser zu verstehen, wie das Geschäft funktioniert und wie Sie Ihre Fähigkeiten verbessern können, wenn Sie ein Produkt an die Bedürfnisse des Geschäfts anpassen. Die Arbeit mag nicht auffällig sein, aber das Lernpotential ist hoch und diese Fähigkeiten werden Ihnen später in Ihrer Karriere gut stehen. Der Großteil der Entwicklung auf Unternehmensebene dreht sich um alle von Ihnen genannten Einschränkungen. Der Code stinkt; Dinge wurden an Ort und Stelle geschlagen, um Fristen zu enthalten, die bereits entgangen waren; Viele Entwickler sind resistent gegen Veränderungen.

Irgendwann werden Sie das Projekt trotzdem verlassen. Die Lektionen, die Sie mitnehmen können, können echte Karrierelektionen sein.

Ihr Vorgesetzter ist wahrscheinlich veränderungsresistent, da er keinen (geschäftlichen) Wert darin sieht, Praktiken zu ändern. Das Unternehmen sieht kein wirkliches Problem, da das, was auch immer vom Entwicklungsteam verlangt wird, irgendwann erledigt wird und Kundenbeschwerden es nicht zu den Menschen schaffen, die sich darum kümmern und / oder etwas tun können, um ein besseres Ergebnis zu erzielen. Entweder das oder das Geschäft hat den gegenwärtigen Stand der Dinge als unvermeidlich akzeptiert.

Wenn Sie Entwicklungspraktiken ändern wollen, müssen Sie ihnen zeigen, dass der aktuelle Stand der Dinge nicht unvermeidlich ist. Der einzige Weg, um Gehör zu finden, besteht darin, einen Business Case zu erstellen, der zeigt, wie der aktuelle Stand der Dinge die Kosten des Produkts in die Höhe treibt, und das Umsatzpotenzial bei einem anderen Stand der Dinge einzuschränken.

Um diesen Business Case zu erstellen, müssen Sie mit dem Produktmanager dieser Software sprechen . Der Produktmanager ist die Person, die über die Priorität der zu entwickelnden Artikel auf der Grundlage des von ihnen repräsentierten Geschäftswerts entscheidet. Der Produktmanager ist (sollte) derjenige, der den Nutzen und den geschäftlichen Nutzen einer schnelleren Entwicklung besserer Software erkennen kann. (Und ich hoffe, es ist nicht dasselbe, das für das Entwicklungsteam verantwortlich ist.)

Der Business Case muss folgende Auswirkungen auf den Geschäftsertrag haben:

• Funktionen, die (noch) nicht implementiert sind und bei deren Implementierung mehr Kunden generiert oder gehalten würden.
• Unzureichend implementierte Funktionen, die zu Unzufriedenheit bei den Kunden führen und zu Abnutzungserscheinungen bei den Kunden führen.

Der Business Case muss auch zeigen, wie sich die aktuellen Entwicklungsmethoden auf die Geschwindigkeit und die Kosten der Entwicklung dringend benötigter Funktionen auswirken:

• Wie lange dauert es, um selbst die einfachsten Änderungen vorzunehmen?
• Wie viele Fehler werden durch die Entwicklung neuer Funktionen sowohl in der neuen Funktion als auch durch Kollateralschäden in anderen Funktionen verursacht?
• Wie viel Zeit wird für die Behebung dieser Fehler benötigt, die nicht für die Implementierung neuer Funktionen aufgewendet werden können?
• Wie viele Support-Anrufe werden aufgrund dieser Fehler generiert und wie viel Support-Personal muss für diese Anrufe ausgegeben werden.

Und natürlich muss gezeigt werden, wie sich die Einführung besserer Entwicklungspraktiken auf diese Zahlen auswirkt.

Möglicherweise müssen Sie (wichtige) Teile der Software neu schreiben. Auch wenn Sie nicht, dann wie eine Boden-Up Rewrite überleben Ohne Losing Your Sanity ist in , wie man diese Art von Projekten nähern lesen müssen.

Letzte Anmerkung: Wenn der Produktmanager nicht an all dem interessiert ist, sind Sie verloren: Sprungschiff.

Ich denke, dass dies ein wirklich schweres Problem ist, für das es keine direkte Lösung gibt. Hier sind einige Ideen, was Sie versuchen könnten:

Angst vor Veränderungen Was das Ändern von Dingen betrifft, verstehe ich, warum sich die Ängste des Managements ändern. Die Leute sind an bestimmte Dinge gewöhnt und wenn man sie ändert, empören sich die Benutzer (vielleicht). Veränderungen sind beängstigend und erfordern normalerweise viel Nachdenken und Studium, bevor sie durchgeführt werden. Was Sie brauchen, sind Daten, die zeigen, dass dies besser ist und die Benutzer es wollen. Wenn Sie von Google Mail sprechen, möchten Sie möglicherweise etwas wie "Google Labs" tun, in dem Sie neue Funktionen aktivieren / deaktivieren können, damit die Nutzer sie ausprobieren können. Schließen Sie dann eine Datensammlung an, um Ihre Änderungen zu sichern.

Ändern des Softwareentwicklungsprozesses Wiederum ist es schwierig, dass sich Menschen ändern, nicht nur, weil Sie sagen, dass es einen besseren Weg gibt. Ich denke, in diesem Szenario ist es meine beste Empfehlung, mit gutem Beispiel voranzugehen. Tun Sie Dinge so, wie Sie es möchten, und zeigen Sie den Menschen, wie viel besser es ist. Auch und das ist der Schlüssel, müssen Sie die anderen finden, die Ihre Gedanken teilen. Wenn Sie ein paar Leute an Bord holen können, wird das Ihrer Sache sehr helfen. Sobald Sie einige Ergebnisse angezeigt haben, können Sie sich an das Management wenden, um diese Änderungen zu erweitern. Ich finde, dass eine Anstrengung von oben nach unten und von unten nach unten wirklich dazu beiträgt, Änderungen vorzunehmen.

Auch auf der Werkzeugseite befürchten Unternehmen, diese zu aktualisieren / zu ändern, weil sie Geld kosten und die Ergebnisse neuer Werkzeuge nicht immer messbar sind. Meine Empfehlung hier ist, Ihre eigenen Werkzeuge zu machen. Wenn Sie Ihre eigenen machen, sparen Sie sich Zeit und arbeiten besser. Hoffentlich werden die Leute es bemerken und wollen es dann auch benutzen.

Ändern des Managements Dies ist schwierig, und ich bin nicht sicher, wie ich es tun soll, abgesehen davon, dass ich jemand bin, der Ergebnisse erzielt und dessen Meinung geschätzt wird. Sobald Ihre Meinung gewürdigt wird, können die Leute anfangen zuzuhören oder nicht.

Erinnern Sie sich zuletzt daran, dass Veränderungen schwierig sind und Zeit brauchen. Bleib dran und fang klein an und baue auf.