Wie sage ich Ressourcen, dass ich sie benötige, um etwas zu tun, was ich technisch selbst tun könnte?

Ich habe einen technischen Hintergrund in der Softwareentwicklung und war einige Zeit als Leiter für ein kleines Team tätig. Letztes Jahr wurde ich offiziell Projektleiter in einem viel größeren Team, mit dessen Arbeit ich viel weniger vertraut bin und weniger Zeit habe, mich in die technischen Details einzuarbeiten.

Manchmal, wenn ich nach Informationen suche, sagt mir ein Entwickler, dass die Informationen, nach denen ich suche, in einem Ordner in der Anwendung oder in einem Git-Repository liegen, als würde er erwarten, dass ich dort danach suche. Technisch gesehen könnte ich die Zeit und Mühe dafür aufwenden, aber das liegt nicht mehr in meiner Verantwortung und würde Zeit von meinen eigentlichen Verantwortlichkeiten nehmen.

Wie sage ich ihnen höflich, aber verbindlich und ohne zu klingen wie „das ist nicht meine Aufgabe“, dass ich sie brauche, um mir diese Informationen in einer bereits verarbeiteten Form zu geben?

Es ist also definitiv ihre Aufgabe, Ihre Recherchen für Sie durchzuführen? (es kann gut sein, oder es könnte sie von ihren wirklichen Verantwortlichkeiten wegnehmen). Auch in Git begraben? Ist es so, dass wenn Sie etwas über Foo-ing wissen wollen und sie Sie auf einen Kommentar in Foo.c verweisen, das zu viel für Sie ist? Wirklich?
Warum gehen Sie davon aus, dass meine Anfrage durch das Lesen eines einzigen Kommentars und ohne weiteres Kontext- oder Domänenwissen beantwortet werden könnte?
@Pedro Nathan geht möglicherweise davon aus, dass Ihrer Frage ein grundlegender Kontext fehlt. Darauf gehe ich (ziemlich erschöpfend) in meiner Antwort unten ein. Ich hoffe es hilft!
@NathanCooper Die Unhöflichkeit war einfach unangebracht. Ich hätte es gerne geklärt, wenn Sie einfach gefragt hätten, ohne das Schlimmste anzunehmen.

Antworten (5)

TL;DR

Sie haben Ihre Frage als zwischenmenschliches Problem formuliert, mit der Annahme, dass es mit Ihrer delegierten Autorität innerhalb Ihres organisatorischen Rahmens zu tun hat. Dies ist eine Annahme, über die wir gleich sprechen werden.

Auch wenn wir davon ausgehen, dass dies eine Angelegenheit Ihrer Befugnis ist, handelt es sich nicht unbedingt um eine persönliche oder zwischenmenschliche Angelegenheit. Da der Verantwortungsbereich eines Projektmanagers darin besteht, Kontrollen auf ein Projekt anzuwenden, kann jedes Versäumnis, bekannte Probleme innerhalb eines Projekts zu kontrollieren, den Erfolg des Projekts beeinträchtigen. Es ist daher besser, das Thema in einem Projektkontext als in einem zwischenmenschlichen zu gestalten.

Darüber hinaus sind Projektmanager häufig für den Prozess eines Projekts und für die Verwaltung der Kommunikation innerhalb des Projekts und zwischen seinen Prozessen verantwortlich. Dies sind im Allgemeinen Bereiche, die weniger Aufmerksamkeit erhalten als Budget und Zeitplan – und sicherlich weniger als Politik und Fragen der Positionsautorität.

Vor diesem Hintergrund empfehle ich Ihnen , die Prozesse und Kommunikation Ihres Projekts zu überprüfen . Wenn Sie Lücken oder Fehler darin finden, können Sie dann mit dem Projektteam zusammenarbeiten, um sie nach Bedarf anzupassen.

Die Dokumentation von Annahmen ist wertvoll

Diese Frage, wie sie derzeit veröffentlicht wird, ist mit Annahmen geplagt. Es enthält Annahmen Ihrerseits und zwingt den Leser, Annahmen über die Rollen, Autorität und den Kontext Ihrer Situation zu treffen. Um die ursprünglich gestellte Frage zu beantworten , werde ich daher einige grundlegende Annahmen dokumentieren, um eine Antwort zu ermöglichen. Die Annahmen sind:

  1. Sie stellen Ad-hoc-Anfragen an Entwickler, die nicht zu ihren derzeit zugewiesenen Aufgaben gehören.
  2. Sie haben die Befugnis , innerhalb Ihres Projekts Ad-hoc-Aufgaben zuzuweisen.
  3. Die Entwickler haben die Verantwortung (wie auch immer delegiert), auf Ihre Anfragen zu antworten.
  4. Sie stellen Ihre Anliegen auf gesellschaftlich, politisch und organisatorisch angemessene Weise.
  5. Ihre Entwickler geben Ihnen Antworten, die ihrer Meinung nach kontextuell angemessen sind, anstatt RTFM oder "up yours!" zu sagen.

Wenn eine dieser Annahmen falsch ist, wird die Antwort für zukünftige Besucher so belassen, aber Sie müssen Ihre Frage möglicherweise überarbeiten, um Ihre gegebenen Umstände genauer widerzuspiegeln.

So beheben Sie Prozess- und Kommunikationsfehler

Da wir a priori davon ausgehen , dass Sie die Informationen, die Ihnen von den Entwicklern ausgehändigt werden, wirklich benötigen und dass jeder so fragt und antwortet, wie er es für angemessen hält, bleibt uns die Annahme, dass es einen Prozess oder eine Kommunikation gibt Versagen bei der Arbeit hier. Schauen wir uns beide Möglichkeiten an.

Prozessfehler

Sie stehen unter Zeitdruck, etwas zu liefern (z. B. einen Bericht oder ein anderes Projektartefakt) und benötigen daher etwas von den Entwicklern. Wenn diese Aufgabe jedoch nicht standardmäßig für Ihr Projekt zugewiesen wurde, erzeugen Sie Zeitdruck und Terminrisiko für die Entwickler (und damit für das Projekt), indem Sie sie bitten, Folgendes zu tun:

  1. Task-Schalter.

    Das Wechseln von Aufgaben kann einen enormen negativen Einfluss auf den kognitiven Fluss in der Wissensarbeit haben. Es ist nicht nur die Zeit, die zum Schalten benötigt wird; Dies beinhaltet auch kognitive Störungen und erzeugt eine kognitive Belastung, wenn der Wissensarbeiter den Kontext zu einer anderen Aufgabe verschiebt. Das ist zwar einmalig kein Projekt-Killer, aber die Teamkapazität sinkt im Allgemeinen mit zunehmendem Aufgabenwechsel und zunehmender kognitiver Belastung.

  2. Schichtkapazität.

    Ihre Anfragen erfordern im Wesentlichen, dass Entwickler einen Teil ihrer verfügbaren Kapazität von dem, woran sie gerade arbeiteten, oder von den Meilensteinen, die ihnen in dieser Phase des Projekts gesetzt wurden, auf etwas anderes verlagern. Dies hat direkte Kosten für das Projekt, da Projekte im Allgemeinen eine begrenzte Kapazität haben. Dies kann auch Auswirkungen haben, wenn abhängige Aufgaben von der reduzierten Kapazität eines Teammitglieds betroffen sind.

    Es braucht keine große Reduzierung der Teamkapazität, um einen Zeitplan zu beeinflussen. Da viele Unternehmen dem Trugschluss der 100-prozentigen Auslastung zum Opfer fallen, braucht es nicht viel Varianz in der individuellen oder Teamkapazität, um ein Projekt aus der Toleranz zu werfen. Auch wenn Ihr Projektzeitplan etwas Spielraum bietet, müssen Sie bedenken, wie stark sich diese Anfragen kumulativ auf den verfügbaren Spielraum auswirken oder ob die reduzierte Kapazität trotz unzureichendem Spielraum einfach zu mehr Druck führt, Termine einzuhalten.

  3. Unsichtbare Arbeit leisten.

    Da diese Anfrage nicht Teil des Projektplans ist und vermutlich nicht als Projektergebnis nachverfolgt wird, bitten Sie den Entwickler, von einer sichtbaren Aufgabe, für die er verantwortlich ist, zu einer „unsichtbaren“ Aufgabe zu wechseln, für die dies nicht der Fall ist für die Stakeholder oder seinen direkten Vorgesetzten sofort sichtbar sein. Da sich diese Arten von Anfragen schnell summieren können, erstellen Sie möglicherweise mehr „off the books“-Arbeit, als Sie denken.

Auf Prozessfehler gibt es nie eine einfache Antwort, da sie (per Definition) systemischer Natur sind. Möglicherweise können Sie Ihren Prozess jedoch auf eine oder mehrere der folgenden Arten überprüfen und anpassen:

  1. Bündeln Sie Anforderungen, um den Overhead beim Wechseln von Aufgaben zu reduzieren.
  2. Stellen Sie sicher, dass Dokumentations-, Berichts- und Forschungsaufgaben innerhalb des Projektplans berücksichtigt werden. Slack ist in Ordnung, aber es ist noch besser, explizite Aufgaben im Projektplan für Dinge zu haben, die Sie planen können (wie Berichte oder Dokumentation).
  3. Stellen Sie sicher, dass Sie in Ihrer Kapazitätsplanung und Ihrer Zeitplanung genügend Spielraum haben, um ungeplante/ungeplante Aufgaben zu berücksichtigen. Denken Sie auch daran, dass Sie für die Zeit, die benötigt wird, um wieder auf Kurs zu kommen, wenn der Fluss unterbrochen ist, Pufferzeit hinzufügen müssen, und nicht nur Budget für die Aufgaben selbst.
  4. Stellen Sie sicher, dass alle Anfragen vom Projekt nachverfolgt werden. Das Gesetz von CodeGnome sagt: "Keine unsichtbare Arbeit, niemals!"

Es kann auch andere Möglichkeiten geben, den Prozess zu beheben. Besprechen Sie es mit den Entwicklern und sehen Sie, was Sie ausarbeiten können!

Kommunikationsfehler

Dies ist tatsächlich ein viel komplizierteres Problem mit viel mehr Variablen als ein potenzieller Prozessausfall. Wir können jedoch das meiste davon in zwei Schlüsselbereiche einteilen: Kontext und Transparenz .

  1. Kontext

    Sie haben einen Kontext darüber, was Sie brauchen, was das Projekt braucht und was die Rollen aller sind. Dies ist möglicherweise kein gemeinsam genutzter Kontext.

    Darüber hinaus haben die Entwickler auch einen Kontext. Sie können den Kontext der Entwickler verstehen oder auch nicht oder haben ein vollständiges Verständnis ihrer Wahrnehmungen und Motivationen in Ihrem gemeinsamen Kontext.

    Sie sollten diese Dinge wahrscheinlich gemeinsam besprechen.

  2. Transparenz

    Auf Prozessebene fehlt es Ihnen möglicherweise an Transparenz darüber, was die Entwickler tun und unter welchem ​​Druck sie stehen. Das Gegenteil ist mit ziemlicher Sicherheit der Fall: Entwickler haben selten Einblick in das, was Projektmanager tun, oder in die Auswirkungen, die irgendetwas außerhalb ihrer zugewiesenen Verantwortlichkeiten auf das Projekt hat.

    Was aus kommunikativer Sicht fehlt, ist Transparenz. Möglicherweise müssen Sie und das Entwicklungsteam effektiver über den Druck auf das Projekt als Ganzes und darüber, wie sich dieser Druck auf das Team auswirkt, kommunizieren. Es kann auch hilfreich sein, mehr Transparenz über die Organisation zu haben, einschließlich der Befehlskette und der delegierten Befugnisse.

    Die einzige Möglichkeit, die Transparenz aus Sicht der Kommunikation zu verbessern, besteht darin, explizit über Dinge zu sprechen, anstatt sich auf einen gemeinsamen Kontext oder angenommene Bezugsrahmen zu verlassen. Vielleicht haben Sie das Gefühl, dass Sie bestimmte Dinge nicht an die Öffentlichkeit bringen und darüber sprechen sollten, aber wenn Sie dies nicht tun, bleiben sie für alle Beteiligten undurchsichtige Probleme.

    Also über Dinge reden. Zusammen!

Es gibt sicherlich noch andere Arten von Kommunikationsausfällen. Vielleicht entdecken Sie einige davon, wenn Sie weiter graben. Am Ende wird die Lösung jedoch fast immer damit beginnen, offener zu sprechen und sicherzustellen, dass Probleme in einem explizit gemeinsamen Kontext diskutiert werden.

Vielleicht müssen Sie die Art und Weise, wie Sie nach Informationen fragen, anpassen.

Wenn Sie nicht mehr die Zeit haben, die Faktenfindung selbst zu erledigen, müssen Sie sie delegieren. Aber Sie müssen sicherstellen, dass Sie diese Änderung klar kommunizieren. Offensichtlich denken die Leute immer noch, dass Sie einfach Daten aus dem Repository abrufen können. Machen Sie beim nächsten Mal deutlich, was Sie brauchen:

Hey Bob, kannst du bitte einen kurzen Bericht darüber erstellen, wie die Sperren für unsere drei Hauptfoos bezüglich des neuen Widgets funktionieren, und ihn mir bis morgen früh zusenden? Danke dir.

Oh, und nenne Menschen nicht "Ressourcen". Wenn Sie mich als „Ressource“ bezeichnet haben, habe ich Ihnen eine Antwort geschickt, in der ich Sie gebeten habe, sich für Aufgaben an meinen direkten Vorgesetzten zu wenden. Sei nett und du wirst nette Leute treffen.

Stimmen Sie zu, wenn Sie eine "schnelle" Frage stellen, erhalten Sie eine schnelle Antwort. Bitten Sie jemanden, einen Tag damit zu verbringen, Ihnen ein Dokument zu schreiben

Wenn Sie der Projektmanager sind und diese Ressourcen Ihnen unterstellt sind, dann delegieren Sie die Aufgabe und skizzieren Sie Ihre Erwartungen, was Sie brauchen, wie Sie es wollen und wann Sie es wollen, und wenn Sie ignoriert werden, ergreifen Sie Maßnahmen.

In welchen Umgebungen berichten Entwickler an Projektmanager? Projektmanager verwalten Projekte, nicht Menschen. Zumindest an jedem Ort, an dem ich je gearbeitet habe.
Jedes Projekt, an dem ich jemals gearbeitet habe. Wenn ein PM keine Kontrolle über Ressourcen hat, einschließlich der menschlichen Art, was genau bedeutet es dann, ein Projekt zu leiten?
Menschen sind keine Ressourcen ... Sie sind Menschen.
Humanressourcen. An etwas gewöhnen.
An was gewöhnen? Ich lebe in der Gegenwart statt in den 90ern.
Ja, du hast recht, @codegnome. Frustration über die scheinbar IT-zentrierten Philosophien.

Als Projektmanager können Sie die Aufgabe an Ihre vertrauten Teammitglieder delegieren. Bitte ändern Sie Ihren Command-and-Control-Ansatz für dieses Problem. Zeigen Sie Ihren Teammitgliedern Ihre dienende Führungsqualität und unterstützen Sie sie bei ihren täglichen Aktivitäten. Es bedeutet nicht, dass Sie ihre Arbeit machen müssen. Erklären Sie die Wichtigkeit der gesuchten Informationen und binden Sie Ihre Teammitglieder ein

Wenn Sie derjenige sind, der die Informationen benötigt, und die Entwickler bereits mit der Entwicklung beschäftigt sind, warum ist es dann ihre Aufgabe, die Informationen für Sie zu finden? Wenn sie sagen "Ich glaube, es ist in diesem Repo", denken sie vielleicht, dass sie hilfreich sind, indem sie Sie in die richtige Richtung weisen.

Ihre Aussage mag zwar wahr sein, aber sie beantwortet nicht wirklich die Frage, die das OP gestellt hat. Selbst wenn Sie der Meinung sind, dass das OP die falsche Frage gestellt hat, sollten Sie als Antwort etwas umsetzbareres vorschlagen.