[Ag Meinungsfindungstool] Pad 8 bitte !

[allusion AT gmx.de]

Liebe AG-Mitglieder,

ich bin sicher jünger als der Durchschnitt hier, aber es gibt eine Sache, die ich gelernt habe und die bisher immer funktioniert hat : Wenn Du Dich verirrt hast, gehe dahin zurück, wo das letzte Mal noch alles okay war. 
Es mag ein subjektiver Eindruck sein, aber ich hatte das Gefühl, daß sehr viele Leute hier eine große Zufriedenheit mit dem Pad 8 hatten. Die dort dargestellte Agenda entspricht der klassischen Herangehensweise in der Softwaretechnik und beim Projektmanagement. Da sich das schon tausendfach bei erfolgreichen Projekten bewährt hat, schlage ich vor, daß wir dieses "Tool" als Grundlage nehmen und uns damit zum Ziel hangeln. 

Auch ich finde die Diskussion über Begriffe nicht hilfreich. Es nützt nichts, neue Begriffe zu erfinden, wenn man als Neueinsteiger vor der Beteiligung an der Debatte erstmal eine andere Sprache büffeln muß, als die bisher erlernte. Das heißt, daß Fachleute ihre Fachbegriffe im oder unter dem Text direkt in Alltagssprache erklären sollten. Man kann sich ja ein kleines Alltagssprach-Lexikon anlegen, aus dem man dann die Erklärungen in die entsprechenden Emails kopiert. (z.B. als Fußnote oder als Link). Falls es mal jemand vergißt, reißt demjenigen bitte nicht gleich den Kopf ab, sondern fragt höflich nach.

Da wir im Moment eine Menge Koordinierungsbedarf haben, halte ich 1-2 an festen Terminen regelmäßig wöchentlich stattfindende Mumble-Runden für sinnvoll. Dort geht die Kommunikation wesentlich schneller, man produziert nicht Fluten von Emails und man mißversteht sich weniger oft, weil man in der Stimme die aktuellen Emotionen des Gegenübers besser einschätzen und dadurch frühzeitig deeskalieren kann. Ich empfand jedenfalls die Mumble-Runde vor 2-3 Wochen als sehr angenehm und stelle fest, daß dort wesentlich konstruktiver gearbeitet wurde, als im Email-Verteiler oder auf den Pads.

Darüber hinaus favorisiere ich folgendes Vorgehen : 
1.) Wir sammeln Arbeitspakete für den ersten Schritt (beispielsweise die Suche nach den Problemen, die zur Toolsuche bzw. zum Ziel eines neuen Tools geführt haben). Als einer von mehreren möglichen Denkanstößen dafür könnte das erste Dokument auf meiner Webseite dienen : tinyurl.com/derthomaspad (nur als Vorschlag für ein unterstützendes Skelett)
2.) Wenn wir dann eine Gliederung von möglichen Quellen von Problemen haben (z.B. Benutzerschnittstelle, Übertragung, Bündelung von Information, menschliche Eigenschaften, etc.), können wir die Arbeit in kleinere Teams aufteilen, die dann erstmal für das Unterthema ins Detail gehen einen oder mehrere Entwürfe erarbeiten (konkrete detaillierte Probleme ausarbeiten mit Beispielen).
3.) Diese Entwürfe werden nach Fertigstellung durch die restlichen Leute ergänzt und diskutiert. Das hat den Vorteil, daß die kleineren Teams schneller vorankommen, daß wir einen hohen Parallelitätsgrad haben und daß nur noch das in den Entwürfen fehlende kommuniziert werden muß. Dafür sind die Pads dann sinnvoll. Ggf. können wir für die Diskussion auch schon eines der bereits gefundenen Tools einsetzen. 
4.) Das gleiche machen wir für die anderen Schritte in Pad 8.

Zum Konflikt "Toolsuche - Toolimplementierung" : Wenn sich die Rheinlandpfälzer dazu durchringen können, die ersten Schritte gemeinsam mit dem Rest zu gehen, dann wäre das eine Win-Win-Situation für beide Seiten :
1.) Die Soll-Eigenschaften und Anforderungen müssen sowohl für die Tool-Suche, als auch für die Tool-Entwicklung gesammelt werden. Ansonsten hat man kein konkretes Ziel vor Augen und verliert sich irgendwann im Dschungel.
2.) (nach der Anforderungsformulierung) Während die Rheinlandpfälzer und Interessierte dann nach weiteren Tools im Internet suchen und diese in einer Tabelle übersichtlich dokumentieren und charakterisieren, entwerfen die "Entwickler" schon mal eine Architektur für das Wunsch-Tool. Bevor dann die konkrete Programmierung losgeht, können die Entwickler von den aus RLP herausgesuchten Tools profitieren, denn wenn wir zu Potte kommen wollen, können wir nicht alles von Null anfangen, sondern müssen sehen, ob wir für das neue Tool OpenSource-Code oder -Konzepte recyclen können.
3.) Sollte am Ende ein neues Tool herauskommen, ist das natürlich auch für die AG aus RLP wieder ein Gewinn. 

Bitte denkt mal drüber nach und laß uns im Doodle 1-2 feste Mumble-Termine pro Woche finden, wo bei wöchentlicher Wiederholung möglichst viele dabei sein können. Dann brauchen wir nicht jede Woche ein neues Doodle für das Mumblen ausfüllen.

Schöne Grüße, Bye Thomas

--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de