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 _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
