Wie gehen „Custom Software-Unternehmen“ mit technischen Schulden um?

Was sind "Custom Software-Unternehmen"?

Mit "Unternehmen für kundenspezifische Software" meine ich Unternehmen, die ihr Geld in erster Linie durch den Bau kundenspezifischer, einmaliger Software verdienen. Beispiele sind Agenturen oder mittelständische Unternehmen oder Auftragnehmer / Berater wie Redify .

Was ist das Gegenteil von "Custom Software Unternehmen"?

Das Gegenteil des oben genannten Geschäftsmodells sind Unternehmen, die sich auf langfristige Produkte konzentrieren, unabhängig davon, ob es sich um bereitstellbare Desktop / Mobile-Apps oder SaaS-Software handelt.

Ein sicherer Weg, um technische Schulden aufzubauen:

Ich arbeite für ein Unternehmen, das versucht, sich auf eine Suite von SaaS-Produkten zu konzentrieren. Aufgrund bestimmter Einschränkungen beugen wir uns jedoch manchmal dem Willen bestimmter Kunden und bauen keine benutzerdefinierten Softwarekomponenten mehr auf, die nur für diesen Kunden verwendet werden können.

Dies ist ein sicherer Weg, um technische Schulden zu machen. Jetzt müssen wir ein bisschen Software warten, die unserem Kernprodukt nichts hinzufügt.

Wie gehen Agenturen damit um, wenn Maßarbeit ein sicherer Weg ist, technische Schulden zu machen?

Das hat mich zum Nachdenken gebracht. Unternehmen, die kein Kernprodukt im Mittelpunkt ihres Geschäftsmodells haben, führen immer maßgeschneiderte Software-Arbeiten durch. Wie gehen sie mit dem Begriff der technischen Verschuldung um? Wie treibt es sie nicht in technische Insolvenz ?

Wenn Sie die benutzerspezifischen Anforderungen in etwas verwandeln können, das für alle nützlich ist, ist das großartig. Wenn der Kunde bereit ist, die laufenden Supportkosten für das Feature zu bezahlen, auch toll. Wenn Sie jedoch ein kleines Team sind und Schwierigkeiten haben, alle Funktionen zu unterstützen, müssen Sie nur einige schwierige Entscheidungen über die Funktionen treffen, die Sie am wenigsten benötigen, und dann einige Zeit investieren, um sie aus Ihrer Codebasis zu entfernen.

SaaS versetzt Sie in die Lage, Nutzungsstatistiken zu sammeln. Sie sollten Ihre Funktionen erweitern, wenn Sie dies noch nicht getan haben, damit Sie verfolgen können, wer was verwendet. Unsere Erfahrung zeigt, dass die idiomatischsten Kunden in der Regel auch die dysfunktionalsten sind. Der Typ, der seine Füße stampfte und den Atem anhielt, bis Sie ihm einen Export-zu-MS-Access-Knopf gaben, hat ihn wahrscheinlich seit über einem Jahr nicht mehr benutzt. Einige Funktionen bleiben erhalten, obwohl sie nur von einem Kunden verwendet werden, da dieser Kunde laut ist und droht, sein Geschäft jedes Mal an einen anderen Ort zu verlegen, wenn etwas nicht zu seiner Zufriedenheit verläuft. Das Abkündigen der Funktion kostet Sie möglicherweise einen Kunden, aber die Zeit, die Sie für die Unterstützung dieser Funktion benötigen, kann Sie im Laufe der Jahre Dutzende von Kunden kosten. Es ist ein Maß für die Qualität Ihres Management-Teams,

Wenn Sie eine Funktion einstellen, müssen Sie die Entscheidung Ihren Kunden (oder zumindest den Betroffenen) rechtzeitig mitteilen. Ein Zeitraum zwischen sechs Monaten und drei Jahren ist angemessen. In der Tat, wenn Sie sich damit einverstanden erklären, benutzerspezifische Funktionen zu erstellen, können Sie versuchen, Ihre Vertriebsmitarbeiter dazu zu bringen, von Anfang an ein Ablaufdatum festzulegen. Nennen Sie es die "Support-Lebensdauer" und machen Sie deutlich, dass je länger sie es wollen, desto mehr Geld wird es kosten. Versuchen Sie, Problemumgehungen für Ihre Kunden bereitzustellen, damit diese nicht in Schwierigkeiten geraten, wenn eine Funktion ausgeführt wird, z. B. ein Skript, das Ihre exportierten XML-Dateien in das MS-Access-Format konvertiert, oder ein paar Ratschläge zur Auswahl eines besseren RDBMS.

Als vorbeugende Maßnahme haben wir uns vorgenommen, monatlich einen Bericht unseres Verkaufsteams an unser Entwicklungsteam und die Geschäftsleitung zu senden. Dieser Bericht behandelt das Feedback von Kunden - welche Funktionen sind am beliebtesten, welche Funktionen sind am gefragtesten, welche vorgeschlagenen Funktionen sorgen für die größte Resonanz. Dies ist interessant, wenn Sie ein Entwickler sind, aber der eigentliche Vorteil für das Verkaufsteam besteht darin, dass es sich im Kontext des Gesamtüberblicks nun ein wenig mehr Gedanken über die einzelnen Funktionen macht, anstatt einen endlosen Strom von Funktionsanforderungen und Prioritäten basierend zu senden Auf welchem ​​Client war der lauteste? Dies hat dazu geführt, dass unsere Vertriebsmitarbeiter bei der Aushandlung von Anfragen nach neuen Funktionen eine härtere Haltung einnehmen, da sie sich besser darüber im Klaren sind, wo die einzelnen Funktionen in das allgemeine Wertversprechen unseres Produkts passen.

Modularer Code mit vielen automatisierten Tests wird Ihnen helfen, wenn Sie Funktionen in Ihr Produkt hacken und diese wieder entfernen. Letztendlich ist dies jedoch keine Programmierfrage, sondern eine Verwaltungsfrage. Das Schreiben von Code, um einen Verkauf zu tätigen, ist ein Kinderspiel.

Wenn ich mit benutzerdefinierten Entwicklungsanforderungen konfrontiert werde, filtere ich sie durch den Cool-Filter, der die Anforderungen in drei Stapel aufteilt:

1. tolle dinge, die für alle nützlich und relativ einfach zu implementieren sind
2. tolle dinge, die für alle nützlich und schwer umzusetzen sind
3. blöde dinge, die nur für diesen einen client gebraucht werden, der sie sowieso nicht wirklich braucht

• Kategorie 1 wird im aktuellen Entwicklungszyklus implementiert.
• Kategorie 2 wird im nächsten Entwicklungszyklus implementiert.
• Kategorie 3 erhält ein Angebot von einem Entwicklermonat, nach dem die meisten Kunden feststellen, dass sich ihre Anfrage nicht lohnt.

Ehrlich gesagt ist dies nie fehlgeschlagen und ich glaube nicht, dass wir am Ende eines der Features der Kategorie 3 implementiert haben. Und natürlich ging keiner der Kunden zu Fuß (der Verkauf hätte mich das sonst nicht durchziehen lassen :)

(Diese Erfahrung war bei einer ISV-Firma)

Aufgrund bestimmter Einschränkungen beugen wir uns manchmal dem Willen bestimmter Kunden und bauen keine benutzerdefinierten Softwarekomponenten mehr auf, die nur für diesen Kunden verwendet werden können.

Ihr Problem ist nicht, dass Sie Code erstellen, der nur für einen Client verwendet wird. Das Problem ist, dass Sie Code, der nur für einen Kunden verwendet wird, in ein Produkt integrieren, das Sie an viele andere Kunden verkaufen, die diese Funktionalität nicht benötigen.

Unternehmen, die kein Kernprodukt im Mittelpunkt ihres Geschäftsmodells haben, erledigen immer maßgeschneiderte Software-Arbeiten. Wie gehen sie mit dem Begriff der technischen Verschuldung um? Wie treibt es sie nicht in die technische Insolvenz?

Sie liefern das Produkt. Und dann ziehen sie weiter. Wenn Sie ein Produkt unter Vertrag entwickeln, ist alles, was Sie in diesem Projekt tun, für diesen einen Kunden bestimmt. Alle technischen Schulden, die während der Entwicklung entstanden sind, werden nach Vertragsende zum Problem des Kunden, und der Entwickler wechselt zu einem anderen Projekt für einen anderen Kunden.

Das heißt natürlich nicht, dass es in Ordnung ist, einen beschissenen Job zu machen. Ihr oberstes Ziel ist es, dass Ihr Kunde weiterhin mit Ihnen zusammenarbeiten möchte, und Qualitätsarbeit ist der Weg dorthin. Dies bedeutet auch nicht, dass technische Schulden für Vertragsentwickler kein Problem darstellen. Selbst wenn Sie durchweg sauberen Code selbst schreiben, besteht die Möglichkeit, dass Sie irgendwann eingestellt werden, um an einem Projekt zu arbeiten, bei dem bereits eine Menge Schulden angefallen sind. Das kann gut sein (der Kunde möchte Sie dafür bezahlen, dass Sie das Chaos bereinigen) oder nicht (der Kunde hat keine Ahnung, wie schlecht der Code ist und versteht nicht, warum "nur" das Hinzufügen einiger weiterer Funktionen so lange dauern wird ).

Ich bin mit der Annahme nicht einverstanden, dass Zollarbeit garantiert technische Schulden erzeugt. Das Vermeiden von technischen Schulden bedeutet nicht, bestimmte Arten von Funktionen zu vermeiden - es bedeutet, unnötige Starrheit, Abhängigkeitsprobleme und Dinge zu vermeiden, deren Änderung eine Codebasis schwierig (dh teuer) macht. Benutzerdefinierte Funktionalität impliziert nichts davon - sie impliziert lediglich eine enge Basis für die Funktionalität. Daher besteht der Schlüssel darin, so viel gemeinsame, wiederverwendbare Logik wie möglich aus der Implementierung herauszuholen und das benutzerdefinierte, einmalige Material als eigenständiges Modul zu belassen, das für den anfragenden Kunden bereitgestellt werden kann.

Nehmen wir zum Beispiel an, Sie hätten ein Ergebnis, das eine interne Webanwendung ist, die Ihre Kunden in einem Intranet installieren würden. Eines Tages kommt ein Kunde und bietet an, einen mit Geld gefüllten Muldenkipper zu Ihrem Unternehmen zu fahren, wenn Sie eine Version für ihn erstellen, die anstelle einer Browser-Oberfläche eine Desktop-Anwendung mit "Rich Client" enthält. Wenn Ihr System gut aufgebaut und Ihre Abhängigkeiten gut verwaltet sind, müssen Sie lediglich die Domänen-, Datenzugriffs- und Dienstkomponenten wiederverwenden, während Sie eine neue Präsentationskomponente erstellen. Technische Schulden spielen keine Rolle, obwohl Sie nur einen Kunden haben, der zu 1999 zurückkehren und eine Desktop-Anwendung dafür haben möchte.

Die Beantwortung dieser Frage ist etwas kompliziert, da sie wie viele andere Dinge von den Umständen des Projekts abhängt, von der Kontrolle des beauftragten Unternehmens, davon, ob die kundenspezifische Software über den gesamten Lebenszyklus vom beauftragten Unternehmen verwaltet wurde, und von der Höhe von "Einmischung" durch andere Personen mit Zugang zur Codebasis, der Einstellung aller Beteiligten, der Komplexität des Projekts und den angewandten Methoden ... Ich könnte wirklich weitermachen.

Alle Systeme sind technisch hoch verschuldet. In einigen Fällen ist dies möglicherweise nicht besonders auffällig, da die Entwickler stets bemüht sind, eine saubere Codebasis zu gewährleisten. Kein System ist jedoch perfekt, und durch eine umfassende Neugestaltung kann ein scheinbar harmloses, aber langjähriges Problem offensichtlich werden. Wie gehen Vertragsunternehmen damit um?

In vielen Fällen nicht. Oft wird Software von einer Firma geschrieben, dann von einer anderen modifiziert, und es ist nicht ungewöhnlich, dass die Codebasis wirklich durcheinander gerät, da jedes unter Vertrag stehende Unternehmen zu einem engen Termin arbeitet und es nicht gerechtfertigt ist, den Code sauber zu halten ( und manchmal kaum getestet), wenn dies bedeutet, dass die Gefahr besteht, dass eine Frist versäumt wird.

In anderen Fällen finden Sie Unternehmen, die nicht nur ihr Vertragsprojekt gut verwalten, sondern auch die Zeit finden, die vorhandene Codebasis in einem besseren Zustand zu belassen, als sie es vorgefunden haben. Sie tun dies häufig mit sorgfältiger Planung, indem sie die Quellen der technischen Verschuldung ermitteln - normalerweise diejenigen, die sich am stärksten auf die neue Arbeit auswirken - und Strategien entwickeln, um Testfälle und Modifikationen bereitzustellen, die zur Verwaltung der technischen Verschuldung beitragen und all dies in ihren Projektplan einbeziehen .

Ist es eine Garantie für technische Schulden, eine maßgeschneiderte Software zu sein, anstatt ein zentrales Produkt zu schreiben? Die kurze Antwort lautet "Nein". Es ist jedoch wahrscheinlich, dass technische Schulden anfallen, wenn diese nicht aktiv bearbeitet werden. Dies ist das gleiche wie bei jedem anderen Softwareprojekt. Wenn Sie das Projekt während seines gesamten Lebenszyklus vollständig kontrollieren, haben Sie eine bessere Gelegenheit, mit technischen Schulden umzugehen. Wenn nicht, müssen Sie sich mit technischen Schulden befassen, die möglicherweise aus dem Code entstanden sind, den das vorherige Unternehmen zurückgelassen hat.

Wenn Sie sich jedoch die Frage stellen, ob das Schreiben von Software unabhängig von Ihrem Geschäftsmodell eine Garantie für die technische Verschuldung ist. Die Antwort wäre auf jeden Fall. Die eigentliche Frage ist, wie ein Unternehmen mit technischen Schulden umgeht. Lassen Sie es zu einem festgelegten Zeitpunkt auflaufen und bearbeiten Sie es oder verwalten Sie eine saubere Codebasis fortlaufend, um die technischen Schulden so schnell wie möglich zu begleichen? Diese Antwort hängt von den individuellen Prioritäten eines Unternehmens ab und davon, ob die entstandenen technischen Schulden finanziell relevant sind.

Kundenspezifische Software ist keine Garantie für die technische Verschuldung, dient aber zwei Mastern.

Ein Unternehmen für kundenspezifische Software erstellt eine Software, die genau auf die jeweilige Aufgabe zugeschnitten ist, liefert sie und wartet sie bei Bedarf. Wirklich kundenspezifische Software benötigt oft keine neuen Funktionen, die sehr oft hinzugefügt werden.

Das in dieser Frage beschriebene Problem besteht darin, dass Produktunternehmen benutzerdefinierte Features in ein sonst generisches Produkt einbauen. Wenn das Produkt vollständig kundenspezifisch wäre, würde es sich nur bewegen, wenn sich die Anforderungen an den einen Kunden ändern. Wenn das Produkt nur generisch wäre, würde es sich nur bewegen, wenn neue Funktionen hinzugefügt werden, um es attraktiver zu machen. Wenn Sie jedoch eine benutzerdefinierte Funktion in einem ansonsten generischen Produkt verwenden, haben Sie zwei Codestücke in engem Kontakt, die sich mit unterschiedlicher Geschwindigkeit bewegen. Wie tektonische Platten, die Erdbeben verursachen, ist die Schnittstelle zwischen diesen Codestücken ein "Hot Spot", der für Probleme reif ist.