Bei unserer Suche nach einer SE/BIM-Lösung ohne E-Mail tun wir uns schwer damit, Kommunikations-„Begriffe“ auf ihre Essenz zu reduzieren. Im PM-Jargon neigen wir dazu, viele Begriffe zu verwenden, wie z. Entscheidung - Maßnahme - Aufgabe - Hinweis - Frage - Änderungswunsch - Änderungsauftrag - Problem - Bemerkung - Kommentar - Genehmigung - Annahme - Punkt - …
Was ist der Mindestsatz an „Bedingungen“, um alle Arten von Kommunikation zu verwalten? Es geht um mehr als nur um Semantik.
Stellen Sie sich vor, Sie möchten eine Datenbankanwendung einrichten, um E-Mail für alle Kommunikationsanforderungen in einem Projekt vollständig zu ersetzen. Sie muss rollenbasiert, nachvollziehbar und wasserdicht sein.
Wofür verwenden wir E-Mail in Projekten? Informieren, hinterfragen, eine Aufgabe erteilen, eine Entscheidung umsetzen, ein Problem melden, eine Änderung anfordern oder anordnen, Feedback geben, ... usw. usw. Wie könnten wir dies auf ein Minimum reduzieren? von 'Arten der Kommunikation' - mangels eines besseren Ausdrucks - um einen datenbankbasierten E-Mail-Ersatz aufzubauen? Mit dem offensichtlichen Vorteil, dass die gesamte Kommunikation immer explizit, strukturiert, zusammenhängend, protokolliert, nachvollziehbar ist, ... anstatt mein Posteingang, der ein Schwarzes Loch ist?
Zum Beispiel:
Eine Notiz (oder Bemerkung oder Kommentar) ist eine Nachricht (eine Information) von einem Sender (einer Person/Rolle oder einem „Meeting“) an einen Empfänger (eine oder mehrere Person(en)/Rolle(n) oder a Treffen). Eine Antwort ist nicht erforderlich. Die einzigen erforderlichen Datenfelder sind also: Nachricht (= die Notiz) - Sender - Empfänger.
Eine Frage (oder Informationsanfrage oder Problem??) ist eine Nachricht von einem Sender an einen Empfänger (gleiche Definitionen wie oben). Es erfordert eine Antwort bis zu einer bestimmten Zeit. Die erforderlichen Datenfelder lauten nun also: Nachricht (= die Frage) - Absender - Empfänger - Fälligkeitsdatum. Die Antwort wird mit dieser Frage verknüpft, damit sie nachvollziehbar ist.
Eine Entscheidung ist eine Nachricht (eine Information) von einem Sender an einen Empfänger (gleiche Definitionen wie oben). Es erfordert keine Reaktion als solche, sollte aber zur Mutation einer Anforderung führen (Löschen, Ändern oder Erstellen). Wenn nicht, ist es nur eine Notiz. Die erforderlichen Datenfelder sind nun also: Nachricht (= die Entscheidung) - Sender - Empfänger - betroffene Anforderung(en). Die Entscheidung bleibt mit der betroffenen Entscheidung verknüpft, sodass sie rückverfolgbar ist.
usw ...
Meine Frage ist nun: Wie viele „Begriffe“ sind erforderlich, um alle Arten von „Informationsaustausch“ in einem rollenbasierten PM-System abzudecken, wenn das Ziel darin besteht, die Verwendung von E-Mail obsolet zu machen? Und was ist das kleinste Set, um es so einfach wie möglich zu halten?
Existiert eine Art „Informationsaustauschmodell“ (dh Kommunikationsmodell)?
Ich werde versuchen, Ihre Frage zu beantworten, bin mir aber nicht sicher, ob das wirklich möglich ist.
Nehmen wir an, es gibt 5 diskrete Nachrichten, die man an einen anderen senden kann.
*Innerhalb von 30 Sekunden nach dem Posten wird jemand sagen: "Was ist mit x?" und sie werden recht haben. Um eine kleine Liste zu erstellen, müssen Sie grobe Verallgemeinerungen vornehmen.
An diesem Punkt würde ein BA oder PM fragen, was ist wirklich das Problem, das Sie zu lösen versuchen? Es hört sich so an, als ob E-Mail für Sie einfach nicht funktioniert und Sie etwas Besseres erstellen möchten. Dann würden wir schauen und sehen, wie viel es kosten würde und welche Vorteile es für die Organisation hätte.
Eines der ersten Dinge, die ich mein Tech-Team fragen würde, ist: „Gibt es bereits Tools, die für weniger zu haben sind, als es für den Bau erforderlich wäre?“ Vielleicht, vielleicht auch nicht, aber es lohnt sich immer zu suchen. (Außerdem wird dieses Produkt ein Teil Ihres Kerngeschäfts sein? Siehe Joels Einstellung )
In diesem speziellen Fall gibt es viele verschiedene Tools, mit denen dieses Problem gelöst werden kann, wenn auch nicht ganz so, wie Sie es erwähnen. Vielleicht würde Schlaff ausreichen, oder vielleicht Asana.
Ich verstehe Ihre Ziele wie folgt:
Angenommen, das stimmt, hier meine Gedanken:
Dies wurde von einer ganzen Reihe von Leuten versucht und teilweise gelöst. Wie wäre es, wenn Sie sich verschiedene Tools für Zusammenarbeit und Kommunikation am Arbeitsplatz ansehen, um zu sehen, für was sie sich in Bezug auf Objekte und Workflows entschieden haben? Dies könnte ein Anfang sein: http://alternativeto.net/software/jira/
Ich kenne Ihre Organisation nicht und weiß nicht, worum es bei diesem Unterfangen geht, aber Ihr Ansatz klingt etwas zu theoretisch. Ich bezweifle, dass dies effizient sein wird und dass Sie zu einer endgültigen Einigung gelangen werden, der sich alle anschließen können und die nicht sehr komplex ist. Das heißt, Sie werden haben
Ohne Wissen über Ihre Organisation werden Ihnen die Menschen nur inspirierende, aber nicht unbedingt punktgenaue Antworten geben können. Wenn Sie versuchen, eine Lösung für Ihre Organisation zu entwickeln, wäre diese auf Ihre Bedürfnisse zugeschnitten und sollte daher von den Prozessen abgeleitet werden, die Ihre Organisation derzeit verwendet (und idealerweise von denen, die Sie in Zukunft einsetzen werden). Entweder können diese Anforderungen also nur von Personen in der Organisation verstanden werden. Oder Sie erhalten Input zu eher generischen Konzepten, die dann aller Wahrscheinlichkeit nach bereits in irgendeiner OTS-Lösung vorhanden sein werden (dh ein gemeinsamer Nenner von PM-Tooling, wenn Sie so wollen).
Ihr bester Ansatz könnte sein, eine Lösung zu verwenden, die
Es gibt mehrere Kommunikationsmodelle. Der sicherste Weg, eine Umgebung ohne E-Mail zu schaffen und ihre Auswirkungen zu verstehen, besteht jedoch darin, E-Mails für die Projektkommunikation zu unterbinden.
Aus verschiedenen Gründen, einschließlich der Kommunikation ... bauen Sie Ihren Projektworkflow um Git oder ein DEZENTRALES Versionskontrollsystem auf.
Sie müssen damit rechnen, dass Menschen an verschiedenen Orten arbeiten, auf Flughäfen, zu Hause, in Parks oder Cafés und gelegentlich an ihren Schreibtischen. Wenn Sie Versionskontroll-Repositories nicht dezentralisieren, wird das Versionskontrollsystem nicht verwendet und die Leute werden eine erstaunliche Vielfalt von Sneakernet- und Ad-hoc-Dateispeicher- und Backup-Alternativen anpassen.
Ich würde dringend raten, dass jeder [der es ernst meint mit Kommunikation] sich den Github-zentrierten Workflow genau ansieht … wegen des vollständigen Github-Codegraphs und all der Möglichkeiten, den Fortschritt allen Teilnehmern von Natur aus mitzuteilen, indem Commits, Pulls, Issues, Kommentare, etc ... UND, was vielleicht noch wichtiger ist, damit Sie auf Meetings verzichten können [wo sowieso nie wirklich kommuniziert wird] und auf den Repository-zentrierten Chat, zB Gitter, zurückgreifen können.
Ein zusätzlicher Bonus für alle, die den Schmerz ertragen müssen, Git zu lernen und zu einem Git-basierten Workflow-Modell zu wechseln, besteht darin, dass Ihre Fähigkeiten, die innerhalb dieses mentalen Rahmens arbeiten, übertragbar sind und unternehmensübergreifend funktionieren.
Git ist Open Source und das ist EXTREM wichtig, weil es erklärt, warum Git und seine Varianten den Kampf im wichtigen Bereich der Versionskontrolle gewonnen haben . Jeder, der Versionskontrolle nutzt, wird die nächsten 25 Jahre oder länger einen Git-Dialekt verwenden ... ein Git-basierter PM-[Kommunikations]-Workflow wird alle anderen proprietären Ansätze übertrumpfen. Wenn es eine bessere Idee gibt, kommt sie von einer Erweiterung oder einem Fork von Git.
Todd A. Jacobs
Johann Küppens
Todd A. Jacobs
MCW