Experten… das ist eines der völlig überstrapazierten Wörter in der heutigen Zeit.
Jeden Tag finden sich neue “Experten”.
Der Markt wir mit “TOP”…. geflutet.
Und ich muss zugeben, ich bin kein Experte dieser Art.
Wenn man “der Beste ist”, so muss man das Keinem sagen.
Wenn man “nicht der Beste ist”, so sollte man das Keinem sagen.
Experten gibt es heute für Alles - bis hin zum Experten vom Schneiden nicht vorhandener Barthaare.
Unsere Gesellschaft verläßt sich auf „konstruktive“ Kritik als einen heimlichen Bestrafungs-Mechanismus.
Kritik ist immer negativ # Nichts, was heutzutage als Kritik bezeichnet wird, ist konstruktiv .
Es reduziert bloß die Selbstbestimmung des Individuums. (Schau mal, ich bin im Recht und Du im Unrecht)
Es gibt zwei Methoden, um jemandem zu sagen, daß er etwas tut, von dem man denkt, daß er es nicht tun sollte.
Ein Lösungsansatz zur Restrukturierung # © 2008-2021 Thomas Arends # Kurzbericht zur Lösung einer Gefahrensituation in einem Unternehmen
Gefahrensituationen in Unternehmen Ein Lösungsansatz
Schreibfehler in diese Seite werden nicht korrigiert Vorwort: # Zu aller erst etwas ganz ganz ganz Wichtiges.
30 (Software)-Engineering-Themen, die seit 30 Jahren konstant geblieben sind # Anfängliche Anforderungen sind selten zu mehr als 50% vollständig. Die Anforderungen wachsen während der Entwicklung mit etwa 2% pro Kalendermonat. Etwa 20 % der anfänglichen Anforderungen verzögern sich bis zu einem zweiten Release. Das Finden und Beheben von Fehlern ist die teuerste Software-Aktivität. Das Erstellen von Papierdokumenten ist die zweitteuerste Softwareaktivität. Codierung ist die drittteuerste Softwareaktivität. Meetings und Diskussionen sind die viertteuerste Aktivität. Die meisten Formen des Testens sind weniger als 35% effizient beim Finden von Fehlern. Die meisten Formen des Testens berühren weniger als 50% des zu testenden Codes. Es gibt mehr Fehler in den Anforderungen und im Design als im Quellcode. Es gibt mehr Fehler in Testfällen als in der Software selbst. Defekte in Anforderungen, Design und Code betragen durchschnittlich 5,0 pro Funktionspunkt. Die Gesamteffizienz der Fehlerbeseitigung vor der Freigabe beträgt im Durchschnitt nur etwa 85 %. Etwa 15 % der Softwaredefekte werden an Kunden ausgeliefert. Ausgelieferte Defekte sind teuer und verursachen Kundenunzufriedenheit und technische Schulden. Etwa 5% der Module in Anwendungen enthalten 50% aller Defekte. Etwa 7 % aller Fehlerreparaturen führen versehentlich zu neuen Fehlern. Software-Wiederverwendung ist nur bei Materialien effektiv, die sich Null-Fehler nähern. Etwa 5 % der Software-Outsourcing-Verträge enden in einem Rechtsstreit. Etwa 35% der Projekte > 10.000 Funktionspunkte werden abgebrochen. Ungefähr 50% der Projekte > 10.000 Funktionspunkte kommen ein Jahr zu spät. Der Fehlermodus für die meisten Kostenschätzungen ist, zu optimistisch zu sein. Die Produktivitätsrate in den USA liegt bei etwa 10 Funktionspunkten pro Mitarbeitermonat. Die Auftragsumfänge für die Entwicklung liegen bei etwa 150 Funktionspunkten. Der Auftragsumfang für die Wartung beträgt ca. 750 Funktionspunkte. Entwicklung kostet in den USA etwa 1200 $ pro Funktionspunkt
(Bereich < $500 bis > $3000). Die Wartung kostet ca. 150 $ pro Funktionspunkt pro Kalenderjahr. Nach der Auslieferung wachsen Anwendungen während der Nutzung um etwa 8 % pro Kalenderjahr. Die durchschnittliche Fehlerbehebungsrate liegt bei etwa 10 Fehlern oder Defekten pro Monat. Programmierer und Manager benötigen jährlich etwa 10 Tage Schulung, um auf dem neuesten Stand zu bleiben.
Projektleiter / Manager Stellenangebote heute…
Ein wünschenswertes Extra / ein Muss sind Zertifizierungen im Bereich Projektmanagement.
“Wie können wir nur ohne Zertifizierung uns auf eine solche Stelle bewerben und uns Projektleiter nennen?”
Eine solch schwachsinnige Frage wurde tatsächlich seitens einer Personalreferentin gestellt.
Schon 1986 gab es Projekte und die haben wir erfolgreich zum Abschluss gebracht. Zertifikate gab es nicht und trotzdem waren wir Projektleiter.
Danach haben wir in mehr oder weniger jeder Entwicklungs-Domäne (Software, Hardware, Mechanik, Personal, Verlagerung….) Erfolge verzeichnet.
Im Laufe der Zeit sind wir immer besser geworden, aber zertifiziert waren wir nie.
Managing any kind of project is never difficult! # Anything is only difficult, as long as you do not understand what your task is, what is the situation, or if you omit vital prooven successful steps. There can be many challenges in a project, but to state, that it is difficult always makes me important and implies that I am better than you.
The project manager is always getting blamed if things do not turn out as expected, no matter what the reason. But if you know that this is a part of the job, you handle it like a father handles his emotional children. You see it, understand it and treat it with a smile.
Autor Patrick Becka –> Übersetzung Thomas Arends # Bei verschiedenen Gelegenheiten war ich in Meetings mit Geschäftsleuten und Softwareexperten involviert und stellte fest, dass beide Parteien ein grundlegendes Missverständnis darüber haben, was agil bedeutet und was nicht.
Beginnen wir also im Hinblick auf das Agile Manifest mit dem, was Agile nicht sagt:
Einzelpersonen und Interaktionen über Prozesse und Werkzeuge # Was das NICHT bedeutet:
Prozesse und Tools spielen keine Rolle.
Prozesse ermöglichen es Unternehmen, im Laufe der Zeit zu lernen und sich zu verbessern, und die Einhaltung von Verfahren führt zu reproduzierbaren Ergebnissen. Werkzeuge können die Art und Weise, wie ein Team Probleme erkennt und auf sie reagiert, grundlegend ändern.
Wie das alte Sprichwort besagt: Wenn das einzige Werkzeug, das Sie haben, ein Hammer ist, sieht jedes Problem wie ein Nagel aus.
Die Boeing 737 MAX 8 ist ein klassisches Beispiel für ausufernde Qualitätskosten.
Das Dieselgate muss man auch nicht weiter ausführen. Das Desaster mit dem VW ID.3 (Verzögerte Auslieferung und Task Force) gehört auch dazu. Die Liste ist – mehr als lang.
Das „magische Dreieck“ – Zeit, Qualität und Kosten wird immer wieder angesprochen. Da denkt man, dass es durch „Agilität“ besser wird, die Erfahrung stützt diese Theorie bis heute nicht.
Absturz ## Ausgangssituation Die klassische Ausgangssituation in fast jedem Projekt heutzutage ist:
Industrie : Management 4:0 # In der Produktion wird automatisiert, optimiert und, und, und.
Im Management gibt es außer der Optimierung in Bezug auf Geld und / oder Zeit selten eine weitere Optimierung.
Die Überlastung der Manager # Geschuldet ist dies Verhalten der Optimierung auf ein Ziel der Überlastung durch
one of the fundamentals in OTSM (Organisation, Technology and Service Management) == Logical Scaled business® is the law of Conway.
You never heard about it?
Maybe should apply it!
Communication. # The law of Conway # "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." — M. Conway (<a href="https://en.wikipedia.org/wiki/Conway's_law" rel="noreferrer noopener" target="_blank">Wikipedia</a>) is something that even having been discovered already in 1967. It seems to be forgotten.
