Hallo André!
André? Aaaandré? Ah gut, noch nicht weggerannt ;-)
Am Freitag, den 19.06.2009, 08:19 +0200 schrieb André Schnabel:
> Morgen,
>
>
> Christoph Noack schrieb:
> > ...
> > Immerhin würde dies für einen Großteil von Entscheidungen (z. B. für die
> > Produktentwicklung) eine stark verbesserte Transparenz ermöglichen -
> > denn das ist aus meiner Sicht eines der heutigen großen Probleme. Es
> > geht oft nicht um den einen oder anderen Bug, der individuell als sehr
> > schmerzhaft wahrgenommen wird, sondern um das Verständnis, warum
> > stattdessen Ressourcen an anderer Stelle (sinnvoller) eingesetzt werden.
>
> Ich habe diese Formel so oft selbst gehört und hergebetet - ich könnte
> inzwischen jedes mal schreiend wegrennen, wenn ich sie höre.
>
> Wir haben zu wenig Ressourcen - ja, das ist so. Dass wir das allerdings
> als Entschuldigung nehmen, immer mehr Arbeit vor uns aufzutürmen und
> parallel davon sprechen, dass wir kein (Qualitäts-)Problem haben passt
> aus meiner Sicht einfach nichtmehr zusammen. Solang wir nicht zugeben,
> dass wir ein Problem haben werden wir auch nicht an einer Lösung arbeiten.
Mir ist derzeit absolut unklar, wie - scheinbar - der Eindruck eines
fehlenden Problembewusstseins entstanden ist. Wieso sonst sind mir Dinge
wie "Vision", "Ziele", "Zielgruppen", ... so wichtig? Weil ich glaube,
dass diese eine Schlüsselrolle in der Entscheidung spielen:
* welche Features direkt ins Produkt kommen,
* welche explizit außerhalb des Core bleiben (oft
unberücksichtigt, z.B. stattdessen als "Unternehmens XY Feature
Pack Extension" implementiert werden,
* welche Bugs die Benutzer besonders stören,
* wie Webseiten und Doku noch besser wird, ...
Bezogen auf das aktuelle Beispiel "Bugfixing" ist es *vorher* schon
wichtig zu wissen was getan werden soll - und nicht danach zu
argumentieren. Wenn klar wäre, dass wir beispielsweise Studierende (die
im Gegensatz zu anderen MS-Produkten ein MS-Office heute noch nicht
kostenlos erhalten) als eine wichtige Zielgruppe haben, dann fallen mir
dazu zig wichtige Funktionen und Bugs ein. Sogar visuelle Attraktivität
wäre dann ein Thema...
> > Martin sprach an, dass "jede lokale Gruppe, jede contributende company
> > leicht unterschiedliche Ziele haben" wird und "fuer ein gemeinsames Ziel
> > kaum Kompromisse eingehen wollen". Aus meiner Sicht ergibt sich hier
> > kaum Widerspruch, wenn man diese Beiträge als "zusätzlich" zum
> > eigentlichen Projektziel betrachtet. Leider ist jedoch ist mein
> > Eindruck, dass wir beispielsweise mehr Contributoren durch fehlende
> > Ziele verlieren als durch vorhandene Ziele verärgern - denn derzeit ist
> > kaum jemandem klar, bei welchem Thema sich die Mithilfe wirklich lohnt.
>
> Meine persönliche Formel: es lohnt sich, bei konkreten Aufgaben zu
> helfen, bei denen Sun oder einer der anderen großen Contributoren einmal
> committed hat. Alles andere ist nahezu Zeitverschwendung - oder schier
> durch die Zeitspanne zwischen eigener Bemühung und letztendlicher
> Umsetzung nichts anderes als frustrierend.
Ich kann diese Formel gut nachvollziehen - Du kennst ja meine Aussage
während der OOoCon. Und selbst wenn man nach dieser Formel arbeitet: Was
ist gerade wichtig? Und was wird wichtig?
Besonders vor Renaissance hat es mich unendlich gestört, dass ich dazu
nicht auskunftsfähig war .... Es gibt eben doch Community-Mitglieder,
die thematisch offen sind und fragen, wie man zielgerichtet (und damit
auch sichtbar) beitragen könnte. Eine solche vermeintlich simple Frage
nicht beantworten zu können - das stört mich maßlos! Von den eigenen
Erfahrungen mal ganz zu schweigen :-)
Mein Eindruck ist, dass Prioritäten bei Unternehmen manchmal sehr
schnell kippen - Dinge, die zeitweise wenig wichtig waren haben dann
eine sehr hohe Priorität. Als Freiwilliger mit zeitlich begrenzten (wenn
auch kontinuierlichem Zeitbudget) wird man teilweise von den sportlichen
Terminplänen überholt. Committed ja, sinnvoller Beitrag ... naja.
> Es gehört eigentlich nicht in die Antwort auf deine Mail- aber die
> zweite Formel, die mir immer wieder bitter aufstößt ist "es entscheidet,
> wer macht". Damit ist immer implizit gemeint "es entscheidet wer
> implementiert". Daraus ergibt sich dann automatisch, dass jemand, der
> Fehler verifiziert, CWSse testet, Dokumentationen schreibt, oder sich
> auf anderen Gebieten intensiv am Projekt beteiligt eben *nicht*
> entscheiden kann (obwohl er "macht").
> Als QA-Ansprechpartner habe ich keinen Einfluss darauf, was nun als
> nächstes implementiert wird - ich kann nur die Fehler nachräumen und bei
> den Anwendern um Entschuldigung bitten, dass neue Features nun doch
> einige Fehler enthalten, und zum Teil Jahre alt Bugs nicht aufgeräumt
> werden. Nach der 1000 bitte um Entschuldigung, gewähren ich mir diese
> selbst nicht mehr.
Find "QA", replace with "UX" :-(
(Mal am Rande: Ich bewundere die QA-Community für ihre wirklich aktive
und gute Arbeit.)
Interessant ist, dass ich bei meinem letzten Besuch bei Sun während
einiger Gespräche wahrgenommen habe, dass "neue Features" einen sehr
großen Stellenwert besitzen. Aus meiner Sicht ist das nicht mehr der
Knackpunkt, um sich von Wettbewerbern zu differenzieren bzw.
konkurrenzfähig zu sein.
Mir persönlich wären stabile und gut durchdachte Features, sowie eine
vollständige abgedeckte API und Dokumentation für die
Extension-Entwicklung viel lieber. Zu Letzterem: statt alles von wenigen
(sehr guten und sehr gut eingearbeiteten) Entwicklern machen zu lassen,
wäre ein vereinfachtes Beitragen außerhalb der Core wünschenswert. Denn
der Kern selbst wird auf absehbare Zeit an Komplexität vermutlich nicht
verlieren.
> Um etwas an der eigentlichen Situation ändern zu können, muss ich aber
> selbst "machen". D.h. den Ansprechpartner-Posten werde ich demnächst
> aufgeben.Ich kann nichts repräsentieren, von dem ich nicht selbst
> überzeugt bin.
Das ist sehr schade zu hören - und das mag ich hier gar nicht
ausdiskutieren. Du bist mit auf dem LinuxTag, oder?
Okay, jetzt sollte ich aber mal wieder anfangen zu "machen".
Viele Grüße,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
