Softwareentwicklungskapazität im Abo?
Ein interessantes Geschäftsmodell für Freiberufler
Beim Streaming-Dienst und dem SIM-Vertrag ist es selbstverständlich: das Abo. Damit ist man total flexibel, allemal wenn es ein Monatsabo ist. Für “größere” Dienstleistungen ist ein Abo hingegen bisher ungewöhnlich. Muss das so sein? Oder hat man dort bisher nur noch nicht die Chance gesehen, die darin steckt? Neulich gab es rund um Design-Dienstleistungen eine Diskussion darüber auf LinkedIn. Die hat mich zum Grübeln gebracht.
Ja, wie wäre es, wenn Softwareentwicklung im Abo zu haben wäre? Was würde ein Abonnent erwarten? Unter welchen Bedingungen könnte sich ein Freiberufler (oder ein Unternehmen) darauf einlassen? Ich will mal laut darüber nachdenken…
Der niedrige Preis ist heiß
Wenn ein Abo keinen Unterschied im Preis machen würde, wäre es wenig attraktiv für Kunden. Bisher sind die Optionen:
Der Angestellte
Unternehmen, allemal Softwareentwicklungsunternehmen, denken zuerst daran, einen Entwickler anzustellen, wenn sie Entwicklungskapazität brauchen. Wenn der Bruttolohn 5700€ ist, kostet sie das pro Monat gute 6800€.
Die Flexibilität ist bei Angestellten gering. Die Einstellung geht schnell — die Kündigung kann schwierig werden. Man ist sich also besser sicher, die Kapazität wirklich zu brauchen. Dann jedoch bekommt man die volle Kontrolle und einen “guten Preis”.
Der Contractor
Wenn ein Unternehmen mehr Flexibilität will, dann sucht es sich stattdessen einen Freiberufler oder ein Dienstleistungsunternehmen. Mit denen muss zwar auch ein Vertrag abgeschlossen werden, doch der lässt sich viel freier gestalten.
Wenn ich 95€ als Stundensatz annehme, kommen allerdings gute 15.000€ pro Monat zusammen. Das ist eine Menge Holz.😳 Aber vielleicht geht es auch für 12.000€ oder 10.000€, wenn man eine lange Vertragslaufzeit vereinbart? (Doch dann könnte auch wieder ein Angestellter passen. Hm…🧐)
Die Flexibilität kostet in jedem Fall einiges Geld. Der Contractor ist 50% bis 100% teurer als der Angestellte.
Das Entwickler-Abo — The new kid on the block
Was kann das Abo an den Tisch bringen, um neben den etablierten als ernsthafte Option zu gelten? Ich denke, es muss eine Quadratur des Kreises versuchen:
Das Abo muss billiger sein als der Angestellte
Das Abo muss flexibler sein als der Contractor
Das Abo muss dieselbe Ergebnisqualität liefern wie Angestellter und Contractor
Wieviel billiger reicht aus? Wenn der Angestellte um die 7000€ pro Monat kostet, dann sollte das Abo die Hälfte oder weniger kosten, z.B. 2500€ bis 3500€ für einen “vollen” Entwickler.
Wenn der Abo-Entwickler versprechen kann “Ich stehe den ganzen Monat für 2500€ zur Verfügung!”, dann lohnt sich das Aufhorchen, finde ich.
Die Flexibilität bringt’s
Das Schöne am Abo bei Netflix & Co ist ja aber nicht nur der Preis, sondern die Einfachheit, mit der es abgeschlossen und vor allem wieder gekündigt werden kann. Da gibt es kein Drama. Keine Erklärung nötig. Einfach den Cancel-Button klicken. Fertig.
Diese Einfachheit muss ein Entwickler-Abo auch bieten, um seinen Namen zu verdienen: easy to enter, easy to leave. Auf diese Weise kommt der Abonnent zum Atmen: Er schließt ein Abo ab, wenn er Bedarf hat. Er kündigt das Abo, wenn er keinen Bedarf mehr hat. Das kann er von Monat zu Monat entscheiden.
Und da das Abo so günstig ist im Vergleich zu den Alternativen, kann er sich auch mal bei der Beurteilung seiner Lage vertun. Wenn er am 8. eines Monats feststellt, dass das Abo überflüssig ist, kündigt er und bezahlt für 22 Tage mehr als nötig. Wenn er am 25. eines Monats feststellt, dass es eigentlich nicht mehr nötig ist, sind es nur 5 Tage zu viel. Im Mittel ist der halbe Abo-Preis im letzten Monat also verschwendet — doch was macht das bei diesem geringen Preis? Weit mehr wird bei kaum kündbaren Angestellten versenkt oder bei Contractors, deren Vertrag zu weit gestreckt ist.
Mit einem Abo kann viel bedarfsgerechter Entwicklungskapazität gebucht werden.
Das ist der Hit, finde ich.
Mehr Flexibilität zu einem geringeren Preis! Wer würde das nicht wollen?
Wo ist der Haken?
Work-in-Process Begrenzung
Es ist offensichtlich, dass ein Entwickler nicht von einem Abo leben kann. Der Freelancer-Stundensatz ist nicht umsonst so hoch, dass mindestens 10.000€ pro Monat rumkommen bei voller Auslastung mit einem Projekt. Freelancer müssen für sich vorsorgen, für Flauten und fürs Alter. Das hat seinen Preis.
Nicht anders geht es dem Abo-Freelancer. Auch der braucht mehr als 2500€ pro Monat.
Nehmen wir an, er möchte 7500€ pro Monat umsetzen. Dann muss er stets 3 Abos à 2500€ laufen haben.
Aber wie geht das, wenn er doch je Abonnent den ganzen Monat zur Verfügung steht? Der Entwickler kann sich nicht teilen.
Doch! Das geht unter einer Voraussetzung:
Je Abo kann stets nur 1 Aufgabe dem Entwickler zugewiesen werden.
Aus Sicht des Abonnenten arbeitet die Abo-Ressource mit Work-in-Process von 1 (WIP=1).
Der Abo-Entwickler gerät in kein Multi-Tasking. Er arbeitet nach der Maxime finish first. Eine angefangene Aufgabe wird erst fertig gemacht. Dann kann eine nächste Aufgabe gestellt werden. Dafür braucht es natürlich eine vernünftige Definition of Done (DoD).
Solche Arbeitsweise sind Abonnenten wahrscheinlich nicht gewohnt. Sie wollen ja für den hohen Preis, den sie für Angestellte oder Contractors zahlen, die volle Kontrolle haben. Sie sollen jederzeit nach ihrer Pfeife tanzen. Alles muss ASAP begonnen werden.
Doch diese Arbeitsweise führt schnurstracks in Unzuverlässigkeit und Verspätungen und Konflikte.
Dem schiebt der Abo-Entwickler einen Riegel durch seine Bedingung vor. Mit ihm gibt es kein Multi-Tasking mit all den negativen Effekten. Er tanzt nicht jederzeit nach der Pfeife des Abonnenten. Damit wirkt seine Arbeit beruhigend auf das Projekt. Ein Abo hat sozusagen einen pädagogischen Effekt — wenn man es so sehen will. Aber dafür braucht es beim Abonnenten schon einige Reife.
Die Vorteile bei Kosten und Flexibilität gibt es eben nur für erwachsene, bewusste Kunden.
Arbeitsweise des Abo-Entwicklers
Die Außensicht des Abonnenten ist, dass der Abo-Entwickler mit WIP=1 arbeitet.
Die Innensicht des Entwicklers hingegen ist WIP=Abo-Anzahl. Denn jedes Abo kann ja eine aktive Aufgabe haben, an der der Entwickler verspricht zu arbeiten.
Wenn der Abo-Anbieter 3 Abos à 2500€ braucht, um seinen Wunschumsatz einzufahren, dann muss er zu jeder Zeit bereit sein, an 3 Aufgaben zu arbeiten. In der Innensicht ist Multi-Tasking also unvermeidlich.
Wie kann das gehen? Entsteht dann nicht doch wieder Unzuverlässigkeit usw.?
Nein. Nicht, wenn eine Prämisse erfüllt ist:
Jede Aufgabe hat ganz natürlich eine Flow Efficiency (FE) von ca. 33%.
FE ist das Verhältnis von Touch Time (TT) zu Cycle Time (CT).
TT ist die Zeit, die aktiv an einer Aufgabe gearbeitet wird. Das “Werkstück” erfährt unmittelbare Aufmerksamkeit.
CT ist die Zeit von Beginn der Arbeit an einer Aufgabe bis zur Ablieferung des Ergebnisses (Done).
Ein Beispiel: Wenn ich gestern eine Aufgabe um 9:00 begonnen und heute um 17:00 das Ergebnis abgeliefert habe, dann ist die CT 16 Arbeitsstunden. Aber wie viel Zeit habe ich in diesem Zeitraum wirklich an der Aufgabe verbracht? Ich habe vielleicht wirklich um 9:00 begonnen, dann aber nur 2h daran gearbeitet. Anschließend wurde ich zu einer Besprechung gerufen. Erst nach dem Mittagessen habe ich mich wieder an die Aufgabe gesetzt von 13:00 bis 15:00 (2h). Gerne hätte ich weitergemacht, doch mir fehlten Testdaten. Die habe ich erst am nächsten Morgen um 10:00 bekommen und ich konnte bis 12:00 weitermachen (2h). Leider habe ich dann Feedback gebraucht. Das kam erst um 14:00. Von 14:00 bis 17:00 (3h) war es mir damit möglich, die Aufgabe fertigzustellen.
Die TT war insgesamt 2h+2h+2h+3h=9h. Daraus folgt eine FE von 9h/16h=56%.
In der CT steckt also nicht nur TT, wie man es gern hätte, sondern viel, viel Wait Time (WT). In diesem Fall 7h. Diese WT entsteht oft überraschend und ist ungewollt; dennoch ist sie kaum zu vermeiden.
Ich halte eine FE von >50% für zu hoch für die Softwareentwicklung, wenn man genau hinschaut. Eher liegt sie bei 20% bis 40%, vermute ich. Warum? Weil es viele Abhängigkeiten gibt:
Immer wieder läuft der Entwickler in Unklarheiten hinein und muss Feedback einholen bzw. “nachschärfen”. Das geht nie auf Zuruf, sondern muss mit dem Auftraggeber (oder Mitarbeitern) koordiniert werden.
Immer wieder braucht der Entwickler auf Informationen/Ergebnisse von anderen angewiesen (Mitarbeiter oder Endkunde). Die liefern oft nicht pünktlich und können auch nicht auf Zuruf “angezapft werden”.
Der Abo-Entwickler tut in diesen Situationen aus eigenem Interesse das einzig Richtige: Er stoppt die Bearbeitung der Aufgabe. Ein Angestellter oder Contractor hingegen will nicht untätig erscheinen und nimmt daher eine weitere und noch eine neue Aufgabe in Angriff; so entsteht Multi-Tasking im Projekt mit allen negativen Effekten.
Nicht so beim Abo-Entwickler. Er ist zwar auch nicht untätig — doch seine Aufmerksamkeit wechselt nun zu einem anderen Abo. Dort ist er wieder fokussiert auf die eine anliegende Aufgabe.
Das Multi-Tasking beim Abo-Entwickler ist also keine Verlegenheit, sondern eine Kompensation für das Unvermeidliche. Und das auch nur in sehr begrenztem, kontrolliertem Umfang.
Im Mittel widmet der Abo-Entwickler also Kapazität/Abo-Anzahl Stunden Aufmerksamkeit jeder Aufgabe, z.B. 8h/3=2,7h pro Tag oder 40h/3=13,3h pro Woche. Das hört sich wenig an, wo doch das Versprechen scheinbar lautet, dass der Abo-Entwickler die ganze Zeit zur Verfügung steht.
Doch das stimmt nicht. Dieses Versprechen gibt der Abo-Entwickler nicht ab. Er verkauft eben nicht seine Zeit wie der Angestellte oder Contractor.
Der Abo-Entwickler verkauft ungeteilte Aufmerksamkeit auf 1 Aufgabe, solange das möglich ist.
Nicht mehr, nicht weniger. Er ist also resultatsorientiert, nicht zeitorientiert.
Wie gesagt, das beruht auf der Prämisse, dass die Aufgaben der Art sind, dass im Mittel knapp alle 3 Stunden ganz natürlich Wartezeit von ca. 5 Stunden entsteht.1
Das ist eine Hypothese. Die müsste die Praxis überprüfen.
Der ideale Abonnent
Nicht jedes Unternehmen, das meint, Softwareentwicklungskapazität zu brauchen, ist ein geeigneter Kunde für den Abo-Entwickler. Der Abo-Entwickler muss Ansprüche an die Gesamtsituation beim Auftraggeber haben, um sein Versprechen erfüllen zu können.
Die Aufgaben müssen der obigen Prämisse genügen. Das ist die mindeste Voraussetzung.
Der Abo-Entwickler darf darüber hinaus nicht zur co-located Arbeit gezwungen werden. Er braucht den Freiraum, sich jederzeit anderen Kunden widmen zu können.
Der Abo-Entwickler kann nur sehr begrenzt synchron mit einem Kunden und dortigen Kollegen arbeiten. Synchrone Arbeit behindert ihn in der Freiheit, seine Aufmerksamkeit anderen Aufgaben zu widmen.
Zwischen Abo-Entwickler und Abonnent braucht es einen Umgang auf Augenhöhe. Beide müssen sich als Unabhängige/Selbstständige verstehen und eine Kooperation wollen, die den anderen nicht ausnutzt. Dazu gehört:
Der Abo-Entwickler darf sich nicht überbuchen und z.B. 4 Abos laufen haben, wenn die FE nur 33% ist (statt 25%).
Der Abonnent darf nicht versuchen, ein Multi-Tasking in seinem Sinn künstlich einzuführen, indem er eine Aufgabe nach belieben beauftragt und vor Fertigstellung abbricht, um wieder eine andere reinzuschieben.
Wo findet der Abo-Entwickler solche Bedingungen? Ich sehe da vor allem zwei Gruppen:
Start-ups in einer frühen Phase, in der es um Proof-of-Concept, Prototyp oder höchstens MVP geht. Hier kann der Abo-Entwickler allein oder vielleicht mit einem weiteren in hoher Autonomität etwas beitragen — und gleichzeitig dem Start-up nicht auf der Tasche liegen oder es inflexibilisieren.2
Unternehmen mit gelegentlichem Bedarf: Unternehmen, die nicht dauernd Bedarf haben und sich deshalb keine angestellten Entwickler leisten können und den Overhead der Suche von Contractors vermeiden wollen, können einen Abo-Entwickler on retainer halten. Sie lassen das Abo laufen, auch wenn es mal ein paar Wochen nichts zu tun gibt. Entsteht wieder Bedarf, steht der Abo-Entwickler ja “Gewehr bei Fuß” und legt los. Das kann auch für softwareferne Unternehmen, z.B. größere Handwerksbetriebe interessant sein, die vielleicht eher no-code Lösungen brauchen oder gelegentlich Ergänzungen für ihren Internet-Auftritt.3
Fazit
Ich finde den Abo-Entwickler eine sehr spannende Idee. Das laute Nachdenken hat meine Überzeugung gestärkt, dass es hier “etwas zu holen gibt”. Allemal in Zeit der KI braucht es frische Ideen, sich als Entwickler attraktiv zu halten.
Wer hat den Mut, das Geschäftsmodell mal auszuprobieren? Ich kenne bisher nur einen: Rebar aus Nürnberg.👍
Alle können dabei nur gewinnen, denke ich. Das garantierte Ergebnis ist Erkenntnis. Doch ich glaube, dass mehr winkt:
Entwickler: Profilierung,
Entwickler: verlässlicher Umsatz,
Abonnent: Kosteneinsparung,
Abonnent: Flexibilität,
Entwickler und Abonnent: Laufruhe, also Entspannung, und
Abonnent: Verlässlichkeit
Ich wünsche also Rebar viel Erfolg! Und jedem anderen auch, der es wagen will. Über Feedback würde ich mich natürlich freuen.
Primär sind die Wartezeiten fremdbestimmt, d.h. durch Unklarheit oder Abhängigkeit von anderen getrieben. Ich denke aber, dass auch selbstbestimmt ein Aufgabenwechsel stattfinden kann. Das kann sein, wenn ein gutes Zwischenergebnis erzielt wurde. Oder es kann durch schwindende Aufmerksamkeit angezeigt sein. Dann kann ein Wechsel zu einer anderen Aufgabe erfrischen.
Angestellte und auch Contractors sind Optimierung für Effizienz. Der Abo-Entwickler steht für Flexibilität. Ab einem gewissen Projektstand mag Effizienz wichtig sein. Vorher jedoch sollte man auf Flexibilität achten. Der Abo-Entwickler kann vor vorzeitiger Optimierung schützen.
Es ließe sich auch denken, dass sich mehrere Firmen mit geringem Bedarf ein Abo teilen, eine fractional subscription. Dann hat mal das eine Unternehmen eine Aufgabe im Rahmen des Abo, mal ein anderes. Wer gerade dran ist, müssen die Abo-Partner unter sich ausmachen. Für jeden ist die Möglichkeit, auf einen Entwickler zuzugreifen aber deutlich günstiger als bei einem Solo-Abo.