Sonstiges > Offtopic

Anfänger in Foren

<< < (14/15) > >>

Marinero Atlántico:

--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Gut zu wissen, dass es geht. Aber so, wie Du hier im Forum auftrittst - damit meine ich das (durchaus nicht negativ gemeinte) Herumjonglieren mit Akronymen und Fachterminologie - würde ich mich als Kunde, der ja als Nichtexperte anzunehmen ist (sonst würde er ja niemanden mit so was beauftragen) doch sehr erschrecken/verängstigen/verunsichern. Das mal nur nebenbei gesagt.

--- Ende Zitat ---
Mit Kunden rede ich auch anders. I thought this were kind of a developers forum.
Wenn man Fachtermini benutzt - auch um Informationen abzukürzen - kann man also sich gegenüber Kunden nicht verständlich ausdrücken.
Herje. @Gandhi: 5 Arschkopf-Punkte  ;D (womit ich mich dann auch wieder als kommunikationsunfähigen Totalfreak oute, weil ich eben einen solchen Begriff wähle).


Ich gehe davon aus, dass alle Leute www.google.de kennen. Dort kommt man schnell an Definitionen von Fachtermini. Ich finde Fachtermini praktisch.  

Mir kommt es gar nicht darauf an, hier mit jedem zu reden oder von Java überzeugen. Ein paar interessierte reichen mir total aus. Was der Rest denkt, ist mir sowieso egal.


--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Zurück zum außergebietlichen Thema:
Was bei dieser Diskussion um die effizienteste Arbeitsweise oft vergessen wird (ist mein Eindruck) ist, worum es hier im Ansatz eigentlich ging:
Viele dieser Techniken wollen das Problem lösen, dass innerhalb der Projekte oft zu wenig gesprochen wird, bzw. sich nicht verstanden wird oder nicht darüber geredet wird, was eigentlich getan wird (z.B. SCRUM, UML, ...). In der Praxis fürht das meinem Empfinden nach aber dazu, dass man sich dieses Themas durch die Technik entledigen will. Das heißt, man redet nicht mehr, weil man ja UML/Use-Cases einsetzt.

--- Ende Zitat ---
Marco. Man kann auch UML benutzen und reden. Bei sehr großen Teams kann Kommunikation allerdings zum Problem werden. Der Punkt des "zu-starkes-Verlassen-auf-Tools" ist übrigens ausgiebig im Kontext von agile aliance und xtreme programming diskutiert worden.  
 

--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Ähnliches ist immer auch bei anderen Bereichen zu befürchten. Beispiel: QS: Wenn ich Test-Tools (zb. JUnit, QARun, ...) einsetze kann dies zu einer Art Betriebsblindheit aufgrund falscher Sicherheit, die einem so eine Technik vermittelt führen.

--- Ende Zitat ---
Auch dazu gibt es quasi wöchentliche Diskussionen auf www.javablogs.com, www.theserverside.com und www.javaranch.com .
Unit-Testen kann niemals Dinge wie Akzeptanztests, Integrationstests, etc. ersetzen. Es ist lediglich eine Vorstufe, die von vornerein weniger Fehler entstehen lässt.
Ich warne nur vor der umgekehrte Argumentation: Da Unit-Testing auch keine 100%-Sicherheit bietet und sogar die Gefahr besteht, dass diese Sicherheit fälschlicherweise vorgegaukelt wird, dann lassen wir es doch ganz.

--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Aus genau diesem Grund bin ich der Meinung, dass der Verstand immer vor der Technik gehen muss - im Zweifelsfall schon um diese selbst nichtperfekten Konstrukte zu überwachen.

--- Ende Zitat ---
Bin völlig d'accord und würde nie etwas anderes behaupten.

--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Auch kann es ganz schnell dazu führen, dass Dinge benutzt werden, die gar nicht gerechtfertigt sind. Mit Kanonen auf Spatzen schießen. Und so behaupte ich eben, dass es nicht in allen Projekten angebracht ist, mit der Kanone der allumfassenden Technologiekeule um sich zu schießen. Auch hier bedarf es des korrigierenden, wachen und emanzipierten Verstands

--- Ende Zitat ---
Ich würde nie etwas anderes behaupten. Wobei imho in diesem Forum z.B. die Komplexität von Java über- und die von LoNo unterschätzt wird.


--- Zitat von: Gandhi am 03.08.04 - 11:09:20 ---Es gab mal eine Statistik zu gescheiterten Projekten. Da hieß es, dass >80% der Projekte nicht aufgrund technischer, sondern aufgrund kommunikativer Probleme scheitern.

--- Ende Zitat ---
Ja klar. Nur diese ganzen Test-Tools, UML-Diagramme dienen ja gerade dazu, die Reibungsverluste der Kommunikation zu vermindern und die Kommunikation fokussierter und exakter zu machen. Ersetzen können sie menschliche Sprache sowieso nicht.
Es dürfte wohl jeder aus eigener Erfahrung kennen, dass es nicht um die Quantität sondern v.a. auch um die Qualität der Kommunikation geht. Ich bin ein Freund von fokussierter Meetings. (Ohhhh hab ich mich jetzt damit wieder als kommunikationsunfähig geoutet?)

Ich schätze mich im realen Projektalltag übrigens als durchaus kommunikations-sensibel ein.

Gruß Axel

Gandhi:

--- Zitat ---5 Arschkopf-Punkte   (womit ich mich dann auch wieder als kommunikationsunfähigen Totalfreak oute, weil ich eben einen solchen Begriff wähle).
--- Ende Zitat ---
Aha, heute noch nicht geduscht  ;)...Suche unter http://www.google.de nach dem Begriff 'Seife' ;D...

Im Ernst: Ich bin schon davon ausgegangen, dass Du bei Deinen Kunden nicht so auftrittst. Hätte ich vielleicht dazuschreiben sollen...

Kurz die genannten Punkte beantwortend:

Fachtermini: Sind wichtig, hilfreich, effizient - aber: Man sollte auf jeden Fall immer auch ohne diese erklären können, worum es geht. Diesen Eindruck habe ich bei den bisherigen Bullshit-Bingo Runden an denen ich teilgenommen habe (damit meine ich nicht das Forum) selten gehabt. Andererseits muss ich sagen, dass ich persönlich Fachtermini nicht immer mag - das ganze kommt mir irgendwie oft zu menschenfeindlich und selbstverliebt vor - auch wenn ich meist ganz gut damit zurecht komme, fühle ich mich oft ein bisschen dämlich, wenn ich einen Satz mit 3-4 DBAs und 3 weiteren Fachbegriffen ausspreche. Das ist aber ganz klar nur mein persönlicher Geschmack.

Ansonsten: Es freut mich, dass Du es genauso siehst, dass Techniken kein Selbstläufer und keine Grund für das Ausschalten von Verstand sein können. Genau diesen Punkt wollte ich unterstrichen wissen, da ich sehr oft auch in den 'besten' Unternehmen dieses Landes durchaus anderes erlebt habe.

Marinero Atlántico:

--- Zitat von: Gandhi am 03.08.04 - 12:53:09 ---
Ansonsten: Es freut mich, dass Du es genauso siehst, dass Techniken kein Selbstläufer und keine Grund für das Ausschalten von Verstand sein können. Genau diesen Punkt wollte ich unterstrichen wissen, da ich sehr oft auch in den 'besten' Unternehmen dieses Landes durchaus anderes erlebt habe.

--- Ende Zitat ---

Ich bin sogar der Meinung, dass sich Unternehmen Mechanismen überlegen sollten, die solche obercoolen, strategisch-denkenden Menschen entsprechend zur Rechenschaft ziehen, wenn Sie nach 6 Monaten Rhetorik und Übersehen von sehr vielen Details mal wieder ein Projekt vor die Wand gefahren haben. In der Zwischenzeit haben sie dann kübelweise Liebe und Zuneigung von bestimmten Leuten erhalten und Kritik wurde mit jenem breiten, allwissenden Grinsen ausgeschaltet.

Ich hatte dieses Jahr eine längere Diskussion mit einem Projekt-Leiter beim Kunden, in dessen Verlauf das tolle Testsystem im Namen von Realismus deutlich umgestellt wurde.
Menschen hören nicht gerne Kritik und man muss da sehr vorsichtig sein.
Das gute an krisenhaften Situationen ist aber, dass Leute einen dann eher mal auch bei unangenehmen Sachen zuhören.  

Gruß Axel

Gandhi:
Na ja,
mein Lateinlehrer hat mal gesagt, es sei unhöflich Leute mit Fremdwörtern 'an die Wand zu klatschen', womit er, wie ich finde, Recht hatte.
Umgekehrt leitet sich für mich das Muß für alle Projektbeteiligten ab, so lange nachzufragen, bis er/sie auch tatsächlich verstanden hat, worum es geht.
Das Tückische im Projekt ist oft, dass es als unqualifiziert angesehen wird, nicht zu verstehen, was ein ABCXY mit einem GFNHD ist. Bevor man sich dann als 'Dummie' outet, schluckt man lieber was da gesagt wurde unverstanden runter. Ein gängiger Mechanismus wäre also tatsächlich immer jeden Fachterminus zu erklären, Abkürzungen aufzulösen etc. Tatsächlich bedeutet dies dann, dass man sich auf die Schnittmenge gemeinsamen Wissens in der Kommunikation beschränken müsste oder einen gemeinsamen Stand via Schulung o.ä. schafft. Knifflig, wie ich finde.
Bei dem Projekt, das ich gerade beobachte, haben sie dann tatsächlich 20 Leute in Use-Cases geschult und ein Projektumfassendes Glossar erstellt. Sehr umständlich - aber, wie ich finde, unumgänglich um Kommunikationsengpässe zu vermeiden.

Voraussetzung sind aber selbstbewußte Projektteilnehmer, die auch zugeben etwas nicht zu kennen (sehr schwer, wenn man die heutigen Job/Projektausschreibungen ansieht) und eine große Offenheit im Umgang miteinander innerhalb des Teams.
Auch dies ist eine Schlüsselqualifikation für die zukünftige Generation von Software-Entwicklern, die diese deutlich von den bisherigen unterscheiden wird. Wer gänzlich unkommunikativ ist, wird in der Zukunft kaum noch IT-Karriere machen können.

Das wiederum, würde mich dann zu den gängigen IT-Studiengänge (v.a. Informatik) führen und zu der Frage, wo genau diese Skills gelehrt werden. Ich glaube Nirgendwo. Aber das wäre dann ein ganz anderes Off-Topic-Thema...

Ach ja, mir ist da gerade noch die Lösung für das Kommunikationsproblem im Projekt eingefallen:

SUSD
(Selbstbewußter Universeller Super Dummie  ;D)
Einfach immer jemandem im Projekt plazieren, der zwar keine Ahnung hat, aber sich dennoch traut Fragen zu stellen. Stellvertretend für die anderen Projektteilnehmer sozusagen.
Eine Stellenausschreibung für einen SUSD könnte dann sehr interessant aussehen...sozusagen die Negation aller anderen Ausschreibungen.

Marinero Atlántico:

--- Zitat von: Gandhi am 03.08.04 - 17:43:29 ---Bei dem Projekt, das ich gerade beobachte, haben sie dann tatsächlich 20 Leute in Use-Cases geschult und ein Projektumfassendes Glossar erstellt. Sehr umständlich - aber, wie ich finde, unumgänglich um Kommunikationsengpässe zu vermeiden.

--- Ende Zitat ---
... wobei diese Begriffe der inhaltlichen Domäne des Softwareprojekts entstammen. Wenn es z.B. eine bankfachliche Anwendung ist, müssen die Entwickler bis zu einem gewissen Grade die bankfachliche Begriflichkeit in einem Zusammenhang bringen.
Es werden aber sicher nicht so Sachen wie EJB, Corba, Klasse, Methode oder Sequenz-Diagramm im Glossar aufgenommen.

Die Softwaretechnische Begrifflichkeit wird einfach erwartet. Bei dem jeweiligen Domänenthema, worum sich das Projekt dreht, muss nachgefragt werden.  


--- Zitat von: Gandhi am 03.08.04 - 17:43:29 ---Das wiederum, würde mich dann zu den gängigen IT-Studiengänge (v.a. Informatik) führen und zu der Frage, wo genau diese Skills gelehrt werden. Ich glaube Nirgendwo. Aber das wäre dann ein ganz anderes Off-Topic-Thema...

--- Ende Zitat ---
Ich glaube einige Informatiker haben eine uneingestandene Angst, dass ihre lange Ausbildung nichts gebracht hat und ihnen irgendwelche Umschüler von den Fleischtöpfen verdrängen.
 
Ich würde aber gerade explizit tiefere Informatik-Kenntnisse nicht unbedingt niedermachen. Ich sehe viele Projekte, wo man den Schlüssel des Misserfolges in Informatikbüchern findet.


--- Zitat von: Gandhi am 03.08.04 - 17:43:29 ---(Selbstbewußter Universeller Super Dummie  ;D)
Einfach immer jemandem im Projekt plazieren, der zwar keine Ahnung hat, aber sich dennoch traut Fragen zu stellen. Stellvertretend für die anderen Projektteilnehmer sozusagen.

--- Ende Zitat ---
Das sehe ich ein wenig anders, glaub ich.
Im Kernbereich der Arbeit (also der RDBMS-, OO-, Notes-, Web-, wasAuchImmerEntwicklung ist aus Effizienzgründen eine gewisse begriffliche und konzeptionelle Strenge unumgänglich.

In Foren wird da von bestimmten, aber nicht allen Leuten auf Anfängerfragen genervt reagiert.

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete