Wie bringe ich als Remote-Mitarbeiter Kollegen dazu, mir Informationen zu geben, die ich für meine Arbeit benötige?

Dafür ist Ihr Vorgesetzter da. Wenn Sie Probleme haben, die Informationen zu erhalten, die Sie für Ihre Arbeit benötigen, und da Sie nicht befugt sind , jemanden anzuweisen, Ihnen zu helfen, sollte Ihr Vorgesetzter mit dem anderen Vorgesetzten sprechen und das Problem lösen.

Um es noch einmal zu wiederholen: Sie haben keine Macht. Du kannst niemanden dazu bringen, etwas zu tun. Es geht nicht darum, unabhängig zu sein. Die Aufgabe Ihres Vorgesetzten besteht nicht darin, jemandem hinterherzulaufen. Die Aufgabe Ihres Vorgesetzten besteht darin, mit einem anderen Vorgesetzten zu sprechen, der dann seinen Untergebenen sagen kann, dass er Ihnen helfen soll. Wenn sie das nicht will, dann macht sie ihren Job nicht.

Früher habe ich das beruflich gemacht. Was ich finde, ist, dass die Leute die Vorstellung fürchten, dass ihre Zeit verschwendet werden könnte. Wenn Sie sie im Voraus wissen lassen, dass Sie ihre Zeit respektieren werden, werden sie sich viel eher bemühen.

Normalerweise habe ich, nachdem ich das Inhaltsverzeichnis zusammengestellt (und es genehmigt bekommen habe), alle Themen aufgeteilt und die fehlenden Details/Lücken gedanklich Personen "zugewiesen", die als interne Experten oder ursprüngliche Ingenieure bekannt sind. Ich würde ihnen im Voraus sagen, dass ich X Zeit benötige, um die folgenden Details zu behandeln, und alle Fragen in derselben E-Mail enthalten. Ich ließ sie wissen, dass es zwei Phasen gibt: die Phase der Informationsbeschaffung und später die Phase der Bearbeitung auf Genauigkeit.

Schüchterne unzugängliche Ingenieure? Kein Problem, wenn Sie ihnen vorab eine Liste mit konkreten Fragen und einer Zeitschätzung per E-Mail senden. Die meisten Menschen werden kooperieren, wenn sie wissen, dass es sich nicht um eine Zeitsenke mit offenem Ende handelt.

Manchmal gibt es echte Sprachbarrieren, sodass Sie möglicherweise alternative Quellen benötigen. Aber dieselben Personen sind möglicherweise bereit, die Bearbeitungspässe auf technische Details/Genauigkeit zu überprüfen, nachdem Sie das gesamte Handbuch/Dokument ausgearbeitet haben. Ein Tonbandgerät hat auch sehr geholfen (besonders wenn jemand über haariges Zeug spricht, das Sie unmöglich auf Anhieb verstehen können, und einen Jargon verwendet, mit dem Sie nicht leben, wie sie es tun). Ganz zu schweigen von Murmeln!

Eine Sache, die mir sehr geholfen hat, war, zu ein paar Produktdesign-Meetings zu gehen (oder was auch immer in Ihrem Fall das Äquivalent ist) - besonders wenn Sie es früh tun können. Auf diese Weise werden Sie "echt" sein, anstatt ein Außenseiter zu sein, von dem sie vielleicht wissen oder nicht einmal etwas wissen. Außerdem können Sie im Voraus einschätzen, wer zugänglich sein wird. Dies kann in Ihrer Situation praktikabel sein oder auch nicht. Contracting ist großartig, aber wie Sie sagten, der Trick besteht darin, dass Sie ein Außenseiter sind, der wie ein Insider produzieren muss.

Ich bin ein technischer Redakteur, der mit Remote-Entwicklern zusammenarbeitet – damit meine ich 500 Meilen entfernt, nicht „nur einige Tage im Büro“. Es gibt zwei Schlüssel zur Lösung dieses Problems, und Sie haben bisher nur nach einem davon gefragt (sie zum Antworten zu bringen). Darauf komme ich noch, aber zuerst werde ich über das andere sprechen.

Entwickler (oder andere Fachexperten) reagieren in der Regel nicht gut auf Fragen, die KMU ihnen bereits beantwortet haben. Das gilt für technische Redakteure, Tester, Kundenbetreuer und wahrscheinlich andere. Ihre Arbeit beginnt also viel früher als die Dokumentation der meist funktionierenden Funktion. Gab es funktionale Spezifikationen? Designbewertungen? Diskussionen über Anforderungen? Haben Sie diese Dokumente gelesen und sind Sie zu diesen Treffen gegangen? Haben Sie frühzeitig Fragen dazu gestellt, wie die Funktion funktionieren wird? (Nein, Sie können dann nicht alle Fragen vorhersehen, aber einige könnten in den Sinn kommen.) Sind Sie Teil des Prozesses ?

Wenn Autoren in Ihrer Organisation nicht so arbeiten, fordere ich Sie auf, alles in Ihrer Macht Stehende zu tun, um dies zu ändern. Wenn die Kultur lautet: „Entwickler werfen ein Release über die Mauer, wenn es fertig ist, und es dem Dokument zuordnen“, werden Sie diesen „zu wenig Informationen, zu spät“-Kampf für immer führen. Wenn es die Art von Organisation ist, in der Sie diese Meetings zum Absturz bringen können, fangen Sie an, aufzutauchen. Wenn dies nicht der Fall ist, arbeiten Sie mit Ihrem Vorgesetzten zusammen, um früher Zugang zu Informationen und Plänen zu erhalten, bevor sie in Stein gemeißelt sind.

(Ja, das bedeutet, dass Sie einige Dinge, die Sie früh lernen, später wieder verlernen müssen; Pläne ändern sich. Nachdem ich es in meiner Karriere in beide Richtungen gemacht habe, kann ich mit Zuversicht sagen, dass es besser ist, den frühen Zugang zu haben. Machen Sie sich gute Notizen damit Sie später noch einmal nachsehen können, wenn die Wahrheit mutiert.)

Dieser Ansatz hat einen Vorteil, der über den bloßen Zugriff auf die Informationen hinausgeht. Sie möchten, dass sich die Entwickler daran gewöhnen, Sie bei diesen Meetings (physisch oder virtuell) zu sehen. Sie möchten, dass sie anfangen , an Sie zu denken, wenn sie mit jemandem über eine Änderung sprechen müssen. Mein Entwicklerteam behandelt mich in fast jeder Hinsicht als Mitglied des Teams (ich muss keine Fehler in der Testsuite beheben :-) ), und das ist kein Zufall. Ich habe es kultiviert.

Nach alledem kommen wir nun zu der Frage, die Sie gestellt haben: Wie erhalten Sie (a) irgendwelche und (b) bessere Antworten auf Ihre Fragen? Ich stimme anderen Ratschlägen zu, die Sie zum Versenden von E-Mails mit Ihren spezifischen Fragen/Themen und zum Planen von Besprechungen erhalten haben, aber darüber hinaus: Stellen Sie gute Fragen. Damit meine ich:

• Sei präzise. "Wie funktioniert der Server?" ist breit und vage; Der Entwickler denkt wahrscheinlich, dass Sie nach einer Klasse fragen. "Wie verarbeitet der Server zu viele eingehende Anfragen?" ist besser.

• Zeigen Sie, was Sie bereits getan haben. Können Sie diese Frage mit der Software zumindest teilweise beantworten? Dann mach das. "Ich habe versucht, eine Reihe von Anfragen so schnell wie möglich durch Browser-Tabs zu senden, aber ich konnte es nicht zum Scheitern bringen" zeigt, dass Sie versucht haben, sich selbst zu helfen. Oder wenn es etwas ist, das Sie nicht vernünftig testen können (Sie werden Zehntausende von Anfragen benötigen und Sie wissen nicht, wie Sie den Code schreiben sollen, um das zu skripten), zeigen Sie den Hintergrundaufwand auf andere Weise: „Ich habe das Design überprüft spec und ich habe den Abschnitt darüber gesehen, wie wir mit diesem Fall umgehen müssen, aber ich verstehe nicht, was Sie über Thread-Pools und Prioritätswarteschlangen gesagt haben".

• Wenn Sie immer wieder die gleichen Fragen haben, fragen Sie, wie man angelt: „Ich muss wissen, welchen Fehlercode wir zurückgeben, wenn X, und ich weiß, dass ich letzte Woche nach dem Fehlercode für Y gefragt habe. Gibt es einen Platz im Code I kann man diese nachschlagen?" Manchmal können Sie es nicht oder es ist die Mühe nicht wert oder es führt Sie in die Irre, aber zu zeigen, dass Ihr erster Instinkt "versuchen Sie es herauszufinden" ist, anstatt "den Entwickler zu fragen", bringt meiner Erfahrung nach Brownie-Punkte ein.

• Wenn Sie sie bitten, etwas zu überprüfen, (a) sagen Sie ihnen, wonach Sie suchen, und (b) zielen Sie darauf angemessen ab. Die Entwickler sind die besten Leute, um die technische Genauigkeit zu überprüfen; Sie sollten Ihr Korrekturlesen oder Ihren Marketing-Spin woanders suchen. Wenn sie frühere Entwürfe gesehen haben, heben Sie hervor, was in diesem anders ist und wie Sie auf ihre vorherigen Kommentare reagiert haben.

Schließlich, wenn Ihre Organisation Tester hat, dann haben Sie einen natürlichen Verbündeten. Sie und sie beide brauchen viele der gleichen Informationen. Versuchen Sie, sich mit ihnen zusammenzutun.

Dein erster Absatz widerspricht sich:

Ich bin Technischer Redakteur und arbeite 1 Tag pro Woche im Büro. Der Job, den ich habe, erfordert nicht viel Teamarbeit, da ich der einzige Autor bin, aber ich muss Informationen von Entwicklern einholen.

Es ist klar, dass Sie nicht völlig isoliert von anderen Menschen arbeiten können, da Sie darauf angewiesen sind, dass sie die Informationen erhalten, die Sie benötigen. Sie sagen jedoch, dass Sie für Ihre Arbeit keine Teamarbeit benötigen.

Ihr Mangel an Zeit im Büro ist wahrscheinlich ein Faktor, der dazu beiträgt, und öfter hineinzugehen, würde wahrscheinlich viele der Probleme lösen, mit denen Sie konfrontiert sind. Es scheint, als würdest du gegen "aus den Augen, aus dem Sinn" kämpfen. Mehr persönliche Interaktionen mit Ihrem Vorgesetzten, den Entwicklern und den Entwicklungsmanagern werden einen großen Beitrag zur Lösung dieses Problems leisten.

Ein weiteres Problem ist, dass die Rolle des Technischen Redakteurs missverstanden wird. Ein früherer Job war in einer Organisation mit einem kleinen Team für technische Redaktion, und viele Leute verstanden nicht wirklich, welchen Mehrwert sie brachten oder was ihre Rollen/Verantwortlichkeiten waren. Wenn Sie mit ihnen sprechen, ist dies in vielen Unternehmen ziemlich üblich, sodass Sie eine Ausbildung absolvieren müssen. Wenn Ihr Chef die Leute nicht jagen will, müssen Sie derjenige sein, der die Leute jagt. Da es Zeitverschwendung ist, Leuten ständig nachzujagen, sollten Sie mit Ihrem Chef darüber sprechen, ob Sie den Rest des Personals darüber aufklären können, was Sie in Bezug auf die Produkte oder Dienstleistungen Ihres Unternehmens tun und wie Sie in das Unternehmen passen Prozess und die Dinge, die Sie können müssen, um Ihre Arbeit rechtzeitig zu erledigen.

Sobald Sie öfter vor Menschen stehen und sie darüber aufklären, was Sie tun, werden viele der Probleme, mit denen Sie konfrontiert sind, weniger. Dass sich das Entwicklungsteam nicht um die Dokumentation kümmert, ist ein viel tieferes kulturelles Problem in diesem Team, das wahrscheinlich außerhalb Ihrer Kontrolle liegt. Extreme Krisenzeiten um Releases herum weisen auch auf andere Prozess- oder Projektprobleme hin, die wahrscheinlich auch auf höherer Ebene auftreten.

Wenn es Widerstand gegen Lösungen gibt – Sie können sich nicht weiterbilden, Sie können keine Zeit mit Menschen verbringen, um Ihre Arbeit zu erledigen, Sie können Manager nicht dazu bringen, Sie zu entsperren – das sind Anzeichen für tiefere organisatorische Probleme.

Ich hasse es, Ihnen zu sagen, dass dies kein einzigartiges Problem ist. Selbst wenn Sie der Chef von jemandem sind, kann dies passieren.

Der Vorschlag, Ihren Vorgesetzten einzubeziehen, ist eine solide Empfehlung. Zu sagen, dass Sie machtlos sind, ist jedoch ein bisschen weit hergeholt.

Sie haben mindestens zwei Werkzeuge in Ihrer Kiste.

1] Immer wenn dich jemand umhauen kann, werden sie es tun. Erinnere dich daran! Also, was machst du? Machen Sie einen Spaziergang. Wählen Sie jede Woche eine Zeit, die Ihnen am besten passt (variieren Sie den Tag und die Uhrzeit jede Woche), gehen Sie zu jedem der Entwickler und beginnen Sie, Fragen zu stellen. Seien Sie herzlich. Sag Hallo. Stelle dich vor. Erklären Sie Ihr Problem und wie sie mit einem Lächeln helfen können. Sag Danke. Seien Sie so freundlich und sanft wie möglich, aber seien Sie fest, dass Ihre Fragen beantwortet werden müssen. Wenn nicht jetzt, dann später. Machen Sie deutlich, dass Sie nicht dazu da sind, ihnen das Leben schwerer zu machen. Wenn es nach dem Mittagessen besser ist, dann ist es in Ordnung. Nach dem Mittagessen ist es soweit. Wenn sie Sie weiterhin abweisen, erklären Sie einfach, dass das Management wahrscheinlich Fragen stellen wird und dass Sie das lieber sagen würden. ist extrem hilfreich statt nicht besonders hilfreich. Zwei weitere Tricks, die helfen, sind, leise und in einem natürlichen Ton zu sprechen, damit niemand wirklich hören kann. So lernt man viel mehr. Wenn Sie mit ihnen sprechen, gehen Sie auch so tief oder tiefer als sie. Ich habe mich auf meine Fersen gehockt, um dies zu ermöglichen. Lächeln. Sei freundlich. Nach einer Weile werden Sie vielleicht überrascht sein, dass sie im Laufe der Zeit anfangen, Details per E-Mail zu versenden. Sie wissen, was für Sie und sie auf dem Spiel steht, und jetzt sind Sie ein Mitglied des Teams. Dies kann einige Wochen dauern, bis es wirklich gut funktioniert. Solange sie verstehen, dass dies kein einmaliges Verhalten ist, werden sie nachgeben. Sie wissen, was für Sie und sie auf dem Spiel steht, und jetzt sind Sie ein Mitglied des Teams. Dies kann einige Wochen dauern, bis es wirklich gut funktioniert. Solange sie verstehen, dass dies kein einmaliges Verhalten ist, werden sie nachgeben. Sie wissen, was für Sie und sie auf dem Spiel steht, und jetzt sind Sie ein Mitglied des Teams. Dies kann einige Wochen dauern, bis es wirklich gut funktioniert. Solange sie verstehen, dass dies kein einmaliges Verhalten ist, werden sie nachgeben.

2] Wenn Sie nicht in der Lage sind, herumzulaufen, dann ist ein weiteres großartiges Werkzeug die Rechenschaftspflicht. Ich hasse es, eine Nervensäge zu sein (PIA), aber manchmal ist dies Ihre einzige Option, es sollte jedoch nicht Ihre erste Option sein. Wenn Sie E-Mails schreiben, setzen Sie Ihren Chef auf CC. Bitten Sie um eine Antwort an alle. Wenn sie nicht allen antworten, leiten Sie jede Antwort an Ihren Chef mit einem CC zurück an die Person weiter. Alles für immer archivieren. So auch bei deinem Chef. Bald wird jeder anfangen zu erkennen, dass es Verantwortung gibt und dass Nichtreagieren Karriere-Selbstmord ist. Sicherlich haben Sie zumindest dokumentiert, warum Sie Schwierigkeiten haben, Ihre Arbeit zu erledigen. Das kannst du deinem Chef erklären. Erklären Sie, dass Sie Stunden in Rechnung stellen, die unproduktiv sind, und dass Sie es vorziehen, dass dies nicht der Fall wäre. Dies ist sowieso eine gute Option, sicherlich für CMMI, ISO und andere Gründe, aber ich bevorzuge Option 1 am besten.

Ich fand, dass beide Optionen gut funktionieren. Es dauert Wochen, bis alles gut funktioniert. Mit Option 1 stellen Sie sich jedoch auf einen unglaublichen Erfolg ein. Ich habe diese Technik angewendet, als ich gescheiterte Projekte für ein globales Telekommunikationsunternehmen übernahm, das das Auge des CEO/Vorsitzenden des Vorstands hatte. Je öfter ich Option 1 nutzte, desto mehr Menschen erkannten, dass ich ihnen einen Gefallen tat, und die Menge an Kooperation, die ich erhielt, war überwältigend. Tatsächlich hatte ich mehr Einfluss als ihre eigenen Chefs, die mich liebten, weil ich sie auch gut aussehen ließ, ohne dass das Management wirklich verstand, warum. Jeder gewinnt.

Sie sind ein Stakeholder im Entwicklungsprozess, und als eine Person, die Ihre eigenen Stakeholder hat, würde ich sagen, dass Sie eher ein Schwein als ein Huhn sind (jemand, der nicht nur beteiligt, sondern auch engagiert ist).

Bringen Sie sich in den Projektmanagement-/Scrum-Prozess ein. Nehmen Sie an Status-/Standup-Meetings teil und teilen Sie dem gesamten Projektteam mit, dass Ihr Beitrag blockiert wird, dass Sie die an Sie delegierte Verpflichtung bezüglich der nächsten auslieferbaren Version nicht erfüllen und akzeptiert haben. Holen Sie sich Akzeptanzkriterien (Anforderungen) und umsetzbare Aufgaben in die Hauptgeschichten, damit die „Definition of Done“ dieser Geschichte Ihren Beitrag beinhaltet.

Was dies tut, ist die Rechenschaftspflicht anderer Menschen Ihnen gegenüber und Ihre Sichtbarkeit für die anderen am Prozess Beteiligten. Einschließlich der Geschäftsinteressenten. Es gibt auch den Personen, deren Zeit und Aufmerksamkeit Sie benötigen, die Erlaubnis, es Ihnen zu geben, da es Teil der Kapazitätsplanung und der Entwicklungsschätzung ist.

E-Mail ist eine schlechte Möglichkeit, Aufgaben zu planen und nachzuverfolgen. Sie müssen das Problem Ihrem Chef mitteilen, der dann ein Treffen mit dem Chef der Entwickler vereinbaren sollte. Ziel sollte es sein, eine Definition of Done zu definierenfür Entwickler, wobei eine Aufgabe oder eine User Story nur dann als abgeschlossen markiert werden sollte, wenn auch die Dokumentationsanforderungen erfüllt sind (ähnlich Coding-Guidelines, Unit-Tests etc.). Das klingt nach einem harten Ansatz, aber oh, das nimmt alle Argumente oder Emotionen aus der Diskussion heraus. Nach mehreren Jahren des Kampfes hat sich die moderne Softwareentwicklung darauf geeinigt, dass Qualitätsschritte wie statische Codeanalyse, Komponententests usw. in den Prozess eingebaut werden sollten, anstatt sie dem Zufall zu überlassen. Die Dokumentation ist immer noch nicht vollständig da, da sie schwer zu automatisieren ist, und auch darüber, wie viel Dokumentation genug Dokumentation ist, wird noch diskutiert. Wenn Ihr Unternehmen jedoch entschieden hat, dass es eine Dokumentation geben sollte, dann sollte diese Aufgabe ebenfalls in den Prozess eingebettet werden.

Ihre Aufgabe als Technischer Redakteur sollte dann sein, über die Qualität der Dokumentation zu diskutieren und nicht ständig zu überzeugen, ob sie überhaupt dokumentieren würden

Schüchterne E-Mails erhalten schüchterne Antworten, durchsetzungsfähige E-Mails erhalten durchsetzungsfähige Antworten.

Wie andere gesagt haben, ist es am besten, dies nach Möglichkeit über die Managementkette zu eskalieren. Wenn sich das Unternehmen bewusst dafür entschieden hat, nicht genügend Ressourcen für die Dokumentation bereitzustellen, sollten Sie dies bei der Überprüfung nach dem Versand ansprechen. Aber die Frage scheint nach einer Problemumgehung zu suchen, wenn das Management ein Problem nicht kommen sah, bis es zu überlastet war, um zu reagieren.

Andere Leute haben die Schritte beschrieben, die notwendig sind, um Leute davon zu überzeugen, dass Sie sich auskennen. Wenn Sie das alles getan haben und immer noch keine Antwort erhalten, versuchen Sie, eine Antwort zu erfinden, die plausibel erscheint, und senden Sie sie dann per E-Mail an die Entwickler und sagen Sie: „Ich denke, das ist richtig. Bitte bestätigen Sie bis zum <Datum>, wann Ich werde es der offiziellen Dokumentation hinzufügen" .

Wenn Ihre Kommunikation Ihre klaren Gedanken und Ihren Respekt für Ihre Kollegen deutlich zeigt, werden sie eine schnelle mentale Berechnung anstellen: Wenn ich nicht antworte, ist diese Person wahrscheinlich artikuliert genug, um es mir anzuhängen; Wenn ich antworte, verdiene ich mir den Respekt, den sie mir entgegenbringen .

Natürlich hat dieser Ansatz seine Risiken, aber wenn Sie die richtige Lösung (Eskalation durch das Management) ausgeschlossen haben, könnten Sie auf diese Wette setzen.

Kurze Antwort, ich würde sagen, Sie können die Leute nicht dazu bringen, auf Ihre E-Mails zu antworten ...

... und lange Antwort, ich persönlich würde sagen, die Art und Weise, wie ich bei Problemen angesprochen werden möchte, ist, um Hilfe gebeten zu werden ...

... also würde ich für eine längere Antwort sagen, dass Sie die Leute nicht dazu bringen können, zu antworten, aber Sie können Ihre E-Mails "response-attraktiver" machen.

Das heißt, aus der Perspektive des gefragten Entwicklers wäre ich eher bereit zu helfen, wenn ich nur zum Korrekturlesen aufgefordert würde, anstatt zur Bereitstellung aufgefordert zu werden.

Wenn ich gebeten werde, Korrektur zu lesen, brauchen Sie meine persönliche Expertise und Erfahrung.

Wenn ich darum gebeten werde, könnte ich fast das Gefühl haben, Sie hätten die Antwort selbst recherchieren können.

Wie man so schön sagt, fängt man mit Honig mehr Fliegen als mit Essig.

Gleichzeitig würde ich nicht auf den Entwickler warten, wenn meine Deadline droht.

Ich würde meine Arbeit weiterhin rechtzeitig meinem Vorgesetzten mit einer Liste von Unterlagen vorlegen, die möglicherweise noch überprüft werden müssen (vielleicht auch hinzufügen, wann der Entwickler und ich das letzte Mal für jeden Punkt auf der Liste gesprochen haben).

Auf diese Weise würde ich immer noch alle meine Grundlagen abdecken und gleichzeitig neue Dinge lernen, die mir in meinem Beruf helfen würden.

Aber vielleicht hast du es ja schon so gemacht.

In diesem Fall tut es mir leid, dass Sie sich in einer solchen Zwickmühle befinden, aber seien Sie versichert, dass Sie bereits proaktiv sind und Ihren Job machen.

Eine Sache, die ich tue, um sicherzustellen, dass E-Mails beantwortet werden, ist, einer Person nach der anderen eine E-Mail zu senden. Ich habe immer wieder gesehen, dass E-Mails an eine Gruppe von Leuten auf der Strecke bleiben, weil niemand unbedingt verantwortlich ist. Wenn also jemand aus dem Entwicklerteam helfen kann, wählen Sie einen aus und senden Sie ihm eine spezielle E-Mail.

Wenn Sie keine Antwort erhalten, senden Sie ihrem Vorgesetzten eine E-Mail wie „Hey, ich habe Steve eine E-Mail geschickt, in der ich um diese Informationen gebeten habe. Ich brauche diese bis zum Ende des Tages, habe aber noch keine Antwort, können Sie dafür sorgen, dass ich sie erhalte? "

Jetzt haben Sie Steve und seinen Manager zur Rechenschaft gezogen.

Wenn Sie immer noch keine Antworten erhalten, gehen Sie eine Ebene höher zum Vorgesetzten dieses Managers und bitten Sie auf die gleiche Weise um Hilfe, bis jemand etwas unternimmt.

Zeigen Sie bei Bedarf Papierspuren an.

Erstens werden Sie derjenige sein, der Leute verfolgt, weil sich niemand sonst mit dieser Aufgabe befassen möchte.

Zweitens sprechen Sie das Problem mit Ihrem Chef an. Auch hier werden Sie die Arbeit erledigen, aber sie hat vielleicht einige Strategien. Irgendwann kommst du an einen Punkt, an dem du nicht rechtzeitig bekommst, was du brauchst, also was tust du dagegen? Wie viel Zeit ist für Sie angemessen, um zu sagen: "Wenn ich etwas nicht habe, brauche ich 'x' Zeit, bevor es fällig ist, wie können wir es neu planen/priorisieren?" Entschuldigung, aber diejenigen, die Entscheidungen treffen, müssen mit dem Problem konfrontiert werden. Konzentrieren Sie sich auf die Tatsache, dass Sie Dinge pünktlich erledigen möchten, aber nicht die Befugnis haben, jeden zur Rechenschaft zu ziehen, damit Sie die benötigten Informationen erhalten. Dokumentieren Sie alle Anfragen und Lieferungen.

Darüber hinaus habe ich es oft sehr eilig, die Dokumentation fertig zu stellen, also ist das ein großes Problem

Die Tatsache, dass du „gehetzt“ wirst, ist kein Problem, du wirst viel Sympathie von jedem bekommen. Sie müssen Ihren Chef dazu bringen, sich zu einem Fälligkeitsdatum/einer Fälligkeitszeit zu verpflichten, wenn Sie bis zu diesem Zeitpunkt nicht das bekommen, was Sie brauchen, es nicht rechtzeitig erledigt wird.

Das Schlechte an Ihrem Unternehmen ist, wenn verschiedene Teams/Abteilungen isoliert bewertet werden. Programmierer kommen damit davon, nicht bei der Dokumentation zu helfen. Um ihnen gegenüber fair zu sein, wenn sie nur für ihren Code verantwortlich sind, wird dieser immer Vorrang vor allem anderen haben. Wenn die Dokumentation wichtig ist (dh Ihr Unternehmen verdient damit direkt oder indirekt Geld), sollten alle Verantwortlichen entlang der gesamten Kette von Ereignissen, die dies erledigen, die Verantwortung und die Belohnungen teilen. Sie und die Entwickler sollten gewissermaßen im selben Team sein, wenn es um Dokumentation geht. Wenn die Entwickler Ihnen rechtzeitig Informationen zukommen lassen und Sie nicht liefern, geht das auf Ihre Entschädigung und umgekehrt. Es kann kein Szenario geben, in dem eine Seite die andere hemmt, ohne die Konsequenzen zu tragen.

Unabhängig davon, welchen Wert die ermittelte Dokumentation dem Unternehmen bringt, jeder sollte die Früchte ernten, wenn sie fertig ist, und diejenigen leiden, die nicht ihren Teil dazu beitragen. Unternehmen tun dies leider nicht. Das Herausfinden einer solchen Struktur sollte das sein, wofür Manager da sind. Was machen sie sonst, um Geld für das Unternehmen zu verdienen?