Ihr Ninja 10X Rockstar-Entwickler zwangsernährt Speck zu Ihrem Lean-Startup

Outsourcing und Beschränkung auf Kernkompetenzen sind unerlässlich – insbesondere in der Softwareentwicklung

Dieser Beitrag richtet sich wirklich an nicht-technische CEOs und CTOs, die Entscheidungen über das Design von Softwarearchitekturen delegieren. Ich liebe euch alle Ninja 10X Rockstar-Entwickler und ich erwarte (oder brauche oder will) nicht, dass ihr euch ändert.

Grundlagen zu Lean-Startups und Lean-Unternehmen konzentrieren sich darauf, wie Sie i ld erstellen und Produkte schnell bewerten können. Obwohl ich die allgemeinen Prinzipien der Lean Startup-Methodik für nützlich halte, vermissen sie meiner Meinung nach eine Beobachtung, die für den Erfolg eines Lean Startups entscheidend ist, und eine, die viele Lean Startup vergessen: alles auslagern, was nicht zum Kern gehört das Geschäft .

So wie Hillary Clinton glaubt, dass der individuelle Erfolg positive Beiträge von Einzelpersonen und Organisationen außerhalb der Kernfamilie erfordert, hängt auch der Erfolg eines schlanken Unternehmens vom Outsourcing ab. Instagram hatte nur 14 Mitarbeiter, als es von Facebook übernommen wurde: Wie viele von ihnen kümmerten sich um Personal, Buchhaltung, Serveradministration, Netzwerkadministration, rechtliche Formalitäten und andere Notwendigkeiten, um erfolgreich zu sein?

Die schlanksten Unternehmen werden so wenig Kernkompetenzen wie möglich identifizieren und alles andere auslagern. Die anfänglichen Kernkompetenzen von Instagram waren (a) Softwareentwicklung von Bildfiltern, (b) Entwicklung von iPhone-Foto-Sharing-Anwendungen und (c) Förderung der Akzeptanz. 14 Mitarbeiter können damit umgehen. Wenn Sie die anderen oben aufgeführten Dinge einwerfen, benötigen sie mindestens das Doppelte des Personals, sodass sie beispielsweise an Amazon Web Services (Server + Netzwerkadministration) ausgelagert werden.

Es geht aber nicht nur darum, organisatorische Funktionen auszulagern – es gibt auch schlanke Wege zur Entwicklung von Software und fette Wege zur Entwicklung von Software. Eine kürzlich durchgeführte Analyse des Scheiterns eines „schlanken Startups“ kam zu dem Schluss, dass sie „fett“ werden mussten, um überhaupt einem wirklich minimal lebensfähigen Produkt für den Markt nahe zu kommen. Nach dem Lesen der Analyse habe ich den Verdacht, dass wahrscheinlich eine Reihe von Entscheidungen für die Softwareentwicklung getroffen wurden, die zu einer Schwellung des Entwicklungszeitplans führten. Nach meiner Erfahrung möchten die meisten Entwickler (a) Frameworks erstellen, (b) mit neuen und heißen Bibliotheken / Toolkits / Sprachen experimentieren und (c) Sie möchten nicht viel Zeit damit verbringen, nach etablierten Bibliotheken / Toolkits / Sprachen zu suchen und diese zu testen. . Dies bedeutet, dass Sie, wenn Sie die MVP-Spezifikation Ihrem Hotshot Ninja 10X Rockstar-Entwickler übergeben, wahrscheinlich auf eine ineffiziente und fette Entwicklung zusteuern.

Ich war dieser Entwickler, und ich habe diese Entwickler verwaltet, und jetzt habe ich eine Regel: 85% der gesamten Entwicklerzeit müssen für geschäftsspezifische Logik aufgewendet werden . Dies bedeutet, dass wir kein eigenes Warteschlangensystem, Geschäftsprozessmanagementsystem, Kommunikationsprotokolle oder HTML-Parser schreiben, es sei denn, dies ist eine unserer wenigen Kernkompetenzen (und damit wahrscheinlich unser Produkt).

Oh, die Online-Dokumentation für AngularJS ist etwas dünn und Sie möchten nicht auf das Eintreffen des O’Reilly-Buches warten, damit Sie es erneut implementieren, da Sie sich ziemlich sicher sind, dass dies nicht der Fall ist trotzdem zeit sparen? Und Sie haben gerade über diese großartige neue Bibliothek gelesen, die für Go geschrieben wurde. Sie werden also die Sprache auf eine Sprache umstellen, die Sie nicht sehr gut kennen, und es wird uns in Zukunft schwerer machen, Entwickler einzustellen? Und Sie werden mindestens 3 Tage brauchen, um die verschiedenen Caching-Server / Bibliotheken zu evaluieren, die wir möglicherweise verwenden, und Sie kennen Redis bereits. Auch wenn Sie sich ziemlich sicher sind, dass Redis auf dem Weg nach draußen ist, sind das 3 ganze Tage! Wenn Sie niemanden haben, der über die langfristigen geschäftlichen Auswirkungen bestimmter Entwicklungsentscheidungen nachdenkt, die Ihr Entwicklungsteam trifft, trifft Ihr Entwicklungsteam wahrscheinlich einige wirklich fette Entscheidungen, selbst wenn Sie versuchen, anderswo schlank zu bleiben.

Ein Kennzeichen der schlanken Softwareentwicklung ist die starke Abhängigkeit von bestimmten Bibliotheken und Tools, die von anderen Personen / Organisationen entwickelt werden. Ich sage deutlich, weil es vielen verschiedenen Bibliotheken und Tools, die im Grunde das Gleiche tun, wenig nützt. Es ist nicht schlank, MySQL und Postgresql auszuführen. Es ist nicht schlank, Cassandra und Mongo oder Memcached und Redis zu betreiben. Es ist nicht schlank, Rails und Django mit etwas Node.JS an der Seite zu betreiben. Nehmen Sie sich die Zeit, um die richtige Bewertung im Voraus vorzunehmen (auch wenn Sie – himmlisch! – innerhalb von 24 Stunden nach Ihrer Idee keine funktionierende Anwendung haben), damit Sie nicht so lange zwischen Elementen in Ihrem Stapel wechseln müssen wie möglich. (Und selbst wenn Sie wechseln müssen, ist zumindest ein Wechsel von All-MySQL zu All-Postgresql besser als ein Wechsel von einer Zusammenführung von Datenbanken.)

Wenn Sie also keine Softwareentwicklung durchführen, wie können Sie feststellen, ob Ihr Entwicklungsteam die 85% -Regel einhält? Eine ziemlich einfache Möglichkeit – wenn Sie einer agilen Entwicklungsmethode folgen – besteht darin, dass regelmäßig unternehmensspezifische Funktionen implementiert werden. Sie sollten sehr skeptisch und besorgt sein, wenn Sie „Meta-Features“ sehen – eine Art Gerüst oder Rahmen, auf dem Ihr Produkt aufgebaut / eingefügt / angepasst werden kann. Wenn Sie Instagram erstellen, sehen Sie besser Bildfilter und Fotofreigabe, nicht Dateitransportbibliotheken und GUI-Frameworks. Ich habe gesehen, wie ein 4-köpfiges Entwicklungsteam (nicht unter mir) mehr als 24 Monate damit verbracht hat, eine Regelengine zu erstellen, wenn es wirklich erforderlich war, (a) eine vorhandene Regelengine zu verwenden oder (b) die Regeln seitdem in Code zu modularisieren Das hätte in weniger als einem Jahr geschehen können und hätte das gleiche Ergebnis erzielt.

Wenn Sie wirklich schlank sein möchten, müssen Sie die Outsourcing-Anforderung auf Ihre Softwareentwicklungspraktiken anwenden.