Wie viel Projektmanagement sollte ein Softwareentwickler leisten?

Um nicht zu allgemein zu sein, wäre die direkte Frage:

Wird von einem Entwickler erwartet, dass er Projektmanager kontinuierlich an ein Feature erinnert, das nicht implementiert wurde, weil ihm die Ressourcen fehlen, um es zu implementieren?

Die Regeln sind wie folgt: Wir haben ein Brett mit Aufgaben in Spalten. Ein Entwickler wählt eine Aufgabe in "OPEN" aus und beginnt mit der Arbeit daran. Dabei verschiebt er die Aufgabe auf "IN PROGRESS". Wenn er fertig ist, geht die Aufgabe zu "ENTWICKLUNG ABGESCHLOSSEN" (später zu Testen). Aber wenn etwas schief geht, sollte die Aufgabe in "FEEDBACK" verschoben werden, wo etwas gelöst werden muss. Vielleicht fehlt das Design oder eine Beschreibung ist unklar ...

Ziemlich einfach, wenn Sie mich fragen.
Meiner Meinung nach ist es als Entwickler, wenn eine Aufgabe nicht abgeschlossen werden kann und ihr Ticket in „FEEDBACK“ ist, die Verantwortung eines Projektmanagers, ein Feature im Auge zu behalten und sich zu bemühen, eine Person zu finden, die das Problem damit lösen kann.

Aber was ist in unserem Team passiert: Es wurde ein Ticket an "FEEDBACK" gesendet, da die benötigte API nicht implementiert war. Das Ticket lag ein paar Monate da (ja, eigentlich fast ein halbes Jahr) und irgendwann hat einer der Projektmanager das Ticket einfach geschlossen, weil ein anderer Projektmanager berichtet hat, dass er das Problem an ein anderes Team weitergeleitet hat. Ein weiterer Monat vergeht und plötzlich taucht dieses Not-Completed-Feature auf. Jetzt ist einer der Projektmanager wütend und behauptet, dass es unsere Verantwortung als Entwickler ist, solche Dinge im Auge zu behalten, und dass er erwarten würde, dass wir eine Art Liste von Dingen haben, die nicht erledigt sind.

Ist das wahr? Sollten wir neben dem Brett, das wir bereits haben, irgendwie ein paar zusätzliche Dinge im Auge behalten? Ich würde erwarten, dass ein einziges Board für solche Dinge ausreichen sollte, und das Entwicklungsteam hat alles in seiner Macht Stehende getan, um ein solches Durcheinander zu verhindern. Wenn nicht, haben Sie eine Empfehlung, wie solche Probleme vermieden oder solche potenziellen Probleme besser verfolgt werden können?

Um eine vollständige Geschichte darüber zu erzählen, wie / was passiert ist:

Wir machen eine mobile Anwendung. Vor einigen Monaten erhielten wir eine Anfrage, dass auf einem bestimmten Bildschirm (selten von einem Benutzer gesehen) ein Fehler von der API empfangen werden könnte (aufgrund einer seltenen Situation). Jetzt wird dieser spezifische Fehler auch einen Unterfehlercode melden. Wenn also dieser Fehler auftritt, wird ein Unterfehler Aoder Unterfehler hinzugefügt. BUnd abhängig von diesem Unterfehler muss die App entweder screenAoder anzeigen screenB. Aber die API lieferte weder Anoch Bund die abgeschlossene Aufgabe konnte nicht validiert oder getestet werden.

Also wurde das Ticket in "FEEDBACK" gestellt und erklärt, dass die API einfach nicht bereit dafür ist. Aber dann begann eine Diskussion über das Ticket, den Bildschirm trotzdem zu sehen, nur um das Design zu überprüfen. Also fügte der Entwickler eine Logik hinzu, um zufällig anzuzeigen screenA, oder screenBund meldete dies im Ticket, das sich noch in "FEEDBACK" befand.

Monate vergingen und irgendwann versuchte einer der PMs, damit umzugehen. Also (nehme ich an) hat er dies dem für API zuständigen Team gemeldet und das Ticket kommentiert, etwa "Sie haben uns gesagt, dass dies ein Fehler auf ihrer Seite ist. Erwähnen Sie: theOtherPM, können wir dieses Ticket jetzt schließen?". Und "theOtherPM" hat dann das Ticket geschlossen. Einen weiteren Monat später bricht darüber die Hölle los und ich bin verwirrt, warum das die Schuld von uns Entwicklern ist.

Hinweis: Noch zu erwähnen ist, dass das andere Team, das unter anderem für die API zuständig ist, nicht Teil unseres Netzwerks und nicht einmal Teil unseres Unternehmens ist. Wir als Entwicklungsteam haben keine direkte Kommunikation mit ihnen. Es gab also keine andere Möglichkeit, dies zu lösen, als durch unser Management.

Gibt es überhaupt die Möglichkeit einer verbindlichen Antwort darauf? Wird das nicht von Site zu Site/Team zu Team variieren?
@MarkC.Wallace Ich hoffe nicht. Ich würde glauben, dass es einige allgemeine Vereinbarungen über die Verantwortlichkeiten der einen oder anderen Position gibt, die objektiv in die eine oder andere Richtung weisen sollten. Wenn nicht, dann ist "Dies muss in Ihrem Team speziell definiert werden" auch eine gültige Antwort, vorausgesetzt, Sie können zumindest einige Argumente für beide Seiten haben.
Als Projektmanager, der auch ein erfahrener Entwickler ist, würde ich antworten, dass es in der Verantwortung Ihres Teams liegt, den Überblick über die Aufgaben zu behalten, die Sie entweder für sich selbst erstellen oder die Ihnen von außen zugewiesen werden. Sie sind diejenigen, die den Quellcode tatsächlich entwickeln und die natürlich mit den internen Komplexitäten der zugrunde liegenden Softwareimplementierung bestens vertraut sind. Projektmanager konzentrieren sich im Allgemeinen auf eine höhere und umfassendere Ebene: „das Projekt selbst“. Sie verlassen sich darauf, dass Sie die Bits-und-Bytes-Minutia ausführen ... korrekt und sichtbar.
Außerdem: Stellen Sie sich vor, Sie wären die "Fachexperten (KMU)" dafür , wie genau diese Anwendung konstruiert und debuggt wird, damit sie genau und vollständig gemäß der Spezifikation funktioniert. Das ist Ihre Sorge. In der Zwischenzeit schauen die Projektmanager beispielsweise auf diese Spezifikation ... auf die Umgebung, in der die Anwendung funktionieren wird ... auf alle anderen Projekte und Arbeitsgruppen, die Ihre Arbeit beeinflussen oder von ihr beeinflusst werden könnten "Sie suchen auf ‚was, nicht wie‘.“ Zwei parallele, aber unterschiedliche Sichtweisen und Verantwortlichkeiten, beide wesentlich!
@MikeRobinson Interessant. Klingt vernünftig. Aber ich konnte es kaum in unseren Fall implementieren. Vielleicht ist es wichtig zu beachten, dass das „andere Team“, das die API verwaltet, kein Team ist, auf das wir Zugriff haben. Erschwerend kommt hinzu, dass es sich nicht einmal um dieselbe Firma handelt. Es gibt also wirklich keine Möglichkeit, unsere Projektmanager zu umgehen, um die benötigten Ressourcen zu erhalten. Also haben wir als Entwicklungsteam sie benachrichtigt. Wir haben das sogar mehrmals mit PMs besprochen. Und es schien, als hätten sie es unter Kontrolle, aber irgendwann wurde unser Ticket geschlossen und Informationen gingen verloren. Und PMs haben es geschlossen, also ...
Das hängt so sehr von der Unternehmenskultur ab. Jeder macht es zwangsläufig etwas anders.
@MaticOblak Der Punkt, dass das API-Team ein Drittanbieter ist, wird einen ziemlich großen Einfluss auf die Antworten haben (z. B. haben sie vermutlich keine Sichtbarkeit Ihres Kanban-Boards und es kann nicht erwartet werden, dass sie Tickets bearbeiten, die sie nicht einmal kennen existieren!), und ich würde empfehlen sicherzustellen, dass Sie in Zukunft eine Liste der Beziehungseigentümer für alle Ihre Drittparteien haben und sicherstellen, dass sie an mindestens einem Meeting pro Woche teilnehmen, um Feedback und Aktualisierungen zu erhalten und bereitzustellen.
Rhetorische Frage: Wer hat das Ticket geschlossen?
Nicht, dass Sie jemals "um die Projektmanager herumgehen sollten, um Ressourcen zu bekommen!" Wenn es ein Problem mit einem Remote-Team gibt, müssen sie es sofort wissen. Nein, sie müssen keine Bits-und-Bytes-Details kennen, aber das ist etwas, das das Projekt blockiert. // Offensichtlich läuft die ganze Sache auf einen Kommunikationsfehler hinaus. Das „Schließen des Tickets“ war möglicherweise versehentlich oder falsch informiert. Die Ursache sollte untersucht werden, um sie zu verstehen.

Antworten (2)

Verantwortliche vs. verantwortliche Rollen in einem Pull-Queue-System

Die Frage, die Sie stellen, ist wirklich ein X / Y-Problem. Sie haben ein paar andere Probleme, die Sie in Ihrer Frage nicht wirklich genannt haben:

  1. Kanban ist ein Pull-Queue -System, kein Push-System. Wenn also das API-Team nicht weiß, dass es aus Ihrer „Feedback“-Spalte ziehen soll, oder wenn es kein eigenes Backlog hat, in das Sie die Arbeitselemente einfügen können, ist es unklar, warum von ihm erwartet wird, dass es die Arbeit zieht ( oder sich dessen überhaupt bewusst ist). ).
  2. Agile Frameworks sind stark abhängig von funktionsübergreifender Kommunikation. Wenn Sie nur Tickets statusen, anstatt mit Stakeholdern wie dem API-Team zusammenzuarbeiten , ist Ihr Prozess kaputt.
  3. Arbeitselemente, die nicht eindeutig mit einem Meilenstein oder Liefergegenstand verknüpft sind, werden nicht nachverfolgt. Es gibt keine Möglichkeit, anhand Ihrer Frage allein zu bestimmen, wem das innerhalb des aktuellen Prozesses Ihres Unternehmens gehört.
  4. Die Unterscheidung zwischen den verantwortlichen und verantwortlichen Rollen für Ihren Prozess wurde entweder nicht definiert oder unzureichend kommuniziert.

Wenn Sie traditionelle Projektmanager haben, die für das Projekt verantwortlich sind, dann sind sie letztendlich dafür verantwortlich, den Status von Arbeitselementen zu verfolgen und sie angemessen zu melden. Dies gilt unabhängig davon, ob sie einen Teil dieser Verantwortung an Mitglieder des Teams delegieren oder nicht.

Wenn Sie andererseits einen wirklich agilen Prozess haben, sollten sowohl die Verantwortung als auch die Verantwortlichkeit für die Nachverfolgung von Arbeitselementen durch die Arbeitsvereinbarungen des Teams klar definiert sein, sowohl innerhalb des Teams als auch mit anderen Teams. Es gibt keine richtige oder falsche Antwort darauf, wer rechenschaftspflichtig oder verantwortlich sein sollte, solange es den Bedürfnissen aller Beteiligten entspricht, einschließlich denen des Projektteams selbst.

Das Problem bei Ihrem ersten Punkt ist, dass das API-Team nicht zu unserem Unternehmen gehört und für uns eher eine Ressource ist. Entwicklungsteams haben keine direkte Kommunikation mit ihnen, also müssen unsere PMs diesen "Bug" an alle Mittel weiterleiten, die sie haben (nach meinem Verständnis haben sie eine offene Kommunikation, sogar wöchentliche Treffen, mit dem anderen Unternehmen). Dieses Ticket wurde also von einer PN gezogen, der Vorgang wurde ausgelöst, aber das Ticket ging verloren. Dann klingt es so, als ob es impliziert wurde, dass das Entwicklungsteam noch ein weiteres Kanban haben sollte, das etwas nicht implementiertes verfolgen würde. Für mich klingt das seltsam.
Der zweite Punkt hat auch ein ähnliches Problem wie der erste. Ich muss zustimmen, dass wir in den meisten Projekten, an denen ich gearbeitet habe, eine direkte Zusammenarbeit und Kommunikation mit anderen Teams innerhalb eines Projekts hatten. Aber es war nicht immer so und ich bin mir nicht sicher, ob das irgendetwas kaputt macht. Zum Beispiel habe ich vor einigen Jahren an einer iOS-Fernbedienung für eine Drohne gearbeitet. Unter anderem musste ich ein Framework integrieren, das von einer anderen Firma am anderen Ende der Welt erstellt wurde. Das Framework war in diesem Fall ähnlich wie bei der API noch in Arbeit. Aber ich habe das Team, das den Rahmen erstellt hat, nie getroffen. Ist das ein No-Go?
Das Fazit ist interessant und führt irgendwie zu dem, was mich am meisten stört: Die Rollen sind nicht klar definiert, aber sobald ein Problem auftritt, wird mit dem Finger gezeigt. Der Grund, warum mich das stört, ist, dass das Problem selbst nicht analysiert wird und keine Anstrengungen unternommen werden, um sicherzustellen, dass dies nicht erneut auftritt. Und leider ist das schon zweimal passiert und ich habe immer noch keine Ahnung, wie ich das angehen soll. Aus diesem Grund habe ich mich an euch gewandt, um Hilfe zu erhalten. Danke schön.
Ich stimme zu – Finger zeigen und der kollaborative Prozess ist unterbrochen. Ich würde denken, dass die Entwicklungsteams und Entwicklungsmanager , nicht übergeordnete Projektmanager , für die Kommunikation mit den Remote-Auftragnehmern verantwortlich wären, da für eine effektive Kommunikation ein rein technischer Kontext erforderlich ist. "Kaiban" hin oder her, jemand redet nicht mit jemand anderem und das kostet dich gerade viel Geld.

Ich denke, dies hat eine kanonische Antwort, zumindest aus traditioneller PM-Sicht, wenn nicht mit Agile oder Kanban oder was auch immer.

Wenn ein Teil der Arbeit aus irgendeinem Grund vom Mechaniker, Entwickler, Handwerker oder wem auch immer nicht abgeschlossen werden konnte, fällt das Problem zurück an den PM- oder PM-Steuerungsteil des Projekts, um verfolgt und gelöst zu werden. Das zugewiesene Projektpersonal, das diese Arbeit ausführen sollte, wechselt entweder zu anderen Arbeiten oder verlässt sogar das Projektgelände. Diese Rolle würde dieses Problem nicht mehr verfolgen und in vielen Fällen nicht mehr kontrollieren und kontrollieren können. Innerhalb der PM-Steuerung wird die Verantwortung zum Eigentümer, und das kann von Projekt zu Projekt unterschiedlich sein.

Wenn etwas in diesem Prozess zusammenbricht und dieser Artikel verloren geht, liegt die Verantwortung für diesen Verlust beim PM oder der PM-Kontrolle.

In einem hochtechnischen Szenario wie diesem würde ich lieber sagen, dass der PM dafür verantwortlich ist, von der Existenz des Problems zu wissen und zu wissen, dass es rechtzeitig gelöst wurde . Ich würde erwarten, dass die Entwicklungsmanager , die direkt mit dem „Heimteam“ zusammenarbeiten, diejenigen sind, die mit den Auftragnehmern kommunizieren, den PMs ständig Informationen zur Verfügung stellen, sie aber nicht bitten, Vermittler zu sein. (Ich habe das Gefühl, dass sie in der Organisation des OP gebeten werden, diese Rollen zu spielen ... )
Rollen können auf viele Arten definiert werden. Einige Rollendefinitionen werden jedoch einfach keinen Sinn machen. Ich weiß, dass es bei den meisten Themen in diesem Austausch um Software geht, aber ich denke oft an andere Arten von Projekten, um diese Fragen zu beantworten. Ich denke an einen Klempner bei einem Wohnungsjob, der wegen seiner Arbeit auf einen Blocker gestoßen ist. Der Klempner meldet das Problem und verlässt das Haus oder geht in einen anderen Teil des Hauses. Ich kann mir nicht vorstellen, dass der Klempner für das Verschieben des Blockers verantwortlich ist. Könnte Vertragsänderung, Architekturänderung, technische Änderung erfordern. Außer Reichweite für den Klempner.
Wie viel Projektmanagement sollte ein Softwareentwickler leisten?
AntwortenHierDatenschutz-Bestimmungen1y, 0v