Ehrlich gesagt erinnert es mich an ein Buch von Ayn Rand.

Für jedes Mal, wenn ich beeindruckt bin, wie ruhig, freundlich und vernünftig der Protagonist ist, gibt es ein anderes Mal, wie schockiert ich darüber bin, wie rachsüchtig und kleinlich das Buch (wenn nicht der Protagonist direkt) für die Menschen ist, die im zu stehen scheinen Weg des Protagonisten. Im Moment sind es Sicherheitsexperten, aber vor ein paar Kapiteln waren es Projektmanager, dann Entwickler und dann der CEO. Niemand in diesen Abteilungen hat Sympathie für den Protagonisten, noch gibt es (bis jetzt) ​​einen Fehler, der eindeutig im Ops-Team lag - sie sind einfach perfekt in ihrer Arbeit. Und lassen Sie mich nicht mit den Beschwerden darüber beginnen, wie schmuddelig die Büros neben der Personalabteilung sind (wenn ein Teil der Arbeit der Personalabteilung darin besteht, den Menschen das Gefühl zu geben, sich wohl zu fühlen, und diese Büros Teil der Stellenbeschreibung sind).

Oh, und Erik, die DevOps-Zen-Meisterin Mary Sue. Er ist als Charakter einfach nicht glaubwürdig. Sicher, er mag existieren, aber er kennt den Protagonisten einfach nicht gut genug, um die Dinge sagen zu können, die er sagt. Ich hoffe insgeheim, dass er Tyler Durden ist.

Beendete es.

Ich bin sehr, sehr überrascht, wie "Continuous Delivery" in den Rücken geklemmt wird.

Ich bin sehr überrascht von den Kommentaren, die Bill (der Protagonist) zu den Entwicklern hat.

Ich bin geradezu erstaunt, dass das Entwicklungsteam eines großen Unternehmens in der Lage ist, innerhalb von Wochen eine wiederholbare testbare Umgebung auf VM-Basis einzurichten, auf eine Cloud-basierte Lösung wie Amazon AWS umzusteigen und eine auf Knopfdruck verpackte bereitstellbare Lösung für die Produktion zusammenzustellen und einige, wie der Operations-Typ den Kredit dafür bekommt.

Ich habe mehr als ein Jahrzehnt als E-Commerce-Berater gearbeitet, und selbst an Orten wie Twitter sind monatelange Anstrengungen erforderlich, um dies zu erreichen. Und es wird komplett beiseite geschoben, da die Entwickler es einfach "tun" können, sobald es ihnen gegenüber erwähnt wird.

Es hätte ein solides Jahr dauern sollen. Es hätte ein Jahr lang einen Engpass in ihrer kritischen Ressource Brent geben müssen. Das Gleiche gilt für die Arbeit, die sie in Kanban geleistet haben, und für den Veränderungsprozess - es hätte Monate gedauert, bis ein Berater alle an Bord gebracht hätte und dann noch länger, um die Leute dazu zu bringen, nicht in alte Gewohnheiten zu verfallen, aber irgendwie kommt Bill zurück nach einem Wochenende und sein Team hat schon alles sortiert. Es ist unehrlich und zeigt eine verzerrte Ansicht darüber, wie viel Arbeit es sein kann, sich zu ändern, und wie viel Angst die Menschen vor Veränderungen haben können, insbesondere vor den Bedrohungen durch Outsourcing und Unternehmensliquidationen.

Ich bin zutiefst schockiert darüber, wie John, der Sicherheitsmann, einen Zusammenbruch erlebt, sich betrinkt und dann ein Evangelist für Bill wird. Es ist bizarr, besonders wenn man seinen Ansatz betrachtet. Fragen Sie Etsy nach ihrer E-Commerce-Funktionalität und fragen Sie dann Etsy, ob sie ohne ihr Sicherheitsteam auskommen könnten. Es ist nicht einmal unehrlich ... es ist respektlos.

Lesen Sie Continuous Integration und darüber hinaus Software-Architektur. Rufen Sie Opscode oder eine andere Entwicklerfirma an, um eine Beratung durchzuführen. Senden Sie Ihre Mitarbeiter an Konferenzen. Nur bitte, bitte, bitte, nimm dieses Buch nicht wörtlich. Es ist Fiktion. Dadurch sieht Ayn Rand realistisch aus.

Und das ist alles, was ich dazu zu sagen habe.

Bill Palmer wird in die CIO-Position bei Parts Unlimited versetzt und hat 90 Tage Zeit, um Hühnersalat aus Hühnerscheiße zu machen, oder die gesamte IT-Abteilung wird ausgelagert. Hat Bill das Zeug dazu?

Geständniszeit: Ich habe in den letzten fünfzehn Jahren in der IT gearbeitet. Als der CTO des Unternehmens, für das ich arbeite, allen IT-Mitarbeitern dringend empfohlen hat, dies zu lesen, habe ich die Kugel gebissen.

Erinnern Sie sich an die Specials nach der Schule, die eine Art Unterricht mit einer fadenscheinigen Geschichte waren? Das war so ziemlich das. Nur anstatt coole Dinge wie Sex und Drogen zu zeigen, ging es hier um die Fallstricke eines IT-Managers. Es las sich wie das Buchäquivalent des schrecklichen Trainingsvideos, das ich mir ansehen musste, als ich vor etwa tausend Jahren bei K-Mart für Schadensverhütung arbeitete.

Bill ist ein Server-Typ, der plötzlich CIO wird und gezwungen ist, das Phoenix-Projekt umzudrehen. Ja, es ist genauso spannend, wie es sich anhört. Alle Kussarsche bei der Arbeit schwärmen von dem Buch, aber es ist kaum ein Roman. Es ist ein Management-Handbuch, das als Roman getarnt ist. Nicht nur das, Bill ist eine Art Schwanz und eine Mary Sue. Ein Dick Sue, wenn Sie so wollen.

Noch bevor ich den Autor untersuchte, konnte ich feststellen, dass er eher ein Operations-Typ als ein Entwickler war. Es war ziemlich leicht zu erkennen, wie er allen außer den Servern die schwerste Schuld gab. Es ist wie wenn ein Müllmann ein Buch schreibt, in dem der Müllmann der einzige ist, der den Tag retten kann.

Das Buch liest sich wie jemand, der von Meetings erzählt, an denen er teilgenommen hat, und das ist so ziemlich das, was es ist. Dies und einige Unternehmenspropaganda, die den Einsatz von Agile IT Management und The Cloud loben. Jetzt, wo ich darüber nachdenke, erinnert es mich irgendwie daran Die Säulen der ErdeWenn die Handlung eine Schleife von Problemen, Lösungen und unerwarteten Komplikationen ist, erstellen sie nur anstelle einer Kirche eine Anwendung. Auch die Vergewaltigungsraten sind nicht gleich.

Das Buch wird am Ende etwas unwahrscheinlich. Nach einigen aufmunternden Gesprächen und der Annahme der Agile-Philosophie kann ein Team, das seine Ärsche nicht mit beiden Händen und einer Karte finden konnte, die Dinge plötzlich genug umdrehen, um Cloud Computing auf einer halben Seite zu beherrschen.

Trotz all der oben erwähnten Abneigungen und der Tatsache, dass die Charaktere so dünn sind wie Toilettenpapier vom Dollarbaum, war dieses Buch kein totaler Scheiß. Obwohl ich entschlossen war, nichts zu lernen, gelang es mir, einige Tipps zu sammeln und viele Ähnlichkeiten mit meinem Alltag zu erkennen.

Zwei von fünf Sternen. Es ist kein großer Roman, aber jemand, der bereits darüber nachdenkt, die Techniken anzunehmen, mit denen dieses Buch Sie über den Kopf schlägt, wird es wahrscheinlich viel höher bewerten.

Weitere Bewertungen finden Sie unter Mich verbessern.

Ich weiß was du denkst.

Beeindruckend. Eine fiktive Darstellung der ITIL- und Agile-Methoden. Das klingt so ... aufregend.



Aber es ist!

Stellen Sie sich meine Überraschung vor, als ich vollständig in Bills Welt hineingezogen wurde.

IT-Betrieb macht nicht immer Spaß: Server stürzen ab; Anwendungen einfrieren; Schwachstellen sind überall; und Kunden - sowohl interne als auch externe - schreien nach Unterstützung.

Wie können Sie alle laufenden Arbeiten (WIP), Notfälle und geplanten Arbeiten verwalten? Es ist genug, um jedem professionellen Geek eine Panikattacke zu versetzen.

Betreten Sie unsere Helden: ITIL und Kanban.

Diese Best-Practice-Methoden werden Bill und seinem Team dabei helfen, die Funktionsweise der IT zu revolutionieren und zum gesamten Unternehmen beizutragen.

Das Phoenix-Projekt nimmt ein trockenes Thema und verwandelt es in eine verständliche Erzählung. Bestimmte Konzepte, die ich während meines Studiums für meine ITIL-Zertifizierung nicht ganz verstanden habe, wurden im Verlauf dieses Buches kristallklar.

Ich freue mich sehr darauf, mit meinem Team bei der Arbeit ein Kanban-Board zu implementieren.

Um ehrlich zu sein, es ist mir ein bisschen peinlich, wie sehr ich dieses Buch genossen habe! Es ist im Grunde ein Business / IT-Management-Buch, das kaum als Roman getarnt ist, aber ich muss sagen, es ist sehr gut gemacht. Es ist ein solches Nischenthema, dass ich nicht sicher bin, ob es jemand außerhalb einer IT Ops-Rolle schätzen würde, aber ich habe wirklich viel darüber gelernt, wie IT in Geschäftsziele integriert werden muss, um tatsächlich etwas zu erreichen, das es in einem nicht gibt Vakuum, und wenn ja, dann ist etwas ernsthaft aus dem Ruder gelaufen. Es predigt gute Prinzipien, im Grunde die Silberkugel der kontinuierlichen Bereitstellung und welchen Wert dies für den Entwicklungszyklus bringt. Ich glaube nach dem, was ich gelesen habe, dass es im Grunde eine Neufassung von 'The Goal' ist - https://en.wikipedia.org/wiki/The_Goa... - das "in führenden Management-Colleges weit verbreitet ist, um Studenten über die Bedeutung der strategischen Kapazitätsplanung und des Constraint-Managements zu unterrichten". aber mit einem DevOps-Spin drauf.

Es ist definitiv ein Technologiebuch, aber es meidet jede Technologie, um sich auf die zugrunde liegenden Prinzipien zu konzentrieren.

Ich bin gespannt, was andere daraus machen.

Stellen Sie sich einen Ayn Rand-Roman vor, in dem John Galt gestelzte Vorträge über ITIL und Lean Manufacturing statt über Objektivismus hält.

Update: Es ist kein großartiges Buch, aber wenn Sie in einer dysfunktionalen IT-Umgebung arbeiten und es nie schaffen, eines der traditionellen Business- / Tech-Bücher zu durchlaufen, die Ihnen helfen könnten, wäre dies ein großartiger Ausgangspunkt. Versprich dir nur, dass du auch hier nicht aufhörst. Ein weiteres Update: Ich habe in letzter Zeit zwei Sterne gelesen und das ist es nicht.

Dies ist das klischeehafteste Buch, das ich je gelesen habe. Das Phoenix-Projekt verwendet eine erfundene Erzählung, um IT-Best Practices zu liefern, wie eine Mutter Apfelmus verwendet, um Erbsen zu verstecken, während sie ein Kleinkind mit dem Löffel füttert. Der Stand der Technik- / Managementbücher mag vor fünf Jahren anders gewesen sein, aber ich fand die übertriebene Natur beleidigend für die Intelligenz der beabsichtigten Bevölkerungsgruppe. Ja, Handlungsstränge helfen dabei, Punkte zu verstärken, aber die besten Bücher, denen ich heutzutage begegne, enthalten echte Beispiele ohne Dramatik und dreihundert Seiten Flaum.

Alle Zeichen sind eindimensional und vorhersehbar. Konstanten. Wie die NPC-Charaktere, denen Sie in alten RPG-Spielen begegnen, wissen Sie, wie der Dialog jedes Mal abläuft. Schließlich können Sie sich eine Kombination aus Abwärtspfeilen und X-Tasten merken und den Dialog überspringen. Sie haben Brent, den 10X-Programmierer. Da ist John, der manische Firewall-Experte, der sich im Grunde genommen zu Tode trinkt und als Superheld wiedergeboren wird. Sarah ist ehrgeizig und es ist nie klar, was sie tut, außer das IT-Team zu bitten, für sie zu arbeiten. Sie haben Nancy, die Frau des Hauptcharakters, die ihn versteht, ihn aber daran erinnert, dass sein Job scheiße ist, sollte er ihn jemals vergessen. Und dann ist da noch Erik.

Erik ist der mysteriöse Sensei-Typ, der Bill, die Hauptfigur, zu grüneren Weiden und Happy End führt. Es gibt viele Rätsel und Beschreibungen seiner Kleidung. Am Ende des Buches stellt sich heraus, dass Erik und Bill viel gemeinsam haben. Früher gab es eine Art Seance, bei der einige der Hauptfiguren das Licht dimmen, an einem Tisch sitzen und jeweils ihre „Geschichte“ enthüllen. Bill enthüllt, dass sein Vater ein schlechter Vater war - was bedeutet, dass er aufgegeben wurde (ja, das Buch geht dahin). Als ich mehr darüber nachdachte, während ich darüber nachdachte, warum ich diese Lektüre nicht genoss, schien es völlig plausibel, dass einer der Autoren in einem frühen Entwurf dieses Buches vorhatte, Erik als Bills Vater zu enthüllen. Ich bin mir nicht sicher, ob dies den Titel für die würdigste Offenbarung angenommen hätte.

Die Handlung geht von schlecht zu schlechter zu schlecht. Teil eins lockt dich an, während Teil zwei eine dröhnende Weltlichkeit ist. In Teil 3 verwenden die Autoren Kapitel 30, um Sie daran zu erinnern, dass sie gut gelesen sind, und lesen später auf zwei Seiten, wie das IT-Team ein Wunder vollbracht und anschließend das Unternehmen gerettet hat.

Wenn Sie Ingenieur sind, lesen Sie dies nicht. Wenn Sie im nicht-technischen Manager-Spektrum sind, gibt es hier etwas für Sie. Sie müssen viel Müll durchforsten - und ich denke, Sie sind besser dran, sich nur mit technisch orientierten Büchern zu beschäftigen -, aber hier ist etwas für Sie. Sie wissen, wie jeder Manager seine hat das Buch? Bitte mach das nicht zu deinem das Buch. Sie sind im Moment nur eine Hypothese für mich und ich bin zuversichtlich, dass Ihre kostbare Zeit unabhängig von Ihrem Hintergrund besser damit verbracht wird, etwas anderes zu lesen. Wirklich, Das Phoenix-Projekt Das Buch scheitert ebenso peinlich wie sein Namensvetter bei Parts Unlimited.

Der Texter hat p150 aufgegeben, und Sie sollten es auch tun. Die Dinge beginnen bergab zu gehen, wenn "illusorisch" "ellusiv" ersetzt und die grammatikalischen Exzentrizitäten Schneeball von dort.

Aber warte, fragst du ... wenn ich jetzt aufhöre, wie werde ich erfahren, ob Bill die drei Gesetze beherrscht? Wird er eine sich gegenseitig unterstützende Arbeitsbeziehung mit dem Informationssicherheitsbeauftragten aufbauen? Wird der rätselhafte Guru Erik eine Olive in seinem Martini verlangen? Warum bringt mich dieses Buch dazu, alles kapitalisieren zu wollen? Und aber wird Bill endlich deine Mutter treffen?

Einige nützliche Tools werden vorgestellt (Kanban-Boards, Pipelines für die kontinuierliche Bereitstellung usw.), jedoch ohne Details. Vermutlich wird von Ihnen erwartet, dass Sie das andere Buch der Autoren erwerben, wenn Sie konkrete Beispiele wünschen.

Dies ist das Einhorn, das wir in den nächsten 5+ Jahren alle jagen werden. De Marcos The Deadline fand schließlich seinen spirituellen Nachfolger.

Nehmen Sie dieses Buch nicht zu wörtlich, wie ein Rezept von Regeln, die befolgt werden müssen. Die Änderung, die sie in dem Buch innerhalb des vorgegebenen Zeitrahmens erreichen können, ist ziemlich unrealistisch. Die meisten Unternehmen sind nicht vom Aussterben bedroht und nicht gezwungen, die Art und Weise, wie Wert geliefert wird, neu zu bewerten. Und wenn ja, dauert es wahrscheinlich Jahre und nicht Wochen und Monate, den gesamten Wertstrom und die Kultur eines Unternehmens zu ändern (wenn wir von einem normalen mittelständischen Unternehmen sprechen).

Aber ich mag und schätze das Denkmodell hinter dem Roman, wie es in Die drei Wege ausgedrückt wird, sehr. Ziemlich augenöffnend für mich. Bisher dachte ich immer an "DevOps" als "Sie bauen es, Sie führen es aus". Mir ist nie in den Sinn gekommen, dass "DevOps" teilweise auch Systemdenken, Wertstromoptimierung und vor allem "wir" und nicht "wir" und "sie" bedeutet.

Ich möchte diese Rezension mit einem meiner Lieblingszitate aus dem Buch beenden:

The relationship between IT and the business is like a dysfunctional marriage -- both feel powerless and held hostage by the other

Sich dessen bewusst zu sein, ist ein guter Anfang

Dies ist das erste Buch, das ich seit extrem langer Zeit von Anfang bis Ende gelesen habe. Und was in dieser Rezension folgt, sind weniger meine letzten Eindrücke als vielmehr die Art und Weise, wie mich das Buch traf, als ich mich darauf einließ. Ich glaube immer noch, dass meine Kritik berechtigt ist, aber sie hat weniger Einfluss auf meine Freude und meine Fähigkeit, die interstitiellen Lektionen aufzunehmen, als ich erwartet hatte. Du bist so vorgewarnt.

Während ich die ersten Kapitel lese, erinnert mich dieses Buch an meine Haltung gegenüber dem Agilen Manifest in diesen Tagen - "niemand versteht, wie * schwer * unser Job ist - wenn sie nur zuhören würden - das ist die Galle, die ich schimpfe Ich würde es ihnen geben - und alle anderen müssen in den Hintergrund treten, um die Bedürfnisse des Entwicklers über die aller anderen zu stellen! " Ja, ich möchte verstehen, wie Sie die Welt sehen, aber wenn Sie die Situation und Bedürfnisse aller anderen äußerst bitter und schräg betrachten, erzeugen Sie im Gegenzug nicht viel Sympathie bei mir.

Ich vermute für diejenigen, die im Kerker des Backoffice versunken sind, unterschätzt und nie gehört, dieses Buch ist ein Glücksfall - "endlich bekommt es jemand!"

Aber hier ist ein Protip: Wenn Sie das Management (oder andere Spieler, die nicht zu Ihrem Team gehören) dazu überreden, dies zu lesen, erwarten Sie nicht, dass sie auf ihre Funhouse-Spiegel-Stereotypen im Buch stoßen und es mit einem durchziehen aufgeschlossen. Noch um durch die pedantischen, herablassenden Vorträge zu waten und sich auf magische Weise in die Seite aller anderen verwandeln zu lassen.

Dies ist eine Lektion in der Verwaltung, die ich auf langsame, harte Weise gelernt habe und die ich als jemand weitergebe, der jetzt Teil der Managementebene ist: Denken Sie daran, dass das Management Sie manchmal hört, manchmal sogar versteht und * noch * entscheide die Dinge nicht auf deine Weise. Wir müssen im Allgemeinen viele konkurrierende Perspektiven, Bedürfnisse und Einschränkungen berücksichtigen und sind oft von einem anderen Entscheidungsergebnis überzeugt als dem, das die meisten Spieler von uns erwarten.

Vielleicht möchten Sie das nicht hören, und Sie sympathisieren möglicherweise nicht mit den Bedürfnissen anderer, und das können andere nicht kontrollieren. Gefällt dir die Entscheidung nicht?

Nehmen Sie sich einen Moment Zeit, um sich vorzustellen, welche anderen Faktoren überzeugender (oder einschränkender) gewesen sein könnten *, auch wenn Sie nicht einverstanden sind, dass sie wichtig sind *. Wahrscheinlich haben die meisten anderen in der Organisation einen ebenso einzigartigen Standpunkt wie Sie und stimmen selten überein.

Die seltsamste Prämisse des Buches, die Sie ohne Frage schlucken sollten, ist der neu beförderte CIO-Stellvertreter Bill, ein zuvor auf mittlerer Ebene tätiger Manager ohne Executive Grooming in einem Unternehmen, in dem CIOs alle zwei Jahre wechseln und dessen Initiativen sind alles abgebrochene Misserfolge, werden irgendwie auf die Exekutivpolitik vorbereitet sein, wissen, wie man die finanziellen und zwischenmenschlichen Herausforderungen auf seiner neuen Ebene bewältigt, * und * werden mit dieser ganzen "DevOps" -Initiative überaus erfolgreich sein als mit jeder anderen CIO-Initiative, die ihm vorausging (vermutlich einige, die sogar von erfolgreichen, sehr erfahrenen, extern eingestellten CIOs stammen). Besonders in einer Organisation, die so feindselig gegenüber Ideen ist, die aus der IT stammen. Wenn alle um Sie herum Sie als Feind behandeln, werden selbst objektiv erfolgreiche Initiativen selten als "Erfolg" anerkannt.

Das rückwirkende Schreiben von Geschichten geht natürlich immer an die Sieger, und sie können Ereignisse neu gestalten, wie sie möchten. Durch diese Linse ist es leicht zu erkennen, wie Bills Entscheidungen als absichtliche Gewinnstrategie angesehen werden.

Im Hinterkopf möchte ich jemanden fragen, ob dieses Märchen auf einer tatsächlichen Erfahrung beruht, da sie die Voraussetzung dafür schaffen, wie es Bill gelingt, das Phoenix-Projekt von jahrelanger Verzögerung in den Einsatz und in den Betrieb zu bringen Gibt es einen Grund für mich zu glauben, dass auch ich durch das Ziehen der gleichen Hebel, die Bill zieht, eine große Chance haben werde, riesige Software-Anstrengungen zum Leben zu erwecken und die Produktion zu atmen? "

Und oh meine Götter sind die herablassenden Abhandlungen in diesem Buch. Für etwas, das versucht, wie ein Thriller zu lesen, nimmt es den Start-Stopp-Stil von Tom Clancy an - nein, eher wie Isaac Asimov - mit stultifizierender Regelmäßigkeit.

Die Geschichte des kompletten Clusterficks in Akt 1 wird unterhaltsam, aber die Autoren verlieren jegliche Glaubwürdigkeit, wenn sie eine Entschuldigung dafür finden, eine lächerliche Frist (die für eine Organisation von 10/XNUMX der Größe, über die wir sprechen, nicht möglich wäre) auf der Website zu streichen Team (und ich kenne die Pointe: Unser John Galt-Held, der bisher nichts von DevOps wusste, erfindet, entwirft und implementiert perfekte DevOps, um aus einer Katastrophenorganisation auf der Titelseite ein Modell für Effizienz und Leistungsfähigkeit zu machen).

Puh-leeze.

Und NOCH, ich war zwei Stunden hinter dem Schlafengehen aufgestanden und habe diesen Trottel zwei Nächte hintereinander gelesen - was bedeuten muss, dass die Geschichte trotz all meiner Proteste etwas Überzeugendes an sich hat, das ich in all meinen Kritikpunkten nicht anerkenne.

Freunde von mir, mit denen ich zur Hälfte gesprochen habe, sagten: "Es ist nicht gerade Hochliteratur", "Die Nebenfiguren sind eher wie Papierpuppen" und "Didaktische Fiktion soll nicht als reines Geschichtenerzählen genossen werden". Ich denke, dies ist eine Übung zur freiwilligen Indoktrination, und ich denke, ich habe immer noch zu viel Ego, um mich zu unterwerfen und in die voreingenommene Sichtweise eines anderen einzutauchen, ohne viel Nachdenken und Beschwerden.

Auf Seite 300 habe ich endlich bemerkt, dass ich nicht aufhören kann, jeder Diskussion aufmerksam zu sein (um genau zu verstehen, welche Änderungen diskutiert werden und wie sich dies auf die größeren Anstrengungen auswirken sollte) und mir Sorgen zu machen, welche neuen Überraschungen schrauben werden mit dem Herkulesfortschritt unserer Helden.

Mein verdammtes Herz pocht, ich bin im Namen von Bill und der Crew gestresst und ich möchte unbedingt sehen, wie die böse Bösewichtin Sarah hart niedergeschlagen wird. Vielleicht in Ketten weggeschleppt oder angeprangert, um zu untergraben, zu posieren und zurückzustechen.

Gegen Ende fällt mir ein, dass die Geschichte ohne einen Antagonisten dieser Größenordnung meine Aufmerksamkeit nicht so fest im Griff hätte. Verdammt, trotz all meiner Beschwerden darüber, wie schmerzhaft das Schreiben ist, lese ich es immer noch wie ein Verrückter.

Meine letzten Eindrücke? So sehr ich mich auch über die Struktur und die Spieler dieses Buches beschwert habe, ich habe es hier bis zum Ende geschafft (eine Premiere für mich in einer langen Zeit) und ich bin wirklich aufgeregt, viele der Lektionen selbst in die Praxis umzusetzen . So skeptisch ich auch gegenüber Kulten der Persönlichkeit sein mag, insgesamt bin ich Gene Kim und seinen Co-Autoren in meinem Herzen dankbar, und ich werde wahrscheinlich anderen, die vor einer Woche in meinen Schuhen standen, ein Verfechter dieses Buches sein.

=== Bearbeiten ===
Wenn ich eine Weile später darauf zurückblicke, erkenne ich dies als das, was es ist: einen religiösen Text, der die suggestiblen Novizen in einen wachsenden Kult verwandeln soll, der nicht durch historische Wahrheiten, sondern durch eine Reihe von Gleichnissen erzählt wird, die für die Willigen glaubwürdig sind.

Ich kann jetzt sehen, dass mich fast keine der „Lektionen“ in diesem Buch darauf vorbereitet hat, in einer DevOps-Welt erfolgreich zu sein, außer mich für weitere Ideen, die unter dem DevOps-Banner zusammengefasst sind, zu empfehlen. Vielleicht das Prinzip „Arbeiten, gut, schnell“? Aber ich vermute, dass das aus jeder Disziplin des Systemdesigns stammt.

Aber es war eine lustige, fiktive Lektüre.

Dies als DevOps-Buch zu bezeichnen, ist eine Untertreibung. Der Schlüssel zum Erfolg des Unternehmens in diesem Buch war nicht die Automatisierung oder kontinuierliche Lieferung. Was den Erfolg von der Produktionsstätte auf die Wissensarbeit übertragbar machte, war die Unterordnung der Erfolgskriterien unter Top-Business-Messungen und die konsequente Anwendung der Theory of Constraints, um dies zu erreichen. Natürlich sind Automatisierung und kontinuierliche Bereitstellung für die meisten traditionellen IT-Organisationen auf diesem Weg notwendige Zwischenschritte.

Das ganze militärische Thema war jedoch im ganzen Buch ziemlich nervig.

Die Prosa war schrecklich - einige sehr beunruhigende Zeitverschiebungen waren die geringsten. und was hat es mich gelehrt? Wenn ich nicht im oberen Management bin, ist nichts wichtig, was ich tue, und ich kann keines der Probleme beheben, die meine Arbeit plagen. Aber wenn das obere Management dieses Buch nur liest, werden wir alle an einen glücklichen Ort gehen und niemand wird zurückschrecken, außer den schnurrbartwirbelnden Bösewichten, die entweder gefeuert oder wie aus einem Kokon in ihre wahre Form wiedergeboren werden

Wenn Sie nach einem "Roman" suchen, wird dieses Buch nicht mehr als 2 Sterne von mir bekommen. Sehr direktes und einfaches Geschichtenerzählen. Aber wenn Sie in der IT sind, ist dies ein 5-Sterne-Hotel!

Wenn Sie ein professioneller IT-Mitarbeiter sind, ist dieses Buch wie das Lesen eines eigenen Tagebuchs und wird Ihnen den Weg weisen. Wenn Sie ein IT-Neuling sind, zeigt dies Ihnen die Grundprinzipien einiger ITIL-Betriebskonzepte.

Sehr zu empfehlen, wenn Sie in der IT sind.

Dies ist ein Roman über ein Unternehmen in der Krise, da IT- und Softwareentwicklung einen Engpass für jeden Aspekt des Geschäfts darstellen. Der Rest des Geschäfts hat Scheuklappen an und versteht ihre Abhängigkeiten von IT und Software nicht einmal wirklich. Klingt bekannt?

Der CEO holt ein potenzielles neues Vorstandsmitglied, das den Vizepräsidenten der IT in "schlanken" Methoden für die IT aufklärt.

Für diejenigen von uns, die sich mit agilen Methoden in der Software beschäftigen, gibt es nicht viele Überraschungen in Bezug auf Details. Das große Ganze ist jedoch eine verheerende Abnahme des normalen Geschäftsbetriebs für Nicht-Software-Unternehmen.

In diesem Fall handelt es sich bei dem fraglichen Unternehmen um ein Fertigungsunternehmen für Automobil- und Motorradteile (ich denke, das Buch enthält seltsamerweise einige Details darüber, was das Unternehmen wirklich ist) mit Einzelhandelsgeschäften.

Die Konzentration auf ein Non-Tech- / Software-Geschäft ist ein kluger Schachzug, da die Softwareindustrie seit einiger Zeit viel über Lean weiß. Die Idee hier ist jedoch, die schlanken Methoden aus der Fertigung zu übernehmen und in die IT zu bringen. innerhalb eines traditionellen Unternehmens.

Kurz gesagt, das Publikum ist absolut kein Softwareunternehmen (oder sollte es auch nicht sein), sondern eher ein stationäres Geschäft mit einem Online-Shop.

Ich werde gegen Ende des Buches zitieren - das ist kein Spoiler. Betrachten Sie es als einen Anreiz, Sie zum Lesen des Buches zu bewegen: "In zehn Jahren wird sicher jeder COO, der sein Geld wert ist, von der IT kommen. Jeder COO, der die IT-Systeme, die das Unternehmen tatsächlich betreiben, nicht genau versteht ist nur ein leerer Anzug, der sich darauf verlässt, dass jemand anderes seine Arbeit erledigt "(S. 332-333).

Dieses Buch hat viel Aufmerksamkeit erregt, was ich hauptsächlich denke, weil das Thema trocken ist und es nicht viele Bücher zum Gesamtthema gibt. Das erfundene Unternehmen und die Szenarien in diesem Buch sind viel zu einfach. Ich mochte den Bereitstellungsmechanismus zur Abdeckung der Grundsätze des DevOps-Ansatzes nicht. Ich würde unter diesen Bedingungen nicht arbeiten und du auch nicht. Suchen Sie sich einen Ort, der Sie und die wichtige Arbeit der IT schätzt, wenn Sie sich eng mit diesen flachen Charakteren verbunden fühlen.

Einige der Grundprinzipien sind gültig. Es ist kein Raketenwissenschaftler erforderlich, um herauszufinden, ob die Dinge besser funktionieren könnten, wenn Entwicklung und Betrieb besser zusammenarbeiten, oder?

Schließlich wurde dieses Buch eindeutig von einem "Ops" -Typ geschrieben. Das Us vs Them während des gesamten Handlungsstrangs ist anstrengend. Vielleicht würde ein ganz anderer Ansatz die DevOps-Erleuchtung etwas früher hervorbringen.

Zwei Sterne sind alles, was ich hier aufbringen konnte, viele widersprüchliche Daten in der Geschichte, zu viele "Aha" -Momente und alles endet am Ende in einem schönen Bogen, einschließlich Beförderungen für das gesamte Team. :) :)

IN ORDNUNG. Es ist also nicht das Ziel. Die Inspiration und die Parallelen sind offensichtlich (sogar explizit) und die Geschichte ist unterhaltsam, aber ich persönlich fand sie nicht bahnbrechend. Es kann sehr gut für die Menschen sein, ein grundlegendes Verständnis der vielen Konzepte (Flow, WIP, TOC, Systemdenken, ...) zu erlangen. Der Fokus des Buches liegt fest auf der operativen Seite der IT und alle Parallelen zur Softwareentwicklung müssen vorsichtig sein.

Ich liebe dieses Buch aus jedem Grund, aus dem ich nicht dachte, dass ich es verlassen würde, als ich es anfing. Habe es auf der Aufnahme eines Freundes aufgenommen. Ich habe andere Geschäftsbücher gelesen, einschließlich solcher, die sich auf IT konzentrieren, aber was mir an diesem Buch wirklich gefallen hat, ist, dass es eher eine Geschichte erzählt als Vorträge gehalten hat. Ungefähr zur Hälfte wechselte ich von unterhalten zu mehr Gedanken über meinen Prozess (Erstellen eines Info-Produkts ... eines Online-Videokurses) und wie ich ihn verbessern kann. Der Story-Teil des Buches hat mir persönlich geholfen, denn während ich verstehe, was Sie tun sollen, war der * Prozess * -Teil mein großer Vorteil. Das habe ich auf mein Unternehmen angewendet und die Belohnungen bereits mit vielen weiteren Dingen zum Experimentieren und Implementieren geerntet.

Übrigens ... Sarah ist eine blöde arrogante Schlampe, und Bill hätte ihr das mehr als einmal ins Gesicht sagen sollen.

Dies ist ein Propaganda-Handbuch für Müllunternehmen, das sich schlecht als Roman für berechtigte weiße verantwortliche Männer tarnt, die ihre Finger über die wirklichen Probleme eines Arbeitsplatzes in die Ohren stecken wollen: stagnierende Löhne, zügelloser Sexismus / Rassismus, Überarbeitung und andere Arten von Missbrauch .

"Vielleicht müssen wir die Arbeiter nicht mehr bezahlen oder ihnen ein Krankengeld geben, was bedeuten würde, dass ich nicht mehr 500 Dollar pro Jahr verdienen würde ... nein, die Lösung besteht darin, alles zu rationalisieren. Perfekt."

Es ist ziemlich ironisch, dass der Ausdruck "IT-Arbeit hat mehr mit Fertigungsanlagen zu tun, als er sich jemals vorgestellt hat" auf der Rückseite steht, da die Fertigungsarbeiten nach einem Jahrhundert der Opferbereitschaft und des Kampfes der am schlechtesten bezahlten Angestellten stark gewerkschaftlich organisiert sind und unterwegs sind -Karikatur für korruptes, egoistisches, gieriges Management.

Als ich in dieses Buch eintauchte, dachte ich, ich hätte eine Idee, ich dachte, es ist inspirierend, Nachhilfe ... alles, es ist einfach nur langweilig, es geht darum zu arbeiten ... buchstäblich zu arbeiten, in einer Kabine, die Art von Dingen, die du dein ganzes liest Leben NICHT zu tun oder sogar zu entkommen, es ist wie mit deinen Augen zu arbeiten (oder in meinem Fall Ohren, weil ich Audio gehört habe), ich habe keine Ahnung, wer das lesen würde, es könnte einige Leute ansprechen, aber Ich glaube nicht, dass diese Art von Arbeitern die Zeit hat, diese Art von Büchern zu lesen, und für den Rest von uns nur ... WARUM? Nun, wenn Sie sich außerhalb Ihrer Lesekomfortzone wagen möchten, kann dies passieren. wenn das passiert nur GTFO und lesen Sie weiter!

Es beginnt vielversprechend und macht dich süchtig. Die Geschichte einer ausfallenden IT-Abteilung aufgrund unangemessenen Geschäftsverhaltens ist nur allzu bekannt. Das Buch nimmt Sie mit auf eine interessante Reise neben den Charakteren und bietet einen Einblick in das tägliche Leben von Software-Leuten. Das Ende ist jedoch gehetzt und fühlt sich wie eine romantische Komödie an, wenn am Ende das Gute herrscht und alles Böse besiegt wird. Ich würde dieses Buch weiterhin jedem Unternehmer empfehlen, der keine Ahnung hat, wie Software funktioniert, und ein Softwareprojekt starten möchte.

Dies ist ein großartiges Buch und ein Muss für jeden IT-Experten oder Manager. Jeder, der jemals für eine mittlere bis große Organisation gearbeitet hat, wird sich sofort mit den im Buch beschriebenen Situationen identifizieren. Wenn Sie mit Lean, Theory of Constraints, Agile Methodologies und DevOps nicht vertraut sind, haben Sie ein zusätzliches Motiv, dieses Buch zu lesen. Aber wenn Sie mit diesen Dingen bereits vertraut sind, sollten Sie dieses Buch trotzdem lesen, nur aus Gründen der Unterhaltung. Ich bin sicher, Sie werden ein paar gute Lektionen daraus lernen. Sehr empfehlenswert.

Jeder, der in der IT arbeitet, kann vom Lesen dieses Buches profitieren ... Ich hätte es wahrscheinlich nicht als Komödie betrachten sollen, aber es gab so viele Szenarien, in denen ich lächelte, nickte und dachte: "Das klingt ungefähr richtig." Ein großes Lob an die Autoren, dass sie die Relevanz der IT im Unternehmen gezeigt haben und wie eng alles miteinander verbunden ist, was unser Geschäft zum Laufen bringt. Darüber hinaus hervorragende Führungsqualitäten, die von der Hauptfigur Bill hervorgehoben werden. Ich denke er wird sehr erfolgreich sein!

Genau wie die Deadline von Tom DeMarco vor fast zwei Jahrzehnten ist dies ein absolutes Muss für alle, die heutzutage in jeder Art von Geschäft auch nur aus der Ferne mit IT, Management und Betrieb zu tun haben.

Ich muss etwas zugeben, ich liebe Fallstudien. Wenn ein Softwareentwicklungsbuch anfängt, "Beispiele" für die diskutierten Methoden herauszugeben, neige ich dazu, mich für die Geschichte zu interessieren. Ich fange an, genauer hinzuschauen. Wenn sie gut geschrieben sind, bin ich sehr interessiert. Im Allgemeinen möchte ich mehr. Natürlich verstehe ich das nicht - das Buch ist eine trockene technische Referenz zu Softwareentwicklungspraktiken und kein Roman. Die darin verteilte Fiktion soll Sie interessieren.

Das Phoenix-Projekt bringt diese Idee zu einem etwas seltsamen Abschluss. Anstatt eine Erforschung von IT-Themen mit Fiktion darin zu sein, ist dies eine Fiktion, die eine Erforschung von IT-Themen ist. Ein besonderes IT-Thema, in diesem Fall Lean Development und DevOps. Für diejenigen, die sich nicht auskennen - Lean Software Development ist eine Weiterentwicklung der agilen Softwareentwicklung, bei der versucht wird, Lehren aus der Fabrik (insbesondere Toyota und Just-in-Time-Management) zu ziehen und auf IT und Entwicklung anzuwenden. Es war in der Nähe; Ich erinnere mich, dass ich vor mindestens fünf oder sieben Jahren an einer Konferenz teilgenommen habe. DevOps ist ein viel neueres Konzept, das meiner Meinung nach den Fokus auf alle Teile einer Anwendung legt - nicht nur auf den Code, sondern auch auf die ausführende Umgebung, das Netzwerk und den Änderungsprozess. Es ist ein wirklich neues Konzept und es wird nur schwer erforscht (beachten Sie, dass "The Visible Ops Handbook" derzeit kein Buch ist).

Das Buch folgt den "Abenteuern" von Bill, einem neu beförderten IT-Leiter eines angeschlagenen Autoteile- / Einzelhandelsunternehmens. Die IT-Abteilung des Unternehmens hat in der Vergangenheit ihre Verpflichtungen nicht erfüllt und verfügt über ein Drehtürmanagement. Dies ist besonders problematisch, da es auch für die Lieferung von "Project Phoenix" verantwortlich ist, einem massiven Unterfangen, das Unternehmen zu revolutionieren. Es läuft nicht gut und Bill wird klar gemacht, dass die Lieferung von Phoenix für die Zukunft seiner Karriere von entscheidender Bedeutung ist. Bill selbst scheint ein netter Kerl zu sein und ist definitiv der "widerstrebende Held" dieser Geschichte; Er hatte kein besonderes Interesse daran, in seiner Karriere voranzukommen, und musste vom CEO des Unternehmens überredet werden.

Er bedauert dies schnell - die IT-Organisation ist eine unterfinanzierte Katastrophe mit einer fehlerhaften Infrastruktur, absolut keinem Prozess- oder Änderungsmanagement und einem einzelnen Mitarbeiter (Brent), der alles über alles weiß. Bills erster Tag wird damit verbracht, in eine Krise zu geraten, die die Lohn- und Gehaltsabrechnung des Unternehmens betrifft, die durch den übereifrigen Leiter der IT-Sicherheit des Unternehmens verursacht wird und das Unternehmen nicht in der Lage ist, Gehaltsschecks auszudrucken. Besser geht es nicht; Phoenix hält sich schnell und eindeutig nicht an eine Frist, die von einer politisierenden SVP vorgegeben wurde, die befugt ist, den CEO zu drängen, seine Freilassung nach dem unvernünftigen Zeitplan von einer Woche zu fordern. Niemand, der im IT-Bereich tätig ist, wird überrascht sein, wenn diese Frist eine Katastrophe darstellt, in diesem Fall jedoch eine eher übermäßige. Ich werde an dieser Stelle sagen, dass es klar ist, dass die Autoren bereits eine oder mehrere Kombinationen dieser Katastrophen erlebt haben - sie schreiben sie so anschaulich, dass ich denke, dass jeder, der für eine große IT-Organisation gearbeitet hat, mit ihrer Notlage und ihrem Erinnern sympathisieren wird vergangene eigene IT-Katastrophen.

Bill wird in seiner "Suche" von Erik betreut. Ein skurriles potenzielles Vorstandsmitglied mit einer Geschichte in der Technologiebranche. Erik ist der kluge Meister dieses Romans. Die meisten seiner Lektionen finden in einer örtlichen Fabrik statt, wo er seine Punkte zu den vier Arten von Arbeit und zum Umgang mit Einschränkungen und zum Bewegen von Arbeit durch das System erläutert. Seine skurrile Persönlichkeit funktioniert sehr gut - ihn als Yoda des Romans vorzustellen, wäre nicht ganz weit weg.

Das Buch endet mit sehr interessanten Darstellungen von Unternehmensverrat, Triumphen und sogar einer Figur, die ihre Vorstellung von Beruf und Leben völlig verändert. Das Ende ist unweigerlich triumphierend - dies wäre wahrscheinlich kein wirkungsvolles Beispiel für die Prinzipien, die der Autor sonst vermitteln möchte.

Als Fiktion bin ich ein Fan dieses Romans. Es schafft es, eine dramatische, interessante Geschichte über eine Gruppe von Mitarbeitern in einem Unternehmen zu schreiben, die etwas über eine neue IT-Methodik lernen. Meist werden Stereotypen vermieden - die Charaktere sind gut definiert und haben tatsächliche Motivationen. Sogar der oben erwähnte Brent wird vernünftigerweise als hilfreiche Person dargestellt, die einfach schon immer da war. Er ist ein Problem, aber mehr in der Art und Weise, wie sich sein Job entwickelt hat, als in einer bestimmten Bösartigkeit. Die schwächsten Charaktere hier sind wahrscheinlich John, der Leiter der IT-Sicherheit, und Sarah, die Bösewichtin des Stücks. Ich habe den Eindruck, dass die Autoren die Art und Weise, wie IT-Sicherheit in den meisten Organisationen funktioniert, nicht besonders respektieren, und Sarah ist hauptsächlich hier, um eine aufdringliche, politische Führungskraft zu sein. Für die Geschichte funktioniert es hauptsächlich, weil der eigentliche Bösewicht der IT-Prozess ist - Sarah ist einfach da, zeigt die Fehler und stampft auf sie, bis sie brechen. Der andere Fehler ist, dass die Charaktere, insbesondere Erik, anfällig für Expositionen sind - dies ist angesichts der Ziele des Romans wahrscheinlich unvermeidlich.

In Bezug auf den Wert dieses Buches als Arbeit zur Veranschaulichung eines neuen IT-Prozesses ist dies uneinheitlicher. Sie erklären definitiv alle Punkte; Ich kann nicht sagen, dass ich zu diesem Zeitpunkt kein Verständnis für die vier Arten von Arbeit habe. Das Problem ist, dass das Buch als Referenz nur einen begrenzten Wert hat, um diese Gedanken in die Praxis umzusetzen. Dies ist einer der wenigen Romane, die ich jemals gelesen habe und die stark von einem Index profitieren könnten. Es könnte auch stark von einem Begleitband profitieren, der all dies auf traditionellere Weise durchläuft. Ich vermute, dass das "IT Ops Handbook" das sein sollte, aber es ist unmöglich zu sagen, da dieses Buch noch nicht existiert.

Insgesamt empfehle ich dieses Buch. Es ist sowohl eine gute Lektüre mit einer interessanten, wenn auch ungewöhnlichen Geschichte, die erzählt werden kann, als auch in der Lage, einen dazu zu bringen, über die richtigen Herangehensweisen an das IT-Management nachzudenken.

Nee. Ich kann mich einfach nicht für diesen Anzug interessieren. Ich weiß nicht, warum ich überhaupt damit angefangen habe, da mein GR-Freund Dan alle Themen so gut dargelegt hat seine Bewertung. Ich glaube, ich habe es meinem Kindle hinzugefügt, bevor er es überprüft hat.

Ich habe ein paar Jahrzehnte in der IT gearbeitet und mich mehrmals mit vermasselten Gehaltsabrechnungen befasst, allerdings für kleinere Unternehmen. Es ist ein Knaller, obwohl ich auch ein Gehalt habe und nicht von stündlichen Gehaltsabrechnungen betroffen bin. Ich weiß, wie es ist, von Gehaltsscheck zu Gehaltsscheck zu leben, also habe ich viel Einfühlungsvermögen, aber ich weiß auch, wie es behoben wird.

Ich bin nicht sicher, ob jeder, der in der IT arbeitet, von diesem Buch profitieren würde. Wenn Sie bereits in einem seriösen Unternehmen arbeiten, gibt es meines Erachtens nicht viel aus diesem Buch herauszunehmen, was Sie noch nicht tun oder wissen. Dennoch werden einige bewährte Methoden für Entwickler vorgestellt, von denen jeder, der in einem problematischen IT-Team arbeitet, auf leicht zu erfassende Weise profitieren kann.
Es ist nur ein Roman, der die "heldenhaften" Leistungen eines IT-Teams in einem großen Unternehmen darstellt. Es fühlte sich ein bisschen übertrieben an, was sie taten und wie. Was mir an diesem Buch gefallen hat, ist genau diese Übertreibung in Situationen, die sich ziemlich realistisch anfühlten. Situationen, auf die Sie möglicherweise gestoßen sind, wenn Sie in dieser Branche arbeiten. Du fühlst dich den Charakteren so nahe, dass du nur willst, dass sie Superhelden sind! Manchmal brachte es mich auch zum Lachen, weil eine Figur mich oder einen meiner Kollegen beschrieb. Als Entwickler war ich überhaupt nicht beleidigt über einige der spöttischen Kommentare der IT-Leute zu unserem "Stamm", im Gegenteil, ich fand sie amüsant (erschieß mich!) Und enthüllte, wie einige IT-Leute uns sehen. Am Ende haben sie alle zusammengearbeitet, um ein größeres Ziel zu erreichen, und ich denke, das ist sowieso das Herz der Entwickler.
Insgesamt war es eine schöne Lektüre, aber Sie werden gewarnt, keine umwerfenden Techniken und Entwicklungspraktiken zu erwarten.

Ich habe dieses Buch und die Art und Weise, wie es geschrieben wurde, wirklich genossen.

Als Roman geschrieben, konnte ich Teile meines Lebens in dem Buch fühlen. Ich könnte mich auf verschiedene Charaktere / Rollen aus Positionen beziehen, in denen ich gearbeitet habe.

Es hebt auch Dinge hervor, die ich als Probleme gelernt habe.

Ich denke, dies ist ein großartiges Buch, nicht nur für IT-Experten oder Manager, sondern für jeden Manager in Ihrem Unternehmen und jeden IT / Entwickler-Mitarbeiter zum Lesen. Dies gibt Ihnen eine bessere Perspektive auf das, was für den Erfolg erforderlich ist.
Es geht nicht nur darum, Ihre Arbeit zu erledigen, sondern Hand in Hand mit allen anderen zu kommunizieren und auf das gemeinsame Ziel hinzuarbeiten.

Was Sie vielleicht als wichtig ansehen, könnte im größeren Schema der Dinge nichts bedeuten.

(Spoiler anzeigen)[
Das Erkennen und besondere Augenmerk auf Ihre Einschränkungen / Engpässe ist von entscheidender Bedeutung.

Wenn Sie menschliche Fehler aus einem Prozess herausnehmen, wird er nicht nur schneller, sondern auch zuverlässiger.

Aus Fehlern zu lernen und vorbeugende Maßnahmen zu ergreifen, ist der Schlüssel.

Lassen Sie sich nicht in ungeplante Arbeiten oder Nacharbeiten verwickeln.

Planung und Transparenz sind der Schlüssel.
(Spoiler verstecken)]

Beschuldigen Sie niemals Fehler / etwas anderes. In Besitz nehmen.

Dieses Buch macht mich aufgeregt, einige Änderungen in unserer Arbeitsweise vorzunehmen.

Ein Kollege von mir hat mir dieses Buch geliehen, während wir uns intensiv mit der Einführung eines DevOps-Modells für die Arbeit unseres Teams befassen. Ich glaube bereits an die Methodik und musste nicht verkauft werden. Er sprach sehr viel über das Buch und so setzte ich mich dieses Wochenende endlich hin, um es zu lesen.

Aber ich war sehr skeptisch. Sehr.

Ein Roman über IT? Pfui. Ich liebe es zu lesen. Ich liebe Technik. Ich habe mehr als ein Jahrzehnt in der IT gearbeitet, aber das schien keine gute Idee zu sein.

Ich habe mich geirrt.

Es ist keine gute Literatur. Es wird keine Literaturpreise gewinnen, aber es ist äußerst effektiv. Es ist gut geschrieben, wenn nicht hoch. Es verkauft seine Ideen gut. Es ist lehrreich, ohne übermäßig didaktisch zu sein. Es erreicht seine Ziele bewundernswert.

Am effektivsten ist es jedoch, sich mit dem IT-Mitarbeiter zu verbinden. Jeder, der in IT-Operationen oder in der Entwicklung gearbeitet hat, wird sich mit der Situation und den Charakteren verbinden. Sie sprechen unsere Sprache und beschäftigen sich mit unseren täglichen Herausforderungen. Die einzige Möglichkeit, wie dieses Buch funktionieren würde, bestand darin, dass die Autoren dies durchführten, und das taten sie auch.

Wenn Sie etwas Bildung benötigen oder vom Wert von DevOps überzeugen möchten, lesen Sie dieses Buch. Ich dachte nicht, dass es meine Zeit wert wäre, aber ich habe mich geirrt.