Tim Lister - Co-Autor von Büchern

• "Menschlicher Faktor. Erfolgreiche Projekte und Teams "(das ursprüngliche Buch heißt" Peopleware ")
• „Walzen mit den Bären: Risikomanagement in Softwareentwicklungsprojekten“
• „Erstaunlich mit Adrenalin und Zombiemustern. Verhaltensmuster des Projektteams

Alle diese Bücher sind Klassiker auf ihrem Gebiet und wurden mit Kollegen der Atlantic Systems Guild geschrieben . In Russland sind seine Kollegen am bekanntesten - Tom Demarco und Peter Khrushchka , die auch viele berühmte Werke geschrieben haben.

Tim verfügt über 40 Jahre Erfahrung in der Softwareentwicklung. 1975 (niemand, der diesen Hubrast schrieb, wurde in diesem Jahr geboren) war Tim bereits Executive Vice President von Yourdon Inc. Jetzt berät, schult und schreibt er und nimmt von Zeit zu Zeit an Konferenzen auf der ganzen Welt mit Berichten teil .

Speziell für Habr haben wir ein Interview mit Tim Lister gemacht. Er wird die DevOops 2019-Konferenz eröffnen, und wir haben viele Fragen zu Büchern und vielem mehr gesammelt. Die Interviews werden von Mikhail Druzhinin und Oleg Chirukhin vom Konferenzprogrammkomitee geführt.

Michael: Könnten Sie ein paar Worte darüber sagen, was Sie jetzt tun?

Tim: Ich bin der Leiter der Atlantic Systems Guild. Wir sind zu sechst in der Gilde, wir nennen uns Schulleiter. Drei in den USA und drei in Europa - deshalb heißt die Gilde Atlantik. Wir sind seit so vielen Jahren zusammen, dass Sie einfach nicht zählen. Wir haben alle unsere eigenen Spezialitäten. In den letzten zehn oder mehr Jahren habe ich mit Kunden gearbeitet. Meine Projekte umfassen nicht nur das Management, sondern auch das Setzen von Anforderungen, die Projektplanung und die Bewertung. Es scheint, dass Projekte, die schlecht beginnen, normalerweise schlecht enden. Daher sollten Sie sicherstellen, dass alle Aktivitäten wirklich gut durchdacht sind und sich darauf einigen, dass die Ideen der Schöpfer kombiniert werden. Es lohnt sich zu überlegen, was Sie tun und warum. Welche Strategien verwenden, um das Projekt abzuschließen.

Seit vielen Jahren berate ich Kunden auf vielfältige Weise. Ein interessantes Beispiel ist ein Unternehmen, das Roboter für Operationen an Knie- und Hüftgelenken herstellt. Der Chirurg arbeitet nicht völlig unabhängig, sondern verwendet einen Roboter. Sicherheit ist hier offen gesagt wichtig. Aber wenn Sie versuchen, Anforderungen mit Menschen zu besprechen, die sich auf die Lösung von Problemen konzentrieren ... Es klingt seltsam, aber in den USA gibt es die FDA (Federal Drug Administration), die Produkte wie diese Roboter lizenziert. Bevor Sie etwas an lebende Menschen verkaufen und verwenden, benötigen Sie eine Lizenz. Eine der Bedingungen ist, Ihre Anforderungen zu zeigen, was die Tests sind, wie Sie sie getestet haben, was die Testergebnisse sind. Wenn Sie die Anforderungen ändern, müssen Sie diesen großen Testprozess immer wieder wiederholen. Unsere Kunden haben es geschafft, das visuelle Design von Anwendungen in ihre Anforderungen aufzunehmen. Sie machten Screenshots direkt als Teil der Anforderungen. Wir müssen sie herausziehen und erklären, dass all diese Programme größtenteils nichts über die Knie und Hüften, all diese Dinge mit der Kamera usw. wissen. Wir müssen die Dokumente mit den Anforderungen neu schreiben, damit sie sich nie ändern, es sei denn, einige wirklich wichtige Grundbedingungen ändern sich. Wenn die Anforderungen kein visuelles Design enthalten, wird das Produkt viel schneller aktualisiert. Unsere Aufgabe ist es, diejenigen Elemente zu finden, die sich mit Operationen an Knie, Hüfte und Rücken befassen, sie in separate Dokumente zu ziehen und zu sagen, dass sie grundlegende Anforderungen sind. Lassen Sie uns eine isolierte Gruppe von Anforderungen an die Knieoperation stellen. Dadurch werden robustere Anforderungen erstellt. Wir werden über die gesamte Produktlinie sprechen und nicht über bestimmte Instanzen von Robotern.

Es wurde viel Arbeit geleistet, aber sie kamen dennoch an die Orte, an denen sie zuvor Wochen und Monate wiederholter Tests ohne Bedeutung und Notwendigkeit verbracht hatten, da ihre auf Papier beschriebenen Anforderungen nicht mit den tatsächlichen Anforderungen übereinstimmten, auf denen die Systeme aufgebaut waren. Jedes Mal, wenn die FDA ihnen sagte: Ihre Anforderungen haben sich geändert, müssen Sie jetzt alles von Grund auf überprüfen. Vollständige Gegenkontrollen des gesamten Produkts haben das Unternehmen getötet.

Es gibt also so wunderbare Aufgaben, wenn Sie sich am Anfang von etwas Interessantem befinden und die ersten Aktionen weitere Spielregeln festlegen. Wenn Sie dies sowohl aus Management- als auch aus technischer Sicht tun, wird diese frühe Aktivität gut funktionieren. Am Ausgang besteht die Möglichkeit, ein hervorragendes Projekt zu erhalten. Aber wenn dieser Teil von den Schienen geraten ist und irgendwo schief gelaufen ist, wenn Sie die grundlegende Übereinstimmung nicht finden können ... nein, nicht, dass Ihr Projekt notwendigerweise scheitern wird. Aber Sie werden nicht sagen können: "Wir sind gut gemacht, wir haben alles wirklich effektiv gemacht." Dies sind die Dinge, die ich tue, um mit Kunden zu kommunizieren.

Michael: Das heißt, Sie starten Projekte, machen eine Art Kickoff und überprüfen, ob die Schienen in die richtige Richtung führen?

Tim: Wir haben auch Ideen, wie wir alle Teile des Mosaiks zusammensetzen können: Welche Fähigkeiten brauchen wir, wann genau sie benötigt werden, wie der Kern des Teams aussieht und andere solche grundlegenden Dinge. Benötigen wir Vollzeitbeschäftigte oder können wir jemanden in Teilzeit einstellen? Planung, Verwaltung. Fragen wie: Was ist das Wichtigste für dieses spezielle Projekt? Wie erreicht man das? Was wissen wir über dieses Produkt oder Projekt, was sind die Risiken und wo ist das Unbekannte, wie werden wir mit all dem umgehen? Natürlich fängt in diesem Moment jemand an zu schreien: "Aber was ist mit Agilität ?!". Nun, Sie sind alle flexibel, aber was nun? Wie genau sieht das Projekt aus, wie werden Sie es herausnehmen, damit es zum Projekt passt? Man kann nicht einfach sagen, dass "unser Ansatz von irgendetwas gezogen wird, wir sind ein Scrum-Team!" Das ist Unsinn und Unsinn. Wohin gehst du als nächstes, warum sollte es verdienen, wo ist der Punkt? Ich bringe meinen Kunden bei, über all diese Themen nachzudenken.

19 Jahre Ajail

Michael: In Ajail versuchen die Leute oft, nichts im Voraus zu bestimmen, sondern treffen Entscheidungen so spät wie möglich und sagen: Wir sind zu groß, ich werde nicht über die allgemeine Architektur nachdenken. Ich werde nicht über ein paar andere Dinge nachdenken, sondern den Kunden jetzt mit etwas Funktionierendem versorgen.

Tim: Ich denke, agile Methoden, beginnend mit dem Agilen Manifest im Jahr 2001, haben die Augen der Branche geöffnet. Andererseits ist nichts perfekt. Ich bin ganz auf der Seite der iterativen Entwicklung. Iterationen sind in den meisten Projekten sehr sinnvoll. Aber Sie müssen über die Frage nachdenken: Wie lange lebt das Produkt, nachdem es herausgekommen ist und in Betrieb genommen wurde? Ist dies ein Produkt, das sechs Monate hält und dann durch ein anderes ersetzt wird? Oder ist es so ein Produkt, das viele, viele Jahre funktionieren wird? Natürlich werde ich keine Namen nennen, aber ... In New York und seiner Gemeinschaft von Finanziers sind die grundlegendsten Systeme sehr alt. Es ist unglaublich. Sie sehen sie sich an und denken, Sie würden 1994 in die Vergangenheit reisen und den Entwicklern sagen: „Ich bin aus der Zukunft gekommen, ab 2019. Entwerfen Sie dieses System einfach so oft, wie Sie es benötigen. Machen Sie es erweiterbar, denken Sie über Architektur nach. Es wird dann für mehr als fünfundzwanzig Jahre verbessert. Wenn Sie die Entwicklung etwas länger verzögern, wird dies niemand auf einer Skala der Geschichte bemerken! “ Wenn Sie Dinge auf lange Sicht bewerten, müssen Sie berücksichtigen, wie viel es insgesamt kosten wird. Manchmal lohnt sich eine gut gestaltete Architektur wirklich, manchmal nicht. Sie müssen sich umschauen und sich die Frage stellen: Sind wir in einer geeigneten Situation für eine solche Lösung?

Eine Idee wie „Wir sind für Agilität, der Kunde selbst wird uns sagen, was er erhalten möchte“ - sie ist übernatürlich. Schließlich wissen Kunden nicht einmal, was sie wollen, und noch mehr wissen sie nicht, was sie bekommen könnten. Einige werden anfangen, historische Beispiele als Argumente zu zitieren, das habe ich bereits gesehen. Aber technisch fortgeschrittene Leute sagen das normalerweise nicht. Sie sagen: "Jetzt ist das Jahr 2019, wir haben solche Möglichkeiten und wir können unsere Sicht auf solche Dinge komplett ändern!" Anstatt die vorhandenen Lösungen nachzuahmen und sie ein wenig schöner und gekämmter zu machen, müssen Sie manchmal rausgehen und sagen: „Lassen Sie uns das, was wir hier versuchen, völlig neu erfinden!“

Und ich glaube nicht, dass die meisten Kunden auf diese Weise an ein Problem denken können. Sie sehen nur das, was sie bereits haben, und das war's. Dann kommen sie mit Anfragen wie „Lass es uns ein bisschen einfacher machen“ oder was auch immer sie normalerweise sagen. Aber wir sind keine Kellner und Kellnerinnen, die eine Bestellung annehmen, egal wie dumm sie sich herausstellte, und sie dann in der Küche backen. Wir sind ihre Führer. Wir müssen ihre Augen öffnen und sagen: Hey, hier haben wir neue Möglichkeiten! Ist Ihnen klar, dass wir die Art und Weise, wie dieser Teil Ihres Geschäfts abgewickelt wird, wirklich ändern können? Eines der Probleme von adjayl ist, dass er sich vom Bewusstsein entfernt, was eine Chance ist, was ein Problem ist, was wir tun müssen und welche der verfügbaren Technologien in dieser speziellen Situation am besten geeignet sind.

Vielleicht bin ich mit Skepsis zu weit gegangen: In der agilen Community passieren viele wundervolle Dinge. Aber ich habe ein Problem mit der Tatsache, dass die Leute anstatt ein Projekt zu definieren, anfangen zu zucken. Ich würde hier fragen - was machen wir, wie machen wir das? Und auf magische Weise stellt sich immer heraus, dass dieser Kunde es am besten wissen sollte. Aber der Kunde weiß es am besten nur, wenn er aus Dingen auswählt, die bereits von jemandem gebaut wurden. Wenn ich ein Auto kaufen möchte und die Größe des Familienbudgets kenne, werde ich schnell ein Auto abholen, das zu meinem Lebensstil passt. Hier weiß ich alles besser als jeder andere! Beachten Sie jedoch, dass bereits jemand die Maschine hergestellt hat. Wie man ein neues Auto erfindet, ich habe keine Ahnung, ich bin kein Experte. Bei der Erstellung von benutzerdefinierten oder speziellen Produkten muss die Stimme des Kunden berücksichtigt werden. Dies ist jedoch nicht die einzige Stimme.

Oleg: Sie haben das Agile Manifest erwähnt. Müssen wir es irgendwie aktualisieren oder überarbeiten, um das aktuelle Verständnis des Problems zu berücksichtigen?

Tim: Ich würde ihn nicht berühren. Ich denke, das ist ein großartiges historisches Dokument. Ich meine, er ist was er ist. Er ist 19 Jahre alt, er ist alt, aber einmal hat er eine Revolution gemacht. Was er gut machte, war eine Reaktion auszulösen, sie fingen an, über ihn zu flüstern. Höchstwahrscheinlich haben Sie 2001 nicht in der Branche gearbeitet, aber dann haben alle an Prozessen gearbeitet. Software Engineering Institute, fünf Ebenen des Software Integrity Potential Model (CMMI). Ich weiß nicht, ob solche Legenden der Antike etwas Tiefes sagen, aber dann war es ein Durchbruch. Zuerst glaubten die Leute, wenn die Prozesse richtig aufgebaut wären, würden die Probleme selbst verschwinden. Und dann erscheint 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 ein Trugbild ist, nicht wahr? Es gibt zu viel Eigenart in Projekten, die Idee eines einzigen, fehlerfreien Prozesses für alle Projekte macht keinen Sinn. Die Probleme sind zu komplex, um zu behaupten, dass für alles eine einzige Lösung gefunden wurde (hi, nirvana).

Ich nehme nicht an, in die Zukunft zu schauen, aber ich werde sagen, dass die Leute jetzt begonnen haben, mehr über Projekte nachzudenken. Ich denke, dass das Agile Manifest sehr gut ist, er springt vor und sagt: „Hey! Sie sind auf einem Schiff und führen dieses Schiff selbst an. Sie müssen eine Entscheidung treffen - wir werden nicht für alle Situationen ein universelles Rezept erstellen. Sie sind die Besatzung des Schiffes, und wenn Sie gut genug sind, können Sie den Weg zum Ziel finden. Es gab andere Schiffe vor Ihnen, und andere Schiffe werden hinter Ihnen her sein, aber dennoch ist Ihre Reise in gewissem Sinne einzigartig. “ So etwas! Dies ist eine Art zu denken. Für mich ist nichts unter dem Mond neu, die Leute sind früher gesegelt und werden wieder schwimmen, aber für Sie ist dies Ihre Hauptreise, und ich werde Ihnen nicht genau sagen, was mit Ihnen geschehen wird. Sie müssen über die Fähigkeiten einer koordinierten Teamarbeit verfügen, und wenn dies wirklich der Fall ist, wird alles funktionieren und Sie werden kommen, wo Sie wollen.

Peopleware: 30 Jahre später

Oleg: Peopleware war auch eine Revolution wie das Manifest?

Tim: Peopleware ... Tom und ich haben dieses Buch geschrieben, aber nicht gedacht, dass alles passieren würde. Irgendwie stimmte es mit den Ideen vieler Menschen überein. Dies war das erste Buch, in dem es heißt: Softwareentwicklung ist eine sehr menschenintensive Aktivität. Trotz unserer technischen Natur sind wir auch eine Gemeinschaft von Menschen, die etwas Großes, sogar Großes, sehr Komplexes bauen. Niemand kann solche Dinge alleine schaffen, oder? Die Idee eines „Teams“ ist also sehr wichtig geworden. Und das nicht nur aus Sicht des Managements, sondern auch für Mitarbeiter eines technischen Lagers, die zusammengekommen sind, um wirklich komplexe, tiefe Probleme mit einer Reihe von Unbekannten zu lösen. Für mich persönlich war dies während meiner gesamten Karriere ein großer Intelligenztest. Und hier müssen Sie sagen können: Ja, dieses Problem ist mehr als ich selbst lösen kann, aber gemeinsam können wir eine elegante Lösung finden, auf die wir stolz sein können. Und ich denke, dass diese besondere Idee am meisten Resonanz fand. Die Idee ist, dass wir einen Teil der Zeit alleine arbeiten, einen Teil der Gruppe, und oft wird die Entscheidung von der Gruppe getroffen. Das Lösen von Gruppenproblemen wurde schnell zu einem wichtigen Merkmal komplexer Projekte.

Trotz der Tatsache, dass Tim eine große Anzahl von Berichten hatte, gibt es nur sehr wenige davon auf YouTube. Sie können den Bericht 2007 The Return of Peopleware sehen. 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: Man kann es aus vielen verschiedenen Blickwinkeln betrachten. Soziologisch sprechen ... einmal, in einfacheren Zeiten, waren Sie und das Team im selben Büro. Sie könnten jeden Tag dort sein, gemeinsam Kaffee trinken und über die Arbeit diskutieren. Was sich wirklich geändert hat, ist, dass Teams jetzt geografisch in verschiedenen Ländern und Zeitzonen verteilt werden können, aber dennoch an derselben Aufgabe arbeiten, was eine völlig neue Komplexitätsebene schafft. Es mag altmodisch klingen, aber es gibt nichts Besseres als persönliche Kommunikation. Wenn Sie alle zusammenkommen, zusammenarbeiten, können Sie zu einem Kollegen gehen und sagen: Schauen Sie, ich habe herausgefunden, wie Sie sich dabei fühlen. Gespräche von Angesicht zu Angesicht bieten einen schnellen Weg zur informellen Kommunikation, und ich denke, dies sollte auch Adjayl-Liebhaber ansprechen. Und ich mache mir Sorgen, weil sich die Welt in Wirklichkeit als sehr klein herausstellte und jetzt alles von verteilten Teams abgedeckt wird, und das alles ist sehr kompliziert.

Wir leben alle in DevOps

Michael: Selbst aus Sicht des Konferenzprogrammkomitees haben wir Leute in Kalifornien, in New York, Europa, Russland ... in Singapur gibt es immer noch niemanden. Der Unterschied in der Geographie ist ziemlich groß und die Menschen beginnen sich noch mehr zu verteilen. Wenn wir bereits über Entwicklung sprechen, können Sie uns mehr über Entwickler und die Zerstörung von Hindernissen zwischen Teams erzählen? Es gibt ein Konzept, dass jeder in seinen Bunkern sitzt, und jetzt bröckeln die Bunker. Wie gefällt Ihnen diese Analogie?

Tim: Es scheint mir, dass Devops angesichts der jüngsten technologischen Durchbrüche von großer Bedeutung sind. Zuvor hatten Sie Teams von Entwicklern und Administratoren, die arbeiteten, arbeiteten, arbeiteten, und irgendwann erschien etwas, mit dem Sie zu den Admins kommen und es auf das Produkt ausrollen konnten. Und hier begann das Gespräch über den Bunker, denn die Admins sind wie Verbündete, zumindest keine Feinde, aber Sie haben erst mit ihnen gesprochen, als alles zum Verkauf bereit war. Sie gingen mit etwas zu ihnen und sagten: Schauen Sie, was ist unsere Anwendung, aber könnten Sie diese Anwendung ausrollen? Und jetzt hat sich das gesamte Lieferkonzept zum Besseren gewendet. Ich meine, die Idee kam auf, dass man Veränderungen schnell vorantreiben kann. Wir können Produkte im laufenden Betrieb aktualisieren. Ich lächle immer, wenn ein Firefox auf meinem Laptop auftaucht und sagt: Hey, wir haben Ihren Firefox im Hintergrund aktualisiert. Sobald Sie eine Minute Zeit haben, können Sie hier klicken und wir werden Ihnen eine neue Version geben. Und ich sage: "Oh ja, Baby!" Während ich schlief, arbeiteten sie direkt an meinem Computer daran, mir eine neue Version zu liefern. Das ist wunderbar, unglaublich.

Aber hier ist die Schwierigkeit: Sie haben diese Funktion mit Software-Updates, aber die Integration von Personen ist viel schwieriger. Was ich auf der DevOops-Keynote sagen möchte, ist, dass wir jetzt weit mehr Spieler als je zuvor haben. Wenn Sie nur an alle denken, die an der Arbeit eines einzigen Teams teilnehmen ... Sie haben es als Team gesehen und es ist viel mehr als nur ein Team von Programmierern. Dies sind Tester, Projektmanager und eine Reihe anderer Personen. Und jeder hat seine eigenen Ansichten über die Welt. Produktmanager unterscheiden sich grundlegend von Projektmanagern. Administratoren haben ihre eigenen Aufgaben. Es wird zu einem ziemlich schwierigen Problem, alle Teilnehmer zu koordinieren, um weiterhin zu wissen, was passiert, und nicht von den Spulen zu steigen. Es ist notwendig, die Aufgaben der Gruppe und die Aufgaben, die sich auf alle beziehen, zu trennen. Dies ist eine sehr schwierige Aufgabe. Andererseits denke ich, dass all dies viel besser geworden ist als vor vielen Jahren. Dies ist genau der Weg, auf dem Menschen wachsen und lernen, sich richtig zu verhalten. Wenn Sie sich mit Integration beschäftigen, verstehen Sie, dass es keine unterirdische Entwicklung geben sollte, damit die Software im allerletzten Moment nicht aus dem Kasten kriecht: Schauen Sie, was haben wir hier getan? Die Idee ist, dass Sie Integration und Entwicklung durchführen können und am Ende ordentlich und iterativ rollen. All dies ist für mich von großer Bedeutung. Dies ermöglicht es, mehr Wert für Benutzer des Systems und für Ihren Kunden zu schaffen.

Michael: Die ganze Idee von Devopse ist es, so früh wie möglich sinnvolle Arbeit zu liefern. Ich sehe, dass die Welt immer schneller wurde. Wie kann man sich an solche Beschleunigungen anpassen? Vor zehn Jahren war das nicht!

Tim: Natürlich will jeder immer mehr Funktionalität. Sie müssen sich nicht bewegen, sondern stapeln sich einfach weiter. Manchmal muss man sogar langsamer fahren, damit das nächste inkrementelle Update zumindest etwas Nützliches bringt - und das ist völlig normal.

Die Idee, die Sie ausführen müssen, ist nicht die beste. Kaum jemand will so leben. Ich möchte, dass der Rhythmus der Lieferungen den eigenen Rhythmus des Projekts festlegt. Wenn Sie nur einen Strom kleiner, relativ bedeutungsloser Dinge produzieren, macht dies alles insgesamt keinen Sinn. Anstatt gedankenlos zu versuchen, die Dinge so früh wie möglich zu veröffentlichen, lohnt es sich, mit führenden Entwicklern sowie Produkt- und Projektmanagern über die Strategie zu diskutieren. Macht das überhaupt Sinn?

Muster und Antimuster

Oleg: Sie sprechen normalerweise über Muster und Antimuster, und dies ist der Unterschied zwischen Leben und Tod von Projekten. Und jetzt brechen Devops in unser Leben ein. Hat er eigene Muster und Antimuster, die das Projekt sofort töten können?

Tim: Muster und Antimuster treten ständig auf. Worüber man reden soll. Nun, es gibt eine Sache, die wir "glänzende Dinge" nennen. Die Leute mögen neue Technologien wirklich sehr. Sie sind einfach verzaubert von der Brillanz 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 Sinn? Ich sehe oft Leute, sagen wir, an der Spitze der Technologie. Sie sind fasziniert von dem, was in der Welt passiert. Aber wenn Sie genauer hinschauen, was nützen sie - oft gibt es einfach nichts Nützliches!

, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».

: , ?

: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .

: , « , »: ?

: . - . – - , , ? , – . , , - : « ! !». Wirklich? .

«-»

: . - , «-» . : , , «-», ? , – , - .

: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?

, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».

- , , . , , . – , « ». Was? , , . - , , , , , . , - , , , , . ! - .

- -. , , ? , , ? - : --, , , , , .

, , . , . , , : , . , . , . .

. – , , , , , , ! - . – …

« »

: ? , , , – « ».

: ! – , - . - , ( , ). – , – , - , .

, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .

: , . , , . , . , – , – . , , , .

: Move fast and break things!

: , , , – -. , ?

: : . . , - , . , , - , « », , : « ». , . , , . – .

, . , , , - . - , , . , – , , , , . , , , . .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

Tim: Richtig. Ich denke, die besten Technikfreaks sind, wenn man sie sich genau ansieht, wie Manager für sich. Wie man es formuliert ...

Oleg: Dein Leben ist dein Projekt, das du verwaltest.

Tim: Richtig! Ich meine, Sie haben Verantwortung übernommen, Sie verstehen das Problem und Sie kommen mit Menschen in Kontakt, wenn Sie sehen, dass Ihre Entscheidungen ihre Arbeit beeinflussen können, alles in diesem Sinne. Es geht nicht nur darum, am Tisch zu sitzen, deine Arbeit zu erledigen und nicht einmal zu wissen, was um dich herum passiert. Nein nein Nein. Übrigens ist eines der besten Dinge in Agile, dass sie kurze Sprints vorgeschlagen haben, da der Zustand aller Teilnehmer gut beobachtet wird und sie alles zusammen beobachten können. Jeden Tag reden wir über einander.

Einstieg in das Risikomanagement

Oleg: Gibt es in diesem Bereich eine formale Wissensstruktur? Zum Beispiel bin ich ein Java-Entwickler und möchte das Risikomanagement verstehen, ohne ein echter Projektmanager für Bildung zu werden. Wahrscheinlich habe ich zuerst "Wie viel kostet ein Softwareprojekt" von McConnell gelesen und dann was? Was sind die ersten Schritte?

Tim: Das erste ist, mit den Leuten im Projekt zu kommunizieren. Dies bietet eine sofortige Verbesserung der Kommunikationskultur mit Kollegen. Sie müssen zunächst standardmäßig alles öffnen, anstatt es auszublenden. Sprich: Das sind die Dinge, die mich stören, das sind die Dinge, die mich nachts wach halten, heute bin ich nachts aufgewacht und so: Götter, das muss berücksichtigt werden! Sehen die anderen dasselbe? Sollten wir als Gruppe auf diese potenziellen Probleme reagieren? Sie müssen in der Lage sein, eine Diskussion zu diesen Themen zu führen. Es gibt keine vorbereitete Formel, nach der wir arbeiten. Hier geht es nicht um Hamburger, sondern um Menschen. „Cheeseburger gemacht - Cheeseburger verkaufen“ - hier geht es überhaupt nicht um uns, und deshalb liebe ich diesen Job so sehr. Ich mag es, wenn alles, was Manager zuvor getan haben, jetzt Eigentum des Teams wird.

Oleg: Sie haben in Büchern und Interviews gesagt, dass die Menschen sich mehr Sorgen um das Glück machen als um die Zahlen in der Grafik. Wenn Sie dem Team jedoch sagen: Wir wechseln zu Entwicklern, und jetzt muss der Programmierer ständig kommunizieren. Dies kann weit über seine Komfortzone hinausgehen. Und in diesem Moment kann er, sagen wir mal, zutiefst unglücklich sein. Was ist in dieser Situation zu tun?

Tim: Ich weiß nicht genau, was ich tun soll. Wenn der Entwickler zu isoliert ist, sieht er nicht, warum die Arbeit überhaupt erledigt ist, er betrachtet nur seinen Teil der Arbeit und muss sich mit dem befassen, was ich den „Kontext“ nenne. Er muss herausfinden, wie alles miteinander verbunden ist. Und natürlich meine ich nicht die formelle Präsentation oder ähnliches. Ich sage, dass Sie mit Kollegen über die Arbeit als Ganzes kommunizieren müssen und nicht nur über den Teil, für den Sie verantwortlich sind. Und in diesem Moment können Sie anfangen, Ideen und allgemeine Vereinbarungen zu diskutieren, damit Ihre Arbeit gut verläuft und wie Sie sich auf ein gemeinsames Problem stützen können.

Um sich anzupassen, möchten Technikfreaks sie oft auch zu Schulungen schicken und Schulungen besprechen. Ein Freund von mir sagt gerne, dass das Training für Hunde ist. Es gibt Training für Menschen. Eines der besten Dinge, um einen Entwickler zu unterrichten, ist die Kommunikation mit Kollegen. Wenn es jemandem wirklich gelungen ist, sollten Sie sehen, wie er arbeitet, oder mit ihm über die Arbeit sprechen oder so etwas. Einige bedingte Kent Beck sprachen ständig über extreme Programmierung. Es ist lustig, weil XP eine so einfache Idee ist, aber es verursacht so viele Probleme. Für jemanden ist XP so, als ob er 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 Jemand wird ernsthaft nervös. Aber wenn Sie erkennen, dass dies der ultimative Weg zum Lernen ist, ändert sich alles. Sie arbeiten eng mit Menschen zusammen, und manche Menschen verstehen das Thema viel besser als Sie.

Michael: Aber das alles lässt dich deine Komfortzone verlassen. Als Ingenieur müssen Sie Ihre Komfortzone verlassen und kommunizieren. Als Person, die Probleme löst, müssen Sie sich ständig in eine schwache Position bringen und überlegen, was schief gehen könnte. Solche Arbeiten sind von Natur aus unpraktisch. Sie versetzen sich bewusst in stressige Situationen. Normalerweise laufen Menschen vor ihnen weg, Menschen mögen es, glückliche Kinder zu sein.

Tim: Was kann man tun, man kann rausgehen und offen sagen: „Alles ist in Ordnung, ich kann damit umgehen! Ich bin nicht allein in Unbehagen. Lassen Sie uns gemeinsam als Team verschiedene unangenehme Dinge besprechen! “ Dies sind unsere gemeinsamen Probleme, wir müssen uns mit ihnen befassen, verstehen? Ich denke, die eigenwilligen brillanten Entwickler - sie sind wie Mammuts, sie sind verschwunden. Ja, und sie haben einen sehr begrenzten Wert. Wenn Sie nicht kommunizieren können, können Sie nicht normal teilnehmen. Sagen Sie es einfach. Sei ehrlich und offen. Es tut mir sehr leid, dass jemand unangenehm ist. Stellen Sie sich vor, vor vielen Jahren gab es eine Studie, nach der die Hauptangst in den USA nicht der Tod ist, aber wissen Sie was? Angst vor öffentlichen Reden! Irgendwo gibt es also Menschen, die eher sterben als laut ein Kompliment zu machen. Und ich denke, Sie haben nur einige grundlegende Fähigkeiten, je nachdem, was Sie tun. Konversationsfähigkeiten, Schreibfähigkeiten - aber so viel, wie es für Ihre Arbeit wirklich notwendig ist. Wenn Sie als Analyst arbeiten, aber nicht lesen, schreiben und sprechen können, haben Sie in meinen Projekten leider nichts zu tun!

Preis der Kommunikation

Oleg: Ist der Einsatz solcher scheidenden Mitarbeiter aus verschiedenen Gründen teurer? Am Ende reden sie ständig statt zu arbeiten!

Tim: Ich hatte den Kern des Teams im Sinn und im Allgemeinen nicht alle hintereinander. Wenn Sie einen Spezialisten haben, der Ihre Datenbanken wirklich cool einrichtet, es liebt, Ihre Datenbanken einzurichten und Ihre Datenbanken für den Rest Ihres Lebens weiter einrichten wird, und das ist alles cool, machen Sie weiter so. Aber ich spreche von Leuten, die im Projekt selbst leben wollen. Der Kern des Teams war die Entwicklung des Projekts. Diese Leute müssen wirklich ständig miteinander kommunizieren. Und besonders zu Beginn des Projekts, wenn Sie Risiken, Wege zur Erreichung globaler Ziele und dergleichen diskutieren.

Michael: Dies gilt für alle, die an dem Projekt beteiligt sind, unabhängig von Spezialisierung, Fähigkeiten und Arbeitsweisen. Sie alle interessieren sich für den Erfolg des Projekts.

Tim: Ja, Sie haben das Gefühl, tief in das Projekt eingetaucht zu sein, und Ihre Aufgabe ist es, das Projekt zu verwirklichen. Seien Sie ein Programmierer, Analyst, Interface-Designer, jeder. Dies ist der Grund, warum ich jeden Morgen zur Arbeit komme, und das tun wir. Wir sind für all diese Menschen verantwortlich, unabhängig von ihren Fähigkeiten. Dies ist eine Gruppe von Menschen, die Gespräche mit Erwachsenen führen.

Oleg: Eigentlich habe ich über gesprächige Mitarbeiter gesprochen und versucht, die Einwände von Menschen zu simulieren, insbesondere von Managern, denen angeboten wird, zu Devops zu wechseln, zu dieser ganz neuen Vision der Welt. Und für Sie als Berater sollten diese Einwände viel besser bekannt sein als für mich als Entwickler! Teilen Sie mit, was Manager am meisten interessiert?

Tim: Manager? Hm. In den meisten Fällen stehen Manager unter dem Druck von Problemen, bevor dringend etwas freigegeben und eine Lieferung und dergleichen vorgenommen werden muss. Sie beobachten, wie wir ständig diskutieren und streiten, und sie sehen es so: Gespräche, Gespräche, Gespräche ... Welche anderen Gespräche? Mach dich wieder an die Arbeit! Weil ihnen Gespräche nicht wie Arbeit erscheinen. Sie schreiben keinen Code, testen keine Software, tun scheinbar nichts - warum schicken Sie Sie nicht, um Geschäfte zu machen? Immerhin ist die Lieferung schon in einem Monat!

Michael: Schreib Code!

Tim: Es scheint mir, dass sie sich keine Sorgen um die Arbeit machen, sondern um die mangelnde Sichtbarkeit, um vorwärts zu kommen. Damit sie glauben, dass wir uns dem Erfolg nähern, müssen sie sehen, wie wir die Tasten auf der Tastatur drücken. Den ganzen Tag von morgens bis abends. Dies ist das Hauptproblem.

Oleg: Mischa, du hast dir etwas gedacht.

Michael: Entschuldigung, dachte ich, ich habe einen Rückblick bekommen. All dies erinnerte mich an eine interessante Rallye, die gestern stattfand ... Gestern gab es zu viele Rallyes ... Und das klingt alles sehr vertraut!

Leben ohne Gehälter

Tim: Übrigens ist es nicht notwendig, "Meetings" für die Kommunikation zu arrangieren. Ich meine, die nützlichsten Diskussionen zwischen Entwicklern finden statt, wenn sie nur miteinander sprechen. Sie kommen morgens mit einer Tasse Kaffee herein, und dort kommen wir fünf zusammen und diskutieren heftig über etwas Technisches. Für mich, wenn ich der Manager dieses Projekts bin, ist es besser, einfach zu lächeln und irgendwohin zu gehen, um über Ihr Geschäft zu sprechen. Sie sind bereits so weit wie möglich involviert. Das ist ein gutes Zeichen.

Oleg: Übrigens, hier haben Sie eine Reihe von Notizen in Ihrem Buch darüber, was gut und was schlecht ist. Verwenden Sie einen von ihnen selbst? Relativ gesehen haben Sie hier jetzt eine Firma und sogar eine sehr unorthodoxe Struktur ...

Tim: Unorthodox, aber ein solches Gerät ist großartig für uns. Wir kennen uns schon lange. Wir vertrauen einander, vertrauten einander viel bevor wir Partner wurden. Zum Beispiel haben wir überhaupt keine Gehälter. Wir arbeiten nur, und wenn ich zum Beispiel Geld von meinen Kunden verdient habe, dann ging das ganze Geld an mich. Danach zahlen wir Mitgliedsbeiträge an die Organisation, und dies reicht aus, um das Unternehmen selbst zu erhalten. Außerdem sind wir alle auf verschiedene Dinge spezialisiert. Zum Beispiel arbeite ich 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 auf unserer Website und niemand bezahlt sie auch. Solange Sie Ihre Gebühren bezahlen, wird niemand daran denken, Ihnen zu sagen, was Sie tun müssen. Zum Beispiel arbeitet Tom jetzt viel weniger als zuvor. Jetzt hat er andere Interessen, was er nicht für die Gilde tut. Aber solange er seine Gebühren bezahlt, wird niemand auf ihn zukommen und sagen: "Hey Tom, komm und arbeite!" Es ist sehr einfach, mit Kollegen umzugehen, wenn zwischen Ihnen kein Geld ist. Und jetzt ist unsere Beziehung eine der Grundideen, die auf verschiedene Fachgebiete angewendet werden. Es funktioniert und es funktioniert sehr gut.

Bester Rat

Michael: Zurück zum „besten Rat“, gibt es etwas, das Sie Ihren Kunden immer wieder wiederholen? Es gibt eine Idee über 80/20, und sicher werden einige Ratschläge öfter wiederholt.

Tim: Als ich dachte, wenn Sie ein Buch wie „Waltzing with the Bears“ schreiben, wird dies den Lauf der Geschichte verändern und die Leute werden aufhören, aber ... Nun, schauen Sie, oft tun Unternehmen so, als ob es ihnen gut geht. Sobald etwas Schlimmes passierte, war es ein Schock und eine Überraschung für sie. „Schauen Sie, wir haben das System getestet und es besteht keine Systemtests. Dies sind weitere drei Monate außergewöhnlicher Arbeit. Wie könnte das passieren? Wer wusste Was hätte schief gehen können? " Glaubst du das ernsthaft?

Ich versuche zu erklären, dass Sie nicht zu sehr auf die aktuelle Situation sauer werden sollten. Sie müssen darüber diskutieren, um wirklich zu verstehen, was schief gelaufen sein könnte und wie Sie solche Dinge in Zukunft verhindern können. Wenn sich das Problem dennoch manifestiert, wie wir es bekämpfen, wie wir es zurückhalten können.

Für mich sieht alles beängstigend aus. Die Menschen beschäftigen sich mit komplexen, unangenehmen Problemen und tun weiterhin so, als würde dies wirklich passieren, wenn sie einfach die Daumen drücken und auf das Beste hoffen. Nein, das funktioniert nicht.

Risikomanagement betreiben!

Michael: Wie viele Organisationen sind Ihrer Meinung nach am Risikomanagement beteiligt?

Tim: Was mich wütend macht, ist, dass die Leute einfach Risiken aufschreiben, sich die resultierende Liste ansehen und zur Arbeit gehen. In der Tat ist das Erkennen von Risiken für sie ein Risikomanagement. Aber für mich klingt das nach einem Grund für die Frage: Nun, es gibt eine Liste, was genau werden Sie ändern? Sie müssen Ihre Standardsequenz von Aktionen ändern, um diese Risiken zu berücksichtigen. Wenn es einen schwierigsten Teil der Arbeit gibt, müssen Sie ihn erledigen und erst dann mit dem einfacheren fortfahren. Beginnen Sie bereits bei den ersten Sprints mit der Lösung komplexer Probleme. Dies ähnelt nun dem Risikomanagement. Normalerweise können die Leute jedoch nicht sagen, was sie geändert haben, nachdem sie eine Liste mit Risiken erstellt haben.

Michael: Und doch, wie viele solcher Risikomanagementunternehmen sind fünf Prozent?

Tim: Leider ist es für mich unangenehm, das zu sagen, aber das ist ein sehr unbedeutender Teil. Aber mehr als fünf, weil es wirklich große Projekte gibt und sie einfach nicht existieren können, wenn sie nicht zumindest etwas tun. Sagen wir einfach, ich wäre sehr überrascht, wenn es mindestens 25% wären. Kleine Projekte beantworten solche Fragen normalerweise folgendermaßen: Wenn uns das Problem berührt, werden wir es lösen. Dann tauchen sie erfolgreich in das Problem ein und beschäftigen sich mit Problemmanagement und Krisenmanagement. Wenn Sie versuchen, ein Problem zu lösen, das Problem jedoch nicht gelöst ist, sind Sie beim Krisenmanagement willkommen.

Ja, ich höre oft: "Wir werden Probleme lösen, sobald sie verfügbar sind." Werden wir recht haben? Werden wir uns genau entscheiden?

Oleg: Sie können dies naiv tun und einfach wichtige Invarianten in die Projektcharta schreiben. Wenn die Invarianten ausfallen, starten Sie das Projekt einfach neu. Es stellt sich in einem sehr pembuccule heraus.

Mikhail: Ja, mir ist passiert, dass das Projekt einfach neu definiert wurde, als die Risiken funktionierten. Schön, Bingo, das Problem ist gelöst, keine Sorgen mehr!

Tim: Drücken Sie die Reset-Taste! Nein, das funktioniert nicht.

Keynote bei DevOops 2019

Michael: Wir kommen zur letzten Frage dieses Interviews. Sie kommen mit einer Keynote zu den nächsten DevOops. Könnten Sie den Schleier der Geheimhaltung über das öffnen, was Sie erzählen werden?

Tim: Im Moment schreiben sechs von ihnen ein Buch über die Arbeitskultur, die unausgesprochenen Regeln von Organisationen. Kultur wird durch die Grundwerte der Organisation bestimmt. Normalerweise bemerken die Leute das nicht, aber wir, die wir seit vielen Jahren in der Beratung arbeiten, sind es gewohnt, es zu bemerken. Sie gehen in die Firma und schon wenige Minuten später spüren Sie, was passiert. Wir nennen es "Aroma". Manchmal ist dieser Duft wirklich gut und manchmal ist es gut. Unterschiedliche Organisationen haben sehr unterschiedliche Dinge.

Michael: Ich arbeite auch seit Jahren in der Beratung und verstehe gut, wovon Sie sprechen.

Tim: Tatsächlich ist eines der Dinge, über die es sich zu sprechen lohnt, dass nicht alles vom Unternehmen bestimmt wird. Sie und Ihr Team als Community - Sie haben Ihre eigene Teamkultur. Es kann sich entweder um das gesamte Unternehmen oder um eine separate Abteilung oder ein separates Team handeln. Aber bevor Sie sagten: Daran glauben wir, das ist wichtig ... Sie können Ihre Kultur nicht ändern, bevor Sie die Werte und Überzeugungen hinter konkreten Maßnahmen erkannt haben. Verhalten ist leicht zu beobachten und Überzeugungsarbeit ist schwierig. DevOps ist nur ein gutes Beispiel dafür, wie es immer schwieriger wird. Interaktionen werden nur noch komplizierter, sie werden nicht sauberer und verständlicher. Sie sollten also darüber nachdenken, woran Sie glauben und worüber alle in der Umgebung schweigen.

Wenn Sie schnelle Ergebnisse erzielen möchten, ist hier ein gutes Thema: Haben Sie Unternehmen gesehen, in denen niemand "Ich weiß nicht" sagt? Es gibt Orte, an denen Sie einen Menschen buchstäblich foltern müssen, bis er zugibt, dass er etwas nicht weiß. Jeder weiß alles, jeder ist ein unglaublicher Gelehrter. Sie nähern sich jeder Person und sie muss sofort etwas auf die Frage beantworten. Anstatt zu sagen "Ich weiß es nicht." Hurra, sie haben eine Menge Gelehrter eingestellt! Und in einigen Kulturen ist es sehr gefährlich zu sagen "Ich weiß nicht", es kann als Manifestation von Schwäche wahrgenommen werden. Es gibt Organisationen, in denen im Gegenteil jeder sagen kann: "Ich weiß nicht." Dort ist es völlig legal, und wenn jemand, der auf eine Frage antwortet, anfängt, das Spiel zu reiben, ist es völlig normal zu antworten: "Sie verstehen nicht, wovon Sie sprechen, oder?" und mach es zu einem Witz.

Idealerweise hätte ich gerne einen Job, bei dem Sie die ganze Zeit glücklich sein könnten. Es wird nicht einfach sein, nicht jeder Tag ist sonnig und angenehm, manchmal muss man hart arbeiten, aber wenn man anfängt zusammenzufassen, stellt sich heraus: Wow, das ist wirklich ein wunderbarer Ort, ich fühle mich gut, hier zu arbeiten, sowohl emotional als auch intellektuell. Und es gibt Unternehmen, in die Sie als Berater eintreten und sofort feststellen, dass Sie drei Monate lang nicht überlebt hätten und entsetzt davongelaufen wären. Darüber möchte ich in dem Bericht sprechen.

Tim Lister wird mit der Keynote "Charaktere, Gemeinschaft und Kultur: Wichtige Faktoren für den Wohlstand" auf der DevOops 2019-Konferenz ankommen, die vom 29. bis 30. Oktober 2019 in St. Petersburg stattfinden wird. Tickets können auf der offiziellen Website gekauft werden . Wir sehen uns bei DevOops!