Wird die Softwareentwicklung weltweit zu einer Art anarchischem System?

TL;DR

Die goldene Regel lautet: "Wer das Gold hat, macht die Regeln." Das bedeutet jedoch nicht, dass derjenige, der die Regeln aufstellt, unbedingt Recht hat oder in seinem eigenen besten Interesse handelt. Du kannst haben, was du willst, aber es bringt dich vielleicht nicht dorthin, wo du wirklich hin musst.

Kontrolle ist nicht Führung

Ich gründe mein eigenes Unternehmen und fing an, ein kleines Team zusammenzustellen, und es ist interessant zu beobachten, dass ein Entwickler umso mehr vorgibt, bei der Implementierung ein Mitspracherecht zu haben, je qualifizierter er ist. Da die Investition jedoch meine ist, möchte ich wichtige Entscheidungen über die Umsetzung selbst treffen.

Während Ihre Frage vielleicht besser zu The Workplace passt , gibt es sicherlich Projektmanager (hier zum Thema) und Geschäftsinhaber (hier nicht zum Thema), die ähnliche Bedenken haben. Das Problem sind jedoch häufiger Rollendefinitionen und Persönlichkeitsmerkmale als alles andere.

Ohne die Absicht, abwertend zu sein, ist Ihre oben zitierte Aussage ziemlich häufig bei Menschen, die:

• relativ neu in der Geschäfts- oder Technologieführung.
• Ingenieure oder Architekten, eher als Manager oder Führungskräfte. NB: Entgegen der landläufigen Verwendung sind „Manager“ und „Führer“ keine Synonyme.
• Mikromanager oder Technokraten, eher als strategische Führer.
• kontrollierende Persönlichkeiten, die nicht effektiv delegieren können oder wollen.
• Perfektionisten oder Command-and-Control-Typen, denen es schwer fällt, anderen zu vertrauen.

Es ist absolut nichts falsch daran zu wollen, dass ein Produkt oder eine Dienstleistung verkäuflich und zweckdienlich ist, aber in Ihrer Aussage ist die implizite Überzeugung eingebettet, dass man sich nicht darauf verlassen kann, dass andere etwas so umsetzen, wie Sie es selbst tun würden. Anstatt die Ergebnisse zu messen (z. B. die Software funktioniert und ist sie einfach zu warten), konzentrieren Sie sich auf die Implementierung, die normalerweise ein geschäftliches Anti-Pattern ist.

Das Hauptproblem eines „Kontrollfreaks“ in einer wissensbasierten Branche wie der IT besteht darin, dass er kreative und talentierte Menschen vertreibt. Mikromanagement erstickt Innovation und unabhängiges Denken. Die einzigen Leute, die ein auf Angst basierendes Management tolerieren – ein Umfeld, in dem eine Autoritätsperson alles kontrollieren will – sind typischerweise diejenigen, die einen sehr direkten Führungsstil bevorzugen, weil sie keine Selbststarter sind, oder Arbeiter, die selbst ängstliche Menschen sind. Dies führt normalerweise zu einem „Team“, in dem die Leute nur das tun, was ihnen gesagt wird, und nicht mehr. Pragmatisch führt dies oft zu einer langsameren Entwicklung und weniger Innovation, weil der Mikromanager wirklich die ganze Arbeit macht, aber zu dem zusätzlichen Preis, dass er sie delegieren und anschließend verifizieren muss.

Agile Frameworks haben Prinzipien und Werte , die darauf abzielen, viele dieser Probleme zu lösen, indem ineffiziente Command-and-Control-Techniken durch kollaborative Prozesse, iterative Entwicklung, Qualitätskontroll-Feedbackschleifen und selbstorganisierte Teams ersetzt werden, die kreative Lösungen schätzen (anstatt sie zu unterdrücken). vielleicht hast du nicht an dich gedacht. Es gibt definitiv Anwendungsfälle für direktivere Ansätze, aber Ihr ursprünglicher Beitrag gehört nicht wirklich dazu.

Mieten Sie für Fit

Letztendlich können Sie als Projektmanager oder Geschäftsinhaber für die kulturelle Eignung einstellen. Wenn Sie es vorziehen, Leute einzustellen, die keine Agilisten sind, oder die einen direkteren Managementstil bevorzugen, ist das in Ordnung. Sie besitzen jedoch das Vorstellungsgespräch und den Auswahlprozess, und Sie besitzen auch weitgehend die Ergebnisse der Auswahl guter oder schlechter Mitarbeiter .

Mit anderen Worten, wenn Sie Mitarbeiter hauptsächlich aufgrund ihrer Bereitschaft einstellen, eng geführt zu werden, können Sie sich nicht darüber beschweren, dass es sich nicht um Menschen handelt, die gerne unabhängig arbeiten. Umgekehrt, wenn Sie Leute einstellen, die Selbststarter sind, sollten Sie sich nicht darüber beschweren, dass sie ihre eigene Perspektive auf ein Problem einbringen.

Keines der beiden Extreme ist gut für die Entwicklung, das Geschäft oder den Teamaufbau. Ihre Aufgabe ist es, die beste Balance zwischen Zusammenarbeit und Unabhängigkeit für Ihre Ziele zu finden und diese dann in Ihrem Einstellungsprozess bewusst auszuwählen. Sie werden Fehler machen, weil jeder Fehler macht, aber wenn Sie nicht die gewünschten Talente anziehen oder ständig schlechte Einstellungen vornehmen, müssen Sie Ihre Unternehmenskultur und Ihren Führungsstil überprüfen und anpassen, anstatt alle anderen zu beschuldigen.

Die agile Bewegung entstand dadurch, dass viele, viele Softwareprojekte scheiterten, ihre Termine nicht einhielten oder die Kosten explodierten. Alle Parteien (Kunden, Entwickler und sogar einige Manager) waren unzufrieden mit der Art und Weise, wie Projekte durchgeführt wurden (siehe: agilemanifesto.org/history.html ). Die Zusammenarbeit im Team macht Software besser , Implementierungsentscheidungen sollten von denen getroffen werden, die es tun (wie auch die Aufwandsschätzung). Vielleicht fallen Ihren Kollegen andere Dinge ein, die Sie vergessen könnten? 8 Augen können mehr sehen als 2, es ist von Vorteil, Implementierungsdetails zu besprechen - ich glaube nicht, dass Sie dumme "Code Monkeys" wollen?

Als Manager (oder Product Owner oder wie auch immer Sie es nennen wollen – ich weiß, das ist nicht ganz dasselbe) besteht die Aufgabe darin, herauszufinden, was die Nutzer Ihrer Software brauchen, und dem Team den Kundennutzen zu erklären. User Stories zum Beispiel dürfen keine Implementierungsdetails enthalten und das ist wichtig, da sie die INVEST - Kriterien erfüllen sollten!

In Scrum gibt es Meetings, bei denen Sie, nehmen wir an, Sie sind der PO, Ihre Meinung zu Implementierungsdetails einbringen können (an dieser Stelle könnten einige anderer Meinung sein), z. B. Task Breakdown. Für mich ist der Schlüsselfaktor, dass Sie Ihrem Team genug vertrauen, um es seine eigenen Entscheidungen treffen zu lassen und keine Lösungen vorzuschreiben.

Sie können mit einem Sprint Zero beginnen , bei dem einige architektonische Entscheidungen getroffen werden, die Sie mit Ihren Teamkollegen besprechen können. Während Sprint Zero nicht von allen Scrum-Organisationen empfohlen wird ( Scrum-Mythen: Es ist in Ordnung, einen Sprint 0, einen Design-Sprint, einen Hardening-Sprint zu haben ... )

Wenn das Projekt wächst (was das Ziel wäre, denke ich), werden Sie nicht in der Lage sein, alle Details zu kennen, also MÜSSEN Sie das Team seine eigenen Entscheidungen treffen lassen.

Als Unternehmer ist mir die technische Umsetzung egal, es sei denn, es belastet meinen Geldbeutel. Ich behalte mir das Recht vor, dem Team zu sagen: "Nein. Dafür bezahle ich nicht. Was sind die anderen Optionen?", aber es ist mir ehrlich gesagt egal, wie sie die Arbeit erledigen. Mir ist nur wichtig, dass sie es rechtzeitig und kostengünstig tun. Ich werde Leute einstellen, um einen Job zu machen, und ihnen vertrauen, dass sie es tun.

Wenn ich Technikern nicht zutraue, technische Entscheidungen zu treffen, warum habe ich sie dann überhaupt eingestellt? Es ist nicht meine Aufgabe, diese Entscheidungen zu treffen. Es ist meine Aufgabe, eine Vision, Ziele und Strategien festzulegen, um sie zu erreichen. Es ist ihre Aufgabe zu implementieren, lassen Sie sie implementieren. Sie sind die Experten, nicht ich. Ich verstehe, ungeachtet der Tatsache, dass ich auch Softwareentwickler bin und könnteihren Job machen, dass ich die Details nicht so gut verstehe wie sie und ihnen wahrscheinlich im Weg stehen werden. Wenn ich ihnen im Weg stehe, werde ich die Dinge verlangsamen, das Team demoralisieren und meine besten Entwickler verlieren. Werden sie Dinge anders machen als ich und einige Fehler machen? Sicher, aber ich würde mehr machen, weil ich mit dem Problemraum nicht so vertraut bin wie sie. Sich zu sehr in die Implementierung einzumischen, tut mir, meinem Team und meinem Unternehmen keinen Gefallen.

Das heißt, Sie sind der Mann, der den Gehaltsscheck unterschreibt. Es ist Ihr Unternehmen und es ist Ihr Recht zu tun, was Sie wollen. Wenn Sie jedoch erfolgreich sein wollen, würde ich das Team tun lassen, wofür Sie es bezahlen.

Agile (und viele vorgeschlagene Methoden) hat seine Wurzeln im Lean-Denken , und wenn wir anfangen, rückwärts zu verfolgen, finden Sie eine solche Relevanz in TQM (einschließlich Demings Lehre) und TPS (was Womack und Jones studiert haben).

Ich kann Ihnen keine einfache Antwort darauf geben, was Sie tun können, aber mein persönlicher Favorit, um ein besserer Manager zu werden, ist die Lektüre von Workplace Management von Toyotas Fertigungsgenie Taiichi Ohno. Seine Lehren legen großen Wert darauf, dass Führungskräfte in der Gemba Kaizen (kontinuierliche Verbesserung) praktizieren. Dem Buch liegt ein Artikel von Jeffrey Liker bei, der in gewisser Weise die Pflichten eines Managers zusammenfasst: 1) Lernen Sie an der Gemba, 2) Bleiben Sie Ihren Schülern voraus, 3) Halten Sie ein hohes Niveau, 4) Lieben Sie Ihre Schüler, und 5) leidenschaftlich und besessen von Kaizen sein.

Vor diesem Hintergrund wird Ihre Anwesenheit als Lehrer (oder Guru oder dienender Leiter, wie manche es nennen würden) in der Werkstatt, um gemeinsam mit den Menschen zu lernen, wie z eine positivere Kultur.