[TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

[Thomas Kowtsch]

Hallo Bernhard,

On 18.11.2010 16:58 Bernhard Ludwig wrote:
> Unkerei ist das keineswegs. Solche Diskussionen entstehen aus einer gewissen
> Unzufriedenheit heraus und dienen der Weiter-/Fortentwicklung eines
> eventuell vorherrschenden Stillstands.

Das ist ja ok. Allerdings ist mir - selbst seit nunmehr 7 Jahren aktiver 
Betreuer von diversen Typo3-Instanzen (ohne damit Geld zu verdienen!) - 
in den letzten Jahren immer mehr aufgefallen, dass es eine große Schere 
gibt: Zwischen denen, die laut nach Lösung XY rufen und denen, die leise 
(aber deutlich) sagen, wie es auch anders geht.

Genau dort liegt ein gewaltiger Unterschied: Kann ich mit Software XY 
Problem Z lösen? Wenn ja, mit welchem Aufwand (Zeit pro Einsatz, 
Einmalaufwand, Schulungsbedarf)? Wenn nein, was muss ich investieren 
damit es geht?
Wenn Du als One-Man-Show vom Admin bis zum Redakteur alles in 
Personalunion bist dann muss die Site schon erhebliche Ansprüche haben, 
damit Typo3 die wirklich beste Wahl ist.

Wo Du Admin bist und 4 Redakteure 95% Standard-Tasks haben und dich 
jeweils 1x in zwei Wochen fragen, wie sie Aufgabe xy am besten umsetzen 
wird es schon interessanter - und wenn Du 50 Redakteure hast ist der 
individuelle Aufwand zu vernachlässigen, solange du sie über 
Veränderungen zielgruppenadäquat informierst.

Letztlich hängt der langfristige Gesamtaufwand davon ab, wie gut vorher 
die Anforderungsanalyse gelaufen ist und wie dann die Umsetzung erfolgt. 
Und das ist das, woran sich ein Unternehmen jedweder Art orientieren 
soll/muss.
Wie gesagt - diese Betrachtung hängt aber vom Gesamtumfang des Projektes ab.

> Und wie Du selbst beschreibst ist das Allheilmittel bei TYPO3 eben oftmals
> der "Workaround", der allerdings seinem Sinn nach folgendes beschreibt:
> "Der Workaround - Damit versteht man die Umgehung eines bekannten Problems
> innerhalb eines technischen Systems durch eine Hilfskonstruktion."

Wobei ein echtes Problem die Tatsache ist, dass nur selten ein Problem 
beschrieben richtig wird. In den meisten Fällen wir nur beschrieben, 
dass man gern mit Feature XY die Lösung Z erreichen möchte und dass das 
nicht geht. Nicht beschrieben ist aber meist, was man - unabhängig von 
der technischen Lösung! - braucht. Dann finden sich nämlich oft andere 
Lösungswege...

> Solche Hilfskonstruktionen haben im Allgemeinen den Nachteil, dass sie nur
> rudimentär das eigentliche Problem entlasten und meist nur zur Lösung einer
> einzigen bestimmten Definition dienen.

Korrekt. Allerdings bleibt die Frage, ob "das eigentliche Problem" 
wirklich korrekt beschrieben wurde oder ob die empfohlene 
"Hilfskonstruktion" zwar einmaligen Aufwand generiert oder tatsächlich 
nur Konstrukt bis zum echten Bugfix ist.

Mein persönliches Erleben ist an der Stelle, dass viel von dieserlei 
Diskussionen sehr stark kulturell und kundenspezifisch verursacht sind: 
In einem Unternehmen mit x-tausen Mitarbeitern und x-hundert Redaktueren 
kommt es auf 2 oder 10 Stunden Anpassungen nicht an, wenn man dafür 3 
Jahre Ruhe hat. Bei einer 15-Mann-Bude zählt das private Engagement der 
Redakteure. Und dazwischen gibt es entweder sehr klare Ziele oder viele 
kleine Firmen, die notgedrungen zig verschiedene Systeme anbieten müssen 
- aber in diversen Details ebenso notgedrungen passen müssen.
Wie stark dann wo "gemeckert" wird ist dann regional verschieden: Die 
einen meckern, die andern ertragen es "leise weinend", ... Aber für 2 
Stunden Manager-Gemecker kann man u.U. auch ein paar Stunden Entwickler 
beauftragen :-).

> Beruhigend finde ich den Einsatz von Workarounds eigentlich nie und kann
> Deiner Ansicht, das sei "einfach und sauber" nur wenig beipflichten.

"Das kommt drauf an". Natürlich gibt es regelmäßig in jeder Software 
Probleme, die man einfach nur versucht "irgendwie" zu umgehen.
Entscheidend ist zu unterscheiden, um was es im großen und ganzen geht: 
Konsistente Lösungen über alle Anwendungsfälle? Lösungen für viele 
kleine Dinge? Echte Bugs?
Zusammen mit der Beurteilung der Frage, ob das Problem wirklich klar und 
lösungsoffen formuliert wurde, ergeben sich u.U. plötzlich ganz andere 
Sichtweisen.
Da kann dann schon mal rauskommen, dass andere Systeme besser geeignet 
sind als Typo3. OK, schade, aber "worth the effort" - für den 
Dienstleister, die Community und den guten Ruf der Systeme.

Typo3 ist keine Religion - es ist für viele ein gutes Mittel, um 
Anforderungen umzusetzen, und zwar so, dass es in Summe rentabler ist 
als mit Alternativen (was je nach Bedarf, Trainingsstand der Nutzer und 
vorhandener Infrastruktur mit MS Sharepoint übrigens preiswerter werden 
kann als mit Typo3!).

Thomas