Softwareentwicklung in groesserem Team

[Ludger]

Hi,

mich interessiert die (ganz fiktive ;-) Anforderung eine Struktur fuer ein groesseres Softwareteam zu bilden. Gegeben sind, sagen wir einfach mal, 16 Fachkraefte mit unterschiedlichem fachlichen Hintergrund. Software soll nicht auf eine Art und Weise entwickelt werden wie in so genannten Softwareschmieden, sondern froehlicher, mit weniger Fachwissen und ohne grossem Ueberbau fuer Dokumentation und Projektarbeit zum Beispiel.

Ich habe folgende Grafik von einem Kollegen uebernommen:

|              |                  |                 |               |
|              |                  | Anwendungs-     |               |
| die Abnehmer | "Produktmanager" | entwickler      | "Architekten" |
|              |       (4)        | (Client Server) |     (4)       |
|              |                  | (8)             |               |

Nun, die Abnehmer sind interne, externe oder Franchisenehmer. Die Produktmanager sind kommunikationsstark, haengen soz. am Abnehmer und versuchen das, was der Abnehmer will, zu verstehen und fuer die Anwendungsentwickler zu uebersetzen und versuchen zu verstehen, was entwickelt und bereitgestellt worden ist von den Anwendungsentwicklern. Sie sind so zu sagen Abnehmer der Anwendungsentwickler und haben als Abnehmer den o.g. Abnehmer (Grafik).
Die Anwendungsentwickler machen was ihr Name ihnen sagt zu machen, also Client- oder Serversoftware erstellen.
Und die Architekten stellen IT-Infrastruktur bereit:

• Regeln wie entwickelt werden soll
• Regeln fuers Projektmanegement
• Softwarekomponenten, die von den Anwendungsentwicklern genutzt werden ("Geschaeftslogikkomponenten")
• Templates und Regeln fuer user interfaces zum Beispiel
• Regeln fuer das Datendesign und den Datenzugriff entwickeln
• Strategisches und Architekturfragen bearbeiten
• ...
  Die Architekten sind die Erfahrensten und sind gegenueber den Projektmanagern und Anwendungsentwicklern weisungsbefugt.

Ist nur eine kleine Skizze, aber kann man sich so aufstellen? Gehts in die richtige Richtung?

Gruss,
Ludger

[Mike©]

Moin Ludger,

Die Architekten sind die Erfahrensten und sind gegenueber den Projektmanagern und Anwendungsentwicklern weisungsbefugt.

also, ich sehe in deiner Skizze keinen Projektmanager, und genau der fehlt mir hier.

4 Produktmangager sind IMHO zuviele, und mit 4 weisungsbefugten Architekten dürfte wohl ein größeres Chaos ins Haus stehen.

regds
Mike©

[Ludger]

Hi,

Die Architekten sind die Erfahrensten und sind gegenueber den Projektmanagern und Anwendungsentwicklern weisungsbefugt.

also, ich sehe in deiner Skizze keinen Projektmanager, und genau der fehlt mir hier.

ich meinte Produktmanager. Projektmanagement erfolgt auch durch die Architekten, allerdings sparsam.

4 Produktmangager sind IMHO zuviele, und mit 4 weisungsbefugten Architekten dürfte wohl ein größeres Chaos ins Haus stehen.

4 Produktmanager sind zuviel? Wirklich, die gesamte Kommunikation mit dem Abnehmer will doch verwaltet werden.
Und zu den 4 Architekten. Einer von denen ist natuerlich Chefarchitekt.

Gruss,
Ludger

[Mike©]

Moin nochmal,

4 Produktmanager sind zuviel? Wirklich, die gesamte Kommunikation mit dem Abnehmer will doch verwaltet werden.

du hast ein (1) Produkt, also 1 Produktmanager. Er soll das Bindeglied und Sprachrohr zwischen Anforderung und Umsetzung sein.

Bei 4 Produktmanagern hast du ca. 6 unterschiedliche Ausagen und Auffassungen.

Und zu den 4 Architekten. Einer von denen ist natuerlich Chefarchitekt.

Anstatt des "Chefarchitekt" setzt du einen Projektmanager, der hat das Sagen, sonst Chaos.

Und der Kommunikationsweg sollte IMHO so aussehen:

Kunde <-> Produktmanager
Produktmanager <-> Projektmanger
Projektmanager <-> Architekt
Architekt <-> Entwickler

Wobei es hier natürlich auch direkte/kurze Wege geben darf und muß wie z.Bsp:

( Entwickler <-> Kunde ) --> Projektmanager

regds
Mike©

[TomIRL]

Moin,

Anstatt des "Chefarchitekt" setzt du einen Projektmanager, der hat das Sagen, sonst Chaos.

Ich vermute, dass sich eine Autorität als Projektmanager der das sagen hat nicht durchsetzen läst.

Die Konstellation spricht dafür, dass irgendwie 4 Partner zusammenarbeiten, die alle gleichberechtigt sein müßen und wollen.

Und der Kommunikationsweg sollte IMHO so aussehen:

Kunde <-> Produktmanager
Produktmanager <-> Projektmanger
Projektmanager <-> Architekt
Architekt <-> Entwickler

Diese Art der Kommunikation ist IMHO sehr ineffizent.

Kunde <-> Produktmanager
Produktmanager <-> Architekt
Architekt <-> Projektmanager (zwecks Koordinierung)
Architekt <-> Entwickler

Sonst platzt Dir als Projektmanager bald die Birne.

TomIRL

Wobei es hier natürlich auch direkte/kurze Wege geben darf und muß wie z.Bsp:

( Entwickler <-> Kunde ) --> Projektmanager

regds
Mike©

[TomIRL]

So rum...
Diese Art der Kommunikation ist IMHO sehr ineffizent.
Kunde <-> Produktmanager
Produktmanager <-> Architekt
Architekt <-> Projektmanager (zwecks Koordinierung)
Architekt <-> Entwickler

Sonst platzt Dir als Projektmanager bald die Birne.

TomIRL

[Ludger]

Hi,

du hast ein (1) Produkt, also 1 Produktmanager. Er soll das Bindeglied und Sprachrohr zwischen Anforderung und Umsetzung sein.

OK, aber ein Produktmanager kann mehr als 1 Produkt betreuen. idealerweise .   ;-)

Bei 4 Produktmanagern hast du ca. 6 unterschiedliche Ausagen und Auffassungen.

Es gibt da keine Aufgabenueberschneidungen. Das waere in der Tat unguenstig.

Und zu den 4 Architekten. Einer von denen ist natuerlich Chefarchitekt.

Anstatt des "Chefarchitekt" setzt du einen Projektmanager, der hat das Sagen, sonst Chaos.

Der Projektmanager hat grundsaetzlich das Problem, dass er fachlich zu wenig drauf hat. Darum sind die Architekten auch weisungsbefugt, damit auf die gehoert wird. (Was ja sonst oft nicht der Fall ist.)

Und der Kommunikationsweg sollte IMHO so aussehen:

Kunde <-> Produktmanager
Produktmanager <-> Projektmanger
Projektmanager <-> Architekt
Architekt <-> Entwickler

Das waere ein anderes Konzept. Ich wuerde gerne auf "DEN PROJEKTMANAGER" verzichten. (Manchmal spielt diese Rolle ein Architekt, bzw. manchmal auch ein Produktmanager oder Entwickler.)

Wobei es hier natürlich auch direkte/kurze Wege geben darf und muß wie z.Bsp:

( Entwickler <-> Kunde ) --> Projektmanager

In Ausnhamefallen aber nur.   ;-)

Danke fuers feedback.

Gruss,
Ludger

[TomIRL]

Moin,
Es fhelt ne klare Zuweisung für QM im weiteren Sinne,.
Das heißt, wer klärt Konflikte, Change Requests etc..
Es sollte meiner Meinung nach, eine Art Oberarchitek beratend arbeiten.
Ein kleinen wenig Dokumentation sollte für mein Empfinden da dann doch stattfinden.

TomIRL

[Ludger]

Hi,

Es fhelt ne klare Zuweisung für QM im weiteren Sinne,.

ich deutete an, dass es eine "froehliche" Aufstellung sein soll. Schwerpunkt: Effizienz und kurze Reaktionszeiten

Das heißt, wer klärt Konflikte, Change Requests etc..

Change Requests machen die Produktmanager, Konflikte klaeren idealerweise ebenfalls, ansonsten muss ein "Architekt" ran.

Es sollte meiner Meinung nach, eine Art Oberarchitek beratend arbeiten.

Idealerweise ein Informatiker (nicht nur mit Consulting-Erfahrung) mit jahrelanger Berufserfahrung (irgendwie faellt mir da Michael Schröpl ein ;-).

Ein kleinen wenig Dokumentation sollte für mein Empfinden da dann doch stattfinden.

OK.

Gruss,
Ludger

[TomIRL]

Moin,

Hi,

Es fhelt ne klare Zuweisung für QM im weiteren Sinne,.

ich deutete an, dass es eine "froehliche" Aufstellung sein soll. Schwerpunkt: Effizienz und kurze Reaktionszeiten

Das eine muß dem anderen ja nicht im Wege stehen, deshalb meinte ich ja im weiteren Sinne.

Das heißt, wer klärt Konflikte, Change Requests etc..

Change Requests machen die Produktmanager, Konflikte klaeren idealerweise ebenfalls, ansonsten muss ein "Architekt" ran.

Ich halte die Konstellation für sehr konflikträchtig, klar könnten die Architekten jenes, aber das ist stark von den persönlichen Eigenschaften und Fähigkeiten jedes einzelnen Architekten abhängig.
Deshalb kam ja der Vorschlag "Oberarchitekt".

Idealerweise ein Informatiker (nicht nur mit Consulting-Erfahrung) mit jahrelanger Berufserfahrung (irgendwie faellt mir da Michael Schröpl ein ;-).

Naja zu Personen äußere ich mich nicht, aber die Richtung stimmt, Berater, und dank Erfahrung und Kompetenz eine natürliche Autorität, die im Fall des Falles Entscheidungen für das Projekt im Konsenz herbeiführen kann.

TomIRL

[Christoph Zurnieden]

Hi,

mich interessiert die (ganz fiktive ;-) Anforderung eine Struktur fuer ein groesseres Softwareteam zu bilden. Gegeben sind, sagen wir einfach mal, 16 Fachkraefte mit unterschiedlichem fachlichen Hintergrund. Software soll nicht auf eine Art und Weise entwickelt werden wie in so genannten Softwareschmieden, sondern froehlicher, mit weniger Fachwissen und ohne grossem Ueberbau fuer Dokumentation und Projektarbeit zum Beispiel.

Das geht dann fröhlich in die Pleite und keiner weiß warum, denn die passende Dokumentation fehlt >;->

[SKIZZE]

Das kann man so allgemein nicht sagen, dafür müßte man wissen, wer die 16 sind, welche Art Software produziert werden soll und wer der Kunde ist. Patentrezepte gibt es nicht.

Wie soll den die Entwicklung aussehen? Wasserfall oder Schleife oder eine der vielen hundert Mischformen?
Wer gibt das Kapital, wer bekommt den Gewinn?
Wie soll die Struktur der Firma aussehen? Hierarchisch oder basisdemokratisch oder eine der vielen hundert Mischformen?
Wer entscheidet über die Entwicklungsrichtung der Software? Der Kunde oder der Entwickler oder der eigentliche Bedarf des Kunden?
Wie wird mit alter Software verfahren; wie mit Fehlentwicklungen?

Ein kleiner Auschnitt eines riesigen Fragenkataloges, die sich alle nicht a priori beantworten lassen.

Aufgrund meiner Tätigkeit konnte ich schon einiges an Organisationsformen bewundern. Da sind teilweise Dinger drunter, da glaubst Du nicht, das es funktioniert obwohl Du es mit eigenen Augen siehst. Trotzdem haben die ein gutes Produkt und erwirtschaften damit sehr gute Umsätze und satte Gewinne. (Anders könnten die sich mich auch gar nicht leisten ;-) Ich kann Dir auch sagen, das in einem Fall erst der Einsatz eines alten und erfahrenen Streeworkers zu einem akzeptablem Arbeitsklima geführt hat.

so short

Christoph Zurnieden

[Ludger]

Hi,

Das geht dann fröhlich in die Pleite und keiner weiß warum, denn die passende Dokumentation fehlt >;->

dann duerfte es uns schon gar nicht mehr geben.

Das kann man so allgemein nicht sagen, dafür müßte man wissen, wer die 16 sind, welche Art Software produziert werden soll und wer der Kunde ist. Patentrezepte gibt es nicht.

Software rund ums Leasing. Webanwendungen, SOAP Services, rich clients, "OLTP"- und "OLAP"-Anwendungen ...

Wie soll den die Entwicklung aussehen? Wasserfall oder Schleife oder eine der vielen hundert Mischformen?

Kein RUP, kein UML, nichts Intellektuelles. Wasserfall pur soz..

Wer gibt das Kapital, wer bekommt den Gewinn?

;-)

Wie soll die Struktur der Firma aussehen? Hierarchisch oder basisdemokratisch oder eine der vielen hundert Mischformen?

Patriarchalisch anarchistisch.

Wer entscheidet über die Entwicklungsrichtung der Software? Der Kunde oder der Entwickler oder der eigentliche Bedarf des Kunden?

Was ist eine Entwicklungsrichtung?

Wie wird mit alter Software verfahren; wie mit Fehlentwicklungen?

Alte Software wird ausser Betrieb genommen, wenn es erforderlich ist. Fehlentwicklungen werden nicht in Betrieb genommen, d.h. das Scheitern von Projekten wird akzeptiert.

Aufgrund meiner Tätigkeit konnte ich schon einiges an Organisationsformen bewundern. Da sind teilweise Dinger drunter, da glaubst Du nicht, das es funktioniert obwohl Du es mit eigenen Augen siehst. Trotzdem haben die ein gutes Produkt und erwirtschaften damit sehr gute Umsätze und satte Gewinne. (Anders könnten die sich mich auch gar nicht leisten ;-) Ich kann Dir auch sagen, das in einem Fall erst der Einsatz eines alten und erfahrenen Streeworkers zu einem akzeptablem Arbeitsklima geführt hat.

Schreib doch mal ein paar Saetze zur ins Auge gefassten Aufstellung des Teams. Werden solche Strukturen erfolgreich gefahren?
Streetworker koennten wir auch gebrauchen.   ;-)

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Das kann man so allgemein nicht sagen, dafür müßte man wissen, wer die 16 sind, welche Art Software produziert werden soll und wer der Kunde ist. Patentrezepte gibt es nicht.

Software rund ums Leasing.

Eigentlich waren das alles rethorische Fragen, die mußt Du Dir erst selber beantworten bevor das andere tun können.

Webanwendungen, SOAP Services, rich clients, "OLTP"- und "OLAP"-Anwendungen ...

Bitte keine Buzzwords, die sind hier vollkommen überflüssig und ich reagiere außerdem allergisch darauf.

Wer entscheidet über die Entwicklungsrichtung der Software? Der Kunde oder der Entwickler oder der eigentliche Bedarf des Kunden?

Was ist eine Entwicklungsrichtung?

Welche Basis, welche Features, welche Bugs sind bedrohlich, welche verzeihlich usw.

---

Beispielshaft aber doch mal etwas kommentiert:

Wie wird mit alter Software verfahren; wie mit Fehlentwicklungen?

Alte Software wird ausser Betrieb genommen, wenn es erforderlich ist.

Was machst Du mit Kunden, die die alte Software benutzen? _Müssen_ die updaten? Können die evt den Code käuflich erwerben? Können die das auch schon vorher (Code mag dabei treuhänderisch verwaltet werden, die kaufen also nur das Recht im Pleitefall o.ä. den Code zu erhalten)?

Fehlentwicklungen werden nicht in Betrieb genommen, d.h. das Scheitern von Projekten wird akzeptiert.

Und was wird aus dem Material? Schmeißt ihr das weg? Keine gute Idee, kann ich Dir sofort sagen. Ist auch die einzige Empfehlung, die ich hier geben kann.

Schreib doch mal ein paar Saetze zur ins Auge gefassten Aufstellung des Teams.

Kam nicht klar genug raus, das das keiner kann ohne genauen Einblick in alle Details?

Werden solche Strukturen erfolgreich gefahren?

Es ist durchaus möglich, das die von Dir beschrieben Struktur funktionieren kann. Wenn die Mitarbeiter mitspielen, der Kunde, die Art der Software, der Kapitalgeber, der Gewinnnehmer, das Wetter ...

Ein kleines Beispiel:
Beim XP wird empfohlen zwei Programmierer auf einen Platz zu setzen, damit die gegenseitig befruchten/über die Schulter schauen. Damit das funktioniert müssen beide auch zusammenpassen, denn es kann alles passieren: "verstehen sich blendend" -> "neutral" -> "bringen sich gegenseitig um" wobei noch die Ziet berücksichtgt erden muß, da nicht bekannt ist, ob die sich nicht nach der Hälfte des Projektes derartig auf den Sackgehen, das sie sich regelmäßig nach dem Frühstück prügeln. Oder umgekehrt: es rauft sich zusammen. Selbst wenn die sich blendend verstehen, muß es nicht unbedingt die Qualität des Codes erhöhen oder den Durchsatz. Es kann auch sein, das die beiden trotz regelmäßiger Prügelei den besten Code der Firma auswerfen und auch noch pünktlich fertig sind.

so short

Christoph Zurnieden

[Ludger]

Hi,

bist Du ein reiner "Consulting-Mensch"?

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

bist Du ein reiner "Consulting-Mensch"?

Nein, hin und wieder streife auch ich mir den Blauman über.
Warum?

so short

Christoph Zurnieden

[Chräcker Heller]

Hallo,

es fehlt mir eine "Testumgebung" in der niemand aus Deiner Skizze direkt beteiligt sein sollte. (schon gar nicht die Programmierer, die bekommen nur ein Telefon da nur eine Hörmuschel und kein Mikrofon hat zu den Testern gelegt...- Damit die fröhlich bleiben, kann man das ja dann bunt anmalen ;-).)

Also User "wie Abnehmer" ohne Abnahmezwang ;-)

Genau die fehlten nämlich ganz offensichtlich bei allen fröhlichen Softwareschmieden die die Bediensoftware meiner zuletzt gekauften Hardware (wie mp3-Player oder Festplattenrekorder) programmiert haben....

Chräcker

[fk]

mich interessiert die (ganz fiktive ;-) Anforderung eine Struktur fuer ein groesseres Softwareteam zu bilden. Gegeben sind, sagen wir einfach mal, 16 Fachkraefte mit unterschiedlichem fachlichen Hintergrund. Software soll nicht auf eine Art und Weise entwickelt werden wie in so genannten Softwareschmieden, sondern froehlicher, mit weniger Fachwissen und ohne grossem Ueberbau fuer Dokumentation und Projektarbeit zum Beispiel.

ein bischen koordination und verantwortlichkeit sollte aber trotzdem dasein. sonst sagt jeder: ich habe keine schuld.

zwischen kunde und auftragnehmer bestehen immer entgegengesetze anforderungen: der kunde will viel für wenig geld, der auftragnehmer will viel geld für wenig leistung.

hier entsteht ein 'tetralemma'.

daher muß es eine 'pufferzone' zwischen der kundenanforderung und der auftragsabwicklung geben: das 'kundensprachrohr' produktmanager, welcher die preis/leistung relation verantwortet.
auf auftragnehmerseite ist der produktmanager der 'kunde', welcher das geld weitergibt.
dieser verhandelt dann mit dem preis/leistungsverantwortlichen auf auftragnehmerseite, dem 'chefproduzenten'. dieser sollte immer den vollen überblick haben, und teilaufgaben erstellen und delegieren.

[Ludger]

Hi,

ein bischen koordination und verantwortlichkeit sollte aber trotzdem dasein. sonst sagt jeder: ich habe keine schuld.

der "Architekt" in meiner Skizze haette am Schluss immer Schuld. Diese darf er dann natuerlich teamintern gerne weiterreichen.

zwischen kunde und auftragnehmer bestehen immer entgegengesetze anforderungen: der kunde will viel für wenig geld, der auftragnehmer will viel geld für wenig leistung.

hier entsteht ein 'tetralemma'.

Hast Du http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Trilemma gemeint? Oder http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Dilemma?

Ich sehe hier kein Dilemma, sondern eine Standard-Kooperationssituation, wo Probleme eigentlich nur (;-) dadurch entstehen, dass eine Seite in Vorleistung gehen muss.

daher muß es eine 'pufferzone' zwischen der kundenanforderung und der auftragsabwicklung geben: das 'kundensprachrohr' produktmanager, welcher die preis/leistung relation verantwortet.
auf auftragnehmerseite ist der produktmanager der 'kunde', welcher das geld weitergibt.
dieser verhandelt dann mit dem preis/leistungsverantwortlichen auf auftragnehmerseite, dem 'chefproduzenten'. dieser sollte immer den vollen überblick haben, und teilaufgaben erstellen und delegieren.

Ja, sehe ich auch so. Dafuer hat man den agilen Produktmanager.

Gruss,
Ludger

[fk]

auf kundenseite gibts 2 beteiligte: den leistungsanforderer und den budgethalter (oder einkäufer).
der erstere will viel, das geld interessiert ihn nicht.
der zweite will wenig ausgeben, was es leistet interessiert ihn nicht.
diese beiden haben unterschiedliche interessen.

auf auftragnehmerseite gibts ebenfalls 2 beteiligte: den aquisiteur (oder verkäufer) und den ersteller.
der erstere will viel geld, was es leistet interessiert ihn nicht.
der zweite will wenig leisten(arbeiten), was es an geld bringt interessiert ihn nicht.
diese beiden haben unterschiedliche interessen.

so verhandeln die ersteren untereinander und machen verträge. das ergebnis verhandeln sie mit dem zweiten auf ihrer seite.

in der regel müssen auch die zweiteren miteinander auskommen ohne daß diese verträge gemacht haben. wenn nun die ersteren mist gemacht haben, gibts bei den zweiteren untereinander ein ganz schönes 'dilemma'.
diese beiden haben manchmal völlig andere interessen.

daher tetralemma.

[Ludger]

Hi,

so verhandeln die ersteren untereinander und machen verträge. das ergebnis verhandeln sie mit dem zweiten auf ihrer seite.

danke fuer die Erlaeuterungen. Ich kannte die Dilemma-Situation nur aus Beispielen wie dem Folgenden:
Gangster A arbeitet mit Gangster B zusammen. Beide werden gepackt und verhoert. Klare Beweise fehlen. Angeboten wird Gangster A

• falls A die Tat zugibt und B nicht, dann kommt A mit 2 Jahren Zuchthaus davon
• falls A nichts zugibt und B gibt zu, dann gibts fuer A die Todesstrafe
• geben A und B die Tat zu, dann muessen beide 5 Jahre sitzen
• geben A und B nichts zu, werden beide nach dem intensiven Verhoer auf freien Fuss gesetzt

Gangster B wird aehnliches angeboten, eine Kommunikationsmoeglichkeit A<->B besteht nicht.

Konsequenz: Gangster A und B singen wie die Voegelchen, um ihr wertes Leben nicht zu riskieren. Dabei waere Schweigen in der Summe guenstiger gewesen fuer die beiden Sportsfreunde.

Gruss,
Ludger

[fk]

das ist für die gangster ein echtes problem.

aber ich wollte nur darauf hinweisen, daß es 4 unterschiedliche interessen gibt.
dieses solltest du in deiner personalstruktur beachten.

ich bin ja auch für flache hierarchien und gleichberechtigte partner. wenns denn funktioniert isses wunnebar. aber eigentlich geht soetwas eher öfter in die hose.

[Ludger]

Hi,

aber ich wollte nur darauf hinweisen, daß es 4 unterschiedliche interessen gibt.
dieses solltest du in deiner personalstruktur beachten.

nun, es ist also kein Dilemma, bzw. Tetralemma, sondern einfach nur eine standardisierte Betrachtung der einzelnen Interessenlagen. BTW - sinds wirklich nur vier?

ich bin ja auch für flache hierarchien und gleichberechtigte partner. wenns denn funktioniert isses wunnebar. aber eigentlich geht soetwas eher öfter in die hose.

Ganz wichtig ist die "soziale Kompetenz" aller Beteiligten, sonst gehts fast immer, soz. unabhaengig von allem, den Bach herunter.

Gruss,
Ludger

[Johannes Zeller]

Hallo Ludger,

Konsequenz: Gangster A und B singen wie die Voegelchen, um ihr wertes Leben nicht zu riskieren. Dabei waere Schweigen in der Summe guenstiger gewesen fuer die beiden Sportsfreunde.

Nein, die Lösung dieses Problems heißt Ómerta ;-)

Schöne Grüße,

Johannes

[Ludger]

Hi,

Konsequenz: Gangster A und B singen wie die Voegelchen, um ihr wertes Leben nicht zu riskieren. Dabei waere Schweigen in der Summe guenstiger gewesen fuer die beiden Sportsfreunde.

Nein, die Lösung dieses Problems heißt Ómerta ;-)

ja, fuer die ganz harten Jungs.   ;-)

Gruss,
Ludger

PS: Liegt hier ein Tetralemma vor?