Gute Buchempfehlungen, da stimme ich Dir zu. Was ich nicht ganz nachvollziehen kann, ist, wie Du in der beschriebenen Situation zu der Schlussfolgerung kommst, dass die Software-Entwickler die Diskussion verloren und die Manager gewonnen hätten. Ich komme zu genau dem gegenteiligen Schluss. Die Manager hätten gewonnen, wenn sie tatsächlich bis Jahresende ihre Software bekommen oder eine neue, konsensfähige Produktvision beschlossen hätten. Beides scheint mir nicht der Fall zu sein. Inzwischen kannst du ja berichten, ob die Software zum Jahresende fertig war? Die Softwareentwickler haben jetzt hingegen bis Jahresende Ruhe, vielleicht sogar ein Agreement so lange von neuen Anforderungen verschont zu bleiben, wer möchte kann sich in Ruhe nach einem neuen Job umsehen, und damit dass die Software bis Jahresende fertig wird rechnet so wie so niemand - nicht mal das Management, wenn es zugehört hat. OK, hat es wahrscheinlich nicht, also muss man auch hier eher wieder zu dem Schluss kommen, dass das Management über seine fehlenden Softskills gestolpert ist, nicht die Entwickler. Eine Diskussion gewinnen heißt doch nicht, die anderen argumentatorisch platt zu machen, sondern etwas erreicht zu haben. Das kann ich hier nicht sehen. Auch oder erst recht nicht beim Management.
Im Prinzip hast du hier doch verloren. Du hattest deinen Standpunkt und gleichzeitig bist du hier auch der Softwarearchitekt. Damit hättest du hinter dem Softwareteam als Architekt stehen müssen und nicht die Rolle des neutralen Moderators annehmen sollen.
Stimmt, hier hätte der Scrum Master im spring Planning das unabhängige schätzen gewährleisten sollen. allerdings treten Scrum Master, die nicht aus der Technik kommen, oft als der verlängerte Arm des Managements auf. Am besten ist deshalb ein Scrum Master, der einen technischen Hintergrund hat und ein gutes Standing Unternehmen besitzt, um bei auftretenden Problemen, die meistens externer Natur sind, diese mit den entsprechenden steakholder zu lösen.
There is no free lunch. Selbst wenn das Dev-Team jetzt unter großen Anstrengungen den Sieg einfährt, wird im Zuge von crunching und co. eine Narbe zurück bleiben. Im schlimmsten Fall werfen Entwickler davor, danach oder währenddessen hin. Der Arbeitsmarkt gibt eine schnelle Neuorientierung definitiv her. Würde als Entscheider technische und personelle Limitation akzeptieren und nicht mein Personal abfucken. Ne anschließende "Pizza-Runde" wird da nicht mehr viel bringen...
Der Gedanke kam mir sofort. Ich würde das letzte halbe Jahr nutzen um davon zu rennen. Sollen doch die guten Schwätzer und Überzeuger einfach alles selber schreiben. Was für eine Dreistigkeit, den Entwicklern zu erklären, wann sie fertig sein werden.
Ja klar, lieber zum Italiener gehen wie den Entwicklern danach am Erfolg in punkto Gehalt zu beteiligen. Den Termin fürs Essen legen wir natürlich aufs Wochende. Sonst kommt einer von denen noch auf die Idee das war Arbeitszeit.
Na, das Set-Up Sales/Marketing vs Dev Team kann ja eigentlich nur so ausgehen, dass das dev team den Kürzeren zieht: Fähige Leute in Sales und Marketing sind Profis im Überreden. Das ist deren Talent und Kernkomptenz! Entwickler können (und sollten!) da natürlich versuchen, aufzuholen. Aber auf Augenhöhe werden sie vermutlich nicht kommen. Ein ordentliches Führungsteam weiß das, und verhindert möglichst, dass sich so eine Konstellation bildet.
Ich habe auch ein Thema mit dem Sales. Allerdings ist hier weniger die Deadline das Thema. Hier geht es eher um das Verständnis von: "Wieso dauert etwas 2 Wochen, dass ist doch nur ein Feld auf der Maske". Man kann hier Argumente bringen wie man will, die Leute sind nicht gewillt auch nur annähernd darauf einzugehen. Ähnlich ist es mit Prioritäten, denn da geht es um die Provision der netten Kollegen. Meiner Meinung nach gehören aber beide Seiten dazu. Die Entwicklung die die Argumente bringt, warum etwas so ist wie es ist. Und in meinem Fall die Sales Seite auf der anderen Seite. Der Vertrieb mag für die Firma den größtmöglichen Umsatz rausholen will. Mit der Art und Weise wie aber auf die Entwicklung zugegangen wird und wie sie behandelt wird, wird einfach nur Frust erzeugt. Jeder unserer Entwickler wird wöchentlich von Headhuntern angesprochen. Irgendwann ist das Maß erreicht, an dem man sich genau diesen Frust nicht mehr antut. Was hat der Vertrieb also mit seiner Art und Weise erreicht? Das Gegenteil! Die Personalnot wird noch größer, die Entwickler noch mehr Frustriert, es besteht Burnout Gefahr und am Ende verliert die Firma! Man sollte also nicht nur die Entwickler weiterbilden ;)
Es kommt oft genug vor, dass die BWLer/Vertriebler durch Gewinnmaximierung auch Unternehmen zerstören. Sei es das es Braindrain gibt, oder die Schaffenden Leute mit Burn-Out Jahre ausfallen.
Ich bin mitterweile so stumpf geworden, dass ich einfach hart bleibe und Nein sage. Ich fordere von der Gegenseite Eingeständnisse. Just for fun könnt ihr ja der Gegenseite mal vorschlagen, dass sie euch folgendes unterscheiben soll: Wenn es zu Crunch kommt, mögen diese Leute bitte unbezahlt anwesend sein, wenn die Überstunden gemacht werden oder Pausen weggelassen.
Danke, dass du das mit den Buchtiteln nochmal angesprochen hast. Ich war schon skeptisch, da die Titel irgendwie esoterisch wirken. Ich hole mir definitiv die beiden Bücher. Danke für die Empfehlung. 😀
Ich kenn nur das „Wie man Freunde gewinnt“, aber kann zu 100% bestätigen, dass der Titel total irreführend ist und nicht das ausdrückt was drin steht. Und meines Erachtens sollte dieses Buch jeder mal gelesen haben. Echt wertvoll!
Diesen Aspekt finde ich genauso wichtig wie die technische Weiterbildung. Ich selber schule mich ab und zu in der Kommunikation in LinkedIn Learning z.B. der Vortrag vom Conrad Giller fand ich gut. Wir sollten unsere Persönlichkeit nicht vernachlässigen. Ich treffe Entwickler, die ihre Persönlichkeitsentwicklung vernachlässigen und dadurch die Stimmung im Team schlecht ist, weil die Kommunikation mit den Anforderern nicht optimal oder unterwürfig läuft.
Hi David, danke für den Buchtipp „Wie man Freunde gewinnt“ von Dale Carnegie. Habe reingelesen und ich kann kaum glauben, dass das Buch schon so alt ist. Man erkennt, dass das sich Miteinander der Menschen nicht ändert. Ist nicht nur für die Erweiterung der Softskills im Arbeitsalltag gut, sondern man kann seine Regeln auf sein gesamtes Umfeld anwenden.
Wenn dann auch noch Uneinigkeit im Entwicklerteam herrscht, hat man überhaupt keine Chance gegen dieses Bollwerk PO und Vertrieb. Wenn Du mit im Entwickler Team bist, wieso bist Du dann Moderator? Aber ich denke selbst dann, wenn Du merkst, das etwas in die falsche Richtung läuft,hättest Du das Team irgendwie stützen müssen, denn auch Du musst jetzt mit dem Ergebnis leben. Wiederhole das Meeting ohne ein Moderator zu sein, dann kannst Du Dein Team stützen.🤗😏✌️
Als Entwickler sehe ich die Wahrheit im technisch machbaren. Jemand der etwas unfertiges unbedingt durch Diskussion erzwingen will, kann in meiner Sicht nur scheitern. Warum kommen aber Verkäufer, POs... damit durch? Warum müssen sie sich nicht verantworten wenn sie die Warnungen ignorierten? Dann würden sie nächstes mal auch realistischer planen.
Die kommen damit durch, weil es im Nachhinein von den Verkäufern dann heißt: "ja wir haben die Entwickler doch gefragt ob es machbar ist", so wie in diesem Fall, nur das es eher ein Überreden auf Druck hin in den meisten Fällen ist...erlebe ich selbst häufig.
Interessanter Ansatz. Es stellt sich allerdings die Frage, ob man in einer Argumentation überzeugen kann, in der die andere Seite nur gewinnen will. Und was das das für ein Phyrrus Sieg ist, wenn dann nach einem halben Jahr die Software immer noch nicht fertig ist, darüber brauchen wir uns nicht zu wundern. Aus meiner Sicht hat ein Projekt in einer Firmenkultur, die so ein Verhalten begünstigt, keine Aussicht auf Erfolg. Aber ich sehe Conway’s Gesetz auch weiter gefasst als die meisten Leute…
Ich kenn nur das „Wie man Freunde gewinnt“, aber kann zu 100% bestätigen, dass der Titel total irreführend ist und nicht das ausdrückt was drin steht. Und meines Erachtens sollte dieses Buch jeder mal gelesen haben. Echt wertvoll!
Das ist genau der Grund, warum Produkte oft beim Kunden reifen. Die Firmen wollen auch fürs Image laufend Innovationen präsentieren, sehen aber nicht den damit verbundenen Aufwand. Da steht z. B. ein Messetermin seit langem fest und der Druck steigt mit der verbleibenden Zeit. Leider gibt es durch den Druck auf die Mitarbeiter das Phänomen, dass es dann doch irgendwie klappt. Gesund ist das nicht - vor allen wenn das zum Normalfall wird und voll auf die Mitarbeiter geht.
War/Ist genauso bei mir als Technischer Zeichner. Vor einem halben Jahr und jetzt wieder. Einmal war es ein Teilfortschritt und jetzt die Projektabgabe. Vor nem halben Jahr wurde mir nach 3 Monaten Unterstützung zugesagt für die letzten 2 Wochen und was ich denn habe. Ich so: Wenn der vorr 4 Wochen eingestiegen wäre hätten wir es locker geschafft (gesamt also die 7 letzten). Ich habe meinen Urlaub verschoben um eine Woche und hab in den letzten 5 Wochen ca. 70-80 Überstunden gemacht. Jetzt wollen die sowas ähnliches, aber ich sagte schon, dass ich mich von damals nicht erholt habe, da es ja direkt stressig weiter ging. Ich mache 1-2 h mehr pro Woche, mein absolutes max. um nicht durchzudrehen. Diesmal habe ich seit 4 Monaten 1 Person mehr, obwohl ich vor nem halben Jahr schon 2-3 Unterstützer (dauerhaft) gefordert habe. Seit nem halben Jahr bin ich dauerhaft einem Burnout sehr nah.
Ich habe schwierigkeiten mir die Diskussion vorzustellen. Ich nehme mal an, an dem Kriesenmeeting hat kein Teamleiter der Entwickler teilgenommen? Meiner Erfahrung nach ist ab fachlicher bzw. disziplinarischer Leitung ein intrinsischer Bedarf der Verbesserung der eigenen Softskills häufig gegeben, somit sollte zumindest ein Teamleiter in der Lage sein sich schützend für sein Team einzusetzen. Schützend deshalb, da vermutlich die Entwickler noch unzufriedener (unzufrieden sind sie vermutlich sowieso schon, keiner freut sich wenn deadlines nicht erreicht werden) sind. Der Druck auf die Entwickler steigt obwohl denen eigentlich klar ist, dass das Ziel nicht erreicht werden kann. Worst case, werden Entwickler kündigen oder krank, da diese sich nicht gehört fühlen und der Druck zu groß wird. Für mich sieht die Arbeitsumgebung ziemlich toxisch aus, ist es nicht deine Pflicht hier einzuschreiten? Du wirst zwar für die Rolle des Architekten bzw. Scrum Masters bezahlt aber für mich gilt hier "wissen verpflichtet". Niemanden ist geholfen wenn im Dezember die ersten Kunden anstehen und nichts funktioniert und alles nur halbfertig ist und die Firma dann trotz einer guten Idee am Ende doch scheitert obwohl du es eventuell hättest verhindern können?
Ganz richtig, der Vertrieb darf nicht direkt auf die einzelnen Entwickler einwirken, sondern das muss über die Team/Gruppenleitung laufen. Sonst hat man durch den Druck am Ende noch weniger Entwickler.
Schon richtig. Bei der derzeitigen Situation wird es zwangsläufig ein halbfertiges Produkt werden für die dann im Nachgang Patches bereitgestellt werden müssen. Sind Windows-Nutzer doch gewöhnt.Wo liegt also das Problem? Imageschaden? Egal, ist der Ruf erst ruiniert... Spaß beiseite ich finde es höchst bedenklich, dass in der Firma niemand genug A... in der Hose hat zu sagen "Vertrieb und wenn ihr euch auf den Kopf stellt und Fliegen fischt die Software wird erst ein halbes Jahr später fertig sein. Ende der Diskussion." Man kann sich nicht ständig nur Freunde machen. Ein mögliche wäre es das Dev-Team aufzustocken, sei es jetzt mit neuen Mitarbeitern oder Freelancern. Was spricht dagegen?
Nicht jedes Team hat einen Team leiter, so wie bei uns. Das Team ist völlig autark bekommt nur die fachlichen features vom PO und das Team entscheidet dann fast alles selbst, zusammen. Zum Glück hält der PO auch vieles von uns fern, so dass wir auch „entspannt“ entwickeln oder uns verbessern können.
Ich finde es läßt sich nicht nur auf Softskills runterbrechen, bei Zeitplänen und Aufwänden spielen viele Sichten rein. Und natürlich gehört dazu auch ein gewisses Schubladendenken der Entscheider dazu. Nimm zwei Entwickler Stellen, die exakt das selbe machen: - Stelle 1: schlechte Software, schlechtes Teamverhalten, rechthaberischer Teamlead, hohe Fluktuation - Stelle 2: gute Software, gutes Teamverhalten, umsichtiger Teamlead, lange Betriebszugehörigkeit Oben kommt sehr häufig an, dass bei Stelle 1 die Thematik anspruchsvoller ist, und man deswegen dort eventuell sogar mehr Mitarbeiter braucht. Während die Stelle 2 Glück hat, dass deren Thema scheinbar einfacher ist. Habe ich genauso erlebt: natürlich sind/waren die Aufgaben der einzelnen Teams unterschiedlich, aber alle Teams haben auch exakt gleiche Aufgaben unterschiedlich gelöst, z.B:: - Kommunikation, Systemphasen, Hochlauf, Switchover, etc. - Daten, Datenpersistenz und Versions-Kompatibilität, etc. Und oft werden bei dem "soliden Handwerk" die größten Böcke geschossen. Es gibt Teams, die beschäftigen sich mehr mit sich selbst, und der eigenen Legacy, als mit innovativer Entwicklung. Und da alles bezahlt werden muss hängt es einfach auch oft einfach davon ab wie *hipp* ein Thema gerade ist. Wird was vom Kunden gefordert (und bezahlt), oder ist ein neuer Markt in Aussicht, dann gewinnt es sich auch als SW Entwickler viel schneller. Arbeitest Du solide, und dein Produkt ist etabliert, dann verlierst Du sehr schnell (weil: 1.) never change a winning team 2.) der Markt ist eh unser). Das Entwickler öfters verlieren liegt IMO einfach an der Inkompetenz der leitenden Manager. Ich habe von meinem CEO sogar mal zu hören bekommen: Du hast gar keine schlechte Ideen, warum bist Du nicht Manager geworden.
@@weluvmusicz Exakt, ich kenne einen Ex-General dessen Credo war: "Objektorientierte Programmierung ist ein Irrweg." Das Produkt, welches er mit diesem Credo selbst verbockt hat, hat ihn in den C-Level aufsteigen lassen (denn das Thema war hipp). An dem Produkt, welches nicht sauber projektiert werden konnte, ist die Firma letztendlich pleite gegangen. Ich selber wurde zu "Aushilfe" genötigt, und weiß somit wie es um das Produkt stand. Informationen nach Housten? Fehlanzeige! Es ist erschreckend wie "solchen Niederlagen" auf Managementseite umgegangen wird. Der alte C-Level wurde geschasst, die anderen hatte keine Handhabe, und gelernt wird nix außer: "Bloß nicht das Maul aufreissen, bloß keine Verantwortung übernehmen, bloß keine Entscheidungen treffen, nichts tun ist besser als Fehler nachgewiesen zu bekommen". Kennt man auch als: "cover your ass".
Am Ende des Jahres auflaufen lassen und "wir haben es euch ja gesagt" dem Vorstand so ins Gesicht sagen. Immer die gleichen Probleme mit Vertrieb die von der Technik keine Ahnung haben. Alle 8 Kündigen selbst ihre Stellen und gehen woanders hin. Dann kann sich das Unternehmen um neue Entwickler Kümmern und die erst einmal einarbeiten. Und das dauert länger als die 6 Monate Verzögerung.
Ehrlich gesagt habe ich gar keine Lust mich als Verkäufer oder Menschenversteher weiterzubilden. Wenn ich das in irgendeiner weise gewollt hätte, hätte ich ein anderes Berufsbild. Es ist eher ein Armutszeugnis der Leitung und der anderen Abteilungen das diese nicht auf diejenigen mit der Erfahrung auf dem Gebiet hören.
Und dann gibt es noch die Realität und die sieht nunmal so aus. Btw sind daß alles Softskills, die auch in der Gehaltsverhandlung und im restlichen Leben helfen, also nicht einfach so abtun bitte
Einfach motzen, wenn was nicht gefällt. Wenn der Niedergang unausweichlich erscheint, hat man auch nichts mehr zu verlieren, sondern hat schon verloren. Deshalb muss man sich nicht stressen lassen.
Was ich nicht verstehe: Warum warst Du Moderator? Bist Du nicht ein bisschen "zu teuer" um nur die Diskussion zu moderieren? :D Außerdem beseht dein Job zu einem Großteil ja auch genau aus dem, was Du hier ansprichst, warum darfst Du nicht unterstützen oder das "Team Softwareentwicklung" in der Diskussion nicht anführen? Oder war das vielleicht sogar geplant, dass sie so den stärksten Redner aus dem "Gegner"-Team "mundtot" gemacht haben?
hi David, eindrückliche Beschreibung und zum Glück kenne ich die Beispiele selbst nur weniger extrem. Was ich mich aber Frage: wieso musstest du deine Rolle so fix ausleben? Das erscheint mir doch sehr dogmatisch. Klar als externer Berater haut man nicht auf den Tisch, aber hättest du da nicht mal explizit aus deiner Rolle rausgehen können? Meine einzige Erklärung, warum du das nicht gemacht hast, wäre, dass du über das IT Dept. engagiert wurdest und dann hast du gegenüber dem Vertrieb natürlich kein starkes Standing um aus der Rolle zu fallen. Wenn du aber über die GF in das Projekt gekommen wärst, wäre ich als Auftraggeber mindestens enttäuscht, dass der Berater dabei zuschaut, wie der Karren vor die Wand fährt. Evtl. war's ja auch nur ne Geschichte, damit wir endlich mal die Bücher lesen. Bei mir stehen sie jetzt immerhin schon mal auf der Wunschliste ;) Würde mich über ein Follow-Up freuen, sowohl was meine Frage angeht als auch, wie es in dem Beispiel ausging.
Okay, als Nerds hätten die vielleicht mit Mathe trumpfen können^^ Dem Kunden vorrechnen wie lange es brauchen wird und selbst mit 10-20% Leistungssteigerung, dass dann nur max 2 Monate schneller gehen würde (bei 4 Monaten verzug wäre das dann schon Mathematisch nicht schaffbar) und dann vielleicht noch anhängen, dass das Projekt nicht realisierbar ist, solange es mit allen momentanen Inhalten länger braucht als bei 20% Leistungssteigerung
Ja ähnliches habe ich auch erlebt und gelesen. Erlernen und verbessern der eigenen Soft Skills benötigt auch praktische Übung, denn grau ist alle Theorie und im Alltag zählt die praktische Umsetzung. Mir fehlt die praktische Übung trotz theoretisch gelesenem Büchern: Psychologie für den Alltag, Die Kunst zu überzeugen, Soft Skills für Softwareentwickler sowie The Mythical Man-Month und Getting to yes: Negotiating agreement without giving in.
Letztendlich Selbstbetrug, wenn ich durch rethorische Mitteln versuche gegen Entwickler anzustinken - letzendlich entwickeln sie das Produkt, alles andere ist einfaches Wunschdenken.
Ich kann euch das Buch „Never Split The Difference“ von Chris Voss ans Herz legen. Es ist kurz, bringt ganz klare Anleitung für eine Hand voll Gesprächstechniken und sie sind wirklich praktisch anwendbar.
Die besten Bücher die ich zu Kommunikation gelesen habe sind die „Miteinander reden“ Reihe von Schulz von Thun. Das erste Buch reicht schon um mehr über das Thema zu wissen als 95 % der Leute.
Vielleicht sind die Titel auch so gewählt, damit man die Bücher im Zug lesen kann. Man wird wahrscheinlich seltsam angeschaut, wenn man ein Buch mit dem Titel "Wie man Menschen manipuliert" liest 😅
Hey David, Interessanten Kanal hast du da, bin grade über Ihn gestolpert. Glocke Aktiv hast du dir verdient und mit meinem Support kannst du rechnen! Viel Erfolg in Zukunft
Habe ständig solche situationen. Vertragsverhandlungen mit den kunden laufen über 7-8 Monatze und dann gibts mitte November nen PO. Und dann soll die Lösung doch bitte bis ende des Jahres fertig sein.. wegen Budget und so. Dann sage ich meinen Kunden:: Kann man so machen... dann wirds halt nicht gut. Wir können uns keine Entwickler aus den RIppen schneiden, also können schnell oder gut... nicht beides. Intern, also ggü. Sales, hilft oft ein simples "Nö". "Aber ihr könntet doch..." "Nö". Einfach wiederholen. Stumpf ist trumpf.. gerade beim vertrieb. Denn wenn es am Ende zum Schwur kommt, egal ob man überstimmt wurde oder nicht, kann man immer sagen: Hab ich doch gesagt, war ne dumme idee.
Meine Frage ist, zu welchen Themen man KONKRET Kurse besuchen oder Bücher lesen sollte. Wo findet man solche Kurse? Wie heißen die? Gibt es da auch auf UA-cam Videos, die empfehlenswert sind? Ich hab mir die beiden Hörbücher besorgt und ich hatte vorher schon eins, dass durchaus empfehlenswert ist: "die Psychologie des Überzeugens". Aber ich würde tatsächlich gern auch mal richtige Kurse besuchen, hab aber keine Ahnung, wo ich anfangen soll.
Das Video offenbart, das die Softwareentwickler wenig Softskills besitzen-leuchtet ein. Es gab aber auch keinen Lösungsansatz zu dem vorgezeigte Problem in der Konferenz. Die Softwareentwickler konnten die Deadline nicht einhalten und haben es kommuniziert-aber was wäre die Lösung gewesen? Mit welcher Aussage / Punkten hätten sie eine gute Basis gehabt?
Bei uns macht einfach jeder was er denkt. Da bleibt eben auch mal etwas wirklich Wichtiges 5 Jahre liegen. - Ja, es ist öffentlicher Dienst. - Da ist jeder froh, wenn die Arbeit irgend jemand anderes erledigt.
Für mich eigentlich unverständlich. Ich will niemanden überzeugen müssen oder sonst was. Für mich beruht das ganze auf Vertrauen ohne irgendwelchen Psychologiekram und Manipulation. Wenn jemand sagt, dass er eine bestimmte Zeit für etwas braucht, dann muss ich ihm vertrauen, denn er ist ja der Fachmann dort. Dass die Aussage dann Marketing/Sales oder sonst wem nicht passt, sollte klar sein. Aber eine Überredenskunst wird auch nix dran ändern, dass der Termin bei gleichem oder sogar wachsendem Featurestack nicht gehalten werden kann. Und das nützt am Ende niemanden. Als Entwickler redet man dem Verkäufer ja auch nicht rein und sagt, du musst jetzt innerhalb einer Woche 10 Neukunden an Land ziehen, wo er normal einen Monat für braucht, nur damit dem Entwickler eine höhere Unternehmensbeteiligung ausgezahlt wird als Bonus. Das hat ein Entwickler ja auch keine Ahnung von und sollte sich auf die Fertigkeiten der verkäufer verlassen.
Ha! Das ist gar nichts. Konnten einmal einen Termin nicht halten. Nach Kommunikation mit Vertrieb und Kunden wurde der Termin dann nicht nach hinten, sondern sogar nach vorne gezogen. 😂😂😂😂 Werde ich mein Leben lang nicht verstehen.
Dejavu an Projekt wo ach so hype, agile, vertriebsorientierte und kommunikativ starke Geschäftsführung, mit teils wenig fachlicher Ahnung aber viel Schaumschlägerei, das ursprünglich hoch motivierte Entwicklerteam innerhalb weniger Monate zu DnV (Dienst nach Vorschrift) brachte durch ständige Produktanpassungen --erweiterungen, Nebentätigkeiten. Entwicklerzeit ging massiv in die Tonne, und am Ende haben alle verloren und Wege trennten sich dauerhaft. Bei solch strukturellen Problemen helfen wohl auch keine Bücher und rein kosmetischen Designverbesserungen zu Lasten von funktionalität. Probleme der heutigen Zeit unabhängig von Softskills ...
Für mich haben in dem Fall die PO‘s versagt. Die haben offensichtlich einen viel zu umfangreichen backlog erstellt. Und an irgendeinem Punkt hätte das ihnen auffallen müssen. Und ich bin eigentlich der Meinung, dass sie bei dieser Diskussion eher zu den Entwicklern halten sollten als zum Vertrieb. So schieben sie den schwarzen Peter einfach nur an die Entwickler weiter.
Wenn ich euer Chef gewesen wäre, hätte ich bestimmt als erstes dich (den Architekt und scrammaster) gekündigt und währe dieses Projekt mit gutem Gewissen zwecks Pünktlichkeit und Qualität angegangen. Weil wer braucht schon Leute die ganze Zeit nur meckern und herumzicken und auch nur reden anstatt endlich anfangen zu programmieren.Sorry wenn ich das sagen musste aber sehe in deinen Videos nur sinnloses hin und her gerede wo wirklich niemanden weiter bringt. Mfg
Gute Buchempfehlungen, da stimme ich Dir zu. Was ich nicht ganz nachvollziehen kann, ist, wie Du in der beschriebenen Situation zu der Schlussfolgerung kommst, dass die Software-Entwickler die Diskussion verloren und die Manager gewonnen hätten. Ich komme zu genau dem gegenteiligen Schluss. Die Manager hätten gewonnen, wenn sie tatsächlich bis Jahresende ihre Software bekommen oder eine neue, konsensfähige Produktvision beschlossen hätten. Beides scheint mir nicht der Fall zu sein. Inzwischen kannst du ja berichten, ob die Software zum Jahresende fertig war? Die Softwareentwickler haben jetzt hingegen bis Jahresende Ruhe, vielleicht sogar ein Agreement so lange von neuen Anforderungen verschont zu bleiben, wer möchte kann sich in Ruhe nach einem neuen Job umsehen, und damit dass die Software bis Jahresende fertig wird rechnet so wie so niemand - nicht mal das Management, wenn es zugehört hat. OK, hat es wahrscheinlich nicht, also muss man auch hier eher wieder zu dem Schluss kommen, dass das Management über seine fehlenden Softskills gestolpert ist, nicht die Entwickler. Eine Diskussion gewinnen heißt doch nicht, die anderen argumentatorisch platt zu machen, sondern etwas erreicht zu haben. Das kann ich hier nicht sehen. Auch oder erst recht nicht beim Management.
Im Prinzip hast du hier doch verloren. Du hattest deinen Standpunkt und gleichzeitig bist du hier auch der Softwarearchitekt. Damit hättest du hinter dem Softwareteam als Architekt stehen müssen und nicht die Rolle des neutralen Moderators annehmen sollen.
Ein schönes Beispiel dafür, warum man die Scrum Master-Rolle nicht anderen Rollen mixen sollte.
Stimmt, hier hätte der Scrum Master im spring Planning das unabhängige schätzen gewährleisten sollen. allerdings treten Scrum Master, die nicht aus der Technik kommen, oft als der verlängerte Arm des Managements auf. Am besten ist deshalb ein Scrum Master, der einen technischen Hintergrund hat und ein gutes Standing Unternehmen besitzt, um bei auftretenden Problemen, die meistens externer Natur sind, diese mit den entsprechenden steakholder zu lösen.
There is no free lunch. Selbst wenn das Dev-Team jetzt unter großen Anstrengungen den Sieg einfährt, wird im Zuge von crunching und co. eine Narbe zurück bleiben. Im schlimmsten Fall werfen Entwickler davor, danach oder währenddessen hin. Der Arbeitsmarkt gibt eine schnelle Neuorientierung definitiv her. Würde als Entscheider technische und personelle Limitation akzeptieren und nicht mein Personal abfucken. Ne anschließende "Pizza-Runde" wird da nicht mehr viel bringen...
Wie jetzt Pizza? Ich dachte erst gibt es Vorschläge danach Kuchen. Vorschläge? - Kuchen ;-)
Der Gedanke kam mir sofort. Ich würde das letzte halbe Jahr nutzen um davon zu rennen. Sollen doch die guten Schwätzer und Überzeuger einfach alles selber schreiben. Was für eine Dreistigkeit, den Entwicklern zu erklären, wann sie fertig sein werden.
Wow, das war 1:1 genau so bei meinem alten Arbeitgeber. Bis hin zur Pizzarunde xD
Ja klar, lieber zum Italiener gehen wie den Entwicklern danach am Erfolg in punkto Gehalt zu beteiligen. Den Termin fürs Essen legen wir natürlich aufs Wochende. Sonst kommt einer von denen noch auf die Idee das war Arbeitszeit.
Na, das Set-Up Sales/Marketing vs Dev Team kann ja eigentlich nur so ausgehen, dass das dev team den Kürzeren zieht: Fähige Leute in Sales und Marketing sind Profis im Überreden. Das ist deren Talent und Kernkomptenz!
Entwickler können (und sollten!) da natürlich versuchen, aufzuholen. Aber auf Augenhöhe werden sie vermutlich nicht kommen. Ein ordentliches Führungsteam weiß das, und verhindert möglichst, dass sich so eine Konstellation bildet.
Ich habe auch ein Thema mit dem Sales. Allerdings ist hier weniger die Deadline das Thema. Hier geht es eher um das Verständnis von: "Wieso dauert etwas 2 Wochen, dass ist doch nur ein Feld auf der Maske". Man kann hier Argumente bringen wie man will, die Leute sind nicht gewillt auch nur annähernd darauf einzugehen. Ähnlich ist es mit Prioritäten, denn da geht es um die Provision der netten Kollegen.
Meiner Meinung nach gehören aber beide Seiten dazu. Die Entwicklung die die Argumente bringt, warum etwas so ist wie es ist. Und in meinem Fall die Sales Seite auf der anderen Seite.
Der Vertrieb mag für die Firma den größtmöglichen Umsatz rausholen will. Mit der Art und Weise wie aber auf die Entwicklung zugegangen wird und wie sie behandelt wird, wird einfach nur Frust erzeugt. Jeder unserer Entwickler wird wöchentlich von Headhuntern angesprochen. Irgendwann ist das Maß erreicht, an dem man sich genau diesen Frust nicht mehr antut.
Was hat der Vertrieb also mit seiner Art und Weise erreicht? Das Gegenteil! Die Personalnot wird noch größer, die Entwickler noch mehr Frustriert, es besteht Burnout Gefahr und am Ende verliert die Firma!
Man sollte also nicht nur die Entwickler weiterbilden ;)
Es kommt oft genug vor, dass die BWLer/Vertriebler durch Gewinnmaximierung auch Unternehmen zerstören. Sei es das es Braindrain gibt, oder die Schaffenden Leute mit Burn-Out Jahre ausfallen.
Ich bin mitterweile so stumpf geworden, dass ich einfach hart bleibe und Nein sage. Ich fordere von der Gegenseite Eingeständnisse. Just for fun könnt ihr ja der Gegenseite mal vorschlagen, dass sie euch folgendes unterscheiben soll: Wenn es zu Crunch kommt, mögen diese Leute bitte unbezahlt anwesend sein, wenn die Überstunden gemacht werden oder Pausen weggelassen.
Die müssens ja nicht mal unterschreiben, wenn Du nur nachweisen kannst, daß Du sie in Kenntnis gesetzt hast.
Danke, dass du das mit den Buchtiteln nochmal angesprochen hast. Ich war schon skeptisch, da die Titel irgendwie esoterisch wirken. Ich hole mir definitiv die beiden Bücher. Danke für die Empfehlung. 😀
Ich kenn nur das „Wie man Freunde gewinnt“, aber kann zu 100% bestätigen, dass der Titel total irreführend ist und nicht das ausdrückt was drin steht. Und meines Erachtens sollte dieses Buch jeder mal gelesen haben. Echt wertvoll!
Wie man Freunde gewinnt ist ein richtig gutes Buch. Das habe ich schon vor 10 Jahren gelesen
Diesen Aspekt finde ich genauso wichtig wie die technische Weiterbildung. Ich selber schule mich ab und zu in der Kommunikation in LinkedIn Learning z.B. der Vortrag vom Conrad Giller fand ich gut. Wir sollten unsere Persönlichkeit nicht vernachlässigen. Ich treffe Entwickler, die ihre Persönlichkeitsentwicklung vernachlässigen und dadurch die Stimmung im Team schlecht ist, weil die Kommunikation mit den Anforderern nicht optimal oder unterwürfig läuft.
Hi David, danke für den Buchtipp „Wie man Freunde gewinnt“ von Dale Carnegie. Habe reingelesen und ich kann kaum glauben, dass das Buch schon so alt ist. Man erkennt, dass das sich Miteinander der Menschen nicht ändert. Ist nicht nur für die Erweiterung der Softskills im Arbeitsalltag gut, sondern man kann seine Regeln auf sein gesamtes Umfeld anwenden.
Wenn dann auch noch Uneinigkeit im Entwicklerteam herrscht, hat man überhaupt keine Chance gegen dieses Bollwerk PO und Vertrieb.
Wenn Du mit im Entwickler Team bist, wieso bist Du dann Moderator? Aber ich denke selbst dann, wenn Du merkst, das etwas in die falsche Richtung läuft,hättest Du das Team irgendwie stützen müssen, denn auch Du musst jetzt mit dem Ergebnis leben.
Wiederhole das Meeting ohne ein Moderator zu sein, dann kannst Du Dein Team stützen.🤗😏✌️
Ein Moderator war er nicht, wenn er ungebremste Reaktion zuließ.
Als Entwickler sehe ich die Wahrheit im technisch machbaren. Jemand der etwas unfertiges unbedingt durch Diskussion erzwingen will, kann in meiner Sicht nur scheitern. Warum kommen aber Verkäufer, POs... damit durch? Warum müssen sie sich nicht verantworten wenn sie die Warnungen ignorierten? Dann würden sie nächstes mal auch realistischer planen.
Die kommen damit durch, weil es im Nachhinein von den Verkäufern dann heißt: "ja wir haben die Entwickler doch gefragt ob es machbar ist", so wie in diesem Fall, nur das es eher ein Überreden auf Druck hin in den meisten Fällen ist...erlebe ich selbst häufig.
Interessanter Ansatz. Es stellt sich allerdings die Frage, ob man in einer Argumentation überzeugen kann, in der die andere Seite nur gewinnen will. Und was das das für ein Phyrrus Sieg ist, wenn dann nach einem halben Jahr die Software immer noch nicht fertig ist, darüber brauchen wir uns nicht zu wundern. Aus meiner Sicht hat ein Projekt in einer Firmenkultur, die so ein Verhalten begünstigt, keine Aussicht auf Erfolg. Aber ich sehe Conway’s Gesetz auch weiter gefasst als die meisten Leute…
Ich kenn nur das „Wie man Freunde gewinnt“, aber kann zu 100% bestätigen, dass der Titel total irreführend ist und nicht das ausdrückt was drin steht. Und meines Erachtens sollte dieses Buch jeder mal gelesen haben. Echt wertvoll!
Das ist genau der Grund, warum Produkte oft beim Kunden reifen. Die Firmen wollen auch fürs Image laufend Innovationen präsentieren, sehen aber nicht den damit verbundenen Aufwand. Da steht z. B. ein Messetermin seit langem fest und der Druck steigt mit der verbleibenden Zeit. Leider gibt es durch den Druck auf die Mitarbeiter das Phänomen, dass es dann doch irgendwie klappt. Gesund ist das nicht - vor allen wenn das zum Normalfall wird und voll auf die Mitarbeiter geht.
War/Ist genauso bei mir als Technischer Zeichner. Vor einem halben Jahr und jetzt wieder. Einmal war es ein Teilfortschritt und jetzt die Projektabgabe. Vor nem halben Jahr wurde mir nach 3 Monaten Unterstützung zugesagt für die letzten 2 Wochen und was ich denn habe. Ich so: Wenn der vorr 4 Wochen eingestiegen wäre hätten wir es locker geschafft (gesamt also die 7 letzten). Ich habe meinen Urlaub verschoben um eine Woche und hab in den letzten 5 Wochen ca. 70-80 Überstunden gemacht. Jetzt wollen die sowas ähnliches, aber ich sagte schon, dass ich mich von damals nicht erholt habe, da es ja direkt stressig weiter ging. Ich mache 1-2 h mehr pro Woche, mein absolutes max. um nicht durchzudrehen. Diesmal habe ich seit 4 Monaten 1 Person mehr, obwohl ich vor nem halben Jahr schon 2-3 Unterstützer (dauerhaft) gefordert habe. Seit nem halben Jahr bin ich dauerhaft einem Burnout sehr nah.
Ich habe schwierigkeiten mir die Diskussion vorzustellen. Ich nehme mal an, an dem Kriesenmeeting hat kein Teamleiter der Entwickler teilgenommen? Meiner Erfahrung nach ist ab fachlicher bzw. disziplinarischer Leitung ein intrinsischer Bedarf der Verbesserung der eigenen Softskills häufig gegeben, somit sollte zumindest ein Teamleiter in der Lage sein sich schützend für sein Team einzusetzen. Schützend deshalb, da vermutlich die Entwickler noch unzufriedener (unzufrieden sind sie vermutlich sowieso schon, keiner freut sich wenn deadlines nicht erreicht werden) sind. Der Druck auf die Entwickler steigt obwohl denen eigentlich klar ist, dass das Ziel nicht erreicht werden kann. Worst case, werden Entwickler kündigen oder krank, da diese sich nicht gehört fühlen und der Druck zu groß wird. Für mich sieht die Arbeitsumgebung ziemlich toxisch aus, ist es nicht deine Pflicht hier einzuschreiten? Du wirst zwar für die Rolle des Architekten bzw. Scrum Masters bezahlt aber für mich gilt hier "wissen verpflichtet". Niemanden ist geholfen wenn im Dezember die ersten Kunden anstehen und nichts funktioniert und alles nur halbfertig ist und die Firma dann trotz einer guten Idee am Ende doch scheitert obwohl du es eventuell hättest verhindern können?
Ganz richtig, der Vertrieb darf nicht direkt auf die einzelnen Entwickler einwirken, sondern das muss über die Team/Gruppenleitung laufen. Sonst hat man durch den Druck am Ende noch weniger Entwickler.
Schon richtig. Bei der derzeitigen Situation wird es zwangsläufig ein halbfertiges Produkt werden für die dann im Nachgang Patches bereitgestellt werden müssen. Sind Windows-Nutzer doch gewöhnt.Wo liegt also das Problem? Imageschaden? Egal, ist der Ruf erst ruiniert... Spaß beiseite ich finde es höchst bedenklich, dass in der Firma niemand genug A... in der Hose hat zu sagen "Vertrieb und wenn ihr euch auf den Kopf stellt und Fliegen fischt die Software wird erst ein halbes Jahr später fertig sein. Ende der Diskussion."
Man kann sich nicht ständig nur Freunde machen.
Ein mögliche wäre es das Dev-Team aufzustocken, sei es jetzt mit neuen Mitarbeitern oder Freelancern. Was spricht dagegen?
Nicht jedes Team hat einen Team leiter, so wie bei uns. Das Team ist völlig autark bekommt nur die fachlichen features vom PO und das Team entscheidet dann fast alles selbst, zusammen. Zum Glück hält der PO auch vieles von uns fern, so dass wir auch „entspannt“ entwickeln oder uns verbessern können.
Da hat der Berater schlechte Arbeit geleistet
Ich finde es läßt sich nicht nur auf Softskills runterbrechen, bei Zeitplänen und Aufwänden spielen viele Sichten rein. Und natürlich gehört dazu auch ein gewisses Schubladendenken der Entscheider dazu. Nimm zwei Entwickler Stellen, die exakt das selbe machen:
- Stelle 1: schlechte Software, schlechtes Teamverhalten, rechthaberischer Teamlead, hohe Fluktuation
- Stelle 2: gute Software, gutes Teamverhalten, umsichtiger Teamlead, lange Betriebszugehörigkeit
Oben kommt sehr häufig an, dass bei Stelle 1 die Thematik anspruchsvoller ist, und man deswegen dort eventuell sogar mehr Mitarbeiter braucht. Während die Stelle 2 Glück hat, dass deren Thema scheinbar einfacher ist.
Habe ich genauso erlebt: natürlich sind/waren die Aufgaben der einzelnen Teams unterschiedlich, aber alle Teams haben auch exakt gleiche Aufgaben unterschiedlich gelöst, z.B::
- Kommunikation, Systemphasen, Hochlauf, Switchover, etc.
- Daten, Datenpersistenz und Versions-Kompatibilität, etc.
Und oft werden bei dem "soliden Handwerk" die größten Böcke geschossen. Es gibt Teams, die beschäftigen sich mehr mit sich selbst, und der eigenen Legacy, als mit innovativer Entwicklung. Und da alles bezahlt werden muss hängt es einfach auch oft einfach davon ab wie *hipp* ein Thema gerade ist. Wird was vom Kunden gefordert (und bezahlt), oder ist ein neuer Markt in Aussicht, dann gewinnt es sich auch als SW Entwickler viel schneller. Arbeitest Du solide, und dein Produkt ist etabliert, dann verlierst Du sehr schnell (weil: 1.) never change a winning team 2.) der Markt ist eh unser).
Das Entwickler öfters verlieren liegt IMO einfach an der Inkompetenz der leitenden Manager. Ich habe von meinem CEO sogar mal zu hören bekommen: Du hast gar keine schlechte Ideen, warum bist Du nicht Manager geworden.
Ja Entwickler sind die Eingreiftruppe und der Manager der General, der seine Leute auf das Schlachtfeld der Produkentwicklung führt :D
@@weluvmusicz Exakt, ich kenne einen Ex-General dessen Credo war: "Objektorientierte Programmierung ist ein Irrweg."
Das Produkt, welches er mit diesem Credo selbst verbockt hat, hat ihn in den C-Level aufsteigen lassen (denn das Thema war hipp). An dem Produkt, welches nicht sauber projektiert werden konnte, ist die Firma letztendlich pleite gegangen. Ich selber wurde zu "Aushilfe" genötigt, und weiß somit wie es um das Produkt stand. Informationen nach Housten? Fehlanzeige!
Es ist erschreckend wie "solchen Niederlagen" auf Managementseite umgegangen wird. Der alte C-Level wurde geschasst, die anderen hatte keine Handhabe, und gelernt wird nix außer: "Bloß nicht das Maul aufreissen, bloß keine Verantwortung übernehmen, bloß keine Entscheidungen treffen, nichts tun ist besser als Fehler nachgewiesen zu bekommen". Kennt man auch als: "cover your ass".
Sehr wichtiges Thema! Danke für die Aufklärung.
Am Ende des Jahres auflaufen lassen und "wir haben es euch ja gesagt" dem Vorstand so ins Gesicht sagen. Immer die gleichen Probleme mit Vertrieb die von der Technik keine Ahnung haben. Alle 8 Kündigen selbst ihre Stellen und gehen woanders hin. Dann kann sich das Unternehmen um neue Entwickler Kümmern und die erst einmal einarbeiten. Und das dauert länger als die 6 Monate Verzögerung.
Ehrlich gesagt habe ich gar keine Lust mich als Verkäufer oder Menschenversteher weiterzubilden. Wenn ich das in irgendeiner weise gewollt hätte, hätte ich ein anderes Berufsbild. Es ist eher ein Armutszeugnis der Leitung und der anderen Abteilungen das diese nicht auf diejenigen mit der Erfahrung auf dem Gebiet hören.
Und dann gibt es noch die Realität und die sieht nunmal so aus. Btw sind daß alles Softskills, die auch in der Gehaltsverhandlung und im restlichen Leben helfen, also nicht einfach so abtun bitte
Einfach motzen, wenn was nicht gefällt. Wenn der Niedergang unausweichlich erscheint, hat man auch nichts mehr zu verlieren, sondern hat schon verloren. Deshalb muss man sich nicht stressen lassen.
Was ich nicht verstehe: Warum warst Du Moderator?
Bist Du nicht ein bisschen "zu teuer" um nur die Diskussion zu moderieren? :D
Außerdem beseht dein Job zu einem Großteil ja auch genau aus dem, was Du hier ansprichst, warum darfst Du nicht unterstützen oder das "Team Softwareentwicklung" in der Diskussion nicht anführen?
Oder war das vielleicht sogar geplant, dass sie so den stärksten Redner aus dem "Gegner"-Team "mundtot" gemacht haben?
Denke das war einfach schlechtes Management in diesem Fall. So einen Fall habe ich zumindest selbst schon bei mir erlebt.
Richtig gutes Video 💪
hi David,
eindrückliche Beschreibung und zum Glück kenne ich die Beispiele selbst nur weniger extrem. Was ich mich aber Frage: wieso musstest du deine Rolle so fix ausleben? Das erscheint mir doch sehr dogmatisch. Klar als externer Berater haut man nicht auf den Tisch, aber hättest du da nicht mal explizit aus deiner Rolle rausgehen können? Meine einzige Erklärung, warum du das nicht gemacht hast, wäre, dass du über das IT Dept. engagiert wurdest und dann hast du gegenüber dem Vertrieb natürlich kein starkes Standing um aus der Rolle zu fallen.
Wenn du aber über die GF in das Projekt gekommen wärst, wäre ich als Auftraggeber mindestens enttäuscht, dass der Berater dabei zuschaut, wie der Karren vor die Wand fährt.
Evtl. war's ja auch nur ne Geschichte, damit wir endlich mal die Bücher lesen. Bei mir stehen sie jetzt immerhin schon mal auf der Wunschliste ;)
Würde mich über ein Follow-Up freuen, sowohl was meine Frage angeht als auch, wie es in dem Beispiel ausging.
Okay, als Nerds hätten die vielleicht mit Mathe trumpfen können^^ Dem Kunden vorrechnen wie lange es brauchen wird und selbst mit 10-20% Leistungssteigerung, dass dann nur max 2 Monate schneller gehen würde (bei 4 Monaten verzug wäre das dann schon Mathematisch nicht schaffbar)
und dann vielleicht noch anhängen, dass das Projekt nicht realisierbar ist, solange es mit allen momentanen Inhalten länger braucht als bei 20% Leistungssteigerung
Ja ähnliches habe ich auch erlebt und gelesen. Erlernen und verbessern der eigenen Soft Skills benötigt auch praktische Übung, denn grau ist alle Theorie und im Alltag zählt die praktische Umsetzung. Mir fehlt die praktische Übung trotz theoretisch gelesenem Büchern:
Psychologie für den Alltag, Die Kunst zu überzeugen, Soft Skills für Softwareentwickler sowie The Mythical Man-Month und Getting to yes: Negotiating agreement without giving in.
morgen bestellt, heute geliefert.....
.. gestern gelesen 😜
Letztendlich Selbstbetrug, wenn ich durch rethorische Mitteln versuche gegen Entwickler anzustinken - letzendlich entwickeln sie das Produkt, alles andere ist einfaches Wunschdenken.
Ich kann euch das Buch „Never Split The Difference“ von Chris Voss ans Herz legen. Es ist kurz, bringt ganz klare Anleitung für eine Hand voll Gesprächstechniken und sie sind wirklich praktisch anwendbar.
Die besten Bücher die ich zu Kommunikation gelesen habe sind die „Miteinander reden“ Reihe von Schulz von Thun. Das erste Buch reicht schon um mehr über das Thema zu wissen als 95 % der Leute.
Vielleicht sind die Titel auch so gewählt, damit man die Bücher im Zug lesen kann. Man wird wahrscheinlich seltsam angeschaut, wenn man ein Buch mit dem Titel "Wie man Menschen manipuliert" liest 😅
Hey David,
Interessanten Kanal hast du da, bin grade über Ihn gestolpert.
Glocke Aktiv hast du dir verdient und mit meinem Support kannst du rechnen! Viel Erfolg in Zukunft
Habe ständig solche situationen. Vertragsverhandlungen mit den kunden laufen über 7-8 Monatze und dann gibts mitte November nen PO. Und dann soll die Lösung doch bitte bis ende des Jahres fertig sein.. wegen Budget und so. Dann sage ich meinen Kunden::
Kann man so machen... dann wirds halt nicht gut. Wir können uns keine Entwickler aus den RIppen schneiden, also können schnell oder gut... nicht beides.
Intern, also ggü. Sales, hilft oft ein simples "Nö". "Aber ihr könntet doch..." "Nö". Einfach wiederholen. Stumpf ist trumpf.. gerade beim vertrieb. Denn wenn es am Ende zum Schwur kommt, egal ob man überstimmt wurde oder nicht, kann man immer sagen: Hab ich doch gesagt, war ne dumme idee.
Meine Frage ist, zu welchen Themen man KONKRET Kurse besuchen oder Bücher lesen sollte. Wo findet man solche Kurse? Wie heißen die? Gibt es da auch auf UA-cam Videos, die empfehlenswert sind?
Ich hab mir die beiden Hörbücher besorgt und ich hatte vorher schon eins, dass durchaus empfehlenswert ist: "die Psychologie des Überzeugens".
Aber ich würde tatsächlich gern auch mal richtige Kurse besuchen, hab aber keine Ahnung, wo ich anfangen soll.
Das Video offenbart, das die Softwareentwickler wenig Softskills besitzen-leuchtet ein. Es gab aber auch keinen Lösungsansatz zu dem vorgezeigte Problem in der Konferenz. Die Softwareentwickler konnten die Deadline nicht einhalten und haben es kommuniziert-aber was wäre die Lösung gewesen? Mit welcher Aussage / Punkten hätten sie eine gute Basis gehabt?
Bei uns macht einfach jeder was er denkt. Da bleibt eben auch mal etwas wirklich Wichtiges 5 Jahre liegen. - Ja, es ist öffentlicher Dienst. - Da ist jeder froh, wenn die Arbeit irgend jemand anderes erledigt.
Für mich eigentlich unverständlich. Ich will niemanden überzeugen müssen oder sonst was. Für mich beruht das ganze auf Vertrauen ohne irgendwelchen Psychologiekram und Manipulation. Wenn jemand sagt, dass er eine bestimmte Zeit für etwas braucht, dann muss ich ihm vertrauen, denn er ist ja der Fachmann dort. Dass die Aussage dann Marketing/Sales oder sonst wem nicht passt, sollte klar sein. Aber eine Überredenskunst wird auch nix dran ändern, dass der Termin bei gleichem oder sogar wachsendem Featurestack nicht gehalten werden kann. Und das nützt am Ende niemanden. Als Entwickler redet man dem Verkäufer ja auch nicht rein und sagt, du musst jetzt innerhalb einer Woche 10 Neukunden an Land ziehen, wo er normal einen Monat für braucht, nur damit dem Entwickler eine höhere Unternehmensbeteiligung ausgezahlt wird als Bonus. Das hat ein Entwickler ja auch keine Ahnung von und sollte sich auf die Fertigkeiten der verkäufer verlassen.
Ich hab dann einfach gekündigt, weil der "Vorgesetzte" einfach das bessere Ansehen bei dem Entwicklungsleiter/GF hatte... Unerträglich....
Ha! Das ist gar nichts. Konnten einmal einen Termin nicht halten. Nach Kommunikation mit Vertrieb und Kunden wurde der Termin dann nicht nach hinten, sondern sogar nach vorne gezogen. 😂😂😂😂 Werde ich mein Leben lang nicht verstehen.
Ziemlich arschig, dass du die Devs nicht supported hast, Scrum hin oder her
Was passiert, wenn zwei Leute mit unterschiedlicher Meinung die selbe Technik anwenden um den jeweils anderen auf seine Seite zu ziehen? 😀
Sie verschmelzen zum Yin Yang Symbol
Naja ... selbst wenn man softskills hat. Hilft nichts bei massivem Bossing oder Diskriminierung ....
Dejavu an Projekt wo ach so hype, agile, vertriebsorientierte und kommunikativ starke Geschäftsführung, mit teils wenig fachlicher Ahnung aber viel Schaumschlägerei, das ursprünglich hoch motivierte Entwicklerteam innerhalb weniger Monate zu DnV (Dienst nach Vorschrift) brachte durch ständige Produktanpassungen --erweiterungen, Nebentätigkeiten. Entwicklerzeit ging massiv in die Tonne, und am Ende haben alle verloren und Wege trennten sich dauerhaft. Bei solch strukturellen Problemen helfen wohl auch keine Bücher und rein kosmetischen Designverbesserungen zu Lasten von funktionalität. Probleme der heutigen Zeit unabhängig von Softskills ...
Für mich haben in dem Fall die PO‘s versagt. Die haben offensichtlich einen viel zu umfangreichen backlog erstellt. Und an irgendeinem Punkt hätte das ihnen auffallen müssen. Und ich bin eigentlich der Meinung, dass sie bei dieser Diskussion eher zu den Entwicklern halten sollten als zum Vertrieb. So schieben sie den schwarzen Peter einfach nur an die Entwickler weiter.
Deswegen studiere ich Wirtschaftsinformatik :)
Da stellen sich doch die anderen auch ziemlich doof an. Die Software Entwickler zu ignorieren ist nicht besonders schlau.
Wer Visionen hat, der möge zum Arzt gehen .... 😂
Ihr braucht nen front mann wie mich. Ich beiss die alle weg wenn die aufs grundstück wollen 🤣
Wenn ich euer Chef gewesen wäre, hätte ich bestimmt als erstes dich (den Architekt und scrammaster) gekündigt und währe dieses Projekt mit gutem Gewissen zwecks Pünktlichkeit und Qualität angegangen. Weil wer braucht schon Leute die ganze Zeit nur meckern und herumzicken und auch nur reden anstatt endlich anfangen zu programmieren.Sorry wenn ich das sagen musste aber sehe in deinen Videos nur sinnloses hin und her gerede wo wirklich niemanden weiter bringt. Mfg
Dann sollen die Woken ihre schxxx Software doch selbst entwickeln. Ich schaue dann entspannt zu.😁