4:03 Da muss ich dir aber Widersprechen; wenn dem Software-Chef der Abteilung nicht interessiert, wie seine Abteilung arbeitet (Code-Review, Entwicklungsprozessabläufe, verwendete Programmiersprache(-n), Festlegen der Reihenfolge zur Arbeitung der Meilensteine, Bestimmung der Beschaffung von Ressourcen (Buildserver, Personal) ... wer und was macht er denn bitte sonst? Exakt der Chef ist dazu da, um die Kommunikation der Entwickler zu Kanalisieren und entsprechend weiterzu tragen; ansonsten muss das ja jeder Entwickler für sich selber tun ... wohin soll das führen und wer soll es sonst tun? Und somit muss der Chef der Abteilung auch die Sprache so wählen, dass alle anderen Abteilungen ihn verstehen. Er leitet und Koordiniert seine Abteilung - daher auch die Bezeichnung Abteilungsleiter.
Ganz offen: Wenn der Chef nicht davon versteht, was seine Untergebenen sagen/schreiben, dann ist es *sein* Problem, *seine* Bildungslücken zu schließen, damit er seinen Führungsaufgaben angemessen nachgehen kann. Dazu kann er beispielsweise seinen Untergebenen so lange Rückfragen stellen, bis er ein Verständnis hat, oder zeitweise einen unabhängigen Tutor einstellen. Es ist ein trauriges Zeichen unserer Zeit, dass natürlich an solchen Wissenslücken des Chefs nicht der Chef selbst, sondern *natürlich* die Softwareentwickler schuld sind.
Und warum ist das die Schuld der Devs, wenn die Geschäftsleitung eines Softwareunternehmens nicht weiß, wie Softwareentwicklung funktioniert? Offensichtlich läuft der Laden ja nicht, wenn die Devs wissen, worans liegt und Lösungsvorschläge machen und die Geschäftsleitung glaubt ihnen nicht, liegt der Fehler nicht in den mangelnden Kommunikationsfähigkeiten der Entwickler. Letztlich kann es ihnen auch egal sein, denn wenn die Devs was auf dem Kasten haben, finden sie schneller nen neuen Job, als der Geschäftführer "Insolvenz!" sagen kann, wenn er den Laden an die Wand gefahren hat.
So wie die Story im Video geschildert wurde, ist der AL-E kein Entwickler. Sonst würde er wissen, dass statische Code-Analyse und Code Reviews unverzichtbar sind. Ich denke, das ist das Problem in dieser Organisation. Die Entwickler können gar nicht wissen, welche Interessen der AL-PM und der GF haben. Die können sich was denken, aber gezielt kommunizieren können sie nicht. Der AL-E sollte die Interessen der Entwickler bei der Geschäftsführung vertreten.
Sehe ich genauso. Das ist nicht die Aufgabe von einem einzelnen Entwickler. Klar kann er diese auch übernehmen aber dafür hat man eigentlich einen Team bzw. Abteilungsleiter. Wenn die nicht wissen was abgeht sind sie fehl am Platz. Wenn das ein Softwareunternehmen ist, ist es noch trauriger. Dann sollte man den Geschäftsführer austauschen.
Ich hatte auch das Gefühl, dass in der Firma nicht miteinander gesprochen wird. Der GF versteht die Entwickler nicht - und was tut er dagegen? Offenbar nichts, lässt das Problem einfach so weiterbestehen. Da gibt es keinen Austauch zwischen den Abteilungen über die individuellen Nöte und Sorgen. Die Entwickler sind nicht im Entscheidungsprozess eingebunden, fühlen sich immer vor vollendete Tatsachen gestellt. In einem persönlichen Gespräch ist ein Entwickler leichter in der Lage, sich dem Wissensstand des Gegenübers anzupassen, in einer E-Mail kann das sehr schwer sein. Im Endeffekt ist es ein Kommunikationsproblem.
Der Köder muss dem Fisch schmecken und nicht dem Angler. Verdammt; ihr müsst den Business-Typen euren Scheiss auch verkaufen. Die schlagen sich mit Finanzierungsrunden, Kreditlinien, Mietverträgen, Überprüfungen der Berufsgenossenschaft zur Auushängepflicht und Entsorgungsnachweis von Leuchtmitteln rum. Die haben ihre eigenen Probleme, die ihr einfach garnicht wissen wollt
Warum bitte landen E-Mails von Entwicklern überhaupt in dieser Form beim Geschäftsführer? Diese E-Mail formuliert ja die gewählten Maßnahmen. Klar, dass sich die anderen Bedarfsträger im Haus nicht für die Maßnahmen selbst sondern die Auswirkungen interessieren, welche eintreten, wenn diese Maßnahmen angewendet werden. Oder eben dafür, was passiert wenn die Maßnahmen NICHT ergriffen werden. Aber man kann doch nicht von Entwicklern verlangen, vom Geschäftsführer bis zur Putzfrau jedem alle Entwicklungsthemen verständlich darlegen zu können. In diesem Beispiel existiert ein Entwicklungsleiter. Hermeneutik und adressatengerechte Argumentationslinien wären seine Aufgabe. Davon mal abgesehen würde ich mir in einem Softwareunternehmen vom Produktmanagement und der Geschäftsführung durchaus auch mal etwas Sachinteresse am Entwicklungsprozess wünschen. Wer nach der Probezeit in einem Softwareunternehmen nicht mindestens 50% der E-Mail versteht, darf wieder gehen.
Hey, da es eine Ressourcenfrage ist, welche den Releaseplan beeinflusst und damit wichtige Termine (in diesem Fall ggf. ein Messetermin) ist das natürlich auch Sache des Geschäftsführers. Selbst wenn diese Email an eine fachlich versierte Person gegangen wäre, fehlt ganz klar das "warum". Interessanter Punkt: doch genau das verlange ich von allen Entwicklern. Wir leben in einer hoch technischen Domäne und jeder sollte in Diskussionen den Sachverhalt so rüberbringen, das auch jemand mit nur begrenztem Sachverstand das Ganze verstehen kann. Diese Fähigkeit existiert in nahezu jeder Branche: Handwerk, Medizin, Recht und vielen anderen. Diese Fähigkeit zählt für mich noch nicht mal zur eigentlichen Softwareentwicklung, sondern ist eine Grundlage der Kommunikationstechniken. Gruß David
@@DavidTielkeKommunikationstechniken... Die lernt man in der Schule? Auf der (technischen) Uni? Und wenn man eine Schulung möchte, heißt es :"warum?" Und die Katze beißt sich in den Schwanz 😅 Danke für das Video
@@DavidTielke Sorry das sehe ich nicht so. Wer ein Softwareunternehmen leitet und keine Ahnung von der Materie hat, ist fehl am Platz. Das ein Code Review oder eine statische Code Analyse die Qualität erhöht, das versteht der Praktikant nach 2 Wochen. Wie der Name Geschäftsführer sagt, muss dieser in der Lage sein zu führen. Also Entscheidungen treffen und Anweisungen geben. Es ist gerade nicht die Aufgabe des Softwareentwicklers dies zu leisten. Sonst wäre es ja ein leitender Entwickler oder selbst Geschäftsführer. Seine Aufgabe ist die Umsetzung der Anweisung. Wenn das so eine wichtige Messe ist und akute Probleme im Unternehmen bestehen, wieso war der Geschäftsführer dann nicht in dem Meeting? Wieso schaut er sich nicht an was schief läuft? Ein Bauleiter bleibt ja auch nicht zuhause und sagt dem Mitarbeiter er soll ihm mal sagen was man besser machen kann. Wie soll das bitte gehen wenn er nicht mal weiß was ein Code Review oder eine statische Code Analyse für Vorteile bringen? Ist das überhaupt ein Softwareunternehmen? Aber ja das "warum" fehlt. Hilft nur niemandem wenn der Geschäftsführer dann nicht mal fragt "Warum?", wenn er selbst keine Ahnung von der Materie hat. Am Ende trägt er die Verantwortung und nicht der Entwickler.
@@DavidTielke Auch mal anders gesagt. Formuliere hier mal das "Warum". Ein Sales kann einfach sagen, er hat X potentielle Kunden und kann zu Y verkaufen. Ist eine gute Nachricht. Warum ein Code Review? Weil der Kollege so schlecht programmiert? Weil wir X Bugs / Fehler gemacht haben? Am Ende wird es auch noch wirklich gemacht und man kann seine Deadlines nicht mehr halten, weil die Code Reviews so lange brauchen. -> Konfliktpotential Ich verstehe schon warum niemand Lust hat hier das "Warum" hinzuschreiben.
@@ArwedMett das weder der Geschäftsführer und teilweise auch der Abteilungsleiter Softwareentwicklung von solchen Themen plan hat, ist leider Usus. Aber das Problem ist, dad auch innerhalb einer Softwareabteilung nicht alle einer Meinung sind und da total unterschiedliche Meinungen vorherrschen. Wenn man dazu noch eine toxische Kultur und 1bis 2 sehr dominante softwareentwickler hat, dann kann man sich alles was die Softwareabteilung kommunikativ verlässt, komplett in die Haare schmieren
Alles schön und gut - allerdings glaube ich nicht, dass die anderen beteiligten Gruppen sich dieselben Gedanken machen, sprich: Wie das, was sie so veräußern, denn bei ihren Devs so ankommt - und ob es für diese Zielgruppe von Wert ist oder nicht. Wenn man bedenkt, was auf die Devs oft für absoluter Schrott eingeredet wird, kann man sich diese Frage relativ schnell beantworten.
Hey, denke der Vergleich hinkt etwas. Wir werden dafür "bezahlt" das wir Anforderungen des Unternehmens in Quellcode umsetzen. Hier fordern wir als Entwickler ja etwas vom Unternehmen, ohne die Vorteile unserer Forderung für das Unternehmen aufzuzeigen. Das die Kommunikation in unsere Richtung oft sehr zweifelhaft ist - gar keine Frage, aber das hat immo wenig mit dem Thema das Videos zu tun :) Gruß David
@@DavidTielke , ja - das war jetzt nicht auf den Inhalt des Videos bezogen. Das Video ist super, ich schätze es sehr. Insgesamt ist zu beobachten, dass der Job eines Software-Entwicklers an sich ein sehr analytischer ist, welcher ein hohes Maß an Abstraktionsvermögen voraussetzt. Natürlich tendiert man mit diesem Mindset dazu, Probleme vollumfänglich und auch auf Meta-Ebene zu reflektieren. Es liegt also in der Natur des Jobs, dass man sich etwas mehr Gedanken macht, bzw. auch Situationen/Verhaltensweisen gerne als Teil eines Systems betrachtet. Ein Checklisten- und kostenorientierter Manager wendet eine solche Denkweise eher nicht an. Aber auch die andere Denkweise hat in ihrem jeweiligen Kontext eine Daseinsberechtigung - oder sagen wir mal: Sie ist zumindest nachvollziehbar. Daher sind Videos wie dieses wichtig, um letztlich zueinander zu finden.
Gut aufbereitetes Video! Muss dir absolut zustimmen, technische Schulden werden oftmals von der fachlichen Seite aus vernachlässigt - bis der Schuh schon zu stark drückt. Als Techniker das entsprechend formulieren zu können ist ultra wichtig und ich finde das hast du in dem Video gut rübergebracht 👍
Ich fürchte die e-mail hätte von mir sein können. Jetzt bin ich schon so lange dabei, aber ich gehe immer wieder fälschlicherweise davon aus, dass meine Vorgesetzten eine Idee davon haben, was wir tun. ;-)
Erstmal ist ja erstaunlich, das in der Firma offenbar die elementaren Grundsätze der SE bis dato gar nicht angewandt bzw. die entsprechenden Tools nicht verwendet wurden. Und dann frage ich mich, warum es keine vernünftige Reportingstruktur gibt. Für einen Entwickler ist die Email absolut schlüssig. Aber die Entwickler reporten an den AL-E und der kann bzw. muss das denn anderen Stakeholdern in deren DSL übersetzen. Das klingt alles in allem nach einer kleinen 20 Mann Firma mit eher wenig Erfahrung.
Hey, ich glaube dass das Thema generell ein Problem ist, so auch hier. Das Beispiel hier hätte ich auch aus vielen anderen Projekten nehmen könne - ist vielerorts identisch. Die schlechte Unternehmenskommunikation ist ja nicht nur eine Erscheinung aus der Softwareentwicklung, es ist ein allgemeines Problem. Gruß David
Kommunikation, das größte Problem der Menschheit. Ich glaube jeder ITler häufiger wie die Augen im Gegenüber abdriften und nichts mehr verstehen, da muss man einfach aufhören zu reden und den anderen in das Gespräch mit einbeziehen. Viele geben sich aber nicht mal Mühe, Dinge einfach und verständlich zu erklären. Irgendwie sehr überheblich.
Super Video! Zeigt wieder einmal wie wichtig es ist, an der eigenen Kommunikationsfähigkeit zu arbeiten um das zu erreichen was man möchte! Es ist allerdings auch mal wieder ein gutes Beispiel wie schlecht die Kommunikation in einem Unternehmen funktionieren kann. Es ist eigentlich im höchsten Interesse des Produktmanagers, als auch des Geschäftsführers zu verstehen, was die Probleme sind. Wie du sagtest bekommt das Unternehmen bzw. hat schon Probleme aufgrund der Software, was mir sagt, dass die IT durch jede Ritze der Firma fließt. Jedes Unternehmen was sich so auf Software stützt sollte Schlüsselpersonen suchen die die Brücke zwischen den Welten spannen, entweder aus der eigenen Abteilung oder von extern. Ich hoffe, dass dieses Unternehmen Stammkunde bei dir wird, David.
Hey, ja absolut- über Kommunikations- und Wissensdefizite reden wir hier indirekt natürlich auch, da läuft einiges schief und muss korrigiert werden. Genau deshalb bin ich recht optimistisch das es Stammkunden werden ;) Gruß David
ach, das kommt einem doch so bekannt vor - da hilft nur, einfach kontinuierlich Verbesserungen durchführen und sich die Zeit nehmen. Einfach die Zeit für sowas oben drauf schlagen, da es eben dazugehört
Dann kommt der Chef und sagt, dass man in der hälfte der Zeit fertig sein muss und man sich erstmal nur auf ein MVP konzentrieren soll. Das läuft dann 5 Jahre so weiter bis das Projekt tot ist und dann sind die Entwickler Schuld obwohl man die Probleme jeden zweiten Tag angesprochen hat... :/
Hallo David :D Bei dem Video musste ich total an das Buch "Wie man Freunde gewinnt" denken. Tolles Video und danke noch mal für die Buchempfehlung. Liebe Grüße Erik
Was wurde weiter aus der Angelegenheit? Ist das nicht einfach ein typischer Fall, wie er meistens bei externer Beratung auftritt? Sobald der Consultant die Firma wieder verlässt, fallen alle Vorsätze und Pläne zur Verbesserung schlagartig in sich zusammen, insbesondere wird exakt Null davon jemals umgesetzt💁🏼♂️
David, wenn ein Softwareentwickler ein guter Verkäufer wäre, wäre er nicht Softwareentwickler. Er wäre Verkäufer. Denn dann würde er Cash ins Unternehmen bringen.
Hallo David, Du sprichst mir aus der Seele. Ich habe Kollegen, die können noch nicht mal den fachlichen Sachverhalt flüssig wiedergeben. Und das Hineinversetzen in den Chef ist ein echtes Problem.
Genauso ist die Praxis! Pflichtvideo für alles Software- und auch Technik-„Nerds“! Die Kunst, dich in deinen Chef hinein zu versetzen, sonst sieht er dich nur mit großen Augen an. Das zum Schluss erwähnte Video ist dabei eine sehr gute Ergänzung.
4:03 Da muss ich dir aber Widersprechen; wenn dem Software-Chef der Abteilung nicht interessiert, wie seine Abteilung arbeitet (Code-Review, Entwicklungsprozessabläufe, verwendete Programmiersprache(-n), Festlegen der Reihenfolge zur Arbeitung der Meilensteine, Bestimmung der Beschaffung von Ressourcen (Buildserver, Personal) ... wer und was macht er denn bitte sonst?
Exakt der Chef ist dazu da, um die Kommunikation der Entwickler zu Kanalisieren und entsprechend weiterzu tragen; ansonsten muss das ja jeder Entwickler für sich selber tun ... wohin soll das führen und wer soll es sonst tun?
Und somit muss der Chef der Abteilung auch die Sprache so wählen, dass alle anderen Abteilungen ihn verstehen.
Er leitet und Koordiniert seine Abteilung - daher auch die Bezeichnung Abteilungsleiter.
Ganz offen: Wenn der Chef nicht davon versteht, was seine Untergebenen sagen/schreiben, dann ist es *sein* Problem, *seine* Bildungslücken zu schließen, damit er seinen Führungsaufgaben angemessen nachgehen kann. Dazu kann er beispielsweise seinen Untergebenen so lange Rückfragen stellen, bis er ein Verständnis hat, oder zeitweise einen unabhängigen Tutor einstellen. Es ist ein trauriges Zeichen unserer Zeit, dass natürlich an solchen Wissenslücken des Chefs nicht der Chef selbst, sondern *natürlich* die Softwareentwickler schuld sind.
Und warum ist das die Schuld der Devs, wenn die Geschäftsleitung eines Softwareunternehmens nicht weiß, wie Softwareentwicklung funktioniert? Offensichtlich läuft der Laden ja nicht, wenn die Devs wissen, worans liegt und Lösungsvorschläge machen und die Geschäftsleitung glaubt ihnen nicht, liegt der Fehler nicht in den mangelnden Kommunikationsfähigkeiten der Entwickler.
Letztlich kann es ihnen auch egal sein, denn wenn die Devs was auf dem Kasten haben, finden sie schneller nen neuen Job, als der Geschäftführer "Insolvenz!" sagen kann, wenn er den Laden an die Wand gefahren hat.
So wie die Story im Video geschildert wurde, ist der AL-E kein Entwickler. Sonst würde er wissen, dass statische Code-Analyse und Code Reviews unverzichtbar sind. Ich denke, das ist das Problem in dieser Organisation. Die Entwickler können gar nicht wissen, welche Interessen der AL-PM und der GF haben. Die können sich was denken, aber gezielt kommunizieren können sie nicht. Der AL-E sollte die Interessen der Entwickler bei der Geschäftsführung vertreten.
Sehe ich genauso. Das ist nicht die Aufgabe von einem einzelnen Entwickler. Klar kann er diese auch übernehmen aber dafür hat man eigentlich einen Team bzw. Abteilungsleiter. Wenn die nicht wissen was abgeht sind sie fehl am Platz. Wenn das ein Softwareunternehmen ist, ist es noch trauriger. Dann sollte man den Geschäftsführer austauschen.
Ich hatte auch das Gefühl, dass in der Firma nicht miteinander gesprochen wird. Der GF versteht die Entwickler nicht - und was tut er dagegen? Offenbar nichts, lässt das Problem einfach so weiterbestehen. Da gibt es keinen Austauch zwischen den Abteilungen über die individuellen Nöte und Sorgen. Die Entwickler sind nicht im Entscheidungsprozess eingebunden, fühlen sich immer vor vollendete Tatsachen gestellt. In einem persönlichen Gespräch ist ein Entwickler leichter in der Lage, sich dem Wissensstand des Gegenübers anzupassen, in einer E-Mail kann das sehr schwer sein.
Im Endeffekt ist es ein Kommunikationsproblem.
Der Köder muss dem Fisch schmecken und nicht dem Angler. Verdammt; ihr müsst den Business-Typen euren Scheiss auch verkaufen. Die schlagen sich mit Finanzierungsrunden, Kreditlinien, Mietverträgen, Überprüfungen der Berufsgenossenschaft zur Auushängepflicht und Entsorgungsnachweis von Leuchtmitteln rum. Die haben ihre eigenen Probleme, die ihr einfach garnicht wissen wollt
Warum bitte landen E-Mails von Entwicklern überhaupt in dieser Form beim Geschäftsführer? Diese E-Mail formuliert ja die gewählten Maßnahmen. Klar, dass sich die anderen Bedarfsträger im Haus nicht für die Maßnahmen selbst sondern die Auswirkungen interessieren, welche eintreten, wenn diese Maßnahmen angewendet werden. Oder eben dafür, was passiert wenn die Maßnahmen NICHT ergriffen werden.
Aber man kann doch nicht von Entwicklern verlangen, vom Geschäftsführer bis zur Putzfrau jedem alle Entwicklungsthemen verständlich darlegen zu können. In diesem Beispiel existiert ein Entwicklungsleiter. Hermeneutik und adressatengerechte Argumentationslinien wären seine Aufgabe.
Davon mal abgesehen würde ich mir in einem Softwareunternehmen vom Produktmanagement und der Geschäftsführung durchaus auch mal etwas Sachinteresse am Entwicklungsprozess wünschen. Wer nach der Probezeit in einem Softwareunternehmen nicht mindestens 50% der E-Mail versteht, darf wieder gehen.
Hey,
da es eine Ressourcenfrage ist, welche den Releaseplan beeinflusst und damit wichtige Termine (in diesem Fall ggf. ein Messetermin) ist das natürlich auch Sache des Geschäftsführers. Selbst wenn diese Email an eine fachlich versierte Person gegangen wäre, fehlt ganz klar das "warum".
Interessanter Punkt: doch genau das verlange ich von allen Entwicklern. Wir leben in einer hoch technischen Domäne und jeder sollte in Diskussionen den Sachverhalt so rüberbringen, das auch jemand mit nur begrenztem Sachverstand das Ganze verstehen kann. Diese Fähigkeit existiert in nahezu jeder Branche: Handwerk, Medizin, Recht und vielen anderen. Diese Fähigkeit zählt für mich noch nicht mal zur eigentlichen Softwareentwicklung, sondern ist eine Grundlage der Kommunikationstechniken.
Gruß David
@@DavidTielkeKommunikationstechniken... Die lernt man in der Schule? Auf der (technischen) Uni? Und wenn man eine Schulung möchte, heißt es :"warum?" Und die Katze beißt sich in den Schwanz 😅
Danke für das Video
@@DavidTielke Sorry das sehe ich nicht so. Wer ein Softwareunternehmen leitet und keine Ahnung von der Materie hat, ist fehl am Platz. Das ein Code Review oder eine statische Code Analyse die Qualität erhöht, das versteht der Praktikant nach 2 Wochen. Wie der Name Geschäftsführer sagt, muss dieser in der Lage sein zu führen. Also Entscheidungen treffen und Anweisungen geben. Es ist gerade nicht die Aufgabe des Softwareentwicklers dies zu leisten. Sonst wäre es ja ein leitender Entwickler oder selbst Geschäftsführer. Seine Aufgabe ist die Umsetzung der Anweisung. Wenn das so eine wichtige Messe ist und akute Probleme im Unternehmen bestehen, wieso war der Geschäftsführer dann nicht in dem Meeting? Wieso schaut er sich nicht an was schief läuft? Ein Bauleiter bleibt ja auch nicht zuhause und sagt dem Mitarbeiter er soll ihm mal sagen was man besser machen kann. Wie soll das bitte gehen wenn er nicht mal weiß was ein Code Review oder eine statische Code Analyse für Vorteile bringen? Ist das überhaupt ein Softwareunternehmen?
Aber ja das "warum" fehlt. Hilft nur niemandem wenn der Geschäftsführer dann nicht mal fragt "Warum?", wenn er selbst keine Ahnung von der Materie hat. Am Ende trägt er die Verantwortung und nicht der Entwickler.
@@DavidTielke Auch mal anders gesagt. Formuliere hier mal das "Warum". Ein Sales kann einfach sagen, er hat X potentielle Kunden und kann zu Y verkaufen. Ist eine gute Nachricht. Warum ein Code Review? Weil der Kollege so schlecht programmiert? Weil wir X Bugs / Fehler gemacht haben? Am Ende wird es auch noch wirklich gemacht und man kann seine Deadlines nicht mehr halten, weil die Code Reviews so lange brauchen. -> Konfliktpotential
Ich verstehe schon warum niemand Lust hat hier das "Warum" hinzuschreiben.
@@ArwedMett das weder der Geschäftsführer und teilweise auch der Abteilungsleiter Softwareentwicklung von solchen Themen plan hat, ist leider Usus.
Aber das Problem ist, dad auch innerhalb einer Softwareabteilung nicht alle einer Meinung sind und da total unterschiedliche Meinungen vorherrschen. Wenn man dazu noch eine toxische Kultur und 1bis 2 sehr dominante softwareentwickler hat, dann kann man sich alles was die Softwareabteilung kommunikativ verlässt, komplett in die Haare schmieren
Ich bin so froh deinen Kanal gefunden zu haben :)
vielen Dank für diesen wertvollen Content!
Alles schön und gut - allerdings glaube ich nicht, dass die anderen beteiligten Gruppen sich dieselben Gedanken machen, sprich: Wie das, was sie so veräußern, denn bei ihren Devs so ankommt - und ob es für diese Zielgruppe von Wert ist oder nicht. Wenn man bedenkt, was auf die Devs oft für absoluter Schrott eingeredet wird, kann man sich diese Frage relativ schnell beantworten.
Hey,
denke der Vergleich hinkt etwas. Wir werden dafür "bezahlt" das wir Anforderungen des Unternehmens in Quellcode umsetzen. Hier fordern wir als Entwickler ja etwas vom Unternehmen, ohne die Vorteile unserer Forderung für das Unternehmen aufzuzeigen.
Das die Kommunikation in unsere Richtung oft sehr zweifelhaft ist - gar keine Frage, aber das hat immo wenig mit dem Thema das Videos zu tun :)
Gruß David
@@DavidTielke , ja - das war jetzt nicht auf den Inhalt des Videos bezogen. Das Video ist super, ich schätze es sehr. Insgesamt ist zu beobachten, dass der Job eines Software-Entwicklers an sich ein sehr analytischer ist, welcher ein hohes Maß an Abstraktionsvermögen voraussetzt. Natürlich tendiert man mit diesem
Mindset dazu, Probleme vollumfänglich und auch auf Meta-Ebene zu reflektieren. Es liegt also in der Natur des Jobs, dass man sich etwas mehr Gedanken macht, bzw. auch Situationen/Verhaltensweisen gerne als Teil eines Systems betrachtet. Ein Checklisten- und kostenorientierter Manager wendet eine solche Denkweise eher nicht an. Aber auch die andere Denkweise hat in ihrem jeweiligen Kontext eine Daseinsberechtigung - oder sagen wir mal: Sie ist zumindest nachvollziehbar. Daher sind Videos wie dieses wichtig, um letztlich zueinander zu finden.
Verkaufen ist einfach:
Hallo Chef, wollen wir die Software auch noch in 2 Jahren verkaufen?
Dann brauchen wir ...
Gut aufbereitetes Video! Muss dir absolut zustimmen, technische Schulden werden oftmals von der fachlichen Seite aus vernachlässigt - bis der Schuh schon zu stark drückt. Als Techniker das entsprechend formulieren zu können ist ultra wichtig und ich finde das hast du in dem Video gut rübergebracht 👍
Hey Noel,
vielen Dank - freut mich das Dir das Video gefällt.
Gruß David
Ich fürchte die e-mail hätte von mir sein können.
Jetzt bin ich schon so lange dabei, aber ich gehe immer wieder fälschlicherweise davon aus, dass meine Vorgesetzten eine Idee davon haben, was wir tun. ;-)
Erstmal ist ja erstaunlich, das in der Firma offenbar die elementaren Grundsätze der SE bis dato gar nicht angewandt bzw. die entsprechenden Tools nicht verwendet wurden.
Und dann frage ich mich, warum es keine vernünftige Reportingstruktur gibt. Für einen Entwickler ist die Email absolut schlüssig. Aber die Entwickler reporten an den AL-E und der kann bzw. muss das denn anderen Stakeholdern in deren DSL übersetzen. Das klingt alles in allem nach einer kleinen 20 Mann Firma mit eher wenig Erfahrung.
Mir scheint, als würden die unterschiedlichen "Seiten" in diesem Beispiel generell zu wenig miteinander kommunizieren.
Hey,
ich glaube dass das Thema generell ein Problem ist, so auch hier. Das Beispiel hier hätte ich auch aus vielen anderen Projekten nehmen könne - ist vielerorts identisch. Die schlechte Unternehmenskommunikation ist ja nicht nur eine Erscheinung aus der Softwareentwicklung, es ist ein allgemeines Problem.
Gruß David
Kommunikation, das größte Problem der Menschheit.
Ich glaube jeder ITler häufiger wie die Augen im Gegenüber abdriften und nichts mehr verstehen, da muss man einfach aufhören zu reden und den anderen in das Gespräch mit einbeziehen.
Viele geben sich aber nicht mal Mühe, Dinge einfach und verständlich zu erklären. Irgendwie sehr überheblich.
Super Video! Zeigt wieder einmal wie wichtig es ist, an der eigenen Kommunikationsfähigkeit zu arbeiten um das zu erreichen was man möchte!
Es ist allerdings auch mal wieder ein gutes Beispiel wie schlecht die Kommunikation in einem Unternehmen funktionieren kann. Es ist eigentlich im höchsten Interesse des Produktmanagers, als auch des Geschäftsführers zu verstehen, was die Probleme sind. Wie du sagtest bekommt das Unternehmen bzw. hat schon Probleme aufgrund der Software, was mir sagt, dass die IT durch jede Ritze der Firma fließt. Jedes Unternehmen was sich so auf Software stützt sollte Schlüsselpersonen suchen die die Brücke zwischen den Welten spannen, entweder aus der eigenen Abteilung oder von extern.
Ich hoffe, dass dieses Unternehmen Stammkunde bei dir wird, David.
Hey,
ja absolut- über Kommunikations- und Wissensdefizite reden wir hier indirekt natürlich auch, da läuft einiges schief und muss korrigiert werden. Genau deshalb bin ich recht optimistisch das es Stammkunden werden ;)
Gruß David
ach, das kommt einem doch so bekannt vor - da hilft nur, einfach kontinuierlich Verbesserungen durchführen und sich die Zeit nehmen. Einfach die Zeit für sowas oben drauf schlagen, da es eben dazugehört
Dann kommt der Chef und sagt, dass man in der hälfte der Zeit fertig sein muss und man sich erstmal nur auf ein MVP konzentrieren soll. Das läuft dann 5 Jahre so weiter bis das Projekt tot ist und dann sind die Entwickler Schuld obwohl man die Probleme jeden zweiten Tag angesprochen hat... :/
Ich würde als GF meine Abteilungsleiter 2x fragen was da steht. Wenn ich 2x nix übersetzt bekomme, gehen die zurück zu den Codern. Mobilität.
Bestes Argument: Wir können dann Entwickler einsparen. 🤑
Hallo David :D
Bei dem Video musste ich total an das Buch "Wie man Freunde gewinnt" denken. Tolles Video und danke noch mal für die Buchempfehlung.
Liebe Grüße Erik
Hey Erik,
stimmt, um dieses Thema geht es da auch - sagte ja, ein geniales Buch!
Gruß David
Was wurde weiter aus der Angelegenheit? Ist das nicht einfach ein typischer Fall, wie er meistens bei externer Beratung auftritt? Sobald der Consultant die Firma wieder verlässt, fallen alle Vorsätze und Pläne zur Verbesserung schlagartig in sich zusammen, insbesondere wird exakt Null davon jemals umgesetzt💁🏼♂️
David, wenn ein Softwareentwickler ein guter Verkäufer wäre, wäre er nicht Softwareentwickler. Er wäre Verkäufer. Denn dann würde er Cash ins Unternehmen bringen.
Super Punkt den du hier ansprichst !
Hallo David, Du sprichst mir aus der Seele. Ich habe Kollegen, die können noch nicht mal den fachlichen Sachverhalt flüssig wiedergeben. Und das Hineinversetzen in den Chef ist ein echtes Problem.
Hey Oliver,
das freut mich :) Ja, solche Kollegen hatte ich früher auch ;)
Gruß David
Dabei ist die höchste Kunst ja oft einem Chef etc. etwas so zu verkaufen das er am Ende glaubt es sei seine eigene Idee gewesen ...
".....jetzt wollen die auch noch ihren quellcode hübsch machen ...." 🤣
Video ist wieder 101% , sogar mit kurzem intro 👍
Hey,
danke - freut mich :) Ja, ich optimiere immer weiter.... :D
Gruß David
👍👍
Genauso ist die Praxis! Pflichtvideo für alles Software- und auch Technik-„Nerds“!
Die Kunst, dich in deinen Chef hinein zu versetzen, sonst sieht er dich nur mit großen Augen an. Das zum Schluss erwähnte Video ist dabei eine sehr gute Ergänzung.
Hallo Frank,
freut mich, dass Dir das Video gefällt. In der Tat ist das manchmal eine "Kunst" :)
Gruß David