Ich finde die starke Betonung von Kommunikation und Soft Skills unbefriedigend. Nicht etwa, weil ich finde, dass sie unwichtig sind. Sie sind sehr wichtig für alles, was man im Leben anstellt, darunter auch die Entwicklung von IT-Systemen. Aber wenn ich etwas enger auf IT schaue, dann stelle ich fest, dass man allein mit noch so guten Kommunikationsfähigkeiten keine guten IT-Systeme bauen wird. Darüber hinaus werden spezifischere Skills benötigt. Aus meiner Sicht ist das insbesondere Umgang mit Komplexität. Vor allem die Fähigkeit, Komplexität beherrschbar zu machen, etwa mit Abstraktion, wie Mike Sperber vorschlägt.
Ja, das ist eine gute Antwort auf die vielen Antworten im Bereich Soft Skills und ein guter Aspekt. Auf der anderen Seite sind die meisten Systeme heute nicht wirklich anspruchsvoll. Und Wissen kann man sich relativ leicht als Dienstleistung kaufen. Aber wenn die Kommunikation und Organisation nicht stimmt, geht es schief. Oder andersrum: Wenn Organisation und Kommunikation stimmen, wird die Organisation einen Weg finden, technische Probleme zu lösen.
@@EberhardWolff Ja, genau, Wissen kann man sich von Leuten wie dir oder mir (bzw. unseren Arbeitgebern) dazu kaufen und wir sind dann diejenigen, die die IT-spezifischen Probleme lösen. Dazu brauchen wir bestimmte Skills, die über gute Kommunikationsfähigkeiten hinaus gehen. Wenn man aus genügend großem Abstand schaut, sind die meisten Systeme tatsächlich nicht anspruchsvoll. Da gehen Daten rein, werden gespeichert, irgendwie verknüpft und schließlich kommen sie wieder raus. Wenn so ein System von Leuten ohne spezifische IT-Skills entwickelt wurde, hat es 1000 Tabellen mit unzähligen Spalten, deren Namen niemand mehr versteht, in denen redundante, inkonsistente Daten stehen. Irgendwo, weit verteilt über Stored Procedures und Client-Anwendungen, verstecken sich die Geschäftsregeln, natürlich kreativ unterschiedlich implementiert. Da ist die "accidental complexity" auf 11 gedreht und es ist leider sehr anspruchsvoll, daran etwas zu ändern. Es hätte nicht so kommen müssen, ist es aber, weil bestimmte Skills gefehlt haben.
@@MichaelSchuerig Das ist die Frage. Schlechte Kommunikation könnte auch die Erklärung für die chaotischen Strukturen der Systeme sein - frei nach Conway.
@@MichaelSchuerig nun ja - so'n ungeschicktes Datenmodell ist wohl das Ergebnis fehlender Erfahrung - insbesondere Erfahrung in der Größenordnung. Wer mal ein System mit 100 Tabellen gebaut hat, hat einen gewissen Erfahrungsschatz. Der reicht aber nicht, um ein System mit 1000 Tabellen zu bauen. Er kann an so einem System mitbauen - aber er kann nicht sagen 'ich weiß, wie es geht'. Das gilt eigentlich für jede Art von Größenordnungs-Sprung: wer ein System für die Betreuung durch 100 Client-Plätze bauen kann, kann noch lange kein System mit 1000 Client-Plätzen entwerfen. Wer ein Team mit 10 Leuten leiten kann, kann noch lange nicht 10 Teams mit je 10 Leuten leiten. Wer ein Projekt mit Budget 100K EUR umsetzen kann, wird beim Projekt mit 1Mio EUR ganz sicher viele neue Dinge lernen. Dies sind ganz sicher keine 'Skills', die man inner Uni oder aufm Lehrgang 'richtig lernen' kann - da kann man davon hören - aber zum 'Können' ist es ein weiter Weg.
@@DinHamburg Ich finde keinen Widerspruch in unseren Aussagen, oder habe ich den übersehen? Ich kenne so große Systeme selbst nur aus der Distanz. Was ich aber bei jedem davon mitbekommen habe, wenn ich in die Nähe gekommen bin, ist, dass es nicht so groß angefangen hat, sondern mit der Zeit auf die Größe angewachsen ist. Dabei sind aber anscheinend die Strukturierungsmittel nicht mit gewachsen. Mir geht es darum, dass es durchaus IT-spezifische Skills gibt, die über das hinaus gehen, was man ohnehin überall im Leben braucht. Wie ich bereits geschrieben habe, sehe ich da insbesondere, die Fähigkeit mit Komplexität umzugehen und sie in Schach zu halten. Wie man das am besten lernt? Soweit ich es selbst kann, ist mein Eindruck, dass es nur durch eine Kombination aus Theorie und Praxis geht.
Danke Eberhard insbes. für deine Anmerkung: "Warum ist eine Entscheidung so gefällt?" Wenn dazu kein Feedback kommt, ist dann nicht jede weitere Frage überflüssig? Wir gehen immer davon aus, dass jede Seite kommunikationsbereit ist. Es scheint aber oft nicht so zu sein. Hohe Motivation trifft auf "Sparflamme", 80% und schafft Frustration. Ich bin Softwareentwickler aus Leidenschaft und musste lernen, dass es mir nicht mehr Leiden schafft. Danke an euch für die anregende Diskussion.
Es gibt ja immer einen Grund für eine Entscheidung, vielleicht wird sie nur nicht kommuniziert. Ich bin aber auch nicht sicher, was die Lösung ist. Man kann versuchen, die Situation zu verbessern. Wenn man sich damit nicht wohlfühlt, gibt es immer die Chance, ineinen anderen Kontext zu wechseln. Es gibt leider Kontexte, die man nicht wirklich verbessern kann. Vielleicht hilft das?
@@EberhardWolff In diesem Fall war es eine strategische Entscheidung, Softwareentwicklung an eine andere Firma zu geben. Argumente für die Fortführung der Entwicklung in house waren dabei nicht (mehr) von Interesse bzw. irrelavant. Leider stelle ich fest, dass gerade in Unternehmen die viel mit Kommunikation zu tun haben, gerade intern schlecht kommuniziert wird.
@@ThomasFunke Ja, solche Sachen zu kommunzieren ist auch anspruchsvoll. Eine solche Entwscheidung zeigt ja auch nicht wirklich einen Fokus der Firma auf Software-Entwicklung....
Tatsächlich war ich derjenige, der gesagt hat, dass "Kommunikation" der wichtigste Skill ist und die technische Expertise nachfolgt. Hintergrund meiner Aussage ist, die Erfahrung aus zig Projekten in denen zu 95% Personen mit einem hohen bis sehr hohen technischen Skill gearbeitet haben. Die technische Expertise war oft nicht das Problem, denn die bekommt man mit Zeit & Geld aufgebaut indem man entweder Personen schult oder sich Expertise über externe Berater reinholt. Wenn allerdings wirklich gute Techniker nicht gut miteinander kommunizieren können und damit die Teamfähigkeit leidet, dann ist das Projekt definitiv in Gefahr. Was ich damit nicht sagen wollte, war, die technische Expertise unwichtig ist. Software wird von Menschen für Menschen entwickelt, Tools und Techniken sind die Werkzeuge, die ich beherrschen muss.
FInde ich passend. Vermutlichen haben die meisten Kommunikation verwendet, weil dort in der Praxis so viele Probleme und Mängel sind - und dadurch wichtiger als technische Skill ist, die eher vorhanden sind.
nochmal zu dem 'Nachspielen mit Handpuppen' - Harald Schmidt hat in einigen seiner Shows komplexe wirtschaftliche, historische, u.a. Abläufe mit Playmobil-Figuren dargestellt. So abwegig ist das also nicht.
Ich finde die starke Betonung von Kommunikation und Soft Skills unbefriedigend. Nicht etwa, weil ich finde, dass sie unwichtig sind. Sie sind sehr wichtig für alles, was man im Leben anstellt, darunter auch die Entwicklung von IT-Systemen. Aber wenn ich etwas enger auf IT schaue, dann stelle ich fest, dass man allein mit noch so guten Kommunikationsfähigkeiten keine guten IT-Systeme bauen wird. Darüber hinaus werden spezifischere Skills benötigt. Aus meiner Sicht ist das insbesondere Umgang mit Komplexität. Vor allem die Fähigkeit, Komplexität beherrschbar zu machen, etwa mit Abstraktion, wie Mike Sperber vorschlägt.
Ja, das ist eine gute Antwort auf die vielen Antworten im Bereich Soft Skills und ein guter Aspekt. Auf der anderen Seite sind die meisten Systeme heute nicht wirklich anspruchsvoll. Und Wissen kann man sich relativ leicht als Dienstleistung kaufen. Aber wenn die Kommunikation und Organisation nicht stimmt, geht es schief. Oder andersrum: Wenn Organisation und Kommunikation stimmen, wird die Organisation einen Weg finden, technische Probleme zu lösen.
@@EberhardWolff Ja, genau, Wissen kann man sich von Leuten wie dir oder mir (bzw. unseren Arbeitgebern) dazu kaufen und wir sind dann diejenigen, die die IT-spezifischen Probleme lösen. Dazu brauchen wir bestimmte Skills, die über gute Kommunikationsfähigkeiten hinaus gehen.
Wenn man aus genügend großem Abstand schaut, sind die meisten Systeme tatsächlich nicht anspruchsvoll. Da gehen Daten rein, werden gespeichert, irgendwie verknüpft und schließlich kommen sie wieder raus. Wenn so ein System von Leuten ohne spezifische IT-Skills entwickelt wurde, hat es 1000 Tabellen mit unzähligen Spalten, deren Namen niemand mehr versteht, in denen redundante, inkonsistente Daten stehen. Irgendwo, weit verteilt über Stored Procedures und Client-Anwendungen, verstecken sich die Geschäftsregeln, natürlich kreativ unterschiedlich implementiert. Da ist die "accidental complexity" auf 11 gedreht und es ist leider sehr anspruchsvoll, daran etwas zu ändern. Es hätte nicht so kommen müssen, ist es aber, weil bestimmte Skills gefehlt haben.
@@MichaelSchuerig Das ist die Frage. Schlechte Kommunikation könnte auch die Erklärung für die chaotischen Strukturen der Systeme sein - frei nach Conway.
@@MichaelSchuerig nun ja - so'n ungeschicktes Datenmodell ist wohl das Ergebnis fehlender Erfahrung - insbesondere Erfahrung in der Größenordnung.
Wer mal ein System mit 100 Tabellen gebaut hat, hat einen gewissen Erfahrungsschatz. Der reicht aber nicht, um ein System mit 1000 Tabellen zu bauen. Er kann an so einem System mitbauen - aber er kann nicht sagen 'ich weiß, wie es geht'. Das gilt eigentlich für jede Art von Größenordnungs-Sprung: wer ein System für die Betreuung durch 100 Client-Plätze bauen kann, kann noch lange kein System mit 1000 Client-Plätzen entwerfen. Wer ein Team mit 10 Leuten leiten kann, kann noch lange nicht 10 Teams mit je 10 Leuten leiten. Wer ein Projekt mit Budget 100K EUR umsetzen kann, wird beim Projekt mit 1Mio EUR ganz sicher viele neue Dinge lernen.
Dies sind ganz sicher keine 'Skills', die man inner Uni oder aufm Lehrgang 'richtig lernen' kann - da kann man davon hören - aber zum 'Können' ist es ein weiter Weg.
@@DinHamburg Ich finde keinen Widerspruch in unseren Aussagen, oder habe ich den übersehen?
Ich kenne so große Systeme selbst nur aus der Distanz. Was ich aber bei jedem davon mitbekommen habe, wenn ich in die Nähe gekommen bin, ist, dass es nicht so groß angefangen hat, sondern mit der Zeit auf die Größe angewachsen ist. Dabei sind aber anscheinend die Strukturierungsmittel nicht mit gewachsen.
Mir geht es darum, dass es durchaus IT-spezifische Skills gibt, die über das hinaus gehen, was man ohnehin überall im Leben braucht. Wie ich bereits geschrieben habe, sehe ich da insbesondere, die Fähigkeit mit Komplexität umzugehen und sie in Schach zu halten. Wie man das am besten lernt? Soweit ich es selbst kann, ist mein Eindruck, dass es nur durch eine Kombination aus Theorie und Praxis geht.
Danke Eberhard insbes. für deine Anmerkung: "Warum ist eine Entscheidung so gefällt?" Wenn dazu kein Feedback kommt, ist dann nicht jede weitere Frage überflüssig? Wir gehen immer davon aus, dass jede Seite kommunikationsbereit ist. Es scheint aber oft nicht so zu sein. Hohe Motivation trifft auf "Sparflamme", 80% und schafft Frustration. Ich bin Softwareentwickler aus Leidenschaft und musste lernen, dass es mir nicht mehr Leiden schafft. Danke an euch für die anregende Diskussion.
@@ThomasFunke Danke für das positive Feedback! 🙂
Es gibt ja immer einen Grund für eine Entscheidung, vielleicht wird sie nur nicht kommuniziert. Ich bin aber auch nicht sicher, was die Lösung ist. Man kann versuchen, die Situation zu verbessern. Wenn man sich damit nicht wohlfühlt, gibt es immer die Chance, ineinen anderen Kontext zu wechseln. Es gibt leider Kontexte, die man nicht wirklich verbessern kann. Vielleicht hilft das?
@@EberhardWolff In diesem Fall war es eine strategische Entscheidung, Softwareentwicklung an eine andere Firma zu geben. Argumente für die Fortführung der Entwicklung in house waren dabei nicht (mehr) von Interesse bzw. irrelavant.
Leider stelle ich fest, dass gerade in Unternehmen die viel mit Kommunikation zu tun haben, gerade intern schlecht kommuniziert wird.
@@ThomasFunke Ja, solche Sachen zu kommunzieren ist auch anspruchsvoll. Eine solche Entwscheidung zeigt ja auch nicht wirklich einen Fokus der Firma auf Software-Entwicklung....
Tatsächlich war ich derjenige, der gesagt hat, dass "Kommunikation" der wichtigste Skill ist und die technische Expertise nachfolgt. Hintergrund meiner Aussage ist, die Erfahrung aus zig Projekten in denen zu 95% Personen mit einem hohen bis sehr hohen technischen Skill gearbeitet haben. Die technische Expertise war oft nicht das Problem, denn die bekommt man mit Zeit & Geld aufgebaut indem man entweder Personen schult oder sich Expertise über externe Berater reinholt. Wenn allerdings wirklich gute Techniker nicht gut miteinander kommunizieren können und damit die Teamfähigkeit leidet, dann ist das Projekt definitiv in Gefahr.
Was ich damit nicht sagen wollte, war, die technische Expertise unwichtig ist. Software wird von Menschen für Menschen entwickelt, Tools und Techniken sind die Werkzeuge, die ich beherrschen muss.
FInde ich passend. Vermutlichen haben die meisten Kommunikation verwendet, weil dort in der Praxis so viele Probleme und Mängel sind - und dadurch wichtiger als technische Skill ist, die eher vorhanden sind.
nochmal zu dem 'Nachspielen mit Handpuppen' - Harald Schmidt hat in einigen seiner Shows komplexe wirtschaftliche, historische, u.a. Abläufe mit Playmobil-Figuren dargestellt.
So abwegig ist das also nicht.
Also ich würde mich das ehrlich gesagt in einer Vorstandspräsentation schlicht nicht trauen.
@@EberhardWolff kommt auf die Mannschaft an - würde aber nachhaltig in Erinnerung bleiben.
@@DinHamburg Das ist nicht immer positiv... 😉
Wenn man die Figuren in einer PowerPoint einbaut, dann könnte es wieder gehen...