1. Foren
  2. Kommentare
  3. Sonstiges
  4. Alle Kommentare zum Artikel
  5. › Software-Entwicklung: Wenn alle…

Gute Problemanalyse

  1. Thema

Neues Thema Ansicht wechseln


  1. Gute Problemanalyse

    Autor: led02 10.09.20 - 13:16

    Das Problem der Kommunikation kenne ich auch sehr gut aus meinen Projekten. Auch wenn sich die Situation im wissenschaftlichen Umfeld, in dem ich tätig bin, etwas anders darstellt, so sind es doch auch häufig die verschiedenen Begrifflichkeiten, die zu Missverständnissen führen.

    Wo ich allerdings etwas enttäuscht bei diesem Artikel bin, ist die Sichtweise des Autors zu den Lösungsansätzen. Diese lesen sich zum einen wie Binsenweisheiten, nutzen Fachbegriffe, die für adressierte die Zielgruppe der Nicht-Software-Entwickler kaum verständlich sind, und schieben die Verantwortung vor allem auf ominöse "Projekt-Manager" ab.

    In meinem Job habe ich viel mit hochspezialisierte "Fachidioten" zu tun, die meist ein paar wenige Grundkenntnisse im Programmieren haben und ihre "Codes" dahinstümpern. Ich versteh meine Rolle als studierter Software-Entwickler nun aber genau darin, als Übersetzer zu arbeiten - nicht zwichen den "Fachidioten" und den Programmierern sondern zwischen den Wissenschaftlern und den Computern, denen sie ihre Aufgabe eigentlich erklären wollen. Schon früh habe ich deswegen erkannt, dass es für mich einfacher ist, ein Grundverständnis für den "Grenzsteuersatz" oder einen "Staupunkt" zu erlangen, sodass meine "Kunden" sich in ihrem Fachgebiet aufhalten können.

    Dabei helfen mit Sicherheit die dargestellten Werkzeuge: Technische Spezifikationen, Glossare, Ticket-Systeme etc. Aber auch hier ist es doch so: Ich kenne diese Werkzeuge als Software-Entwickler sehr gut und weiß auch genau, was sie zu leisten fähig sind. Das Fachpersonal, mit dem ich zu tun habe, sieht diese Tools jedoch erstmal als Behinderung an und so liegt es an mir, ihnen eine Arbeitsweise zu vorzuschlagen, die für sie verständlich ist und möglichst wenig Umgewöhnung fordert. Dann kann schließlich auch die Kommunikation über für mich gewohnte Wege erfolgen, wenn vielleicht auch nicht in dem Detailgrad, wie es das Idealmodell vorsieht.

    Am Ende führt das dazu, dass unsere Entwicklungsprozesse sehr individuell und pragmatisch umgesetzt sind. Aber da sie auf die Anwender ausgerichtet sind, kommen die sehr gut damit zu recht und können selbstständig neue Mitarbeiter anlernen. Die dadurch gewonnene Zeit kann dann von meiner Seite wiederum dafür genutzt werden, die Prozesse weiter anzupassen und zu verbessern - immer mit dem Fokus auf den Nutzern.

  2. Re: Gute Problemanalyse

    Autor: rizzorat 10.09.20 - 15:37

    Meine erster Job nach der Uni war ein Großprojekt der EU. Gesamtumfang 1.1 Mrd Euro, nur auf unserer Seite.

    Als kleiner Junior Ingenieur der mithelfen sollte habe ich am Anfang erstmal nur die Klappe gehalten, weil ich vieles nicht verstanden habe. Die Firma war völlig überfordert mit der Größe des Projektes und wir Nachwuchsingenieure haben sehr schnell sehr viel Verantwortung bekommen. Man wächst mit seinen Aufgaben war die Devise.

    Nach gerademal 2 Jahren ist mir der Hut hoch gegangen in einem Meeting. Da saßen sich gestande Ingenieure und Softwareentwickler gegebenüber, Jahrzehnte an Erfahrung und haben sich gegenseitig angeschrieen wieso es denn an allen Ecken knackt und knarzt und nix funktioniert. Wie die Kleinkinder.

    Ich hab dann nur dazwischen gebrüllt "Alter ihr sprecht nicht die selbe Sprache!!! Du (zum Electrical Architect) redest mit Vokabeln die 20 Jahre alt sind aus der Rubrik der anlalogen Schaltungstechnik, die du verstehst, mit einem Softwareentwickler der teilweise die selben Begriffe nutzt , die in seinem Genre aber eine völlig andere Bedeutung haben!!! Und unser Req. Ingeneiur ist zu dumm das zu erkennen und entsprechend zu übersetzen!!!"

    Bumms da war erstmal Ruhe. Ich hatte nen hochroten Kopf weil ich natürlich mich weeeeit ausm Fenster gelehnt hatte.

    Ich hab aus meiner Sparte dann ein paar Beispiele aufgezählt wie unglaublich schlecht die Requirements der E-Ingenieure in die Req. der Firmware übersetzt worden sind. Das hatte teilweise nicht mal ansatzweise was mit der Intention des E-Ingenieurs zu tun. Es hatte mich Wochen gekostet die "Übersetzungen" zu korrigieren so das meine kleine Ecke zumindestens die Firmware so lief wie es das elektrische Design vorsah.

    Das schlimme war das die End-Reqs. für die Firmware von den E-Ingenieuren nicht korrektur gelesen wurden, die haben nur die Toplevel req. eingetippt ins System und eine Req.-Engineering Gruppe hatte das dann auf einzele Reqs. für die Firmware Leute runtergebrochen.

    Das schlimme war dann das diese Req.Engineering Gruppe genauso aus Studienabgängern bestand die teilweise fachlich weder aus Elektrotechnik noch Software/Firmware kamen. Als wenn Blinde von Farbe erzählen sollen.......

    Lösung der ganze Sache: Subsystem Ingenieure und entsprechende Firmware-Entwickler haben sich dann in 2 Wochen in ein Büro gesetzt und mal (teilweise das erstmal überhaupt) mit einander geredet.

    Am Ende lief das System wie es sollte jedoch mit 18 Monaten Verzug, knapp 50mio ¤ Konventionalstrafe wegen dem Verzug.

    Mein Senior Ingenieur war stolz wie bolle weil sein kleiner Schützling da mal seine Meinung gegeigt hatte. Dem Schützling (mir) wurde vom Projektleiter der Kopf gewaschen weil ich solche Kritik nicht anzubringen hatte.

    Entsprechend war ich nach Abschluss des Projektes weg. ging auf keine Kuhhaut das ganze.

  3. Re: Gute Problemanalyse

    Autor: coder 11.09.20 - 11:22

    rizzorat schrieb:
    --------------------------------------------------------------------------------
    > Meine erster Job nach der Uni war ein Großprojekt der EU. Gesamtumfang 1.1
    > Mrd Euro, nur auf unserer Seite.
    >
    > Als kleiner Junior Ingenieur der mithelfen sollte habe ich am Anfang
    > erstmal nur die Klappe gehalten, weil ich vieles nicht verstanden habe. Die
    > Firma war völlig überfordert mit der Größe des Projektes und wir
    > Nachwuchsingenieure haben sehr schnell sehr viel Verantwortung bekommen.
    > Man wächst mit seinen Aufgaben war die Devise.
    >
    > Nach gerademal 2 Jahren ist mir der Hut hoch gegangen in einem Meeting. Da
    > saßen sich gestande Ingenieure und Softwareentwickler gegebenüber,
    > Jahrzehnte an Erfahrung und haben sich gegenseitig angeschrieen wieso es
    > denn an allen Ecken knackt und knarzt und nix funktioniert. Wie die
    > Kleinkinder.
    >
    > Ich hab dann nur dazwischen gebrüllt "Alter ihr sprecht nicht die selbe
    > Sprache!!! Du (zum Electrical Architect) redest mit Vokabeln die 20 Jahre
    > alt sind aus der Rubrik der anlalogen Schaltungstechnik, die du verstehst,
    > mit einem Softwareentwickler der teilweise die selben Begriffe nutzt , die
    > in seinem Genre aber eine völlig andere Bedeutung haben!!! Und unser Req.
    > Ingeneiur ist zu dumm das zu erkennen und entsprechend zu übersetzen!!!"
    >
    > Bumms da war erstmal Ruhe. Ich hatte nen hochroten Kopf weil ich natürlich
    > mich weeeeit ausm Fenster gelehnt hatte.
    >
    > Ich hab aus meiner Sparte dann ein paar Beispiele aufgezählt wie
    > unglaublich schlecht die Requirements der E-Ingenieure in die Req. der
    > Firmware übersetzt worden sind. Das hatte teilweise nicht mal ansatzweise
    > was mit der Intention des E-Ingenieurs zu tun. Es hatte mich Wochen
    > gekostet die "Übersetzungen" zu korrigieren so das meine kleine Ecke
    > zumindestens die Firmware so lief wie es das elektrische Design vorsah.
    >
    > Das schlimme war das die End-Reqs. für die Firmware von den E-Ingenieuren
    > nicht korrektur gelesen wurden, die haben nur die Toplevel req. eingetippt
    > ins System und eine Req.-Engineering Gruppe hatte das dann auf einzele
    > Reqs. für die Firmware Leute runtergebrochen.
    >
    > Das schlimme war dann das diese Req.Engineering Gruppe genauso aus
    > Studienabgängern bestand die teilweise fachlich weder aus Elektrotechnik
    > noch Software/Firmware kamen. Als wenn Blinde von Farbe erzählen
    > sollen.......
    >
    > Lösung der ganze Sache: Subsystem Ingenieure und entsprechende
    > Firmware-Entwickler haben sich dann in 2 Wochen in ein Büro gesetzt und mal
    > (teilweise das erstmal überhaupt) mit einander geredet.
    >
    > Am Ende lief das System wie es sollte jedoch mit 18 Monaten Verzug, knapp
    > 50mio ¤ Konventionalstrafe wegen dem Verzug.
    >
    > Mein Senior Ingenieur war stolz wie bolle weil sein kleiner Schützling da
    > mal seine Meinung gegeigt hatte. Dem Schützling (mir) wurde vom
    > Projektleiter der Kopf gewaschen weil ich solche Kritik nicht anzubringen
    > hatte.
    >
    > Entsprechend war ich nach Abschluss des Projektes weg. ging auf keine
    > Kuhhaut das ganze.

    +1

  4. Re: Gute Problemanalyse

    Autor: aemm202009 13.09.20 - 09:02

    Auch mir ging es so.

    Die Analyse selbst, bzw. der gut zusammengefasste Erfahrungsbericht setzt den Leser, der ähnliche Erfahrungen gemacht hat, in einen reflektorischen Zustand. Sicherlich sogar in einen, dass für das nächste Projekt nochmal Dinge versucht werden, zu verbessern - denn immer wieder wiederholen dieser Probleme hilft temporär immer.

    Aber schon jetzt, weiss man dass die "Binsenweisheiten" wahrscheinlich nicht tiefgreifend Bestand haben werden.

    Der Artikel geht nämlich nicht weit genug. Er bleibt philosophisch gesehen auf einer gewissen Dimension stehen - und auf der Dimension werden die eigentlichen Probleme nicht gelöst und fressen sich dann wieder nach außen, egal wie sehr sich die Beteiligten bemühen, "besser" zu kommunizieren.

    Der Ansatz, dass der/die Entwickler in das fachliche mit einsteigen müssen, ist eine Dimension weiter. Eine andere Dimension wäre, dass wesentliche Rollen auf der fachlichen Seite einsteigen in die Komplexität, bzw. bereit sind, Komplexität zu zulassen, denn: Komplexes kann man nicht vereinfachen.
    Eine weitere Dimension wäre, dass alle Beteiligten sich von Anfang an gewahr sein müssen, dass niemand am Anfang das weiss, was er dann auf dem Wege durch das Projekt an Wissen aufnimmt. Im Artikel stoppte es an der Stelle, dass bei grossen Projekten niemand alles weiss, sondern viele zum Grossen Ganzen beitragen und sich gegenseitig ggf. erläutern. Der Artikel geht nicht darauf, wie alle Beteiligten ständig aufgrund der Auseinandersetzung mit dem Projektgeschehen und den Mitbeteiligten neues Wissen aufnehmen - und zwar nicht durch Erlernen von anderen Beteiligten, sondern durch neues (Er-)Denken, das zu neuen Erkenntnissen führt, aufsammeln: gerade bei Innovativen Projekten, was häufig auf Softwareentwicklung, die immer ein höchst kreativer Prozess ist, passt. Und dieses Wissen auf das Projektgeschehen selbst wieder sehr stark einwirkt - ein absolut chaotisches Prinzip.

    Und das ist m.E.(!) das größte philosophische Problem: Chaos <> Ordnung. Die meisten Projektleiter sind sich nicht bewusst, dass ein Projekt das Problem des organisierten Chaos hat. Meist wird versucht das Chaos durch extrem (ordentliche) Organisation in Ordnung zu überführen - was nie funktioniert. Man hat aber immer das Problem, dass man durch zu viel Ordnung wieder Chaos schafft (Mitchell Feigenbaum/Feigenbaum-Diagramm).

    Also, aus meiner Sicht muss man etliche weitere Ebenen betrachten und versuchen hierfür Lösungen oder mindestens Bewusstsein schaffen. In etlichen Projektmethoden stecken oft in dem warum diese Submethode so gestaltet wurde, hintergruendig etliche philosophische Problematiken drinnen. Sie verstecken das warum aber oft, in der Annahme, die meisten werden allerhöchstens die Methode erlernen können, aber das Warum nicht verstehen - und wenn man einige Jahre in der Wirtschaft zugebracht hat, kann man diese Annahme verstehen. Vielleicht ist es aber an der Zeit die Philosophie und nicht nur das intellektuell fertig geschlussfolgerte Protokoll nach außen zu tragen.

    Cheers,
    A.Emm

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. European Bank for Financial Services GmbH (ebase®), Aschheim
  2. NetApp Deutschland GmbH, Hamburg, Berlin
  3. Deutsche Nationalbibliothek, Frankfurt am Main
  4. Hays AG, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Xbox Series S für 290,99€, Xbox Wireless Controller Carbon Black/Robot White/Shock Blue...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Made in USA: Deutsche Huawei-Gegner schweigen zu Juniper-Hintertüren
Made in USA
Deutsche Huawei-Gegner schweigen zu Juniper-Hintertüren

Zu unbequemen Fragen schweigen die Transatlantiker Manuel Höferlin, Falko Mohrs, Metin Hakverdi, Norbert Röttgen und Friedrich Merz. Das wirkt unredlich.
Eine Recherche von Achim Sawall

  1. Sandworm Hacker nutzen alte Exim-Sicherheitslücke aus

Geforce RTX 3060 Ti im Test: Die wäre toll, wenn verfügbar-Grafikkarte
Geforce RTX 3060 Ti im Test
Die "wäre toll, wenn verfügbar"-Grafikkarte

Mit der Geforce RTX 3060 Ti bringt Nvidia die Ampere-Technik in das 400-Euro-Segment. Dort ist die Radeon RX 5700 XT chancenlos.
Ein Test von Marc Sauter

  1. Supercomputer-Beschleuniger Nvidia verdoppelt Videospeicher des A100
  2. Nvidia Geforce RTX 3080 Ti kommt im Januar 2021 für 1.000 US-Dollar
  3. Ampere-Grafikkarten Specs der RTX 3080 Ti und RTX 3060 Ti

Star Wars: Darth-Vader-Darsteller Dave Prowse ist tot
Star Wars
Darth-Vader-Darsteller Dave Prowse ist tot

Er war einer der großen Stars der originalen Star-Wars-Trilogie und doch kaum jemandem bekannt. David Prowse ist im Alter von 85 Jahren gestorben.
Ein Nachruf von Peter Osteried

  1. Spaceballs Möge der Saft mit euch sein
  2. The Mandalorian Erste Folge der zweiten Staffel ist online
  3. Star Wars Disney und Lego legen Star Wars Holiday Special neu auf