Was Digitalisierung ausmacht und wo sie letztendlich herkommt, darüber hat Jörg Friedrich, Philosoph und Mitbegründer der INDAL GmbH & Co. KG, einen Aufsatz geschrieben, der in der letzten Ausgabe der Zeitschrift für Kulturphilosophie veröffentlicht wurde. Eine Vorversion des Manuskripts können Sie hier herunterladen.

Der Beitrag Die Herkunft der digitalen Welt erschien zuerst auf INDAL Software-Spezialist.

Vielfältige Möglichkeiten für Crowdwork

Einsetzbar ist Crowdworking überall, wo die Arbeitsaufgabe klar beschreibbar und einzeln ausführbar ist und das Ergebnis digital bereitgestellt werden kann. Im besten Fall wird die Arbeit direkt in der Plattform getan. Damit sich die Sache lohnt, muss es natürlich eine Vielzahl gleicher Arbeitsaufgaben geben, sodass viele Crowdworker (eben die “Crowd” – der “Schwarm”) angesprochen werden können, oder ein jeder relativ viele, gleichartige Aufgaben lösen kann.
Die Crowd wird nicht nur im kommerziellen Bereich tätig – unter dem schönen Titel Citizen Science spannen auch die Wissenschaften inzwischen viele Laien für Hilfsarbeiten ein, Tätigkeiten, die den Computern immer noch schwer fallen, die aber Menschen dank ihrer intuitiven Intelligenz ohne weiteres bewerkstelligen können. dazu gehört etwa das Durchsuchen von hochauflösenden Himmelsaufnahmen nach Galaxien und deren Klassifikation.
Amazon selbst hat die Crowdwokring-Plattform dazu gegründet, um CD-Cover nach unanständigen Motiven zu durchsuchen, damit uns auf der Verkaufsplattform nicht plötzlich eine barbusige Dame engegenprangt.

Die Gewerkschaften erwachen

Nun sind in den letzten Monaten auch die Gewerkschaften und die SPD auf den neuen Trend aufmerksam geworden, und wollen sich der Sache natürlich annehmen. Sie wittern Ausbeutung und wollen Crowdworking kontrollieren und regulieren. Das wird sicherlich eine schwierige Angelegenheit, aber wer weiß, wenn man das Thema erst mal auf europäischer Ebene angeht, wird man die Gesetze und Vorschriften sicher so formuliert bekommen, dass es den Unternehmen schwer gemacht wird, die flexiblen Ressourcen der Crowd gescheit zu nutzen.

Was sagt die Forschung zum Crowdworking?

Dabei hat die ökonomische Forschung bereits gezeigt, dass sich Crowd-Working mit den Mitteln der Marktwirtschaft ganz wunderbar selbst regulieren kann – und das tut keinem weh. Drei aktuelle Forschungsarbeiten sind dabei interessant. Lasecki et. al (2014) haben festgestellt, dass Crowdworking-Projekte vor allem zwei Gefahren ausgesetzt sind: der Manipulation der Ergebnisse durch die Crowd-Worker und der Informationsabfluss. Interessant ist, dass unzufriedene Crowd-Arbeiter sich sehr leicht dazu bringen lassen, sich an Sabotage-Aktionen gegenüber dem Arbeitgeber zu beteiligen. Man darf nicht vergessen, dass es für die Crowd-Arbeiter sehr einfach ist, sich zu vernetzen. Ein paar Klicks und eine Google-Suche weiter finden sie die potenziellen Kollaborateure.
Deshalb verweisen Dow et al. (2012) auch schon darauf, dass es gut ist, den Schwarm zu hüten, und dass es sich auszahlt, die Crowdworker individuell und gut zu behandeln, ernst zu nehmen und an den Arbeitgeber zu binden. Schon deshalb werden sich reine Ausbeuter-Modelle nicht durchsetzen. Das beweist auch, dass Citicen Science Projekte im allgemeinen bessere Qualität liefern als bezahlte Arbeit, obwohl die Hobby-Wissenschaftler ihren Anteil kostenlos erbringen – sie sind aber davon überzeugt, dass sie an einer großen, guten und wichtigen Sache mitarbeiten.

Welche Möglichkeiten eröffnen sich

Man sollte also eher die Chancen sehen, gerade, wenn man die Interessen der Arbeitnehmer vertreten will. Crowdworking schafft Möglichkeiten für erfüllte bezahlte Arbeit auch für Menschen, die aus verschiedenen Gründen ans Haus gebunden sind.
Unternehmen sollten sich fragen, welche Arbeiten sie in die Crowd auslagern können, wie da die Qualität sicher gestellt werden kann und wie die Arbeit strukturiert werden muss. Nicht immer ist das mit einer Standard-Plattform möglich, etwa, wenn Arbeitspakete voneinander abhängen oder wenn Tests und Qualitätssicherung der Arbeit hohe Priorität hat. Auch das kann die Crowd leisten. In einer Konzeptionsphase kann man überlegen, ob eine Standard-Software geeignet ist oder ob man besser eine individuelle Webanwendung erstellen sollte. Wenn Sie Interesse an den Möglichkeiten einer Crowdworking-Lösung haben, sprechen Sie uns an.

Lasecki, W. S., Teevan, J., & Kamar, E. (2014). Information extraction and manipulation threats in crowd-powered systems Proceedings of the 17th ACM conference on Computer supported cooperative work & social computing DOI: 10.1145/2531602.2531733
Dow, S., Kulkarni, A., Klemmer, S., & Hartmann, B. (2012). Shepherding the crowd yields better work Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work DOI: 10.1145/2145204.2145355

Der Beitrag Crowdworking – Zukunft der Arbeit? erschien zuerst auf INDAL Software-Spezialist.

In Communities wird geteilt

Communities werden dazu gebildet, etwas zu teilen: Ein Interesse, Wissen, Erfahrungen. Diese Communities sind somit für den Alltag unterstützend, ohne direkt in die tägliche Arbeit einzugreifen. Allerdings wissen gerade Entwickler, welche große Rolle sie heute beim schnellen Finden von Problemlösungen spielen können. Für Organisationen kann es deshalb ein Produktivitätsgewinn sein, den Mitarbeitern die Möglichkeit der Teilnahme an Communities zu geben. Andererseits befürchten manche Unternehmen zu recht, dass Know How abfließen könnte, welches einen Wettbewerbsvorteil darstellt. (Dieses Thema werde ich demnächst bei der Diskussion eines weiteren Papers aus diesem Umfeld aufgreifen).

Eine Ausnahme bilden Communities of Practice, darunter werden diejenigen Strukturen verstanden, die gemeinsam an offenen Systemen arbeiten, etwa an Open Source Projekten.

Allen Communities gemeinsam ist, dass die Mitglieder recht einfach und ohne Zutrittsregeln Mitglied werden können, und dass sie die Community genauso einfach wieder verlassen können. Entscheidungsprozesse sind in einer Community, wenn überhaupt, nur durch die Ausbildung einer impliziten Kultur möglich.

Netzwerke nutzen Technik

Das wichtigste Merkmal eines Netzwerkes ist die Sicherstellung einer gegenseitigen Erreichbarkeit. Tamburri verweist deshalb darauf, dass Netzwerke zumeist an Technologien (E-Mail, Soziale Medien, Kollaborationsplattformen) gebunden sind. Netzwerke bilden letztlich die Infrastruktur für andere kollektive Strukturen. Andererseits, und das ist für die Frage der kollektiven Entscheidungsfindung bedeutsam, erlauben Netzwerke, vorgegebene und definierte Entscheidungswege zu umgehen, Entscheidungsmechanismen, die unserer eigenen Forschung nach die Rationalität der Organisation ausmachen, können durch Netzwerke ausgehebelt werden.

Teams und Gruppen

Die eigentliche Arbeit wird in Teams und Gruppen durchgeführt, diese werden überhaupt zu dem Zwecke gebildet, die Projektarbeit zu organisieren. Tamburri unterscheidet zwischen ihnen: Gruppen werden projektunabhängig und langfristig gebildet, sie bieten den Rahmen, in dem die Arbeit organisiert wird. Abteilungen, aber auch Entwickler- und Testteams können dazu gezählt werden. Das, was Tamburri als Teams, oder Projektteams bezeichnet, sind kollektive Strukturen, die innerhalb des Projekts aus Personen zusammengesetzt werden, die gemeinsam eine bestimmte Aufgabe innerhalb des Projekts lösen sollen.

Entscheidungsfindung und Rationalität

Für unsere Forschung bei INDAL ist diese Klassifikation insofern interessant, dass die verschiedenen kollektiven Strukturen jeweils eine bestimmte Art von Rationalität in der Entscheidungsfindung zeigen, deshalb können sie in der Perspektive der ökonomischen Theorie unterschiedlich als rationale Akteure angesehen werden, für deren Beschreibung und Erklärung ökonomische Theorien herangezogen werden können. Gruppen haben durch ihre langfristige Struktur feste kulturelle regeln der Entscheidungsfindung, die entweder durch Autorität von Führungspersonen oder durch Regelwerke abgesichert sein können. Allerdings kann ihre Rationalität durch Netzwerke, aber auch durch Communities unterlaufen werden. Teams bilden selten eine kollektive Rationalität aus, da sie zu kurzzeitig existieren und die Teilnehmer oft aus unterschiedlichen Kulturen kommen. Ihre Entscheidungen sind deshalb im Sinne der ökonomischen Theorie selten als rational zu betrachten.

Auch für die unmittelbare Unternehmenspraxis können die Ergebnisse sinnvoll genutzt werden, indem auf ihrer Basis eine systematische Analyse der kollektiven Strukturen im Unternehmen und in Projekten durchgeführt wird. Letztlich ist das immer ein Teil der Anforderungsanalyse für komplexe Individualsoftware. Im Ergebnis können Schwachstellen erkannt und Optimierungen in den Entscheidungsstrukturen vorgenommen werden.

Tamburri, D., Lago, P., & Vliet, H. (2013). Organizational social structures for software engineering ACM Computing Surveys, 46 (1), 1-35 DOI: 10.1145/2522968.2522971

Der Beitrag Kollektive Strukturen im Software-Engineering erschien zuerst auf INDAL Software-Spezialist.

Informationen, die die eine Seite hat, damit die andere zu einem guten Ergebnis kommt, sind im Softwareprojekt von besonderer Bedeutung. Solche Situationen beschreibt die ökonomische Forschung mit dem Prinzipal-Agent-Ansatz: Der Agent verfügt über Informationen, die er zum Nutzen des Prinzipals einbringen soll – allerdings kann der Prinzipal das Verhalten des Agenten nicht jederzeit komplett beobachten. So weiß er nicht, ob der Agent wirklich alles tut, um das vereinbarte Ziel bestmöglich zu erreichen. Daraus entstehen Verhaltensunsicherheiten, die der Prinzipal beherrschen möchte. Das soll über ein geeignetes Vertragsdesign geschehen.

In der ökonomischen Forschung zu Softwareprojekten wird bis heute zumeist der Kunde als Prinzipal angesehen, während dem Lieferanten die Rolle des Agenten zufällt. Das scheint auch nahe liegend, denn der Lieferant soll für den Kunden eine Software entwickeln, er verfügt dazu über Informationen, die der Kunde nicht hat, und er kann während der Softwareentwicklung nicht jederzeit beobachtet werden.

Der Kunde als Agent

Allerdings – und das ist der zentrale Punkt der Arbeit von Cornelia Gaebert – gibt es im Softwareprojekt auch den umgekehrten Fall: Der Kunde wird zum Agenten, und zwar dann, wenn die Anforderungsspezifikation nicht vollständig ist, eine Situation, die uns bei komplexen Softwareprojekten zu Beginn zumeist begegnet. Dann verfügt der Kunde über Informationen, die er für den Erfolg des Lieferanten ins Projekt einbringen muss. Das ist grundsätzlich auch klar, aber es gibt eine reihe von Gründen, die dazu führen, dass der Kunde dies nicht ausreichend tut.

Sowohl für die Wissenschaft als auch für die Praxis ist die Frage interessant, welche Möglichkeiten der Vertragsgestaltung es gibt, um dieses Problem beherrschbar zu machen und das Projekt zum Erfolg zu bringen. Die Antwort hängt von den Gründen ab, die dazu führen, dass der Kunde seinen Beitrag nicht leistet. So kann es sein, dass er dazu schlicht nicht in der Lage ist, weil ihm das Know How oder das Wissen um die Notwendigkeit seines Beitrags fehlen. Es kann aber auch sein, dass er seinen Beitrag bewusst nicht leistet, weil er Ziele verfolgt, die dem Projekterfolg entgegenstehen. Dementsprechend unterscheiden sich auch die Möglichkeiten, die konkrete Situation richtig zu beurteilen und die richtigen Maßnahmen abzuleiten.

In diesem Paper (hier der vollständige Text als PDF), die dieser Tage auf einer Konferenz im schwedischen Lund vorgestellt wird, werden die Wege zu einem geeigeneten Vertragsdesign aufgezeigt.

Cornelia Gaebert (2014). Contract Design and Uncertainty in Software
Development Projects Proceedings of the 13th International Conference on Perspectives in Business Informatics Research DOI: 10.1007/978-3-319-11370-8_16

Der Beitrag Die Unsicherheiten im Softwareprojekt beherrschen erschien zuerst auf INDAL Software-Spezialist.

Zeit, die Blickrichtung zu wechseln. Wir sollten, gerade, wenn das Softwareprojekt durch ein externes Softwarehaus realisiert wird, die Vertragsbeziehung zwischen dem Kunden und dem Softwarehersteller in den Blick nehmen. Ist das Scheitern des Projektes vielleicht oft schon in der Vertragsbeziehung angelegt? Werden Pflichten und Anreize möglicherweise schon dort so festgeschrieben, dass das Projekt in Gefahr geraten muss, sobald auch nur “Kleinigkeiten” schief gehen? Das ist die Frage, der das Forschungsprojekt von Cornelia Gaebert nachgeht. Die ersten Ergebnisse wurden von ihr im August auf einer Internationalen Konferenz in Wien vorgestellt. Die Resultate gelten prinzipiell auch für Projekte, die innerhalb des Unternehmens durchgeführt werden, wenn die Verantwortlichkeiten und die zu tragenden Kosten durch klare Regeln (einen Vertrag) zwischen den Abteilungen festgelegt sind.

Anforderungslücken in der Softwarespezifikation

Anforderungslücken, also die unvollständige Spezifikation und die Änderung von Anforderungen, werden von allen Studien als wichtige Gründe des Scheiterns von Softwareprojekten angesehen. Deshalb wird auch viel Kraft in die Verbesserung der Methoden des Requirement Engineering investiert. Es ist aber plausibel, dass Anforderungen niemals zu Projektbeginn vollständig spezifiziert werden können. Deshalb muss man sich fragen, wie mit Anforderungslücken während des Projekts umgegangen wird. Wer ist für das Schließen der Lücken verantwortlich? Wer muss den Aufwand leisten?

Es sagt sich leicht hin, dass am besten beide Partner, Kunde und Softwarehersteller, diesen Aufwand am besten gemeinsam tragen. In der Praxis müssen beide Seiten Kosten sparen, insbesondere, wenn ein Festpreis für die Erstellung sdes Systems vereinbart wurde, und das Schließen von Anforderungslücken verursacht kosten, Experten werden benötigt, die oft keine Zeit haben, Informationen müssen beschafft werden. Um Kosten zu sparen, versuchen oft beide Seiten, den eigenen Aufwand zu reduzieren und die Arbeit den anderen Partner machen zu lassen.

Das Dilemma zwischen Softwarehersteller und Kunden

Man kann zeigen, dass die Projektpartner sich in einer so genannten Dilemmasituation befinden, die in der ökonomischen Forschung als Gefangenendilemma bekannt ist. Im Ergebnis findet im Projekt keine Kooperation zwischen den Parteien statt – obwohl Kooperation zum besten Ergebnis für beide führen würde. Am Ende stehen beide Seiten mit leeren Händen da, weil das Projekt scheitert.

Die Forschung zum Gefangenendilemma kann aber auch den Ausweg weisen. Sie können Wege aufzeigen, wie der Vertrag zu gestalten ist, damit beide Seiten zur Kooperation bereit sind. Das ist natürlich besonders schwierig, wenn es sich um einen autoritären Festpreisvertrag handelt, den der Kunde dominiert. Aber auch dann gibt es Wege, die Beistellungen des Kunden so zu bestimmen und die Anreize so zu setzen, dass Kooperation nicht ausschließlich auf dem guten Willen der Beteiligten basiert, sondern auf ökonomischen Nutzenskalkülen. Dann legt der Vertrag den Grundstein für den Projekterfolg, und ist nicht länger ein Risiko.

Cornelia Gaebert (2014). Dilemma Structures between Contracting Parties in Software Development Projects Proceedings of the 9th International Conference on Software Engineering and Applications DOI: 10.5220/0004996405390548

Den kompletten Text des Forschungsartikels als PDF finden Sie hier.

Der Beitrag Das Scheitern von Softwareprojekten ist oft schon im Vertrag angelegt erschien zuerst auf INDAL Software-Spezialist.

Der Beitrag Vernetzt, verstrickt, verfilzt, verheddert? erschien zuerst auf INDAL Software-Spezialist.

Die Generation derer, die die ersten kommerziellen Softwaresysteme für Unternehmen programmiert haben, hat sich inzwischen aus den Code-Werkstätten weitgehend zurückgezogen. Hier und da sitzt noch ein alter COBOL-Kenner am Bildschirm, denn bekanntlich sind die Systeme, die vor Jahrzehnten in Banken und Versicherungen kreiert wurden, zwar in die Jahre gekommen, aber sie gleichen weniger klapprigen Invaliden als vielmehr rüstigen Senioren, die bei guter Pflege noch eine Menge Arbeit verrichten können.

Weiterlesen bei heise Developer

Der Beitrag Source Reflection #5: Laborverhalten. Programmieren als Experiment erschien zuerst auf INDAL Software-Spezialist.

Weiterlesen bei heise Developer

Der Beitrag Sprachverwirrung erschien zuerst auf INDAL Software-Spezialist.

Weiterlesen bei heise Developer

Der Beitrag Große Kategorien oder kleine Differenzen erschien zuerst auf INDAL Software-Spezialist.

Nur über Dinge, die man weiß, kann man sich irren. Mein Wissen zeichnet sich dadurch aus, dass ich daran nicht zweifeln kann, aber andere schon.

Es könnte z. B. sein, jemand hätte mich gestern Abend mit meiner Notebooktasche aus dem Arbeitszimmer kommen sehen. Er vermutet, dass der Computer darin war, und zweifelt deshalb daran, dass das Gerät noch auf dem Tisch steht. Es stellt sich heraus, dass der Zweifel berechtigt war und ich mich geirrt habe. Es könnte auch sein, er selbst hat das Notebook weggeräumt. Dann zweifelt er nicht, er weiß, dass ich mich irre.

Wenn es mir des Öfteren passiert, dass ich vergesse, was ich getan habe (dass ich z. B. das Notebook aus dem Arbeitszimmer mitgenommen habe), dann kann ich an meiner Überzeugung schon zweifeln, ohne dass ich Hinweise darauf hätte, dass sie falsch ist. Das ist dann allerdings ein unbestimmter, nebulöser, unbegründeter Zweifel. Auf bestimmte Überzeugungen verlässt man sich einfach, zum einen auf die Dinge, die man unmittelbar beobachten kann, zum anderen auf die klaren Erinnerungen an eigene Beobachtungen.

Um eigene Erinnerungen zu stabilisieren, benutzen wir Hilfsmittel. Ich könnte mir angewöhnen, von jedem Raum, den ich verlasse, mit meinem Smartphone ein Foto zu machen, das Foto könnte ich auf meinen Web-Space hochladen und damit fast jederzeit und überall überprüfen, ob ich mein Notebook im Arbeitszimmer zurückgelassen habe. Ich könnte an wichtigen Orten sogar eine Webcam installieren und dort nachsehen, ob der Raum sich noch in dem Zustand befindet, wie ich ihn der Erinnerung nach verlassen habe.

Wenn ich so vorgehe, dann beginne ich sozusagen, mein Gedächtnis auszulagern, um meine Zweifel über das, was ich zu wissen glaube, verkleinern zu können. Das haben wir schon immer getan, seitdem wir z. B. Telefonnummern aufschreiben oder Urlaubsfotos in Fotoalben kleben und mit Ort und Datum beschriften, um uns besser erinnern zu können, wann wir wo gewesen sind. Solche Informationen im Netz abzulegen erweitert diese Möglichkeit zunächst nur graduell und nicht qualitativ. Wir können dann also, wenn wir Zweifel an einer Überzeugung aus der Erinnerung haben, auf solche Erweiterungen unseres Gedächtnisses zugreifen, um Zweifel zu zerstreuen oder zu bestätigen.

Ich kann jedoch auch noch einen großen Schritt weitergehen. Ich kann z. B., wenn ich meine Urlaubsbilder ins Album geklebt oder auf meinem Facebook-Account hochgeladen habe, die Detailinformationen einfach vergessen. Es ist zwar gar nicht so leicht, etwas aktiv zu vergessen, aber es macht natürlich einen Unterschied, ob ich mir Informationen eigentlich gut merken will und nur im Notfall auf externe Erinnerungshilfen vertrauen möchte oder ob ich die Informationen von Anfang an mit der Gewissheit aufnehme, dass ich sie sozusagen im Kopf nur so lange zwischenspeichere, bis ich sie extern, sicher, unzerstörbar und nicht fälschbar abgelegt habe. Mein eigenes Gedächtnis, so gut es trainiert sein mag, ist trügerisch und vor allem nicht überprüfbar, nicht einmal durch mich selbst, so könnte man argumentieren, sicher ist nur, was ich irgendwo aufgeschrieben, abgespeichert – verewigt – habe, also ist es gar nicht sinnvoll, sich etwas zu merken. Sinnvoll kann nur sein, alle Informationen sicher und überall abrufbar abzuspeichern und sich lediglich zu merken, wo sie gespeichert sind.

Auszug aus dem Buch “Kritik der vernetzten Vernunft” von Jörg Friedrich

Bestellen bei Amazon

Kindle Edition

E-Book-Ausgabe

Der Beitrag Wo steckt das Wissen? erschien zuerst auf INDAL Software-Spezialist.