Ich bin Softwareentwickler und habe vor einigen Monaten mit der Arbeit an einem neuen Projekt begonnen. Im Gegensatz zu allen anderen Projekten, an denen ich gearbeitet habe, gibt es in meinem aktuellen Team jedoch einen „Software-Architekten“, der jedes Stück der Architektur der von uns erstellten Anwendung definieren kann und ständig selbst in einigen Implementierungsdetails auf sehr niedriger Ebene herumspielt .
Ich arbeite seit einiger Zeit (fast 6 Jahre) in derselben Firma und in allen Projekten, an denen ich gearbeitet habe, hatte ich kreative Freiheit - dh ich kann sowohl das Design als auch die Umsetzung der von mir übernommenen Aufgaben übernehmen und nur danach macht jemand eine Überprüfung und ich wende (schließlich) einige (kleine) Änderungen an. Nun, bevor ich mit der Umsetzung beginne, muss ich zuerst meinen Umsetzungsplan mit dem Architekten besprechen, der ihn nach seinen Wünschen ändert. Ich bin ziemlich unzufrieden mit dieser neuen Situation, in der ich wie ein Bauarbeiter behandelt werde, der nichts tun kann, ohne vorher angewiesen zu werden, wie es zu tun ist, und ich mit diesem Typen ( der der technische Leiter des Projekts und mehr oder weniger mein Chef ist).
Da ich nicht so viel Erfahrung habe, habe ich mich gefragt - ist das ein normaler Workflow? Ist es weit verbreitet? Ich spüre eine gewisse Spannung zwischen mir und diesem Typen (im Grunde bin ich es ein bisschen leid, dass er mir sagt, was ich tun soll) – wie gehe ich damit um?
Beginnen wir mit den offensichtlichen Problemen am Arbeitsplatz, die nichts mit Softwareentwicklung zu tun haben. Sie haben angegeben, dass er Ihr Chef ist. Er hat jedes Recht zu bestimmen, wie er Design verwalten will. Es ist nicht Ihr Anruf, es sei denn, er entscheidet, dass es Ihr Anruf ist. Sich darüber aufzuregen ist kontraproduktiv. Es ist riskant für Ihre Karriere an diesem bestimmten Ort, sich darüber zu ärgern, dass er etwas tut, das zu seinen normalen Aufgaben gehört.
Es gibt Projekte, bei denen diese Art von übergreifendem Design üblich ist, insbesondere wenn das Projekt Wasserfallmethoden anstelle von Agile verwendet. Dies ist üblich, wenn die Software einen starken regulatorischen oder rechtlichen Aspekt hat oder wenn die Kosten für Fehler sehr hoch sind, wie z. B. im Weltraumprogramm oder bei medizinischen Geräten. In diesen Welten ist es sehr wichtig, dass das Design im Voraus erstellt und genehmigt wird und dass ohne Genehmigung nicht vom Design abgewichen wird.
Ob Ihr Projekt in eine dieser Kategorien fällt, ist jedoch nahezu irrelevant. Die verantwortliche Person möchte diese Technik anwenden, und Sie haben die Pflicht, ihren Anweisungen zu folgen und sich ihr nicht zu widersetzen. Dafür werden Sie bezahlt.
Was Sie in dieser Situation tun können, ist, das zu tun, worum Sie gebeten werden. Sie können professionelle Diskussionen über alternative Methoden führen, aber gehen Sie niemals hinter seinen Rücken und unternehmen Sie Dinge gegen die Art und Weise, wie er das System entworfen hat, selbst wenn Sie mit seinem Design nicht einverstanden sind. Es gibt Überlegungen, die Ihnen möglicherweise nicht bewusst sind, und dies zu tun, ist Ungehorsam und ein Kündigungsgrund.
Wenn Sie professionell über eine alternative Vorgehensweise sprechen und er sich gegen Ihren Vorschlag entscheidet, dann nehmen Sie es professionell und streiten Sie nicht weiter. Die Entscheidung in diesem Projekt liegt bei ihm und er ist derjenige, der den Preis zahlen muss, wenn er sich geirrt hat. Auf keinen Fall sollten Sie sich streiten. Es ist durchaus möglich, herzliche Fachgespräche über technische Alternativen zu führen. Dies ist eine Fähigkeit, die Sie sowieso haben müssen, um erfolgreich zu sein, also haben Sie die Möglichkeit, sie zu üben. Es ist am besten, Alternativen zu Beginn zu diskutieren, wenn die Dinge zum ersten Mal angesprochen werden, nicht später, wenn andere Teile des Projekts davon abhängen, dass Dinge auf eine bestimmte Weise erledigt werden.
Je mehr Sie seine Entscheidungen unterstützen, desto wahrscheinlicher wird er Ihnen zuhören, wenn es entscheidend ist. Streiten Sie nicht über Kleinigkeiten.
Sie haben offenbar schon lange in diesem Unternehmen gearbeitet, also arbeiten Sie an diesem Projekt und suchen Sie nach einem Projekt, das von jemand anderem geleitet wird, für das Sie sich freiwillig engagieren können. Oder suchen Sie sich einen neuen Job, wenn Sie mit einer absolut vernünftigen Managementanforderung nicht fertig werden. Aber ruinieren Sie nicht Ihren Ruf in diesem Unternehmen, indem Sie als wütende Person bekannt werden, die kein Teamplayer ist. Halten Sie es durch und wechseln Sie zu einem anderen Projekt. Nutzen Sie die Gelegenheit, Dinge über Architektur zu lernen, die er Ihnen beibringen kann, und Dinge wie den Umgang mit Untergebenen, die manchmal am besten gelernt werden, wenn Sie für jemanden arbeiten, dessen Stil nicht Ihr bevorzugter ist.
In Ihrer Karriere müssen Sie mit vielen verschiedenen Arten von Menschen mit vielen unterschiedlichen Führungsstilen zusammenarbeiten. Sie werden mit Leuten zusammenarbeiten, die Sie persönlich nicht mögen. Sie müssen lernen, mit verschiedenen Stilen und Persönlichkeitstypen umzugehen und Ihre Ideen effektiv zu präsentieren, wenn Sie keine freie Hand haben, um das zu tun, was Sie wollen. Dies ist daher eine hervorragende Gelegenheit für Sie, Ihre Soft Skills zu erweitern.
Ich schätze, es hängt davon ab, wie niedrig dieser Typ Sie mikromanagt, aber ja, es ist nicht ungewöhnlich, dass ein leitender Entwickler genau vorschreibt, wie ein bestimmter Prozess zum Laufen gebracht werden soll. Manchmal – zugegeben, im Allgemeinen, wenn eine Person mit sehr jungen Entwicklern arbeitet – werden Sie jemanden sehen, der so weit geht, die Klassen zu benennen und Funktionssignaturen zu definieren. Auf der anderen Seite gibt es auch sehr oft einen großen Spielraum, um vorgeben zu können, wie Sie ein bestimmtes Problem lösen, aber ich werde sagen, dass die meisten Orte einen BA oder einen Architekten haben, der eingreift und zumindest einige definiertdes Designs (idealerweise durch Konferenzen mit Stakeholdern, was Sie als Programmierer wahrscheinlich sowieso nicht tun möchten, seien Sie also dankbar für diese Leute), Spezifikationen und Anforderungen, bevor Sie sich den Rest ausdenken.
Es kann sein, dass das Projekt, an dem Sie arbeiten, Compliance und Governance entsprechen muss. In meiner Rolle als Technical Architect muss ich alles überprüfen, was das Entwicklungsteam tut. Dies liegt an der Tatsache, dass die gesamte Entwicklung von Offshore-Drittanbieter-Beratungsunternehmen durchgeführt wird, wir keine interne Entwicklung durchführen, sodass ich eine technische Aufsichtsrolle habe (wir haben 1 Architekten pro LOB-Anwendung). In einigen Situationen werde ich Architekturdokumente zusammenstellen, in denen die UML-Diagramme die Klassen und Methodensignaturen sowie Entwurfsmuster und Softwarestrukturen identifizieren. In anderen Situationen überprüfe ich den implementierten Code, vergleiche ihn mit unseren Richtlinien und Standards und führe auch Code- und Performance-Analysen durch. Grundsätzlich klingt der Job, für den ich angestellt bin, in vielerlei Hinsicht wie der Softwarearchitekt in Ihrer Frage.
Warum arbeite ich so? Der Grund dafür ist, dass das Unternehmen in der Vergangenheit von seinen Lieferanten im Stich gelassen wurde, und da wir an die Einhaltung gesetzlicher Vorschriften gebunden sind, muss ich als Torwächter und Schiedsrichter fungieren, was das Unternehmen verwenden muss. Wenn eine LOB-Anwendung, wie die, an der ich arbeite, aufgrund falscher Berechnungen in einem Jahr 25 Millionen Pfund verloren hat. Dies führt dazu, dass die Anzahl der FTE (Vollzeitmitarbeiter) aufgrund der schlechten Leistung erhöht werden muss, wenn der Zweck der Anwendung darin besteht, die Anzahl der FTE-Mitarbeiter zu reduzieren. Dann neigen die Unternehmen dazu zu sagen: "Wir brauchen jemanden, der Verantwortung übernimmt und aufpasst, was wir bekommen", also liegt es an mir, nicht an den Entwicklern (es sei denn, die Situation, mit der Sie sich tatsächlich befassen, ist im Gegensatz zu meiner eine Schuldzuweisungskultur das ist der Bock, der bei mir aufhört).
Obwohl ich zustimmen würde, dass das, was ich tue und was Sie erleben, für viele Anwendungen kein "normaler" Arbeitsablauf ist, ist es vielleicht am besten für Sie, sich mit einem Senior Stakeholder oder dem Architekten zu erkundigen, warum es so sein muss, es könnte einfach sein sein, dass das Projekt die Einhaltung gesetzlicher Vorschriften, Governance und Aufsicht erfordert.
Es kann variieren, aber wenn Sie einen Architekten haben und er sich so entschieden hat, die Rolle zu handhaben, können Sie nicht viel dagegen tun. Und du wirst die Scheißprojekte bekommen. Ein Argument ist alles genauso, auch wenn es nicht für jedes einzelne Programm den besten Unterhaltungswert hat. Wenn Sie argumentieren, scheinen sie nur mehr einzugreifen. Nehmen Sie die Herausforderung an, ihren Weg zum Laufen zu bringen.
Wo ich ziemlich frustriert bin, ist, wenn ich weiß, dass ich persönlich 2 oder mehr Ansätze testen würde, um zu sehen, was am besten funktioniert.
Wenn ich weiß, dass die Leistung nachlässt, werde ich sie ruhig einmal ansprechen und dann einfach ihr Design tanken lassen.
Was wirklich Spaß macht, ist, wenn der Datenbankarchitekt nicht dem Softwarearchitekten entsprechen muss und Ihre Geschäftsobjekte nicht mit dem Datenbankdesign übereinstimmen. Ich war dort und Sie müssen sie nur herausfordern lassen. Wenn ein Softwarearchitekt (der sich nicht mit Datenbanken auskennt) einem Datenbankarchitekten sagt, wie man Datenbankdesign macht, machen die Dinge wirklich Spaß.
Nein, Ihre Situation ist etwas extrem. Sie haben da jemanden als Architekten, der etwas anal zurückhaltend ist. Code-Reviews sind eine Sache, aber wenn Sie sich nicht hinsetzen und programmieren können, ohne sich vor der Arbeit von jemandem diktieren zu lassen, ist das eine ganz andere Sache. Dieser Ansatz kann nur in einem kleinen Geschäft funktionieren und lässt sich nicht skalieren. Können Sie sich ein Team von 25, 30, 35 Entwicklern vorstellen, die alle warten müssen, bis sie an der Reihe sind, um einen Architekten zu sehen, bevor sie Code schreiben? Es ist Zeit für eine ernsthafte Entscheidung Ihrerseits.
Wenn man dort seit sechs Jahren als Softwareentwickler arbeitet, dann ist die Situation absolut nicht normal. Es ist absolut kontraproduktiv. Ich weiß, dass es viele Leute gibt, die sich der Theorie „Tu, was dir gesagt wird“ anschließen. Die Realität ist, dass jeder unbewusst versuchen wird, zu beweisen, dass er Recht hat. Wenn Sie Ihr eigenes Design entwickeln, versuchen Sie unbewusst zu beweisen, dass es funktioniert. Wenn ein analer zurückhaltender „Architekt“ Sie zwingt, seinen Anweisungen zu folgen, werden Sie unbewusst versuchen, zu beweisen, dass Sie Recht haben, was bedeutet, dass Sie unbewusst scheitern wollen. Wenn Ratschläge gegeben werden, sollte es darum gehen, Menschen auf den richtigen Weg zu bringen, und nichts anderes.
Sie können zwei Dinge tun: Gehen Sie zu Ihrem Chef (über dem „Architekten“) und sagen Sie ihm, dass Sie mit der Situation unzufrieden sind und warum. Wenn Sie dort sechs Jahre lang gute Arbeit geleistet haben, besteht die Möglichkeit, dass Ihr Chef Ihnen zustimmt. Wenn das nicht funktioniert, suchen Sie sich woanders einen Job. Es gibt auch die Regel, dass Sie oft den Job wechseln müssen, um Beförderungen und/oder Gehaltserhöhungen zu bekommen, also könnte das doppelt gut funktionieren.
Es konnte nicht als normal angesehen werden. Wenn er genau wüsste, wie die Arbeit erledigt werden sollte, warum konnte er es dann nicht selbst tun? Der schwierige Teil einer Entwicklung besteht darin, herauszufinden, wie die Anwendung intern funktionieren und wie der Code strukturiert sein sollte.
Die einzige Situation, in der der Manager den Codierungsprozess vor der Codeüberprüfung stören könnte, ist die Betreuung neuer Mitarbeiter, aber wenn Sie ~6 Jahre Erfahrung haben, ist das nicht der Fall.
Die Codeüberprüfung, die umfassende Dokumentation bewährter Praktiken und Standards ist eine Sache, aber Mikromanagement ist ein schrecklicher Fehler, der von schrecklichen Managern begangen wird. Wenn es eine geschäftliche Notwendigkeit für einen sehr strukturierten und starren Entwicklungsprozess gibt, lassen Sie dies vom Manager dokumentieren.
Ja, einige Unternehmen, vielleicht sogar die Hälfte von ihnen, forcieren jetzt die hochhierarchische, kontrollierte Arbeitsorganisation des Software-Engineerings und für sie wäre dies normal. Ja, Sie werden wahrscheinlich gefeuert, auch wenn Sie offensichtlicher zeigen, dass Sie mit diesen neuen Winden nicht zufrieden sind. Ja, ich verstehe auch voll und ganz, dass diese neue Erfahrung extrem frustrierend sein kann, und je mehr Kompetenz und Erfahrung Sie selbst haben, desto frustrierender ist es.
Ich weiß derzeit nicht, wie sich die Dinge weiter entwickeln werden. Viel hängt davon ab, ob mit dem ungewöhnlich hohen Mikromanagement tatsächlich eine bessere Produktivität oder gar Qualität erreicht werden könnte. Die Antwort darauf kann je nach Unternehmen, Kultur und Softwareprodukt unterschiedlich ausfallen.
Das ist nicht normal und würde mich stören. Früher oder später, wenn das Projekt wächst, wird der Softwarearchitekt zu einem riesigen, teuren Engpass, wenn er oder sie darauf besteht, den Code aller zu überprüfen.
Wenn ich es wäre, würde ich gebeten, zu einem Projekt zu wechseln, in dem Sie mehr Autonomie haben. Wenn das nicht funktioniert, ist es ein Verkäufermarkt. Haben Sie keine Angst zu hüpfen.
Fragen Sie ihn trotzdem, wie lange er das vorhat und wann er oder sie damit rechnen würde, Ihnen mehr Autonomie zu geben. Vielleicht sieht er oder sie nur, ob Sie kompetent sind und es nur vorübergehend ist.
JasonJ
Joe Terror