Guter Thread.
Also ich nenne es lieber Kontrolle o.ä., damit wir nicht Wörter benutzen, die dasselbe Prinzip in sich tragen, aber schöner klingen. Aber ich glaube, das ist ja auch gar nicht das Problem. Und ob Inklusion zu Bespitzelung und Überwachung führt… weiß ich nicht. Kommt wohl einfach auf die Form der Inklusion an. Wichtig wäre an der Stelle herauszustellen, ob unsere Form diese Folgen haben könnte und wie wir sie vermeiden können. Die Bespitzelung, nicht unbedingt die Kontrolle an sich.
Ich finde es wichtig, erst einmal zu diskutieren, was es zu kontrollieren gibt, bevor wir darüber reden, wie wir dem begegnen können. Was ich gerade sehe sind folgende Punkte:
- Nutzung privater sowie zum Zweck der Bedürfnisbefriedigung gesetzten Mittel für Commoning
Das finde ich sehr wichtig. Wenn Leute ihr privates Eigentum zur Verfügung stellen, muss auch sichergestellt werden, dass sie für die angegeben Prozesse und nicht etwa kommerziell verwendet werden. Dasselbe gilt für Mittel/Dinge die dem Zweck der Bedürfnisbefriedigung untergeordnet sind (also kein privates Eigentum sind). Wir wissen nicht, wie diese Dinge zur Verfügung stehen. Vielleicht gibt es Leute, wie im Projekt Teilbar, die sich um die Ausgabe und Annahme kümmern. Vielleicht können Leute mit dem Code eines Zahlenschlosses oder einer Chipkarte, wie es bei Teilauto der Fall ist, auf diese Dinge zugreifen. Wissen wir nicht. Aber wieder: Wesentliche Aufgabe der Software ist die transparente Zwecksetzung von Mitteln, um diese auch diskutierbar zu machen. Daher finde ich es auch wichtig, dass die Verwendung auf eine Weise kontrolliert werden kann.
Die Resultate der einzelnen Tätigkeiten im Kooperationsprozess müssen eine bestimmte Qualität haben, damit das Bedürfnis am Ende befriedigt werden kann. Bewertet werden kann dabei einerseits, inwiefern das Tätigkeitsmuster dazu geeignet ist, den jeweiligen Bedarf zu decken/das jeweilige Bedürfnis befrieden, aber anderseits inwiefern die ausführende Person geeignet war, sich dem Tätigkeitsmuster anzunehmen. Beziehungsweise: Ob sie sich mit der nötigen Aufmerksam der Tätigkeit angenommen hat etc.
Die einfache Antwort wäre: Diejenigen, welche das Resultat erhalten, bewerten seine Qualität. Allerdings kann das auch außerhalb der Kompetenz dieser Person liegen. Wenn jemand einen … Traktor zur Ernte benötigt, weiß die Person nicht unbedingt, ob der Traktor dem Design und verwendeten Materialien her lange halten wird. Oder welche Schadstoffwerte er hat. Vielleicht merkt er noch nicht einmal, wenn ein Teil daran fehlt oder etwa billigere Bauteile verwendet wurden, als eigentlich angegeben. Also: Er/Sie kann vielleicht weder das Muster richtig bewerten, noch kann er/sie die Tätigkeit der konkreten Person wirklich bewerten.
Ein weiteres Problem (und ich will das hier wirklich so klar benennen): Nachsichtigkeit. Wir bewegen uns in einer Struktur, in der es keine Vorgesetzen oder Vorarbeiterinnen gibt. Das ist sehr sehr gut, aber das bedeutet auch, dass ich Personen bewerten muss, die mir auf Augenhöhe begegnen und etwas für mich getan haben. Und denen ich meistens wohl nichts böses will, aber vielleicht merke ich auch (mit der Zeit), dass ihre Leistung nicht ausreichend ist, um die jeweilige Tätigkeit zu erfüllen. Eine konrollierende Instanz kann hier wirklich entlastend wirken.
- Richtigkeit bei Angaben im Tätigkeitsmuster
Hauptsächlich betrifft das natürlich die Aufwandsfrage: Wird sie gewissenhaft beantwortet oder der eigene Vorteil darin gesehen, wenn der Aufwand möglichst hoch angegeben wurde. Ist ein Tätigkeitsmuster vielleicht nur erstellt worden, um Trava auszutauschen (@fkleedorfer hat das in der Telefonkonferenz vom 26.3 angebracht) oder ist es auf andere Weise absichtlich auf eine „das System manipulierende Weise“ angelegt worden?
Dann natürlich: Ist der Prozess so beschrieben worden, dass er auch wirklich ohne Vorerfahrung (aber mit den notwendigen Qualifikationen) angegangen werden kann? Ist der Bedarf vollständig angegeben? Ich sage jetzt nicht, dass die Antwort auf die letzteren Fragen unbedingt schwierig ausfallen muss - nur, dass eine Kontrolle im sehr allgemeinen Sinn hier notwendig sein kann.
- Richtigkeit der Angaben von integrierten Zusammenschlüssen
Das ist so ein bisschen die Königsdisziplin, meiner Meinung nach. Und echt richtig richtig richtig hart, da was sinnvolles herauszustellen. Die Integration von Zusammenschlüssen ist noch kein Thema in der Textreihe und ein Grund, warum ich die Trava eben jetzt - im vierten Teil - besprechen wollte, war, dass eben die Aufwandsbestimmung von Tätigkeitsmustern und auch die Aufwandsbestimmung der Tätigkeiten von integrierten Zusammenschlüssen im Konfigurationsprozess eine wesentliche Rolle spielen und besonders letzteres unendlich schwierig ist.
(Integrierte Zusammenschlüsse? What? -> Timeless Way: Alexander 485 - Holzkamp 80b)
Wo liegt das Problem? Zusammenschlüsse, welche sich in die Softwarestruktur integrieren, müssen sich nicht nach Tätigkeitsmustern richten. Sie geben nur an, was sie bereitsstellen können/werden und was sie dafür brauchen. Mehr darf da meiner Meinung nach auch nicht sein. Damit der Konfigurationsprozess funktioniert, müssen sie den Aufwand angeben, der mit der Verfügbarmachung des jeweiligen Resultates zusammenhängt. Hier gilt das gleiche wie im Tätigkeitsmuster: Je höher der Aufwand, desto größer der eigene individuelle Vorteil im Trava-Prinzip. Aber eben auch: Je höher der Aufwand angegeben wird, desto später wird der Zusammenschluss im Konfigurationsprozess angesprochen (kurz dazu: Tätigkeitsmuster werden zur Selbstzuordnung freigegeben, Zusammenschlüsse werden natürlich nicht freigegeben, sondern angesprochen/angefragt/die direkte Möglichkeit zur eigenen Zuordnung gegeben/o.ä.). Frage: Gibt es Fälle, in denen die Angabe des Aufwandes kontrolliert werden muss? Vielleicht etwa, wenn das Resultat in der lokalen Umgebung nicht durch Selbstzuordnung gedeckt werden kann und damit eine gewisse Abhängigkeit von diesem Zusammenschluss entsteht.
Bedarf: Selbes Thema. Ein Zusammenschluss kann als Bedarf angeben, was er möchte. An sich lässt sich sagen: Je mehr Bedarf angegeben wird, desto höher eben die Prozessqualität (Aufwand + spekulativer Aufwand zur Bedarfsdeckung), desto später die Ansprache im Konfigurationsprozess. Allerdings: Die Prozessqualität umfasst nur die Mittel, die lokal nicht verfügbar sind. An sich könnte jeder Zusammschlüsse irgendwelche Bedarfe angeben, die lokal verfügbar sind und sich diese damit aneignen und zum Beispiel weiterverkaufen. In der Softwarestruktur ist nicht einsichtig, was „in einem solchen Zusammenschluss“ vor sich geht, wie also aus dem Bedarf das Resultat wird (im Gegensatz zum Tätigkeitsmuster, das diesen Prozess transparent macht). Allein schon um Misstrauen vorzubeugen, sehe ich die Notwendigkeit von Kontrollmechanismen irgendeiner Form.
Ich hab bestimmt was vergessen. Bevor wir uns mit der Problemlösung beschäftigen, würde ich gerne die Liste vervollständigen bzw. feststellen, ob wir uns darauf einigen können, dass bei den bisher angegeben Problemen eine Kontrolle, in welcher Weise auch immer, notwendig ist bzw. notwendig sein kann.
Seht ihr (Interessenten an der Diskussion, nicht alle natürlich) noch Ergänzungen oder gibt es etwas, dem ihr soweit widersprechen würdet?