Ich kann den Termindruck verstehen. Sie möchten Ihren Nutzern eine Freude machen, denn sie sind das Lebenselixier des Unternehmens. Es ist jedoch auch wahr, dass bestimmte Änderungen später alles einfacher machen werden. Leider hat das Management in meiner Organisation einen instinktiven Widerstand gegen solche Änderungen und dieser Widerstand ist so stark, dass er langfristige Verbesserungen behindert.

Beispielsweise hat Apple kürzlich die automatische Referenzzählung für iOS-Programme eingeführt. Dies ist eine wesentliche Verbesserung gegenüber den manuellen Retain / Release-Aufrufen, die zuvor verwendet wurden. Der Code ist einfacher zu schreiben und einfacher zu warten. Die Umstellung selbst kann zu Abstürzen führen. Aber sobald diese geklärt sind, wird die Anzahl der zufälligen seltsamen Abstürze wahrscheinlich sinken.

Ich habe meinem Chef kürzlich gesagt, dass ich auf automatische Referenzzählung umstellen möchte. Seine Antwort war, dass er sich auf sichtbare Verbesserungen konzentrieren wollte. Es ist wahrscheinlich, dass diese Reaktion wiederum auf den Druck zurückzuführen ist, den er von oben auf sich nimmt - und wahrscheinlich direkt vom CEO.

Es gibt viele ähnliche Beispiele. Der rote Faden ist, dass etwas repariert werden muss, aber die kurzfristigen Kosten des Updates überwiegen die kurzfristigen Vorteile, wobei "kurzfristig" als "innerhalb der nächsten Wochen" definiert wird.

Wie soll ich mit der Situation umgehen?

EDIT: Danke für die Antworten. Lass sie kommen. Da dies für meine Situation relevant ist, sollte ich klarstellen, dass mein Manager und der CEO beide Programmierer sind - obwohl der CEO möglicherweise inzwischen vergessen hat, wie dies ist. Anscheinend wurden ihre Programmiererseiten von anderen Belastungen überfordert.

Sie sprechen wirklich über technische Schulden. Vielleicht würde eine Metapher Ihren Managern helfen. Ich vergleiche oft den Effekt der technischen Verschuldung von Software mit dem Kochen in einer schmutzigen Küche. Wenn das Waschbecken, die Theken und der Herd mit schmutzigem Geschirr angehäuft sind und sich Müll auf dem Boden befindet, dauert es länger, eine Mahlzeit zuzubereiten. Der schnellste Weg, um die nächste Mahlzeit zuzubereiten, ist jedoch, die Unordnung zu umgehen. Das Reinigen der Küche und das Sauberhalten verzögern die nächste Mahlzeit, verbessern jedoch die Lieferung aller nachfolgenden Mahlzeiten. Und so wie die hungrige Person im Esszimmer die unordentliche Küche nicht sehen kann und nicht versteht, warum Sie aufräumen wollen, bevor Sie mit dem Kochen beginnen, kann Ihr Management die Unordnung im Code nicht sehen. Sie müssen ihnen entweder das Durcheinander zeigen oder die Qualitätsprobleme und Verzögerungen, die durch das Durcheinander verursacht werden.

Vielleicht könnten Sie auch über dringende Aufgaben und wichtige Aufgaben sprechen. Wenn wichtige Aufgaben nicht erledigt sind, dauern dringende Aufgaben länger und kosten mehr.

Sie sind auf etwas gestoßen, das Programmierer irgendwann in ihrer Karriere überall plagt : Dieser Code muss überarbeitet werden, es gibt dort architektonische Probleme, dieses Modul ist nicht mehr zu pflegen usw. Aufgrund der gegenwärtigen Unternehmenskultur jedoch Sie müssen sich auf Arbeiten konzentrieren, die nur unmittelbar sichtbare Vorteile bringen.

Es ist wieder das klassische Eisberggeheimnis . Das Geheimnis hat mit der Tatsache zu tun , die genauso wie ein Eisberg 90% unter Wasser ist, so ist die Mehrheit des jedes Entwicklungsprojektes: 90% der Arbeit völlig unsichtbar für den Endverbraucher sein wird. Dieser Code wird sich auf den Endbenutzer auswirken, aber das Management hat Probleme, sich darüber Gedanken zu machen, warum Sie sechs Stunden damit verbracht haben, die Wartungs- / Freigabe- und automatischen Referenzierungsaufrufe umzugestalten, wenn sie keinen Unterschied sehen und alles in Ordnung ist.

Hier sind einige Fakten, die Sie zu diesem Thema mitnehmen können.

• Das Management wird das Eisberggeheimnis nicht verstehen , es sei denn, es ist selbst Programmierer .
• Dies ist ein Problem der Unwissenheit, nicht der Bosheit. Der CEO möchte ein gutes Produkt - er versteht einfach nicht alles, was zu einem guten Produkt gehört.
• Der CEO (und Ihr direkter Chef) sind nicht dumm - studieren Sie und bereiten Sie einige Fakten und einige konkrete Daten vor, warum Sie die Zeit für diese und andere Iceberg-Probleme aufwenden sollten.

Vergiss nicht - du bist ein Mann (oder eine Frau) der Firma. Kein Codemann. Sie entwickeln dieses Produkt für ein Unternehmen, das ein berechtigtes Interesse an Erfolg oder Misserfolg hat - Ihre Projekte und Projektvorschläge sollten dies widerspiegeln. Zeigen Sie Ihre Leidenschaft für das Unternehmen und das Produkt, zeigen Sie Ihr Wissen und beweisen Sie Ihrem Chef und CEO, dass sie Ihnen vertrauen sollten, wenn Sie zu ihnen kommen und sagen, dass etwas funktionieren muss. Zeigen Sie ihnen, wie sich dies auf das Endergebnis auswirkt - sei es, indem Sie dem Produkt einen Mehrwert verleihen (mehr Menschen kaufen Kopien) oder indem Sie später Zeit sparen (weniger verärgerte Kunden, wenn Ihr Produkt ausfällt).

Das tust du nicht.

Ich sehe diese und alle ähnlichen Fragen als eine Sackgasse. Man kann die Leute von nichts "überzeugen". Wenn sie sich solcher Dinge noch nicht bewusst sind oder sie nicht untersuchen, geben sie wahrscheinlich keinen Schlag ab. Und keine Datenmenge wird sie sonst überzeugen. Veränderung muss von innen kommen. Sie können ein Pferd zum Wasser führen, aber Sie können ihn nicht zum Trinken bringen.

Ich sage, backe deine gewünschten Änderungen in deine nächsten technischen Schätzungen. Seien Sie wie, hey, wir müssen auf dieses neue Framework upgraden, das Apple eingeführt hat. Lassen Sie es nicht zu, dass Sie ARC nicht in Ihrer Roadmap verwenden. Es gibt keine Optionen. Die Migration auf ARC ist der einzige Weg.

Ich habe hier bereits eine ähnliche Frage beantwortet, sodass dies als Duplikat angesehen werden kann. Grundsätzlich werden Sie keine Abmeldung erhalten, um eine "Umgestaltungsmaßnahme" durchzuführen. Die Art und Weise, wie Sie den Code bereinigen, entspricht der Pfadfinderregel: Lassen Sie den Code immer bereinigen, wenn Sie ihn verlassen, als wenn Sie angekommen sind.

Genauso wie die Tilgung echter Schulden wie eine unüberwindliche Aufgabe (oder das Aufräumen eines unordentlichen Hauses) erscheinen kann. Der Trick ist, es Stück für Stück besser zu machen, bis Sie anfangen, "Inseln der Sauberkeit" zu sehen. Sobald Sie eine signifikante Dynamik erreicht haben, werden andere Entwickler im Team dies bemerken und eventuell einen Beitrag zur Aufgabe leisten.

Ich würde vorschlagen, den Clean Coder von "Onkel" Bob Martin zu lesen . Das Schreiben von gutem Code ist Teil Ihrer Arbeit. Sie bitten nicht um Erlaubnis, Ihren Job zu machen, Sie tun es einfach.

Wie bei anderen Fragen dieser Art müssen Sie Zahlen angeben, die das Management verstehen wird. Zahlen, die anzeigen, wie viel Zeit durch die Implementierung dieser Verbesserungen gespart wird, wie viele weniger "zufällige seltsame Abstürze" auftreten usw. Überzeugen Sie sie davon, dass Abstürze für den Endbenutzer sichtbar sind und dass alles, was getan wird, um sie zu verhindern, sich positiv auf das Geschäft auswirkt.

Sie können auch versuchen, diese Verbesserungen in Ihrer Freizeit (dh außerhalb der Arbeitszeit) umzusetzen und anschließend dem Management die Vorteile aufzuzeigen. Ich würde dies nur tun, wenn klar ist, dass das Management nicht versteht, was Sie vermitteln möchten, und / oder dass es keine Zeit für Sie einplanen möchte, um es überhaupt zu versuchen.

Viel Glück!

Präsentieren Sie einen Business Case

Es gibt viele Gründe, warum Empfehlungen von Ingenieuren häufig ignoriert werden. Der beste Weg, um mit fast allen Gründen umzugehen, ist der Business Case, warum dies getan werden sollte. Die klassische Kosten-Nutzen-Analyse. Dies ist nicht nur ein zwingendes Argument, sondern gibt Ihren Chefs auch etwas, das sie ihren Vorgesetzten empfehlen können.

• Was kostet es im Voraus?
• Was sind die laufenden Kosten?
• Was sind die projizierten Zeit- / Geldeinsparungen und woher kommen sie?
• Wie lange wird es dauern, bis wir den ROI sehen?

Bei einem Business Case sollten Sie Ihre Argumentation immer mit Daten untermauern.

• Wie viel Zeit investiert die Entwicklung derzeit in die Bewältigung von Problemen, die dadurch beseitigt oder gemildert werden?
• Wie viele Anwenderbeschwerden treten im Zusammenhang mit den Problemen auf, die dadurch beseitigt oder gemildert werden?
• Welche weiteren Vorteile wird es haben?

Richten Sie die Zahlen aus und stellen Sie eine grobe, aber einfache Gleichung auf. Das kostet X und kommt der Firma Y zugute.

Hinweis: Seien Sie nicht überrascht, wenn es unerschwinglich ist, eine akademisch gute Idee umzusetzen.

Diese Art von Änderung fällt in die Kategorie Refactoring. Der agile Ansatz wäre, dass Sie AMPLE-Refactoring-Zeit in jede von Ihnen geschätzte Story einbeziehen, und das ist genau der Grund. Abgesehen von Ingenieuren wird niemand verstehen, warum Sie dies tun möchten, und das ist in Ordnung. Es ist nicht IHRE Aufgabe, zu bestimmen, wie Sie richtig codieren, sondern Ihre.

Wenn Sie das nächste Mal einen Teil Ihrer Arbeit erledigen müssen, stellen Sie sicher, dass diese Änderungen ein Teil davon sind. Wenn Sie Schätzungen bereitstellen, müssen Sie 30% zu Ihrer Schätzung für das Refactoring hinzufügen. Wenn Sie keine Schätzungen bereitstellen, führen Sie das Refactoring einfach als Teil Ihrer Arbeit aus.

Es kann dich langsamer machen - nun, nein, das ist nicht die Art und Weise, wie du es siehst. Die Art und Weise, wie du es siehst, ist, dass deine momentane Geschwindigkeit eine Illusion ist, im Wesentlichen eine Lüge, dass du die Kette hochkommst etwas langsamer wegen dieser Arbeit, von der Sie wissen, dass sie erledigt werden muss.

Sie könnten wahrscheinlich schneller Häuser bauen, wenn Sie keinen Beton als Fundament verwenden - und sie würden für den Kunden genauso gut aussehen, aber - nun - auch wenn der Kunde die Notwendigkeit für das Fundament, den Erbauer, nicht sieht muss. (Dies ist tatsächlich eine interessante Parallele, da sich herausstellt, dass Bauherren nicht immer das tun, wovon sie wissen, dass sie es tun sollten. Wir müssen Gesetze verabschieden, um sie dazu zu zwingen. Es gibt keine derartigen Gesetze für die Softwareentwicklung, auch wenn wir vor denselben Herausforderungen stehen Entscheidungen treffen und oft die falschen ...)

Sie erwähnen, dass Sie das Glück haben, dass Ihr Manager und Ihr CEO beide Programmierer sind. So sie wahrscheinlich tun verstehen , was technische Schuld ist.

Sie sollten mit der Situation umgehen, indem Sie versuchen, die Situation anhand von Fakten zu lösen. Dies bedeutet, dass Sie möglicherweise nicht die gewünschten technischen Verbesserungen vornehmen (Fakten können auf diese Weise ärgerlich sein).

Ihre Aufgabe ist es, sicherzustellen, dass sie die Kosten und den Nutzen der Tilgung bestimmter technischer Schulden, die Ihnen entstehen, verstehen. Ihre Aufgabe ist es, zu entscheiden, ob die beste Verwendung der Ressourcen darin besteht, sie auszuzahlen oder etwas anderes zu tun.

Genauso wie es für Leute, die nicht mit dem Code befasst sind, schwierig sein kann, die Vorteile der Verbesserung des "verborgenen" Materials zu erkennen, kann es für Programmierer schwierig sein, die Vorteile von sichtbaren Codeänderungen zu erkennen, wenn sich die Vorteile auf Bereiche des Geschäfts auswirken. versteckt "vor den Entwicklern.

Es ist schön, wenn Ihr Management Ihnen erklären kann, warum die sichtbaren Merkmale Ihre Zeit wert sind, als die technischen Schulden zu begleichen, aber es ist in Wirklichkeit nicht Ihre Aufgabe, die Entscheidung zu treffen. Wenn du es dir also erklärst, ist das nicht viel für das Geschäft, außer dass du glücklich bist. Und in gewisser Weise besteht das darin, ihnen nicht zu vertrauen, dass sie ihre Arbeit tun. Wenn du es nicht magst, wenn sie dich mikromanagen, solltest du es verstehen.

Also, solange Sie sie über den Status aller technischen Schulden und die Kosten und Vorteile des Ignorierens im Vergleich zur Tilgung auf dem Laufenden halten, haben Sie Ihre Arbeit getan. Es sei denn , Sie wirklich nicht vertrauen Management ihre tun, in dem Fall , dass Sie ein viel größeres Problem, dass eine ganz andere Frage zu beantworten wäre.

Vielleicht ist dies keine Antwort, sondern eine Antwort, die auf Fehlern basiert, die ich gemacht habe. Auch eine Meinungsverschiedenheit mit einigen der Philosophien, die ich hier lese.

• Lassen Sie sich nicht von dem Glauben täuschen, dass der Programmierer es am besten weiß.
• Sei ehrlich. Überdenken Sie die Faktoren, aber lügen Sie nicht und schreiben Sie Schätzungen für Ihre eigenen Zwecke auf.
• Du besitzt den Code nicht. Nehmen Sie keine Arbeiten vor, die nicht vom Leiter genehmigt wurden.
• Du könntest mit etwas Recht haben; Sie könnten sich irren ... aber Sie sollten das tun, wofür Sie bezahlt werden.

Befolgen Sie jedoch unbedingt die hervorragenden Ratschläge zur Verbesserung der Situation.

Sie arbeiten offensichtlich für einen spitzen Chef (PHB). Er programmiert nicht mehr, wenn überhaupt, und wenn er es tat, war er wahrscheinlich nicht wirklich gut (obwohl er gerne Sätze wie "const correctness" und "segmentation fault" einfügt, damit die Jungs wissen, dass er sich seine Streifen verdient hat ) - so wurde er für das Management ausgewählt.

Der CEO (der praktisch einen Mohawk hat) mag das PHB, weil das PHB Funktionen bietet . Stolz demonstriert er bei jedem Sprint ein neues Kästchen (leicht falsch ausgerichtet, mit einem mehrdeutigen Etikett), ein funkelndes Symbol (das noch in keiner Umgebung funktioniert, aber 8-Bit-Farben über Citrix) und eine Form (die aufgrund der Rennbedingungen zufällig abstürzt) In der maßgeschneiderten XML-Variante implementierte C eine lokale Datenbank, die niemand im Entwicklerteam zu berühren wagt, da sie vor 10 Jahren von einer der Legenden der alten Garde-Entwickler geschrieben wurde und ALLES mit Makros mit 5-Buchstaben-Namen ausführt, unabhängig davon, ob sie 5 Buchstaben benötigten oder nicht).

Die Programmierer, die tatsächlich die "Arbeit" erledigen (Sie kennen das, was passiert, ungünstigerweise nach all der wirklichen Arbeit wie dem Zeichnen von Kreisen auf Whiteboards, Schreien und Essen von Miniatur-Battenburgs), wissen, dass in einem vernünftigen System die Arbeit erledigt ist, die gerade erledigt wurde 10 Jungs 10 Tage, um sich mühsam aus dem nicht gepflegten Dschungel herauszuhacken, würden wahrscheinlich ein oder zwei Manntage betragen, einschließlich des Testens. Aber um das System dahin zu bringen, wo es vernünftig ist, kann es 6 Monate dauern, bis wirklich harte Arbeit geleistet ist, wobei die offensichtliche externe Belohnung gering ist.

Der PHB weiß, dass er in 6 Monaten per Haken oder Gauner dreißig oder vierzig neue Funktionen in die Anwendung integrieren kann, mit denen die Verkäufer (die Magier sein müssen, wenn sie wissen, was sie tatsächlich verkaufen) neue Einkäufe und Upgrades veranlassen können .

Um dem PHB seine Gebühren zukommen zu lassen: Ohne diese Ankreuzfelder und Formulare könnte der Verkauf stagnieren oder sinken, ein Wettbewerber könnte Marktanteile gewinnen, und das könnte schlimmer sein als die Alternative.

Die Schlussfolgerung, zu der ich gekommen bin, ist, dass der einzige Ausweg aus dem Sumpf die Arbeit in einem neuen Startup ist, mit ein paar Leuten, die Ihre Vision davon teilen, wie Software gemacht werden sollte, und sich dann beharrlich an diese Philosophie halten (ich arbeite immer noch daran, dorthin zu gelangen!)

Es gibt noch weitere versteckte Kosten, die in anderen Antworten nicht erwähnt werden. Das heißt, dass gute Ingenieure dazu neigen, in der beschriebenen Umgebung zu bleiben. Irgendwann hat jemand mit dem Ehrgeiz oder der Fähigkeit zur Umgestaltung das Unternehmen verlassen, und dann werden die Dinge auf eine sehr schlechte Art und Weise verlaufen, wahrscheinlich unbehebbar. Leider können Sie Ihrem Manager dies nicht sagen, ohne arrogant ("Ich bin einer Ihrer besten Programmierer") und aufdringlich ("Ich gehe, wenn Sie nicht tun, was ich will") zu wirken. Denken Sie jedoch daran, dies in Ihrem Exit-Interview zu erwähnen, um sicherzustellen, dass Sie nicht erneut eingestellt werden.

Sie haben beide Recht und Unrecht, deshalb bleiben diese Themen lange Zeit bestehen und erzeugen harte Gefühle.

Die Gründe dafür sind oben klar angegeben: Management denkt in Geld; oder noch genauer: Einnahmen. Für sie bedeutet etwas, das Kosten verursacht, aber keine direkte Sichtbarkeit für den Kunden hat, keinen Umsatz, also ist es ein schlechter Plan.

Ihre Vision ist auch richtig: Es wird gut für die Kunden sein, aber auf längere Sicht. Ihre Maßnahmen könnten in Zukunft einen noch größeren Umsatz generieren als die kurzfristigen Pläne.

Sie sind nicht der Manager, Sie sind nicht derjenige, der direkt für die Einnahmen verantwortlich ist (ich nehme natürlich an). Sie vermischen sich also mit ihren Problemen (so fühlt es sich für das Management an), und Sie konzentrieren sich nicht auf Ihre Aufgabe: die Software weiter auszubauen.

Alles harte, klare Worte, aber so entstehen die meisten Probleme aufgrund von Kommunikationsfehlern. Sie wollen beide dasselbe, aber Ihre kurzfristigen Entscheidungen werden unterschiedlich getroffen. Alles, weil der Entwickler eine andere Einstellung hat als der Manager.

Wie lösen Sie dieses Problem? Sie kommunizieren und verstehen sich in einer Reihe von Fragen recht gut. Das wird höchstwahrscheinlich der Fokus auf Kundenbindung und -zufriedenheit sein.

Um dieses Problem in einer stabilen und zukunftssicheren Methode zu lösen, müssen Sie Folgendes feststellen: Messen Sie die Kosten für die Fehlerbehebung in altem Code. Messen Sie die Zeit, die zusätzlich benötigt wird, um mit der alten Software zu arbeiten, und wie es mit der neuen Codebasis wäre.

Um dies zu beweisen, können Sie beispielsweise Folgendes ganz einfach tun: Verzweigen Sie die Software in Ihre Versionierung. Tun Sie zunächst, was das Management wünscht, und erstellen Sie diese Funktion. Sie tun dies, aber die Vereinbarung ist, dass Sie Zeit haben, den anderen Weg zu zeigen. Dann machen Sie dasselbe in der neuen Branche, aber beheben Sie zuerst die Probleme, die Sie loswerden möchten. Dann entwickeln Sie auch die Lösung.

Jetzt haben Sie die gleiche Lösung, aber völlig anders entwickelt. Erstellen Sie daraus einen Fall, und stellen Sie die Lösungen nebeneinander, einschließlich einiger Verwaltungsinformationen wie Stabilität, benötigter Codemenge und des Codes selbst.

Nehmen Sie sich jetzt einen Kaffee zusammen und werfen Sie einen Blick darauf. Dabei geht es nicht darum, wer Recht hat, sondern welchen Einfluss beide Richtungen auf das Unternehmen haben. Das wird ein Treffen schaffen, das wirklich nützlich ist und keine besser-schlechter-Diskussion, weil das nicht die Atmosphäre erzeugt, die Sie beide brauchen werden. Das macht Ihr Produkt nicht besser.

Wenn Sie eine Codeüberprüfung haben, erstellen Sie ein technisches Ticket, aus dem hervorgeht, dass der Code mithilfe von ARC verbessert werden sollte, und weisen Sie es dem Manager zu.

Ihn davon überzeugen. Erläutern Sie ihm einige kleine Beispiele für ähnliche technische Verbesserungen, die Sie vorgenommen haben, und deren Vorteile für die Projekte.

Sie müssen diese Änderungen nur so verkaufen, wie das Management bereit ist, sie zu kaufen:

Suchen Sie nach einer benutzerbezogenen Funktion, die so überzeugend ist, dass die Verwaltung sie nur haben muss, ohne einige grundlegende Verbesserungen des Codes jedoch nicht auskommen kann.

Es ist die Aufgabe Ihres Chefs, sicherzustellen, dass das Unternehmen seine Entwicklung darauf konzentriert, das zu liefern, was Kunden als Mehrwert wahrnehmen. Es gibt zwei Faktoren, die diese Wahrnehmung verändern können:

1. Wie lange dauert die Zustellung auf Kundenwunsch?
2. Liefern Sie, wenn Sie sagen, dass Sie es tun werden?

Die meisten würden es vorziehen, wenn Sie sagen, dass es 6 Wochen dauert und in 5 Tagen liefert, als wenn Sie sagen, dass Sie in 3 Tagen liefern, aber in 4 Tagen.

Mit einer aktuellen Codebasis, die einfacher zu verwalten und zu erweitern ist, können Sie schneller liefern und die Vorhersagbarkeit verbessern. Wenn Sie zu viel Zeit für Fehlerkorrekturen aufwenden, stehen Ihnen weniger Ressourcen zum Hinzufügen neuer Funktionen zur Verfügung. Bewerten Sie die Menge an Ressourcen, die für das Korrigieren des Codes aufgewendet wurden, und wie genau Sie die versprochenen Features einhalten. Auf diese Weise können Sie feststellen, ob Ihr aktueller Code (gemäß der Philosophie Ihres Chefs) zu teuer ist.

Lassen Sie mich Ihnen von einer 2-Milliarden-Dollar-Chance erzählen, die uns aufgrund der Trägheit des Managements fast durch die Hände gerutscht wäre.

Einige von uns hören gerne auf die Stimme des Kunden und verstehen, was er will. Es ist nicht immer das, wonach er fragt, aber wenn Sie in der Lage sind, Gespräche mit Ihrem Kunden zu führen, können Sie sich schließlich gegenseitig ein Bild davon machen, was er will. (Dann kann er explizit danach fragen.)

Vor diesem Hintergrund ist es wichtig zu verstehen, wer dieses Gespräch mit dem Kunden führen soll. In der Regel arbeiten Ihre Mitarbeiter für die Geschäftsentwicklung mit einigen Hauptdesignern zusammen. Wenn Sie eine Konkurrenz haben, können Sie davon ausgehen, dass der Kunde dieses Gespräch auch mit ihm führt.

Gleichzeitig ist es wichtig, dass die Entwickler auf ihrem Gebiet auf dem neuesten Stand sind, denn es wird einen Wettbewerb geben, der Sie schlagen wird, wenn Sie es nicht sind.

In unserer Situation hatten wir einen bestehenden Kunden und ein einigermaßen effektives Produkt, das auf alter Technologie basierte, und der Kunde benötigte schnelle Upgrades. Was sie wirklich brauchten, war ein komplettes Ersatzprodukt, aber die Denkweise in unserem Unternehmen war, dass dies uns sofort in eine Wettbewerbsposition zwingen würde, während die Modifizierung des bestehenden Produkts es unserem Kunden ermöglichte, mit uns fortzufahren, ohne rechtlich dazu verpflichtet zu sein, es wettbewerbsfähig zu machen. Unser Management glaubte, dass sie diesen Markt besaßen. Das Problem war, dass sie die Upgrade-Anforderungen nicht erfüllen konnten, da die vorhandene Produktstruktur nicht flexibel genug war, um ein Upgrade durchzuführen.

Der Kunde wurde ungeduldig und begann Gespräche mit konkurrierenden Quellen zu führen. Wir haben unser "Eigentum" an diesem Markt und ein paar Milliarden Dollar Umsatz verloren. Als der Markt uns jedoch in eine Wettbewerbsposition zwang, hatte das Management keine andere Wahl, als entweder aus dem Geschäft auszusteigen oder im Wettbewerb zu bestehen. (Die meisten von denen, die Straßensperren waren, wurden schließlich entlassen.) Wir nahmen am Wettbewerb teil und konnten das Geschäft durch den dünnsten Faden zurückerobern.

Ich sagte zu Beginn, dass uns diese Gelegenheit fast entgangen wäre. Wir haben das Geschäft für die Einnahmen zurückbekommen, die ich erwähnt habe. Wenn wir uns am Anfang eher auf die Kundenbedenken eingestellt hätten, hätte es keinen echten Wettbewerb gegeben.

Das Take-away, das ich anbiete, ist folgendes: Versuchen Sie immer, in Ihren persönlichen Fähigkeiten führend zu bleiben. Entwickeln Sie immer ein Produkt, das flexibel ist und schnell an die Bedürfnisse Ihrer Kunden angepasst werden kann. Wenn Sie zu lange für ein Unternehmen arbeiten, das nicht so denkt, verkümmern Sie und Ihre persönliche Motivation nimmt ab. Ich habe es gesehen.

Wenn Sie die Idee haben, Ihr Produkt aus irgendeinem Grund zu verbessern, stellen Sie sich folgende Fragen: - Ist es das, was der Kunde meiner Meinung nach möchte? Kann ich meine Gedanken zur Produktentwicklung gegen die Stimme des Kunden validieren? Ist mein Unternehmen in der Lage, auf die Bedürfnisse des Kunden einzugehen? Wenn das so ist, wie? - Sie sollten dann in der Lage sein, Ihre Produktentwicklungsvorschläge zu überzeugen.

Die gemeinsame Geschäftssprache in allen Bereichen und Branchen ist Geld. Das Problem, das Sie beschreiben, ist kein Programmierproblem, sondern ein Geschäftsproblem. Wenn Sie eine angemessene Antwort auf ein Geschäftsangebot erhalten möchten, müssen Sie es in der Geschäftssprache formulieren. Dies bedeutet, dass Sie in der Lage sein müssen, einen alternativen Projektplan mit allen Kosten und Nutzen vorzulegen.

Sie müssen sich mit Opportunitätskosten, dem ROI (Return on Investment) und dem Kapitalwert (Barwert) vertraut machen. Sie benötigen dazu keinen MBA, benötigen jedoch Zugriff auf Daten, die Ihnen möglicherweise nicht zur Verfügung stehen, z. B. Personalkosten, Gemeinkosten und Umsatzpotenzial. Wenn Sie ein klares Argument dafür abgeben können, dass ein Pfad mit harten Zahlen mehr Wert liefert als ein anderer, erhalten Sie die volle Aufmerksamkeit des Managements.

Als ich ein neuerer Entwickler in einem sehr kleinen Team war, habe ich in meiner Freizeit viele dieser Verbesserungen vorgenommen. Ich habe es genossen; Ich loggte mich ein und probierte interessante neue Techniken aus, während ich abends mit meiner Frau im Wohnzimmer saß. Als ich älterer Entwickler und dann Manager eines größeren Teams wurde, verschwand meine Freizeit. Wir haben zusätzliche Stunden gearbeitet, um die Funktionen und wichtigen Korrekturen zu erledigen. Es wurde wirklich schwer zu rechtfertigen, dass jemand seine Zeit für diese regelmäßige Hausarbeit aufwenden musste, obwohl wir alle wussten, wie wichtig es war.

Ihre Vorgesetzten müssen nicht erklären, wie wichtig es ist, die Wartungskosten niedrig zu halten, die Kosten für zukünftiges Wachstum zu senken, ein talentiertes Entwicklungsteam zu beschäftigen usw. Wenn dies der Fall ist, haben Sie große Probleme. Was sie jedoch brauchen könnten, ist ein Plan. Denn ich vermute im Moment, dass sie alle möglichen Pläne, Zeitpläne, Roadmaps, Versprechungen und Druck auf der Seite "Funktionalität hinzufügen" haben, die gegen bloßes Wunschdenken und unbefristete Anfragen des Entwicklerteams konkurrieren.

Eine Sache, die Sie versuchen könnten, ist die Erstellung eines dokumentierten Plans. Prüfen Sie, ob Sie es an Releases binden oder Kriterien für neue Funktionen beenden können. Die Aufforderung, "einige Zeit damit zu verbringen, die Referenzzählung zu wiederholen", ist für Ihren Chef möglicherweise schwierig zu genehmigen, die Planung eines Zeitblocks von 5 Tagen in 4 Wochen ist jedoch möglicherweise einfacher. Grundsätzlich können Sie jedoch feststellen, dass neue Funktionen geplant und geplant sind. Versuchen Sie, dies nachzuahmen, oder fügen Sie einen Teil unter der Haube hinzu.

Beginnen Sie klein, indem Sie nach 5% Zeit fragen, die für diese Art von Dingen zur Verfügung steht, und bauen Sie dann nach und nach Ihre eigenen Prioritäten für die Technologie-Roadmap auf. Schon bald werden Sie sogar einen Eindruck von den Herausforderungen Ihrer Chefs bekommen, da Sie schnell viel mehr großartige Ideen finden, als Sie Zeit haben.

Viel Glück!

Aus folgenden Gründen wird Ihre Anfrage zur automatischen Referenzzählung abgelehnt:

1. Es ist keine Verbesserung . Sobald Sie etwas Größeres als hallo Welt haben, geht jede Änderung in die falsche Richtung. Keine Umgestaltung wird die Tatsache ändern, dass Änderungen immer in die falsche Richtung führen. Der Trick besteht darin, zu wissen, wann Ihre Änderungen so bedeutend sind, dass das Risiko neuer Probleme weiterhin besteht. Ihr Management hat klargestellt, dass es das Risiko nicht wert ist, wenn Endbenutzer es nicht sehen können.
2. Referenzzählung ist eine völlig verrückte Funktion. Sie haben gesehen, wie eine bekannte Firma ein Feature implementiert hat, und sofort gedacht, dass Sie dasselbe Feature benötigen. Nun, es ist sehr wahrscheinlich, dass Ihre Codebasis völlig anders ist als die, die Apple verwendet. Wahrscheinlich funktioniert das Referenzzählen nicht oder es ist nur Zeitverschwendung. Sie sollten einen anderen Weg finden, bei dem Referenzzählungsprimitive nicht überall in Ihrem Code verteilt werden müssen. Wahrscheinlich erfordert Ihr Nachzählungsplan Tausende von Änderungen in der Codebasis. Die meisten dieser Änderungen sind nicht erforderlich. Nur Zeit- und Geldverschwendung.
3. Sie lösen das falsche Problem. Das Management weiß normalerweise, welche Probleme im System auftreten. Einige irrelevante Speicherverluste, die von der Lösung für die Nachzählung behoben werden, gehören nicht dazu. Konzentrieren Sie sich auf echte Probleme und nicht auf imaginäre Probleme beim Umgang mit Speicher.
4. Die Implementierung dauert zu lange. Apple ist ein etwas größeres Unternehmen als Ihr unbedeutendes Team mit wenigen Programmierern und einigen Managern. Sie können große Veränderungen vornehmen, indem sie nur den Preis bezahlen. Wenn es ein paar Millionen braucht, um etwas umzusetzen, dann sind es Erdnüsse. Wenn kleine Unternehmen versuchen, dasselbe zu tun, wird ihnen schnell das Geld ausgehen. Softwareentwicklung ist schon sehr teuer; das Hinzufügen unnötiger Kosten wird kein bisschen helfen. Eine irrelevante Funktion wie die Speicherverwaltung wird die Schleusentore öffnen: Nachdem sie diese genehmigt haben, möchte die Hälfte Ihrer Programmierer, dass ihre eigene "Verbesserung" implementiert wird. Es ist eine unendliche Geschichte und das Unternehmen könnte stattdessen etwas Nützliches tun.

Hier sind einige Schritte, mit denen Sie das Problem beheben können:

1. Löschen Sie die Funktion
2. Finden Sie heraus, was das eigentliche Problem ist
3. Mach etwas Nützliches
4. Planen Sie sorgfältig, wie Sie Ihre Zeit nutzen
5. Finden Sie heraus, wie Ihre Verbesserungen Geld einbringen
6. Wählen Sie nur die Funktionen aus, mit denen Sie am meisten Geld verdienen
7. Erkennen Sie, dass der Programmieraspekt der Softwareentwicklung nur einen kleinen Teil des gesamten Systems ausmacht - Verbesserungen daran sind niemals die Zeit wert