Wie man mit einem Softwarearchitekten umgeht, der nicht kompetent erscheint

Ich wurde kürzlich in eine andere Abteilung unseres Unternehmens versetzt.

Das Team lief gut, aber ich stelle fest, dass sie einige Probleme mit unserem Software-Architekten haben. In unserem Team sind wir in zwei Abteilungen unterteilt, von denen wir derzeit den größten Teil der Frontend-Entwicklung durchführen, und in der anderen Abteilung, die sich auf die Erstellung der Backend-APIs (Backend-Entwicklung) konzentriert. Die beiden Abteilungen treffen sich nur ein- oder zweimal pro Woche über Meeting Calls. Beide Geschäftsbereiche sind geografisch auf zwei verschiedene Länder getrennt. Deshalb arbeiten wir über Anrufe und E-Mails zusammen.

Wir erhalten weiterhin Feedback-Ergebnisse mit dem Back-End-Team darüber, was sie in den letzten 2 Monaten abgeschlossen haben. Der Software-Architekt im Back-End-Team sagte uns, dass das Back-End gut laufe, und sie wiederholen immer wieder dieselbe Antwort, weil wir ihre Ergebnisse haben wollen, die sie im letzten Monat noch nicht gegeben haben.

In letzter Zeit in unserer Division (Front End Development). Wir hatten ein Meeting mit dem Backend-Team sowie mit dem Projektmanager und den Business Managern. Mein Team (Frontend) hat unsere Bedenken hinsichtlich der Fristen und Projektergebnisse unseres Webprojekts sowie der Ergebnisse des Backend-Teams geäußert. Wir waren wirklich schockiert, dass sie in den letzten 2 Monaten nur zwei APIs entwickelt haben, die nichts mit dem zu tun haben, was ursprünglich vereinbart wurde. Ganz ohne Datenbanken. Es ist sehr unvorstellbar.

Einer der Projektmanager (aus einer anderen Abteilung) stellte dem Softwarearchitekten mehrere Fragen.

Projektmanager : Welche Programmiersprache hat Ihr Team für die Back-End-APIs verwendet? (Java, PHP usw.).

Software-Architekt : Ist das überhaupt wichtig? Lassen Sie mich zum Team kommen

Software Architect : Ich habe eine kurze Frage, was ist Agile Scrum und warum verwenden wir es?

Software-Architekt : Außerdem benötigen wir den API-Quellcode von der Abteilung (des Projektmanagers), damit wir den Code von unserer Seite wiederverwenden können

Wir waren wirklich so überrascht, dass er nicht einmal wusste, was Agile Scrum ist.

Was kann ich als Mitglied des Teams tun, damit es mit beiden Teams gut läuft?

(Aktualisiert: Wir haben bereits mit der Geschäftsführung gesprochen und sie scheinen unsere Bedenken auf der Seite der Softwarearchitekten zu vertreten.)

Warum fragt er nach API-Code, wenn sein Team die API-Arbeit erledigt? Könnte helfen, Abteilungen mit einer Variablen oder so etwas zu klären, um die Dinge in der Frage klar zu halten.
Ich habe das Thema geändert, um es abzuschwächen, damit es nicht so subjektiv und aufrührerisch wirkt, und einige kleinere Änderungen vorgenommen.
Die letzte Frage des Architekten: Ist er es als Backend-Entwickler, der fragt, welche API das Frontend entwickelt hat? Frontend produziert keine API, sie produziert UI und sie brauchen sie nicht, um ihr Backend zu validieren. Scheint mir eine Falle zu sein.
FWIW, die erste Aussage des Architekten trifft zu, was die Schnittstelle zwischen Frontend und Backend betrifft. Der Benutzer des muss die Sprache hinter der Benutzeroberfläche nicht kennen. Wenn der PM Bedenken hinsichtlich der Leistung hat, wäre das anders, aber nicht als Schnittstelle

Antworten (4)

Dies ist ein größeres Problem als nur der Architekt. Du hast auch eine unwirksame PN.

Wir erhalten weiterhin Feedback-Ergebnisse mit dem Back-End-Team darüber, was sie in den letzten 2 Monaten abgeschlossen haben. Der Software-Architekt im Back-End-Team sagte uns, dass das Back-End gut läuft, [aber] sie haben es im letzten Monat noch nicht gegeben.

Der PM sollte die Interaktionen zwischen den Teams verwalten, aber er schläft ernsthaft am Steuer, wenn er akzeptiert, dass die Arbeit vom Remote-Team ohne Beweise dafür erledigt wurde . Ebenso, wenn er nicht glaubt, dass die Arbeit erledigt ist, aber nichts unternimmt. Ob der Architekt Scrum versteht oder nicht, ist nicht der wichtigste Punkt – er und sein Team machen Versprechungen, scheitern daran und werden nicht zur Rechenschaft gezogen. Vermutlich wird das Scheitern zu einem weit entfernten Zeitpunkt in der Zukunft herauskommen, wenn nichts wie geplant funktioniert, aber zu diesem Zeitpunkt wird es viel zu spät sein, die Situation zu korrigieren.

Beachten Sie, dass der PM, wenn er kompetent wäre, das Zentrum der Scrum-Methode wäre, und daher gibt es keine Möglichkeit, dass er nicht weiß, was Scrum/Agile ist, zumindest nicht sehr grob.

Sie brauchen das Management, um Maßnahmen zu ergreifen. Wenn der Architekt nicht einmal eine Ahnung hat, wie er seine eigene Arbeit erledigen soll, wird dies enorme Auswirkungen haben, es sei denn, es gibt jemand anderen, der seine Arbeit und seine eigene erledigt, was langfristige Auswirkungen haben wird. Das Management muss zuerst etwas über diesen Typen herausfinden und wie er eingestellt wurde, vielleicht ist er woanders qualifiziert und fehl am Platz, aber das sind wirklich, wirklich schlechte Antworten für einen Architekten.

Ein Architekt sollte über solide Erfahrung in der Entwicklung sowie im Programmdesign über den gesamten Lebenszyklus und normalerweise in mehreren Sprachen verfügen, es sei denn, er ist auf bestimmte Technologien spezialisiert. Der agile Teil beschäftigt mich nicht so sehr, obwohl er zumindest vertraut sein sollte, auch wenn er noch nie damit gearbeitet hat, aber die Antworten auf Codesprachen und die Aufforderung zum Kopieren von Code sind schockierend, zusammen mit dem Output des anderen Team scheint arm von dem, was Sie sagen. Einige APIs sind sehr komplex und brauchen Zeit, aber wenn es sich um eine einfache API handelt und es viele geben soll und sie keine gute Zeit haben, muss das Management sie zur Leistung motivieren oder einige personelle Anpassungen vornehmen, um die Dinge zu erreichen.

Eskalieren Sie Ihre Bedenken sofort an das Management und bringen Sie es dazu, entweder Maßnahmen zu ergreifen oder Verzögerungen aufgrund des anderen Teams zu erwarten.

Dies ist ein „Alle Mann an Deck“-Notfall. Ihr Management muss SOFORT ein Audit-Team zu den Back-End-Entwicklern schicken. Etwas sagt mir, dass du sehr bald eine Menge Enttäuschungen erleben wirst.
Das Problem ist, dass das „Management“ auf der Seite des Back-End-Teams steht. Sie vertrauen ihnen mehr als dem Front-End-Team
@Jon Wenn sich das Management auf die Seite des Back-End-Teams stellt, müssen Sie sich auf die Auswirkungen auf die Arbeit von Ihnen/Ihrem Team konzentrieren, anstatt auf die mangelnde Produktion des anderen Teams. Wenn sie wirklich schlecht abschneiden, sollte sich das im Laufe der Zeit zeigen und zu Veränderungen führen, aber stellen Sie sicher, dass Ihre Arbeit und die Arbeit Ihres Teams vollständig auf Kurs ist und alle vom anderen Team verursachten Ausrutscher vollständig dokumentiert werden, um die genaue Ursache für jede Verzögerung aufzuzeigen Detail.

Offensichtlich gibt es ein Management und möglicherweise Missverständnisse. Das Managementproblem wird durch andere Antworten abgedeckt. Ich möchte einige der technischen Vorschläge hinzufügen, die Sie äußern können, wenn Sie das Problem mit Ihrem Management besprechen:

  • Haben Sie ein Scrum-Backlog, das beide Teams für die Entwicklung verwenden
  • Sprints für beide Teams ausrichten, Sprint-Review-Meeting (Demo) für beide Teams kombinieren
  • Stimmen Sie den API-Prototypen zu. Schreiben Sie kleine schnelle Integrationstests, die verspottete Daten zurückgeben. Das UI-Team kann mit dem Prototyp arbeiten und das API-Team kennt das Format der echten Daten, die es zurückgeben muss
  • Führen Sie Integrationstests auf Ihrem CI-Server durch
  • Wenn die Backend-API implementiert ist, schreiben Sie mehr Integrationstests mit echten Daten
  • Erwägen Sie die Verwendung von Chat-Anwendungen, um die Kommunikation zwischen Teams zu beschleunigen und zu verbessern (z. B. Slack oder ähnliches)
  • Erstellen Sie einen API-Plan. Trennen Sie ähnliche Funktionen in Partitionen. Titelnummer der implementierten API und was übrig bleibt. Implementieren Sie zuerst die wichtigste API und zielen Sie darauf ab, in jedem Sprint eine voll funktionsfähige Benutzeroberfläche und API freizugeben

Was kann ich als Mitglied des Teams tun, damit es mit beiden Teams gut läuft?

Einfache Antwort : Der Architekt muss gehen. Diese Person sollte die Antwort auf die Fragen, die Sie im Beitrag genannt haben, bereits kennen.

Das nicht so einfache wie:

Der Umgang mit einem schlechten Softwarearchitekten ist sehr schwierig. Wenn Ihr Unternehmen entschieden hat, dass es (zuerst) einen braucht, und dann tatsächlich einen einstellt, hat er einen gewissen erhöhten Status. Früher habe ich mit jemandem zusammengearbeitet, den ich einen erfahrenen Googleer nannte, er konnte einfache Konzeptbeispiele nicht codieren oder implementieren.

Die Art und Weise, wie unser Team mit ihnen umging, bestand darin, ihn konsequent technisch herauszufordern und ihn zu bitten, Mock-ups von Konzepten (mehr als das, was man einfach googeln kann) bereitzustellen, die das Team implementieren sollte. Am Ende, nachdem dies konsequent getan wurde, begann das Management zu sehen, dass die Person zwar einen ausgefallenen Titel hatte, aber nicht wirklich viel tun konnte, um einen Mehrwert für das Team zu schaffen, und sie wurden entlassen.

Es dauerte eine Weile und war schmerzhaft. Ich beneide Sie nicht um Ihre Position.

Wie man mit einem Softwarearchitekten umgeht, der nicht kompetent erscheint
AntwortenHierDatenschutz-Bestimmungen1y, 0v