Einheit 3 Verständnis von Arbeit & Kooperation

INHALT DER VORLESUNG EIGENE Annahmen (Kommunikation, Fairneß, Moral …) ICH als BERATER/ENTWICKLERin in EDV-PROJEKTEN mit MENSCHEN Arbeit mit Gruppen EDV -Design in Gruppen Angestrebte Rolle Projekte Inhalte Vermarktung Projektziele Verantwortung Vereinbarungen Projektdesign Rolle Berater Anbote Projektcontrolling ... Kalkulation Qualifizierung ... ... EIGENE Annahmen (Kommunikation, Fairneß, Moral …) THEORETISCHE KONZEPTE

The problem ‘problem’ Attention on problem definition How comes this is a problem & for whom? Is this the problem? How do the participants work on it? How to work on it - social perspective? Attention on problem solving What are the requirements? Are these requirements complete? What are the design options? How to work on it - factual perspective. Process dimension Factual dimension

SPEZIALISIERUNG Human Resource Management Ruth: (Text Joh) 000207 SPEZIALISIERUNG Human Resource Management Produktion Leistungserbringung Personalbeschaffung & Auswahl Kapazitätsplanung Leistungsbeurteilung …. Arbeitszeitgestaltung Entgeltgestaltung Konflikte BR X GF Personalentwicklung Führung

LEISTUNGEN IN DER BERATUNG Karin: 000214 Layout LEISTUNGEN IN DER BERATUNG Fachberatung Prozeßberatung Vorgehen & Projektorganisation Planungstechniken Moderation Ergonomie ... Abrechnung Recht ... Software & Werkzeuge

Ein “gut organisierter” Schreibtisch

Freie Markt … unsichtbare Hand … invisible hand es braucht auch (Verweis auf sogar noch weiteren Zusammenhang) invisible hand-shake

Spezifikation Spezifikation <--> Anwendung Was soll das System aus Sicht der AnwenderInnen leisten hinsichtlich: Funktionalität Arbeit mit dem System ... Das System soll diese Anforderungen unter den konkreten, jeweiligen Bedingungen erfüllen. Spezifikation <--> Technik Anforderungen hinsichtlich Implementierung (Was soll das System tun, aber nicht, wie es es tun soll!) Woher kommen Probleme?

“Anforderungen”? “The requirement engineer is said (among other things) to ‘capture’, ‘specify’, ‘elicit’ or ‘construct’ requirements. It is interesting to note the position on the nature of requirements implicit in each term.... There is no term as yet in current use which suggests the ongoing evolution of requirements from processes of interaction, both social and technical, continuing through the whole lifecycle...” (Jirotka and Goguen, 1994) capture = einfangen, elicit = herauslocken

Ein klein wenig Ketzerei “The retroperspective character of requirements... ... Another basic principle of social theory of information may be an extension of Suchmann´s (1987) work on plans to the broader claim that only post hoc explanations for situated events appear to attain relative stability and independence from context; let us call this the retroperspective hypothesis.” (Goguen in Jirota and Goguen, 1994)

Problem processing ‘problem’ Attention on problem definition How comes this is a problem & for whom? Is this the problem? How do the participants work on it? How to work on it - social perspective? Attention on problem solving What are the requirements? Are these requirements complete? What are the design options? How to work on it - factual perspective. Process dimension Factual dimension

ANGEBOT Was können wir annehmen über das Umfeld: Interesse Aufgabe ist klar definiert, weil Aufwand klar begrenzt ist (XX) - abzuschätzen ODER weil sie problem definition beeinflussen man kann es selbst und hat die Zeit es geht von hochgradig geklärten Rollen aus - kooperativer Zielfestlegung Was ist gut daran - für kooperatives Zusammenarbeiten? Definieren wodurch mehr Kosten entstehen können Was ist nicht gut daran - für kooperatives Zusammenarbeiten? Nicht definiert wie viel Varianten berücksichtigt sind Anderer Ansatz erfordert eine Möglichkeit Varianten zu definieren setzt wenig auf problem definition auf Nicht definiert Zeittraum für Kapazitätssteuerung & für Kunden