Tim Lister – Co-Autor von Büchern

• "Menschlicher Faktor. Erfolgreiche Projekte und Teams“ (das Originalbuch heißt „Peopleware“)
• „Waltzing with the Bears: Risikomanagement in Softwareprojekten“
• „Adrenalinverrückt und durch Muster zombifiziert. Verhaltensmuster von Projektteams“

Alle diese Bücher sind Klassiker ihres Fachs und wurden gemeinsam mit Kollegen in verfasst Atlantic Systems Guild. In Russland sind seine Kollegen am berühmtesten - Tom DeMarco и Peter Hruschka, der auch viele berühmte Werke schrieb.

Tim verfügt über 40 Jahre Erfahrung in der Softwareentwicklung; 1975 (keiner von denen, die diesen Habrapost geschrieben haben, wurde in diesem Jahr geboren) war Tim bereits Executive Vice President von Yourdon Inc. Heute verbringt er seine Zeit mit Beratung, Unterricht und Schreiben, mit gelegentlichen Besuchen mit Berichten Konferenzen auf der ganzen Welt.

Wir haben speziell für Habr ein Interview mit Tim Lister geführt. Er wird die DevOops-Konferenz 2019 eröffnen und wir haben viele Fragen zu Büchern und mehr. Das Interview wird von Mikhail Druzhinin und Oleg Chirukhin vom Programmkomitee der Konferenz geführt.

Michael: Können Sie ein paar Worte zu dem sagen, was Sie gerade tun?

Tim: Ich bin der Leiter der Atlantic Systems Guild. Wir sind zu sechst in der Gilde und nennen uns Schulleiter. Drei in den USA und drei in Europa – deshalb heißt die Gilde Atlantic. Wir sind schon so viele Jahre zusammen, dass man sie einfach nicht zählen kann. Wir alle haben unsere Spezialitäten. Ich arbeite seit mindestens einem Jahrzehnt mit Kunden zusammen. Meine Projekte umfassen nicht nur Management, sondern auch Anforderungssetzung, Projektplanung und Evaluierung. Es scheint, dass Projekte, die schlecht beginnen, normalerweise schlecht enden. Daher lohnt es sich, darauf zu achten, dass alle Aktivitäten wirklich gut durchdacht und aufeinander abgestimmt sind, dass die Ideen der Macher gebündelt werden. Es lohnt sich, darüber nachzudenken, was Sie tun und warum. Welche Strategien sind anzuwenden, um das Projekt zum Abschluss zu bringen?

Seit vielen Jahren berate ich Klienten auf vielfältige Weise. Ein interessantes Beispiel ist ein Unternehmen, das Roboter für Knie- und Hüftoperationen herstellt. Dabei operiert der Chirurg nicht völlig selbstständig, sondern nutzt einen Roboter. Sicherheit ist hier, ehrlich gesagt, wichtig. Aber wenn man versucht, Anforderungen mit Leuten zu besprechen, die sich auf die Lösung von Problemen konzentrieren ... Es mag seltsam klingen, aber in den USA gibt es das FDA (Federal Drug Administration), die Produkte wie diese Roboter lizenziert. Bevor Sie etwas verkaufen und an lebenden Menschen anwenden, müssen Sie eine Lizenz erwerben. Eine der Bedingungen besteht darin, Ihre Anforderungen darzulegen, was die Tests sind, wie Sie sie getestet haben und was die Testergebnisse sind. Wenn Sie die Anforderungen ändern, müssen Sie diesen ganzen umfangreichen Testprozess immer wieder durchlaufen. Unseren Kunden ist es gelungen, die visuelle Gestaltung von Anwendungen in ihre Anforderungen einzubeziehen. Sie hatten Screenshots direkt als Teil der Anforderungen. Wir müssen sie herausholen und erklären, dass die meisten dieser Programme überhaupt keine Ahnung von Knien und Hüften, all diesen Dingen mit der Kamera usw. haben. Wir müssen die Anforderungsdokumente so umschreiben, dass sie sich nie ändern, es sei denn, es ändern sich einige wirklich wichtige Grundbedingungen. Wenn visuelles Design nicht in den Anforderungen enthalten ist, erfolgt die Aktualisierung des Produkts viel schneller. Unsere Aufgabe besteht darin, diejenigen Elemente zu finden, die sich mit Operationen am Knie, der Hüfte und dem Rücken befassen, sie in separaten Dokumenten zusammenzufassen und zu sagen, dass dies die grundlegenden Anforderungen sein werden. Lassen Sie uns eine isolierte Gruppe von Anforderungen zu Knieoperationen aufstellen. Dies wird es uns ermöglichen, einen stabileren Satz von Anforderungen aufzubauen. Wir werden über die gesamte Produktlinie sprechen und nicht über bestimmte Roboter.

Es wurde viel Arbeit geleistet, aber sie gelangten immer noch an Punkte, an denen sie zuvor wochen- und monatelang wiederholte Tests ohne Sinn und Zweck verbrachten, weil ihre auf dem Papier beschriebenen Anforderungen nicht mit den tatsächlichen Anforderungen übereinstimmten, für die die Systeme gebaut wurden. Die FDA sagte ihnen jedes Mal: ​​Ihre Anforderungen haben sich geändert, jetzt müssen Sie alles von Grund auf überprüfen. Komplette Nachprüfungen des gesamten Produkts machten das Unternehmen zunichte.

Es gibt also so wunderbare Aufgaben, wenn man sich ganz am Anfang von etwas Interessantem befindet und die allerersten Aktionen die weiteren Spielregeln festlegen. Wenn Sie sicherstellen, dass diese frühe Aktivität sowohl aus betriebswirtschaftlicher als auch aus technischer Sicht gut funktioniert, besteht die Chance, dass Sie am Ende ein großartiges Projekt erhalten. Aber wenn dieser Teil aus dem Ruder läuft und irgendwo schief läuft, wenn Sie die grundlegenden Vereinbarungen nicht finden können ... Nein, Ihr Projekt wird nicht zwangsläufig scheitern. Aber Sie werden nicht mehr sagen können: „Das haben wir super gemacht, wir haben alles wirklich effektiv gemacht.“ Dies sind die Dinge, die ich tue, wenn ich mit Kunden kommuniziere.

Michael: Das heißt, Sie starten Projekte, machen eine Art Kickoff und prüfen, ob die Weichen in die richtige Richtung gehen?

Tim: Wir haben auch Ideen, wie wir alle Puzzleteile zusammensetzen können: welche Fähigkeiten wir brauchen, wann genau sie gebraucht werden, wie der Kern des Teams aussieht und andere grundlegende Dinge. Brauchen wir Vollzeitkräfte oder können wir jemanden in Teilzeit einstellen? Planung, Management. Fragen wie: Was ist für dieses spezielle Projekt am wichtigsten? Wie erreicht man das? Was wissen wir über dieses Produkt oder Projekt, was sind die Risiken und wo liegen die Unbekannten, wie gehen wir mit all dem um? Natürlich beginnt in diesem Moment jemand zu schreien: „Was ist mit Agilität?!“ Okay, ihr seid alle flexibel, aber na und? Wie genau sieht das Projekt aus, wie wollen Sie es passend zum Projekt umsetzen? Man kann nicht einfach sagen: „Unser Ansatz erstreckt sich auf alles, wir sind ein Scrum-Team!“ Das ist Unsinn und Unsinn. Wohin gehst du als nächstes, warum sollte es funktionieren, wo ist der Sinn? Ich bringe meinen Kunden bei, über all diese Fragen nachzudenken.

19 Jahre agil

Michael: Bei Agile versucht man oft, nichts im Voraus zu definieren, sondern Entscheidungen so spät wie möglich zu treffen und sagt: „Wir sind zu groß, ich denke nicht über die Gesamtarchitektur nach.“ Ich werde nicht über viele andere Dinge nachdenken, sondern dem Kunden etwas liefern, das sofort funktioniert.

Tim: Ich denke, dass agile Methoden, beginnend mit Agiles Manifest im Jahr 2001 öffnete der Branche die Augen. Aber andererseits ist nichts perfekt. Ich bin voll und ganz für iterative Entwicklung. Iteration ist in den meisten Projekten sehr sinnvoll. Aber die Frage, über die Sie nachdenken müssen, ist: Wie lange hält das Produkt, wenn es einmal draußen und in Gebrauch ist? Ist das ein Produkt, das sechs Monate hält, bevor es durch etwas anderes ersetzt wird? Oder ist das ein Produkt, das viele, viele Jahre lang funktioniert? Natürlich werde ich keine Namen nennen, aber ... In New York und seiner Finanzwelt sind die grundlegendsten Systeme sehr alt. Das ist großartig. Man schaut sie sich an und denkt, wenn man nur in die Zeit zurückgehen könnte, ins Jahr 1994, und den Entwicklern sagen könnte: „Ich komme aus der Zukunft, aus dem Jahr 2019.“ Entwickeln Sie dieses System einfach so lange, wie Sie es benötigen. Machen Sie es erweiterbar, denken Sie über die Architektur nach. Anschließend wird es über mehr als XNUMX Jahre hinweg verbessert. Wenn man die Entwicklung noch etwas hinauszögert, wird es im Großen und Ganzen niemandem auffallen!“ Wenn Sie die Dinge langfristig abschätzen, müssen Sie berücksichtigen, wie viel es insgesamt kosten wird. Manchmal lohnt sich eine gut gestaltete Architektur wirklich, manchmal nicht. Wir müssen uns umschauen und uns fragen: Sind wir in der richtigen Situation für eine solche Entscheidung?

Eine Idee wie „Wir sind für Agilität, der Kunde sagt uns selbst, was er bekommen möchte“ ist also super naiv. Kunden wissen nicht einmal, was sie wollen, und noch mehr: Sie wissen nicht, was sie bekommen könnten. Manche Leute werden anfangen, historische Beispiele als Argumente anzuführen, das habe ich bereits gesehen. Aber technisch fortgeschrittene Leute sagen das normalerweise nicht. Sie sagen: „Wir haben das Jahr 2019, das sind die Möglichkeiten, die wir haben, und wir können die Art und Weise, wie wir diese Dinge betrachten, völlig ändern!“ Anstatt bestehende Lösungen nachzuahmen und sie ein wenig hübscher und gekämmter zu machen, muss man manchmal sagen: „Lasst uns das, was wir hier zu tun versuchen, völlig neu erfinden!“

Und ich glaube nicht, dass die meisten Kunden so über das Problem denken können. Sie sehen nur das, was sie bereits haben, das ist alles. Danach kommen sie mit Bitten wie „Machen wir das etwas einfacher“ oder was auch immer sie normalerweise sagen. Aber wir sind keine Kellner oder Kellnerinnen, also können wir eine Bestellung entgegennehmen, egal wie dumm sie ausfällt, und sie dann in der Küche backen. Wir sind ihre Führer. Wir müssen ihnen die Augen öffnen und sagen: Hey, wir haben hier neue Möglichkeiten! Ist Ihnen bewusst, dass wir die Art und Weise, wie dieser Teil Ihres Geschäfts abgewickelt wird, wirklich verändern können? Eines der Probleme bei Agile besteht darin, dass dadurch das Bewusstsein dafür verloren geht, was eine Chance ist, was ein Problem ist, was wir überhaupt tun müssen und welche verfügbaren Technologien für diese spezielle Situation am besten geeignet sind.

Vielleicht bin ich hier zu skeptisch: In der agilen Community passieren viele wunderbare Dinge. Aber ich habe ein Problem damit, dass die Leute anfangen, die Hände zu heben, anstatt ein Projekt zu definieren. Ich würde hier fragen: Was machen wir, wie machen wir es? Und auf magische Weise stellt sich immer heraus, dass der Kunde es besser wissen sollte als jeder andere. Aber der Kunde weiß es erst am besten, wenn er aus Dingen auswählt, die bereits von jemandem gebaut wurden. Wenn ich ein Auto kaufen möchte und weiß, wie groß mein Familienbudget ist, dann werde ich schnell ein Auto auswählen, das zu meinem Lebensstil passt. Hier weiß ich alles besser als jeder andere! Bitte beachten Sie jedoch, dass die Autos bereits von jemandem hergestellt wurden. Ich habe keine Ahnung, wie man ein neues Auto erfindet, ich bin kein Experte. Wenn wir kundenspezifische oder spezielle Produkte erstellen, muss die Stimme des Kunden berücksichtigt werden, aber dies ist nicht mehr die einzige Stimme.

Oleg: Sie haben das Agile Manifest erwähnt. Müssen wir es unter Berücksichtigung des modernen Verständnisses des Themas irgendwie aktualisieren oder überarbeiten?

Tim: Ich würde ihn nicht anfassen. Ich denke, es ist ein großartiges historisches Dokument. Ich meine, er ist, was er ist. Er wird 19 Jahre alt, er ist alt, aber zu seiner Zeit hat er eine Revolution gemacht. Was ihm gut gelang, war, dass er eine Reaktion auslöste und die Leute anfingen, über ihn zu flüstern. Im Jahr 2001 waren Sie höchstwahrscheinlich noch nicht in der Branche tätig, aber damals arbeiteten alle nach Prozessen. Software Engineering Institute, fünf Ebenen des Software-Vollständigkeitsmodells (CMMI). Ich weiß nicht, ob solche Legenden aus der Antike etwas sagen, aber es war ein Durchbruch. Anfangs glaubte man, dass die Probleme von selbst verschwinden würden, wenn die Prozesse richtig eingerichtet wären. Und dann kommt das Manifest und sagt: „Nein, nein, nein – wir werden auf Menschen basieren, nicht auf Prozessen.“ Wir sind Meister der Softwareentwicklung. Wir verstehen, dass der ideale Prozess eine Fata Morgana ist; er findet nicht statt. Es gibt zu viele Eigenheiten in Projekten, die Idee eines einzigen perfekten Prozesses für alle Projekte ergibt keinen Sinn. Die Probleme sind zu komplex, um zu behaupten, dass es für alles nur eine Lösung gibt (Hallo, Nirvana).

Ich maße mir nicht an, in die Zukunft zu blicken, aber ich muss sagen, dass die Menschen jetzt begonnen haben, mehr über Projekte nachzudenken. Ich denke, dass das Agile Manifest sehr gut darin ist, herauszuspringen und zu sagen: „Hey! Sie sind auf einem Schiff und steuern dieses Schiff selbst. Sie müssen eine Entscheidung treffen – wir schlagen Ihnen kein Universalrezept für alle Situationen vor. Sie sind die Besatzung des Schiffes, und wenn Sie gut genug sind, können Sie einen Weg zum Ziel finden. Vor Ihnen gab es andere Schiffe, und es wird auch nach Ihnen andere Schiffe geben, aber dennoch ist Ihre Reise in gewisser Weise einzigartig.“ So ähnlich! Es ist eine Denkweise. Für mich gibt es nichts Neues unter der Sonne, Menschen sind schon einmal gesegelt und werden wieder segeln, aber für Sie ist dies Ihre Hauptreise, und ich werde Ihnen nicht sagen, was genau mit Ihnen passieren wird. Sie müssen über die Fähigkeiten zur koordinierten Arbeit im Team verfügen, und wenn Sie diese wirklich haben, wird alles klappen und Sie kommen an Ihr Ziel.

Peopleware: 30 Jahre später

Oleg: War Peopleware ebenso eine Revolution wie das Manifest?

Tim: Peopleware... Tom und ich haben dieses Buch geschrieben, aber wir hätten nicht gedacht, dass es so passieren würde. Irgendwie fand es bei vielen Leuten Anklang bei den Ideen. Dies war das erste Buch, in dem es hieß: Softwareentwicklung ist eine sehr menschenintensive Tätigkeit. Trotz unserer technischen Natur sind wir auch eine Gemeinschaft von Menschen, die etwas Großes, sogar Riesiges, sehr Komplexes bauen. Niemand kann solche Dinge alleine erschaffen, oder? Daher wurde die Idee des „Teams“ sehr wichtig. Und das nicht nur aus Managementsicht, sondern auch für Techniker, die zusammenkamen, um wirklich komplexe, tiefgreifende Probleme mit einer Menge Unbekannter zu lösen. Für mich persönlich war dies im Laufe meiner gesamten Karriere ein großer Intelligenztest. Und hier muss man sagen können: Ja, dieses Problem ist mehr, als ich alleine bewältigen kann, aber gemeinsam können wir eine elegante Lösung finden, auf die wir stolz sein können. Und ich denke, es war diese Idee, die am meisten Anklang fand. Die Idee, dass wir zeitweise alleine arbeiten, teilweise als Teil einer Gruppe, und oft wird die Entscheidung von der Gruppe getroffen. Das Lösen von Gruppenproblemen ist schnell zu einem wichtigen Merkmal komplexer Projekte geworden.

Obwohl Tim eine große Anzahl von Vorträgen gehalten hat, werden nur sehr wenige davon auf YouTube gepostet. Sie können sich den Bericht „The Return of Peopleware“ aus dem Jahr 2007 ansehen. Die Qualität lässt natürlich zu wünschen übrig.

Michael: Hat sich in den letzten 30 Jahren seit der Veröffentlichung des Buches etwas geändert?

Tim: Das kann man aus vielen verschiedenen Blickwinkeln betrachten. Soziologisch gesehen... es war einmal, in einfacheren Zeiten, da saßen Sie und Ihr Team im selben Büro. Man könnte sich jeden Tag nahe sein, gemeinsam Kaffee trinken und über die Arbeit sprechen. Was sich wirklich geändert hat, ist, dass Teams jetzt geografisch in verschiedenen Ländern und Zeitzonen verteilt sein können, aber immer noch an demselben Problem arbeiten, was eine ganz neue Ebene der Komplexität mit sich bringt. Das hört sich vielleicht altmodisch an, aber es gibt nichts Besseres als eine persönliche Kommunikation, bei der man alle zusammen sitzt und zusammenarbeitet und zu einem Kollegen geht und sagt: „Sehen Sie, was ich entdeckt habe, wie gefällt Ihnen das?“ Persönliche Gespräche bieten einen schnellen Übergang zur informellen Kommunikation, und ich denke, dass dies auch agilen Enthusiasten gefallen dürfte. Und ich mache mir auch Sorgen, weil die Welt in Wirklichkeit sehr klein geworden ist und jetzt alles mit verteilten Teams bedeckt ist und alles sehr komplex ist.

Wir alle leben in DevOps

Michael: Selbst aus Sicht des Programmkomitees der Konferenz haben wir Leute in Kalifornien, in New York, Europa, Russland ... in Singapur gibt es noch niemanden. Der geografische Unterschied ist ziemlich groß und die Menschen verteilen sich noch weiter. Wenn wir über Entwicklung sprechen, können Sie uns mehr über Entwickler und den Abbau von Barrieren zwischen Teams erzählen? Es gibt das Konzept, dass jeder in seinen Bunkern sitzt und die Bunker jetzt einstürzen. Was halten Sie von dieser Analogie?

Tim: Mir scheint, dass DevOps angesichts der jüngsten technologischen Durchbrüche von großer Bedeutung sind. Früher gab es Teams aus Entwicklern und Administratoren, die arbeiteten, arbeiteten, arbeiteten, und irgendwann tauchte ein Ding auf, mit dem man zu den Admins kommen und es für die Produktion ausrollen konnte. Und hier begann das Gespräch über den Bunker, denn die Admins sind gewissermaßen Verbündete, zumindest keine Feinde, aber man hat erst mit ihnen gesprochen, als alles bereit war, in Produktion zu gehen. Sind Sie mit etwas zu ihnen gegangen und haben gesagt: Schauen Sie, was für eine Anwendung wir haben, aber könnten Sie diese Anwendung einführen? Und jetzt hat sich das gesamte Lieferkonzept zum Besseren verändert. Ich meine, es gab die Idee, dass man Veränderungen schnell durchsetzen kann. Wir können Produkte im Handumdrehen aktualisieren. Ich lächle immer, wenn Firefox auf meinem Laptop auftaucht und sagt: „Hey, wir haben Ihren Firefox im Hintergrund aktualisiert, und sobald Sie eine Minute Zeit haben, können Sie hier klicken und wir geben Ihnen die neueste Version.“ Und ich dachte: „Oh ja, Baby!“ Während ich schlief, arbeiteten sie daran, mir eine neue Veröffentlichung direkt auf meinen Computer zu liefern. Das ist wunderbar, unglaublich.

Aber hier liegt die Schwierigkeit: Man hat diese Funktion bei der Aktualisierung der Software, aber die Integration von Personen ist viel schwieriger. Was ich bei der DevOops-Keynote zum Ausdruck bringen möchte, ist, dass wir jetzt viel mehr Spieler haben als jemals zuvor. Wenn Sie nur an alle Beteiligten in nur einem Team denken…. Sie haben es als Team betrachtet, und es ist viel mehr als nur ein Team von Programmierern. Das sind Tester, Projektmanager und viele andere Leute. Und jeder hat seine eigene Sicht auf die Welt. Produktmanager unterscheiden sich grundlegend von Projektmanagern. Administratoren haben ihre eigenen Aufgaben. Es wird zu einem ziemlich schwierigen Problem, alle Beteiligten zu koordinieren, um weiterhin auf dem Laufenden zu bleiben, was passiert, und nicht verrückt zu werden. Es ist notwendig, die Aufgaben der Gruppe und die Aufgaben, die für alle gelten, zu trennen. Das ist eine sehr schwierige Aufgabe. Andererseits finde ich, dass alles viel besser ist als vor vielen Jahren. Genau auf diesem Weg wachsen Menschen und lernen, sich richtig zu verhalten. Wenn Sie die Integration durchführen, verstehen Sie, dass es keine unterirdische Entwicklung geben sollte, damit die Software nicht im allerletzten Moment wie ein Springteufel herauskriecht: Schauen Sie, was wir hier gemacht haben! Die Idee ist, dass Sie in der Lage sein werden, Integration und Entwicklung durchzuführen und am Ende auf saubere und iterative Weise einzuführen. Das alles bedeutet mir sehr viel. Dadurch ist es möglich, mehr Wert für die Benutzer des Systems und für Ihren Kunden zu schaffen.

Michael: Die ganze Idee von Devops besteht darin, sinnvolle Entwicklungen so früh wie möglich zu liefern. Ich sehe, dass die Welt immer schneller wird. Wie kann man sich an solche Beschleunigungen anpassen? Vor zehn Jahren gab es das noch nicht!

Tim: Natürlich wünscht sich jeder immer mehr Funktionalität. Sie müssen nicht umziehen, einfach mehr aufstapeln. Manchmal muss man sogar langsamer fahren, damit das nächste inkrementelle Update etwas Nützliches bringt – und das ist völlig normal.

Die Idee, dass man laufen, laufen, laufen muss, ist nicht die beste. Es ist unwahrscheinlich, dass irgendjemand sein Leben so leben möchte. Ich möchte, dass der Rhythmus der Lieferungen den Rhythmus des Projekts vorgibt. Wenn man nur einen Strom kleiner, relativ bedeutungsloser Dinge produziert, ergibt alles keinen Sinn. Anstatt gedankenlos zu versuchen, Dinge so früh wie möglich zu veröffentlichen, lohnt es sich, mit den leitenden Entwicklern sowie Produkt- und Projektmanagern über die Strategie zu sprechen. Macht das überhaupt Sinn?

Muster und Antimuster

Oleg: Normalerweise spricht man von Mustern und Antimustern, und das ist der Unterschied zwischen Leben und Tod von Projekten. Und jetzt bricht Devops in unser Leben ein. Gibt es eigene Muster und Anti-Muster, die das Projekt sofort zum Scheitern bringen können?

Tim: Muster und Anti-Muster passieren ständig. Etwas, worüber man reden kann. Nun, es gibt dieses Ding, das wir „glänzende Dinge“ nennen. Die Leute mögen neue Technologien wirklich sehr. Sie sind einfach fasziniert vom Glanz von allem, was cool und stylisch aussieht, und stellen keine Fragen mehr: Ist das überhaupt notwendig? Was werden wir erreichen? Ist das Ding zuverlässig, macht es irgendeinen Sinn? Ich sehe oft Menschen, die sozusagen auf dem neuesten Stand der Technik sind. Sie sind hypnotisiert von dem, was in der Welt passiert. Schaut man sich aber genauer an, welche nützlichen Dinge sie tun, ist oft einfach nichts Nützliches dabei!

Wir haben gerade mit unseren Kameraden darüber gesprochen, dass dieses Jahr ein Jubiläumsjahr ist, fünfzig Jahre seit der Mondlandung. Das war im Jahr 1969. Die Technologie, die den Menschen dabei geholfen hat, dorthin zu gelangen, ist nicht einmal die Technologie von 1969, sondern eher von 1960 oder 62, weil die NASA nur Dinge verwenden wollte, die gute Beweise für ihre Zuverlässigkeit hatten. Und so schaut man es sich an und versteht – ja, und sie waren wahr! Nun nein, nein, aber man bekommt Probleme mit der Technologie, einfach weil alles zu stark vorangetrieben und aus allen Ecken und Enden verkauft wird. Von überall her rufen Menschen: „Seht mal, was für ein Ding, das ist das Neueste, das Schönste auf der Welt, für absolut jeden geeignet!“ Nun ja, das ist alles... meist erweist sich das alles nur als Lockvogel, und dann muss alles weggeworfen werden. Vielleicht liegt es daran, dass ich schon ein alter Mann bin und solche Dinge mit großer Skepsis betrachte, wenn die Leute rauslaufen und sagen, sie hätten den einzig richtigen Weg gefunden, die besten Technologien zu schaffen. In diesem Moment erwacht in mir eine Stimme, die sagt: „Was für ein Durcheinander!“

Michael: Wie oft haben wir schon von der nächsten Wunderwaffe gehört?

Tim: Genau, und das ist der übliche Lauf der Dinge! Zum Beispiel ... es scheint, dass dies auf der ganzen Welt bereits zu einem Witz geworden ist, aber hier wird oft über die Blockchain-Technologie gesprochen. Und sie machen in bestimmten Situationen tatsächlich Sinn! Wenn Sie wirklich verlässliche Beweise für Ereignisse benötigen, dafür, dass das System funktioniert und dass uns niemand getäuscht hat, wenn Sie Sicherheitsprobleme und all das miteinander vermischt haben, ist Blockchain sinnvoll. Aber wenn sie sagen, dass Blockchain nun die ganze Welt erobern und alles wegfegen wird, was sich ihr in den Weg stellt? Träumen Sie mehr! Dies ist eine sehr teure und komplexe Technologie. Technisch aufwendig und zeitaufwändig. Auch rein algorithmisch, jedes Mal, wenn Sie die Mathematik neu berechnen müssen, mit den kleinsten Änderungen ... und das ist eine tolle Idee – aber nur für bestimmte Fälle. Mein ganzes Leben und meine Karriere drehten sich darum: interessante Ideen in ganz bestimmten Situationen. Es ist sehr wichtig, genau zu verstehen, wie Ihre Situation ist.

Michael: Ja, die wichtigste „Frage des Lebens, des Universums und allem“: Ist diese Technologie oder dieser Ansatz für Ihre Situation geeignet oder nicht?

Tim: Diese Frage kann bereits jetzt mit dem Technologiekonzern besprochen werden. Vielleicht ziehen Sie sogar einen Berater hinzu. Schauen Sie sich das Projekt an und verstehen Sie: Werden wir jetzt etwas richtig und nützlich machen, besser als zuvor? Vielleicht passt es, vielleicht auch nicht. Am wichtigsten ist jedoch, dass Sie eine solche Entscheidung nicht automatisch treffen, nur weil jemand herausplatzt: „Wir brauchen dringend eine Blockchain!“ Ich habe gerade im Flugzeug in einer Zeitschrift von ihm gelesen!“ Ernsthaft? Es ist nicht einmal lustig.

Der mythische „Devops-Ingenieur“

Oleg: Jetzt implementieren alle Entwickler. Jemand liest im Internet über Entwickler, und morgen erscheint auf einer Rekrutierungsseite eine weitere Stelle. „Entwicklungsingenieur“. Hier möchte ich Ihre Aufmerksamkeit lenken: Glauben Sie, dass dieser Begriff „Devops-Ingenieur“ ein Recht auf Leben hat? Es gibt die Meinung, dass Devops eine Kultur ist, und hier stimmt etwas nicht.

Tim: So so. Lassen Sie sie dann gleich eine Erklärung zu diesem Begriff geben. Etwas, das es einzigartig macht. Solange sie nicht beweisen, dass hinter einer offenen Stelle wie dieser eine einzigartige Kombination von Fähigkeiten steckt, werde ich sie nicht kaufen! Ich meine, nun ja, wir haben eine Berufsbezeichnung, „Devops-Ingenieur“, eine interessante Bezeichnung, ja, wie geht es weiter? Berufsbezeichnungen sind im Allgemeinen eine sehr interessante Sache. Sagen wir „Entwickler“ – was ist das überhaupt? Unterschiedliche Organisationen bedeuten völlig unterschiedliche Dinge. In einigen Unternehmen schreiben hochqualifizierte Programmierer Tests, die sinnvoller sind als Tests, die von speziellen professionellen Testern in anderen Unternehmen geschrieben wurden. Was nun, sind sie jetzt Programmierer oder Tester?

Ja, wir haben Berufsbezeichnungen, aber wenn man lange genug fragt, stellt sich irgendwann heraus, dass wir alle Problemlöser sind. Wir sind auf der Suche nach Lösungen, und einige verfügen über einige technische Fähigkeiten, andere über andere. Wenn Sie in einer Umgebung leben, in der DevOps Einzug gehalten hat, beschäftigen Sie sich mit der Integration von Entwicklung und Verwaltung, und diese Tätigkeit hat einen ziemlich wichtigen Zweck. Wenn man aber fragt, was genau man tut und wofür man verantwortlich ist, stellt sich heraus, dass die Menschen all diese Dinge schon seit Menschengedenken tun. „Ich bin für die Architektur verantwortlich“, „Ich bin für die Datenbanken verantwortlich“ und so weiter, was auch immer, sehen Sie – das alles war vor „Devops“.

Wenn mir jemand seine Berufsbezeichnung sagt, höre ich nicht wirklich zu. Lassen Sie sich lieber von ihm sagen, wofür er eigentlich verantwortlich ist, dann können wir das Problem viel besser verstehen. Mein Lieblingsbeispiel ist, wenn eine Person behauptet, ein „Projektmanager“ zu sein. Was? Es bedeutet nichts, ich weiß immer noch nicht, was du tust. Ein Projektmanager kann ein Entwickler sein, der Leiter eines Teams aus vier Personen, der Code schreibt, Arbeit erledigt, der zum Teamleiter geworden ist und den die Leute untereinander als Leiter anerkennen. Und ein Projektmanager kann auch ein Manager sein, der sechshundert Leute an einem Projekt leitet, andere Manager leitet, für die Erstellung von Zeitplänen und die Planung von Budgets verantwortlich ist, das ist alles. Das sind zwei völlig unterschiedliche Welten! Aber ihre Berufsbezeichnung klingt gleich.

Lassen Sie uns das etwas anders umdrehen. Was kannst du wirklich gut, hast viel Erfahrung, hast du Talent? Wofür werden Sie die Verantwortung übernehmen, weil Sie denken, dass Sie die Aufgabe bewältigen können? Und hier wird sofort jemand anfangen zu leugnen: Nein, nein, nein, ich habe überhaupt keine Lust, mich mit Projektressourcen zu befassen, das geht mich nichts an, ich bin ein technischer Typ und verstehe Usability und Benutzeroberflächen, das tue ich nicht Wenn du überhaupt Armeen von Menschen verwalten willst, lass mich besser an die Arbeit gehen.

Übrigens bin ich ein großer Befürworter eines Ansatzes, bei dem diese Art der Kompetenztrennung gut funktioniert. Wo Techniker ihre Karriere so weit entwickeln können, wie sie möchten. Ich sehe jedoch immer noch Organisationen, in denen sich Technikfreaks beschweren: Ich muss ins Projektmanagement, weil das in diesem Unternehmen der einzige Weg ist. Manchmal führt dies zu schrecklichen Ergebnissen. Die besten Technikfreaks sind überhaupt keine guten Manager, und die besten Manager können nicht mit Technologie umgehen. Seien wir ehrlich.

Ich sehe mittlerweile eine große Nachfrage dafür. Wenn Sie ein Technikfreak sind, kann Ihnen Ihr Unternehmen helfen, aber Sie müssen auf jeden Fall Ihren eigenen Karriereweg finden, denn die Technologie verändert sich ständig und Sie müssen sich mit ihr neu erfinden! In nur zwanzig Jahren können sich Technologien mindestens fünfmal ändern. Technologie ist eine seltsame Sache ...

„Experten für alles“

Michael: Wie können Menschen mit der Geschwindigkeit des technologischen Wandels umgehen? Ihre Komplexität wächst, ihre Zahl wächst, auch der Gesamtumfang der Kommunikation zwischen Menschen wächst und es stellt sich heraus, dass man kein „Experte für alles“ werden kann.

Tim: Rechts! Wenn Sie im Technologiebereich arbeiten, müssen Sie sich auf jeden Fall für etwas Bestimmtes entscheiden und sich damit befassen. Einige Technologien, die Ihre Organisation nützlich findet (und möglicherweise tatsächlich nützlich sein wird). Und wenn Sie sich nicht mehr dafür interessieren – ich hätte nie geglaubt, dass ich das sagen würde –, dann sollten Sie vielleicht zu einer anderen Organisation wechseln, wo die Technologie interessanter oder bequemer zu studieren ist.

Aber im Großen und Ganzen hast du recht. Technologien entwickeln sich gleichzeitig in alle Richtungen; niemand kann sagen: „Ich bin ein Experte in allen Technologien, die es gibt.“ Auf der anderen Seite gibt es Schwammmenschen, die technologisches Wissen buchstäblich aufsaugen und verrückt danach sind. Ich habe ein paar solcher Menschen gesehen, sie atmen und leben es buchstäblich, es ist nützlich und interessant, mit ihnen zu sprechen. Sie studieren nicht nur, was innerhalb der Organisation passiert, sondern reden im Allgemeinen darüber, sie sind auch wirklich coole Technologen, sie sind sehr bewusst und zielstrebig. Sie versuchen einfach, auf dem Höhepunkt der Welle zu bleiben, unabhängig davon, was ihr Hauptberuf ist, denn ihre Leidenschaft ist die Bewegung von Technologie, die Förderung von Technologie. Wenn du plötzlich so einen Menschen triffst, solltest du mit ihm zum Mittagessen gehen und beim Mittagessen verschiedene coole Dinge besprechen. Ich denke, jede Organisation braucht mindestens ein paar solcher Leute.

Risiken und Unsicherheit

Michael: Verehrte Ingenieure, ja. Lassen Sie uns auf das Risikomanagement eingehen, solange wir Zeit haben. Wir haben dieses Interview mit einer Diskussion über medizinische Software begonnen, bei der Fehler schwerwiegende Folgen haben können. Dann sprachen wir über das Mondprogramm, bei dem ein Fehler Millionen von Dollar und möglicherweise mehrere Menschenleben kostet. Aber jetzt sehe ich die gegenteilige Entwicklung in der Branche: Die Menschen denken nicht über Risiken nach, versuchen nicht, sie vorherzusagen, sie beobachten sie nicht einmal.

Oleg: Bewegen Sie sich schnell und machen Sie Dinge kaputt!

Michael: Ja, bewegen Sie sich schnell, machen Sie Dinge kaputt, immer mehr Dinge, bis Sie an etwas sterben. Wie sollte der durchschnittliche Entwickler aus Ihrer Sicht jetzt an das Erlernen des Risikomanagements herangehen?

Tim: Lassen Sie uns hier eine Grenze zwischen zwei Dingen ziehen: Risiken und Unsicherheit. Das sind verschiedene Dinge. Unsicherheit entsteht, wenn zu einem bestimmten Zeitpunkt nicht genügend Daten vorliegen, um zu einer endgültigen Antwort zu gelangen. Wenn Sie beispielsweise in einem sehr frühen Stadium eines Projekts jemand fragt: „Wann werden Sie mit der Arbeit fertig sein?“, werden Sie, wenn Sie ein recht ehrlicher Mensch sind, antworten: „Ich habe keine Ahnung.“ Du weißt es einfach nicht, und das ist in Ordnung. Sie haben die Probleme noch nicht untersucht und sind mit dem Team nicht vertraut, Sie kennen seine Fähigkeiten nicht und so weiter. Das ist Unsicherheit.

Risiken entstehen, wenn potenzielle Probleme bereits erkennbar sind. So etwas kann passieren, seine Wahrscheinlichkeit ist größer als Null, aber kleiner als hundert Prozent, irgendwo dazwischen. Dadurch kann alles passieren, von Verzögerungen und unnötiger Arbeit bis hin zum fatalen Ausgang des Projekts. Das Ergebnis: Wenn man sagt: „Leute, lasst uns unsere Sonnenschirme zusammenklappen und den Strand verlassen“, werden wir es nie zu Ende bringen, es ist alles vorbei, Punkt. Wir gingen davon aus, dass das Ding funktionieren würde, aber es funktioniert überhaupt nicht, es ist Zeit aufzuhören. Das sind die Situationen.

Oft lassen sich Probleme am einfachsten lösen, wenn sie bereits aufgetreten sind und das Problem gerade auftritt. Aber wenn ein Problem direkt vor Ihnen liegt, betreiben Sie kein Risikomanagement, sondern Problemlösung, Krisenmanagement. Wenn Sie ein leitender Entwickler oder Manager sind, fragen Sie sich bestimmt, was passieren könnte, das zu Verzögerungen, Zeitverschwendung, unnötigen Kosten oder zum Scheitern des gesamten Projekts führen würde? Was bringt uns dazu, innezuhalten und von vorne zu beginnen? Wenn all diese Dinge funktionieren, was werden wir dann damit machen? Es gibt eine einfache Antwort, die für die meisten Situationen gilt: Laufen Sie nicht vor Risiken davon, sondern arbeiten Sie daran. Erfahren Sie, wie Sie eine riskante Situation lösen, sie auf ein Nichts reduzieren und sie von einem Problem in etwas anderes verwandeln können. Anstatt zu sagen: Na ja, wir lösen Probleme, wenn sie entstehen.

Bei allem, womit Sie zu tun haben, sollten Unsicherheit und Risiko im Vordergrund stehen. Sie können einen Projektplan erstellen, bestimmte kritische Risiken im Voraus prüfen und sagen: Wir müssen uns jetzt darum kümmern, denn wenn irgendetwas davon schief geht, ist alles andere von Bedeutung. Sie sollten sich keine Sorgen um die Schönheit der Tischdecke auf dem Tisch machen, wenn Sie nicht sicher sind, ob Sie das Abendessen zubereiten können. Zuerst müssen Sie alle Risiken bei der Zubereitung eines köstlichen Abendessens erkennen, mit ihnen umgehen und erst dann an alle anderen Dinge denken, die keine wirkliche Bedrohung darstellen.

Noch einmal: Was macht Ihr Projekt einzigartig? Mal sehen, was unser Projekt aus der Bahn werfen kann. Was können wir tun, um die Wahrscheinlichkeit, dass dies geschieht, zu minimieren? Normalerweise kann man sie nicht einfach zu 100 % neutralisieren und guten Gewissens sagen: „Das ist es, das ist kein Problem mehr, das Risiko ist beseitigt!“ Für mich ist das ein Zeichen erwachsenen Verhaltens. Das ist der Unterschied zwischen einem Kind und einem Erwachsenen – Kinder denken, dass sie unsterblich sind, dass nichts schief gehen kann, alles wird gut! Gleichzeitig beobachten Erwachsene, wie dreijährige Kinder auf dem Spielplatz hüpfen, die Bewegungen mit den Augen verfolgen und sich sagen: „Ooh-ooh, ooh-ooh.“ Ich stehe in der Nähe und mache mich bereit, aufzufangen, wenn das Kind fällt.

Andererseits gefällt mir dieses Geschäft auch deshalb so gut, weil es riskant ist. Wir tun Dinge, und diese Dinge sind riskant. Sie erfordern einen erwachsenen Ansatz. Begeisterung allein wird Ihre Probleme nicht lösen!

Ingenieursdenken für Erwachsene

Michael: Das Beispiel mit Kindern ist gut. Wenn ich ein gewöhnlicher Ingenieur bin, dann freue ich mich, ein Kind zu sein. Aber wie kommt man zu einem erwachseneren Denken?

Tim: Eine der Ideen, die sowohl für Anfänger als auch für erfahrene Entwickler gleichermaßen gut funktioniert, ist das Konzept des Kontexts. Was wir tun, was wir erreichen werden. Was ist bei diesem Projekt wirklich wichtig? Es spielt keine Rolle, wer Sie bei diesem Projekt sind, ob Sie Praktikant oder Chefarchitekt sind, jeder braucht Kontext. Wir müssen jeden dazu bringen, in einem größeren Maßstab als seiner eigenen Arbeit zu denken. „Ich mache mein Stück und solange es funktioniert, bin ich glücklich.“ Nein und noch einmal nein. Es lohnt sich immer (ohne unhöflich zu sein!), die Leute an den Kontext zu erinnern, in dem sie arbeiten. Was wir alle gemeinsam erreichen wollen. Vorstellungen, dass man ein Kind sein kann, solange mit seinem Teil des Projekts alles in Ordnung ist – bitte tun Sie das nicht. Wenn wir die Ziellinie überhaupt überqueren, werden wir sie nur gemeinsam überqueren. Du bist nicht allein, wir sind alle zusammen. Wenn alle Leute im Projekt, ob alt oder jung, anfangen würden, darüber zu sprechen, was genau für das Projekt wichtig ist, warum das Unternehmen Geld in das investiert, was wir alle erreichen wollen ... werden sich die meisten von ihnen viel besser fühlen, weil sie werden sehen, wie ihre Arbeit mit der Arbeit aller anderen zusammenhängt. Einerseits verstehe ich das Stück, für das ich persönlich verantwortlich bin. Aber um die Arbeit zu Ende zu bringen, brauchen wir auch alle anderen Leute. Und wenn Sie wirklich glauben, dass Sie fertig sind, haben wir im Projekt immer noch Arbeit zu erledigen!

Oleg: Wenn Sie relativ gesehen nach Kanban arbeiten, können Sie, wenn Sie beim Testen auf einen Engpass stoßen, mit dem aufhören, was Sie dort getan haben (z. B. Programmieren) und den Testern helfen.

Tim: Genau. Ich denke, dass die besten Technikfreaks, wenn man sie genau betrachtet, sozusagen ihre eigenen Manager sind. Wie kann ich das formulieren...

Oleg: Ihr Leben ist Ihr Projekt, das Sie verwalten.

Tim: Genau! Ich meine, man übernimmt Verantwortung, man versteht das Problem, und man kommt mit Menschen in Kontakt, wenn man sieht, dass sich seine Entscheidungen auf ihre Arbeit auswirken können, solche Dinge. Es geht nicht darum, nur an Ihrem Schreibtisch zu sitzen, Ihre Arbeit zu erledigen und nicht einmal zu bemerken, was um Sie herum vor sich geht. Nein nein Nein. Eines der besten Dinge an Agile ist übrigens, dass sie kurze Sprints vorschlagen, denn so ist der Sachverhalt aller Teilnehmer klar erkennbar, sie können alles gemeinsam sehen. Wir reden jeden Tag übereinander.

Wie Sie ins Risikomanagement einsteigen

Oleg: Gibt es in diesem Bereich eine formale Wissensstruktur? Ich bin zum Beispiel Java-Entwickler und möchte Risikomanagement verstehen, ohne durch eine Ausbildung ein echter Projektmanager zu werden. Ich werde wahrscheinlich zuerst McConnells „How Much Does a Software Project Cost“ lesen, und was dann? Was sind die ersten Schritte?

Tim: Die erste besteht darin, mit den Menschen im Projekt zu kommunizieren. Dies führt zu einer unmittelbaren Verbesserung der Kommunikationskultur mit Kollegen. Wir müssen damit beginnen, alles standardmäßig zu öffnen, anstatt es zu verbergen. Sagen Sie: Das sind die Dinge, die mich stören, das sind die Dinge, die mich nachts wach halten. Ich bin heute Nacht aufgewacht und dachte: Mein Gott, darüber muss ich nachdenken! Sehen andere das Gleiche? Sollten wir als Gruppe auf diese potenziellen Probleme reagieren? Sie müssen in der Lage sein, eine Diskussion zu diesen Themen zu unterstützen. Es gibt kein vorgefertigtes Rezept, nach dem wir arbeiten. Es geht nicht darum, Hamburger zu machen, es geht nur um Menschen. „Einen Cheeseburger machen, einen Cheeseburger verkaufen“ ist überhaupt nicht unser Ding und deshalb liebe ich diesen Job so sehr. Ich mag es, wenn alles, was Manager früher gemacht haben, jetzt Eigentum des Teams wird.

Oleg: Sie haben in Büchern und Interviews darüber gesprochen, dass Menschen mehr Wert auf Glück als auf Zahlen in einer Grafik legen. Wenn Sie dem Team andererseits sagen: „Wir wechseln zu DevOps“ und der Programmierer muss jetzt ständig kommunizieren, liegt dies möglicherweise weit außerhalb seiner Komfortzone. Und in diesem Moment könnte er, sagen wir mal, zutiefst unglücklich sein. Was tun in dieser Situation?

Tim: Ich weiß nicht genau, was ich tun soll. Wenn ein Entwickler zu isoliert ist, sieht er überhaupt nicht, warum die Arbeit erledigt wird, er betrachtet nur seinen Teil der Arbeit und muss sich mit dem befassen, was ich „Kontext“ nenne. Er muss herausfinden, wie alles zusammenhängt. Und damit meine ich natürlich keine formellen Präsentationen oder ähnliches. Ich spreche davon, dass Sie mit Kollegen über die Arbeit als Ganzes kommunizieren müssen und nicht nur über den Teil davon, für den Sie verantwortlich sind. Hier können Sie beginnen, Ideen zu besprechen, gemeinsame Vereinbarungen zu treffen, damit Ihre Arbeit gut zusammenpasst, und wie Sie ein gemeinsames Problem gemeinsam angehen können.

Um ihnen bei der Anpassung zu helfen, schicken sie oft Technikfreaks zu Schulungen und besprechen die Schulung. Ein Freund von mir sagt immer, dass Training etwas für Hunde ist. Es gibt Schulungen für Menschen. Eines der besten Dinge beim Lernen als Entwickler ist die Interaktion mit Ihren Kollegen. Wenn jemand etwas wirklich gut kann, sollte man ihm bei der Arbeit zusehen oder mit ihm über seine Arbeit oder ähnliches sprechen. Ein gewisser konventioneller Kent Beck sprach ständig von extremer Programmierung. Es ist lustig, weil XP eine so einfache Idee ist, aber so viele Probleme verursacht. Für manche ist XP so, als ob man gezwungen wäre, sich vor Freunden nackt auszuziehen. Sie werden sehen, was ich tue! Sie sind meine Kollegen, sie werden nicht nur sehen, sondern auch verstehen! Schrecklich! Manche Menschen beginnen ernsthaft nervös zu werden. Aber wenn man erkennt, dass dies der ultimative Weg zum Lernen ist, ändert sich alles. Sie arbeiten eng mit Menschen zusammen und manche verstehen das Thema viel besser als Sie.

Michael: Aber all das zwingt Sie dazu, Ihre Komfortzone zu verlassen. Als Ingenieur müssen Sie Ihre Komfortzone verlassen und kommunizieren. Als Problemlöser muss man sich ständig in eine schwache Position versetzen und darüber nachdenken, was schiefgehen könnte. Diese Art von Arbeit ist von Natur aus darauf ausgelegt, lästig zu sein. Sie begeben sich bewusst in Stresssituationen. Normalerweise laufen die Leute vor ihnen weg, die Leute sind gerne glückliche Kinder.

Tim: Was getan werden kann, kann man zum Vorschein bringen und offen sagen: „Alles ist in Ordnung, ich komme damit zurecht!“ Ich bin nicht der Einzige, der sich unwohl fühlt. Lasst uns gemeinsam im Team verschiedene unangenehme Dinge besprechen!“ Das sind unsere gemeinsamen Probleme, mit denen wir uns befassen müssen, wissen Sie? Ich denke, eigenwillige, geniale Entwickler sind wie Mammuts, sie sind verschwunden. Und ihre Bedeutung ist sehr begrenzt. Wer nicht kommunizieren kann, kann auch nicht gut teilnehmen. Sprechen Sie deshalb einfach. Seien Sie ehrlich und offen. Es tut mir sehr leid, dass dies für jemanden unangenehm ist. Können Sie sich vorstellen, dass es vor vielen Jahren eine Studie gab, der zufolge die größte Angst in den Vereinigten Staaten nicht der Tod ist, aber wissen Sie was? Angst vor öffentlichen Reden! Das bedeutet, dass es irgendwo Menschen gibt, die lieber sterben würden, als laut ein Kompliment auszusprechen. Und ich denke, es reicht aus, wenn man über einige Grundkenntnisse verfügt, je nachdem, was man tut. Sprechfähigkeiten, Schreibfähigkeiten – aber nur so viel, wie in Ihrer Arbeit wirklich benötigt wird. Wenn Sie als Analytiker arbeiten, aber nicht lesen, schreiben oder sprechen können, haben Sie in meinen Projekten leider nichts zu tun!

Der Preis der Kommunikation

Oleg: Ist die Beschäftigung solcher ausscheidenden Mitarbeiter aus verschiedenen Gründen nicht teurer? Schließlich wird ständig geplaudert statt gearbeitet!

Tim: Ich meinte den Kern des Teams und nicht nur jeden. Wenn Sie jemanden haben, der wirklich cool darin ist, Datenbanken zu optimieren, der es liebt, Datenbanken zu optimieren und für den Rest seines Lebens damit fortfahren wird, Ihre Datenbanken zu optimieren, und das ist alles, cool, machen Sie weiter so. Aber ich spreche von Menschen, die im Projekt selbst leben wollen. Der Kern des Teams, der auf die Entwicklung des Projekts abzielt. Diese Menschen müssen wirklich ständig miteinander kommunizieren. Und das insbesondere zu Beginn des Projekts, wenn Sie über Risiken, Wege zur Erreichung globaler Ziele und Ähnliches diskutieren.

Michael: Dies gilt für alle Projektbeteiligten, unabhängig von Spezialisierung, Fähigkeiten oder Arbeitsweise. Sie alle sind am Erfolg des Projekts interessiert.

Tim: Ja, Sie haben das Gefühl, dass Sie ausreichend in das Projekt vertieft sind und dass Ihre Aufgabe darin besteht, zur Verwirklichung des Projekts beizutragen. Egal, ob Sie Programmierer, Analyst, Schnittstellendesigner oder irgendjemand sind. Das ist der Grund, warum ich jeden Morgen zur Arbeit komme, und das ist es, was wir tun. Wir tragen Verantwortung für all diese Menschen, unabhängig von ihren Fähigkeiten. Dies ist eine Gruppe von Menschen, die Gespräche für Erwachsene führen.

Oleg: Tatsächlich habe ich, als ich über gesprächige Mitarbeiter sprach, versucht, die Einwände von Menschen, insbesondere von Managern, zu simulieren, die aufgefordert werden, zu DevOps zu wechseln, gegen diese völlig neue Vision der Welt. Und Sie als Berater sollten sich dieser Einwände viel besser bewusst sein als ich als Entwickler! Teilen Sie mit, was Managern am meisten Sorgen bereitet.

Tim: Manager? Hm. Am häufigsten stehen Manager unter dem Druck von Problemen, stehen vor der Notwendigkeit, dringend etwas freizugeben und eine Lieferung durchzuführen und dergleichen. Sie beobachten, wie wir ständig über etwas diskutieren und streiten, und sie sehen es so: Gespräche, Gespräche, Gespräche ... Welche anderen Gespräche? Zurück an die Arbeit! Denn Reden fühlt sich für sie nicht wie Arbeit an. Du schreibst keinen Code, testest keine Software, scheinst nichts zu tun – warum schickst du dich nicht, etwas zu tun? Schließlich erfolgt die Lieferung bereits in einem Monat!

Michael: Schreiben Sie etwas Code!

Tim: Es scheint mir, dass sie sich keine Sorgen um die Arbeit machen, sondern um die mangelnde Sichtbarkeit des Fortschritts. Um den Eindruck zu erwecken, dass wir dem Erfolg näher kommen, müssen sie sehen, wie wir Tasten auf der Tastatur drücken. Den ganzen Tag von morgens bis abends. Das ist Problem Nummer eins.

Oleg: Mischa, du denkst über etwas nach.

Michael: Entschuldigung, ich war in Gedanken versunken und habe eine Rückblende eingefangen. Das alles erinnerte mich an eine interessante Kundgebung von gestern ... Gestern gab es zu viele Kundgebungen ... Und das kommt mir alles sehr bekannt vor!

Leben ohne Gehälter

Tim: Übrigens ist es überhaupt nicht notwendig, „Kundgebungen“ zur Kommunikation zu organisieren. Ich meine, die nützlichsten Diskussionen zwischen Entwicklern finden dann statt, wenn sie einfach miteinander reden. Sie kommen morgens mit einer Tasse Kaffee herein, und da sind fünf Leute versammelt und diskutieren heftig über etwas Technisches. Wenn ich der Manager dieses Projekts bin, ist es für mich besser, einfach zu lächeln und irgendwohin über mein Geschäft zu gehen und sie darüber diskutieren zu lassen. Sie sind bereits so weit wie möglich involviert. Das ist ein gutes Zeichen.

Oleg: Übrigens gibt es in Ihrem Buch eine Menge Notizen darüber, was gut und was schlecht ist. Benutzen Sie selbst welche davon? Relativ gesehen haben Sie jetzt ein Unternehmen, und zwar eines, das sehr unorthodox strukturiert ist ...

Tim: Unorthodox, aber dieses Gerät passt perfekt zu uns. Wir kennen uns schon lange. Wir vertrauen einander, wir haben einander sehr vertraut, bevor wir Partner wurden. Und wir haben zum Beispiel überhaupt keine Gehälter. Wir arbeiten einfach, und wenn ich zum Beispiel Geld mit meinen Kunden verdient habe, dann ging das ganze Geld an mich. Danach zahlen wir Mitgliedsbeiträge an die Organisation, die ausreichen, um das Unternehmen selbst zu unterstützen. Außerdem sind wir alle auf unterschiedliche Dinge spezialisiert. Ich arbeite zum Beispiel mit Buchhaltern zusammen, fülle Steuererklärungen aus, erledige alle möglichen administrativen Dinge für das Unternehmen, und niemand bezahlt mich dafür. James und Tom arbeiten an unserer Website und werden auch von niemandem bezahlt. Solange Sie Ihre Gebühren bezahlen, wird niemand auf die Idee kommen, Ihnen zu sagen, was Sie tun müssen. Tom arbeitet zum Beispiel jetzt viel weniger als früher. Jetzt hat er andere Interessen; einige Dinge tut er nicht für die Gilde. Aber solange er seine Schulden bezahlt, wird niemand auf ihn zukommen und sagen: „Hey, Tom, geh zur Arbeit!“ Es ist sehr einfach, mit Kollegen umzugehen, wenn zwischen Ihnen kein Geld vorhanden ist. Und jetzt ist unsere Beziehung eine der Grundideen in Bezug auf verschiedene Fachgebiete. Es funktioniert und es funktioniert sehr gut.

bester Ratschlag

Michael: Um auf die „beste Beratung“ zurückzukommen: Gibt es etwas, das Sie Ihren Kunden immer wieder sagen? Es gibt eine Vorstellung von 80/20, und einige Ratschläge werden wahrscheinlich häufiger wiederholt.

Tim: Ich dachte einmal, wenn man ein Buch wie „Waltzing with Bears“ schreiben würde, würde das den Lauf der Geschichte verändern und die Leute würden aufhören, aber... Nun ja, Unternehmen tun oft so, als wäre bei ihnen alles in Ordnung. Sobald etwas Schlimmes passiert, ist es für sie ein Schock und eine Überraschung. „Sehen Sie, wir haben das System getestet und es besteht keinen Systemtest, und das sind weitere drei Monate außerplanmäßiger Arbeit, wie konnte das passieren? Wer wusste? Was könnte schiefgehen? Im Ernst, glauben Sie das?

Ich versuche zu erklären, dass Sie sich über die aktuelle Situation nicht zu sehr aufregen sollten. Wir müssen darüber reden, wirklich verstehen, was schief gelaufen sein könnte und wie wir verhindern können, dass solche Dinge in Zukunft passieren. Wenn ein Problem auftritt, wie werden wir es bekämpfen, wie werden wir es eindämmen?

Für mich sieht das alles beängstigend aus. Die Menschen beschäftigen sich mit komplexen, leidigen Problemen und tun weiterhin so, als ob das „Beste“ tatsächlich passieren würde, wenn sie nur die Daumen drücken und auf das Beste hoffen. Nein, so funktioniert das nicht.

Betreiben Sie Risikomanagement!

Michael: Wie viele Organisationen betreiben Ihrer Meinung nach Risikomanagement?

Tim: Was mich wütend macht, ist, dass die Leute einfach Risiken aufschreiben, sich die resultierende Liste ansehen und sich an die Arbeit machen. Tatsächlich ist die Identifizierung von Risiken für sie Risikomanagement. Aber für mich klingt das nach einem Grund zu fragen: Okay, es gibt eine Liste, was genau werden Sie ändern? Unter Berücksichtigung dieser Risiken müssen Sie Ihre Standard-Handlungsabläufe ändern. Wenn es einen sehr schwierigen Teil der Arbeit gibt, müssen Sie ihn in Angriff nehmen und erst dann mit etwas Einfacherem fortfahren. Beginnen Sie in den ersten Sprints mit der Lösung komplexer Probleme. Das sieht schon nach Risikomanagement aus. Aber normalerweise können Menschen nicht sagen, was sie geändert haben, nachdem sie eine Risikoliste erstellt haben.

Michael: Und doch, wie viele dieser Unternehmen sind im Risikomanagement tätig, fünf Prozent?

Tim: Leider sage ich das ungern, aber das ist ein sehr unbedeutender Teil. Aber mehr als fünf, weil es wirklich große Projekte sind, und die können einfach nicht existieren, wenn sie nicht zumindest etwas tun. Sagen wir einfach, dass ich sehr überrascht sein werde, wenn es mindestens 25 % sind. Kleine Projekte beantworten solche Fragen meist so: Wenn uns das Problem betrifft, dann lösen wir es. Dann bringen sie sich erfolgreich in Schwierigkeiten und betreiben Problemmanagement und Krisenmanagement. Wenn Sie versuchen, ein Problem zu lösen, und das Problem nicht gelöst wird, sind Sie im Krisenmanagement willkommen.

Ja, ich höre oft: „Wir lösen Probleme, sobald sie entstehen.“ Sicherlich werden wir das tun? Werden wir uns wirklich entscheiden?

Oleg: Sie können es naiv machen und einfach wichtige Invarianten in die Projektcharta schreiben, und wenn die Invarianten kaputt gehen, starten Sie das Projekt einfach neu. Es stellt sich als sehr piembucky heraus.

Michael: Ja, es ist mir passiert, dass bei Auslösung von Risiken das Projekt einfach neu definiert wurde. Schön, Bingo, Problem gelöst, mach dir keine Sorgen mehr!

Tim: Drücken wir den Reset-Knopf! Nein, so funktioniert das nicht.

Keynote bei DevOops 2019

Michael: Wir kommen zur letzten Frage dieses Interviews. Sie kommen mit einer Keynote zur nächsten DevOops. Könnten Sie den Vorhang der Geheimhaltung lüften, was Sie erzählen werden?

Tim: Sechs von ihnen schreiben derzeit ein Buch über Arbeitskultur, die unausgesprochenen Regeln von Organisationen. Die Kultur wird durch die Grundwerte der Organisation bestimmt. Normalerweise fällt es den Leuten nicht auf, aber da wir viele Jahre in der Beratung gearbeitet haben, sind wir es gewohnt, es zu bemerken. Sie betreten ein Unternehmen und beginnen buchstäblich innerhalb weniger Minuten zu spüren, was vor sich geht. Wir nennen das „Geschmack“. Manchmal ist dieser Duft wirklich gut und manchmal ist er, na ja, ups. Die Dinge sind für verschiedene Organisationen sehr unterschiedlich.

Michael: Auch ich bin seit Jahren in der Beratung tätig und verstehe gut, wovon Sie sprechen.

Tim: Tatsächlich ist es bei der Keynote erwähnenswert, dass nicht alles vom Unternehmen bestimmt wird. Sie und Ihr Team haben als Gemeinschaft Ihre eigene Teamkultur. Dies kann das gesamte Unternehmen oder eine separate Abteilung oder ein separates Team sein. Aber bevor Sie es gesagt haben: Folgendes glauben wir, Folgendes ist wichtig ... Sie können eine Kultur nicht ändern, bevor die Werte und Überzeugungen hinter bestimmten Handlungen verstanden werden. Verhalten ist leicht zu beobachten, aber die Suche nach Überzeugungen ist schwierig. DevOps ist nur ein gutes Beispiel dafür, wie die Dinge immer komplexer werden. Interaktionen werden nur komplexer, sie werden überhaupt nicht sauberer oder klarer, also sollten Sie darüber nachdenken, woran Sie glauben und worüber alle um Sie herum schweigen.

Wenn Sie schnelle Ergebnisse erzielen möchten, ist hier ein gutes Thema für Sie: Kennen Sie Unternehmen, bei denen niemand „Ich weiß nicht“ sagt? Es gibt Orte, an denen man einen Menschen regelrecht quält, bis er zugibt, dass er etwas nicht weiß. Jeder weiß alles, jeder ist ein unglaublicher Gelehrter. Sie wenden sich an eine beliebige Person, und diese muss die Frage sofort beantworten. Anstatt zu sagen: „Ich weiß es nicht.“ Hurra, sie haben eine Menge Gelehrte angeheuert! Und in manchen Kulturen ist es generell sehr gefährlich, „Ich weiß nicht“ zu sagen; es kann als Zeichen von Schwäche aufgefasst werden. Es gibt auch Organisationen, in denen im Gegenteil jeder sagen kann: „Ich weiß nicht.“ Dort ist es völlig legal, und wenn jemand auf eine Frage hin zu Blödsinn anfängt, ist es völlig normal zu antworten: „Du weißt nicht, wovon du redest, oder?“ und alles in einen Witz verwandeln.

Idealerweise möchten Sie einen Job haben, bei dem Sie dauerhaft glücklich sein können. Es wird nicht einfach sein, nicht jeder Tag ist sonnig und angenehm, manchmal muss man hart arbeiten, aber wenn man anfängt, Bilanz zu ziehen, wird sich herausstellen: Wow, das ist ein wirklich wunderbarer Ort, ich fühle mich gut, hier zu arbeiten, sowohl emotional als auch intellektuell. Und es gibt Unternehmen, da geht man als Berater hin und merkt sofort, dass man es drei Monate nicht aushält und vor Entsetzen davonlaufen würde. Darüber möchte ich in dem Bericht sprechen.

Tim Lister wird mit einer Keynote vor Ort sein „Charaktere, Gemeinschaft und Kultur: Wichtige Faktoren für Wohlstand“zur DevOops 2019-Konferenz, die vom 29. bis 30. Oktober 2019 in St. Petersburg stattfinden wird. Sie können Tickets kaufen auf der offiziellen Website. Wir erwarten Sie bei DevOops!

Source: habr.com