ティム・リスター - 書籍の共著者

• "ヒューマンファクター。 成功するプロジェクトとチーム』 (原著の名前は「Peopleware」)
• 「クマとワルツを: ソフトウェア プロジェクトのリスク管理」
• 「アドレナリンに狂い、パターンによってゾンビ化。 プロジェクトチームの行動パターン」

これらの本はすべてその分野の古典であり、同僚と共同で書かれました。 アトランティック システム ギルド。 ロシアでは彼の同僚が最も有名だ。 トム・デマルコ и ピーター・フルシュカ、多くの有名な作品も書いています。

ティムはソフトウェア開発で 40 年の経験があり、1975 年には (このハブラポストを書いた人は誰も今年生まれではありません)、ティムはすでに Yourdon Inc. の執行副社長でした。 彼は現在、コンサルティング、教育、執筆に時間を費やしており、時折、 レポート付き 世界中のカンファレンス。

私たちは特にハブルのためにティム・リスターにインタビューをしました。 彼は DevOops 2019 カンファレンスのオープニングを務めることになっており、書籍などについてたくさんの質問があります。 インタビューは会議プログラム委員会のミハイル・ドルジニン氏とオレグ・チルヒン氏が担当した。

マイケル： あなたが今何をしているかについて一言いただけますか？

ティム: 私はアトランティック システム ギルドの代表です。 ギルドには私たちXNUMX人がいて、自分たちをプリンシパルと呼んでいます。 米国に XNUMX つ、ヨーロッパに XNUMX つ - それがギルドが大西洋と呼ばれる理由です。 私たちは数え切れないほど何年も一緒に過ごしてきました。 私たちは皆、自分の専門分野を持っています。 私は過去 XNUMX 年以上にわたってクライアントと仕事をしてきました。 私のプロジェクトには管理だけでなく、要件設定、プロジェクトの計画、評価も含まれます。 プロジェクトのスタートがうまくいかないと、たいていはうまくいかないようです。 したがって、すべての活動が本当によく考えられて調整され、作成者のアイデアが組み合わされていることを確認することが重要です。 自分が何をしているのか、なぜそうしているのかを考える価値があります。 プロジェクトを完了させるためにどのような戦略を使用するか。

私は長年にわたり、さまざまな方法でクライアントのカウンセリングを行ってきました。 興味深い例は、膝と股関節の手術用のロボットを製造している会社です。 外科医は完全に独立して手術するのではなく、ロボットを使用します。 率直に言って、ここでの安全性は重要です。 しかし、問題解決に重点を置いている人々と要件について話し合おうとすると...奇妙に聞こえるかもしれませんが、米国には次のようなものがあります。 FDA （連邦医薬品局）は、これらのロボットのような製品にライセンスを供与しています。 何かを販売したり、生きている人に使用したりする前に、ライセンスを取得する必要があります。 条件の XNUMX つは、要件、テストの内容、テスト方法、テスト結果を示すことです。 要件を変更する場合は、この膨大なテスト プロセス全体を何度も繰り返す必要があります。 私たちのクライアントは、アプリケーションのビジュアル デザインを要件に含めることに成功しました。 要件の一部としてスクリーンショットが直接含まれていました。 私たちはそれらを取り出して、これらすべてのプログラムはほとんどの場合、膝や腰、カメラに関するこれらすべてのことについて何も知らないことを説明する必要があります。 本当に重要な基礎的な条件が変わらない限り、要件文書が決して変更されないように要件文書を書き直す必要があります。 ビジュアルデザインが要件に含まれていない場合、製品の更新ははるかに速くなります。 私たちの仕事は、膝、腰、背中の手術に対応する要素を見つけ出し、それらを別の文書に取り出して、これらが基本的な要件であると宣言することです。 膝の手術に関する要件の独立したグループを作成してみましょう。 これにより、より安定した一連の要件を構築できるようになります。 特定のロボットについてではなく、製品ライン全体について説明します。

多くの作業が行われましたが、紙に書かれた要件がシステム構築の実際の要件と一致しなかったため、以前は何週間も何ヶ月も意味も必要もなく繰り返しテストを行っていたところまでたどり着きました。 FDA は毎回彼らに、「要件が変わったので、すべてを最初から確認する必要がある」と言いました。 製品全体の完全な再チェックは企業の命を奪っていました。

したがって、何か面白いことを始めようとしているときに、このような素晴らしいタスクがあり、最初のアクションがゲームのさらなるルールを設定します。 この初期の活動が管理面と技術面の両方でうまく機能し始めることを確認できれば、素晴らしいプロジェクトが完成する可能性があります。 しかし、この部分が軌道から外れてどこか間違った方向に進んでしまったり、基本的な合意を見つけることができなかったりすると…いいえ、プロジェクトが必ず失敗するというわけではありません。 しかし、「私たちはうまくいきました。すべてを本当に効果的に行いました。」とはもう言えなくなります。 これらは私がお客様とコミュニケーションをとるときに行っていることです。

マイケル： つまり、プロジェクトを立ち上げ、何らかのキックオフを行い、レールが正しい方向に進んでいることを確認しますか?

ティム: また、パズルのすべてのピースを組み立てる方法についてのアイデアもあります。どのようなスキルが必要か、正確にいつ必要になるか、チームの中核がどのようなものであるか、その他の基本的な事項です。 フルタイムの従業員が必要ですか、それともパートタイムの人を雇うことはできますか? 企画、運営。 次のような質問があります: この特定のプロジェクトにとって最も重要なことは何ですか? これを達成するにはどうすればよいでしょうか? この製品やプロジェクトについて私たちは何を知っていますか、リスクは何で、未知の部分はどこにあるのか、これらすべてにどのように対処するのでしょうか? もちろん、この瞬間に誰かが「アジャイルはどうなの?!」と叫び始めます。 さて、皆さんは柔軟ですが、それではどうでしょうか？ プロジェクトは具体的にどのようなもので、プロジェクトに適した方法でどのように取り出すつもりですか？ 「私たちのアプローチは何にでも対応します。私たちはスクラム チームです!」とだけ言うことはできません。 これはナンセンスでナンセンスです。 次にどこに行くのか、なぜそれが機能するのか、ポイントはどこにあるのか? 私はクライアントに、これらすべての質問について考えるように教えています。

19 年間のアジャイル

マイケル： アジャイルでは、人々は事前に何も定義せず、できるだけ遅く決定を下そうとし、「私たちは大きすぎるので、アーキテクチャ全体については考えません」と言うことがよくあります。 余計なことは考えず、今、お客様に役立つものをお届けします。

ティム: アジャイル手法は、以下から始まると思います。 アジャイルマニフェスト 2001 年に業界の注目を集めました。 しかしその一方で、完璧なものはありません。 私は反復的な開発に大賛成です。 ほとんどのプロジェクトでは、反復は非常に意味があります。 しかし、考えなければならないのは、製品が発売されて使用されたら、どれくらいの期間使用できるのかということです。 この製品は 1994 か月以内に他の製品に置き換えられるのでしょうか? それとも、これは何年も使い続ける製品なのでしょうか？ もちろん名前は出しませんが… ニューヨークとその金融界では、最も基本的なシステムが非常に古いものです。 これは素晴らしいです。 あなたはそれらを見て、2019 年にタイムスリップできたらと思い、開発者にこう言います。「私は未来から、XNUMX 年から来ました。 必要なだけこのシステムを開発してください。 拡張可能にし、アーキテクチャを検討します。 その後、XNUMX 年以上改良が加えられます。 開発をもう少し遅らせても、大局的には誰も気付かないでしょう！」 長期的に物事を見積もる場合は、トータルでどれくらいの費用がかかるかを考慮する必要があります。 うまく設計されたアーキテクチャには本当に価値がある場合もあれば、そうでない場合もあります。 私たちは周囲を見回して自問する必要があります。私たちはそのような決定を下すのに適切な状況にあるのでしょうか?

したがって、「私たちはアジャイルを支持しており、顧客自身が何を取得したいかを私たちに伝えるだろう」といった考えは非常に単純です。 顧客は自分が何を望んでいるのかすらわかっておらず、さらに何が得られるのかもわかりません。 議論として歴史的な例を引用し始める人もいますが、私はそれをすでに見てきました。 しかし、技術的に進んだ人は通常そんなことは言いません。 彼らはこう言います。「2019 年はこれが私たちに与えられたチャンスであり、これらのものに対する見方を完全に変えることができます。」 既存のソリューションを模倣して、もう少し美しく洗練されたものにするのではなく、時には「ここでやろうとしていることを完全に再発明しましょう!」と言う必要があります。

そして、ほとんどの顧客は問題をそのように考えることができないと思います。 彼らはすでに持っているものだけを見ます、それだけです。 その後、「もう少しシンプルにしましょう」など、いつも言うような要望が来ます。 しかし、私たちはウェイターやウェイトレスではないので、どんなに愚かな注文であっても、注文を受けてキッチンで焼きます。 私たちは彼らのガイドです。 私たちは彼らの目を開いて、「おい、ここには新しいチャンスがある！」と言わなければなりません。 貴社のビジネスのこの部分のやり方を私たちが本当に変えることができるということをご存知ですか? アジャイルの問題の XNUMX つは、何が機会なのか、何が問題なのか、何をする必要があるのか​​、この特定の状況に最適な利用可能なテクノロジは何か、という認識が失われることです。

おそらく私はここで懐疑的になりすぎていますが、アジャイル コミュニティでは素晴らしいことがたくさん起こっています。 しかし、人々がプロジェクトを定義する代わりに手を上げ始めるという事実に問題があります。 私はここで尋ねたいと思います - 私たちは何をしているのでしょうか、どのようにそれを行うつもりですか？ そしてどういうわけか魔法のように、クライアントは誰よりもよく知っているはずであることが常に判明します。 しかし、クライアントは、誰かがすでに構築したものの中から選択する場合にのみ、最もよく知っています。 車を購入したいと思っていて、家計の規模がわかっていれば、自分のライフスタイルに合った車をすぐに選ぶことができます。 ここでは私は誰よりもすべてを知っています！ ただし、すでに誰かが車を作っていることに注意してください。 私は専門家ではないので、新しい車を発明する方法がわかりません。 カスタム製品や特別な製品を作成するときは、お客様の声を考慮する必要がありますが、これが唯一の声ではなくなりました。

オレグ： アジャイルマニフェストについて言及しました。 この問題に対する現代の理解を考慮して、何らかの方法で更新または改訂する必要があるでしょうか?

ティム: 私は彼には触れません。 素晴らしい歴史的資料だと思います。 つまり、彼は彼そのものなのです。 彼はもう 19 歳になり、高齢ですが、当時、彼は革命を起こしました。 彼がうまくいったのは、彼が反応を引き起こし、人々が彼のことをささやき始めたことです。 おそらく、2001 年にはまだこの業界で働いていなかったでしょうが、当時は誰もがプロセスに従って働いていました。 Software Engineering Institute、ソフトウェア完全性モデル (CMMI) の XNUMX つのレベル。 このような古代の伝説が何かを物語っているかどうかはわかりませんが、それは画期的な出来事でした。 当初、人々はプロセスが正しく設定されていれば問題は自然に解決すると信じていました。 そしてマニフェストが登場し、こう述べています。「いいえ、いいえ、いいえ、私たちはプロセスではなく人に基づいていきます。」 私たちはソフトウェア開発の達人です。 私たちは、理想的なプロセスは蜃気楼であることを理解していますが、それは起こりません。 プロジェクトには特異性が多すぎるため、すべてのプロジェクトに単一の完璧なプロセスを適用するという考えは意味がありません。 すべてに対する解決策が XNUMX つしかないと主張するには、問題はあまりにも複雑です (こんにちは、涅槃)。

将来のことを考えるつもりはありませんが、人々は今、プロジェクトについてもっと考え始めていると言いたいと思います。 アジャイルマニフェストは、飛び出して「おい！」と言うのがとても上手だと思います。 あなたは船に乗っており、あなた自身がこの船を運転しています。 決定を下す必要があります。すべての状況に対応する普遍的なレシピを提案するわけではありません。 あなたは船の乗組員であり、十分な能力を持っていれば、目標に到達する方法を見つけることができます。 あなたの前にも他の船があり、あなたの後にも他の船が現れるでしょう。しかし、それでも、ある意味、あなたの旅はユニークです。」 そんな感じ！ それは考え方です。 私にとって、太陽の下に新しいものは何もありません。人々は以前にも航海しましたし、また航海するでしょう。しかし、あなたにとってはこれがあなたの主要な旅であり、私はあなたに正確に何が起こるかはあなたに言いません。 チーム内で調整して仕事をするスキルが必要です。それを本当に持っていれば、すべてがうまくいき、望んでいた場所に到達できるでしょう。

ピープルウェア: 30 年後

オレグ： Peopleware はマニフェストと同様に革命でしたか?

ティム: Peopleware...トムと私はこの本を書きましたが、こんなことになるとは思っていませんでした。 どういうわけか、それは多くの人々の考えに共鳴しました。 これは、ソフトウェア開発は非常に人間集約的な活動であると述べた最初の本です。 私たちの技術的な性質にもかかわらず、私たちは大きなもの、さらには巨大で非常に複雑なものを構築する人々のコミュニティでもあります。 そんなものは一人では作れませんよね？ そこで「チーム」という考え方が非常に重要になりました。 そして、管理の観点からだけでなく、未知の部分がたくさんある本当に複雑で深い問題を解決するために集まった技術者にとっても同様です。 私個人にとって、これは私のキャリアを通じて知性を試す大きなテストでした。 そして、ここであなたはこう言える必要があります。「はい、この問題は私一人では対処できない問題ですが、私たちは一緒に誇りに思える洗練された解決策を見つけることができます。」 そして、最も共感を呼んだのはこのアイデアだったと思います。 私たちは、ある時間は自分たちで働き、ある時間はグループの一員として働き、多くの場合、決定はグループによって行われるという考えです。 グループでの問題解決は、急速に複雑なプロジェクトの重要な機能になりました。

ティムは膨大な数の講演を行っているにもかかわらず、YouTube に投稿されている講演はほとんどありません。 2007 年のレポート「The Return of Peopleware」をご覧ください。 もちろん、品質にはまだまだ改善の余地があります。

マイケル： この本が出版されてから30年間で何か変化はありましたか？

ティム: これをさまざまな角度から見ることができます。 社会学的に言えば...昔々、もっと単純な時代に、あなたとあなたのチームは同じオフィスに座っていました。 毎日近くにいて、一緒にコーヒーを飲みながら仕事について話し合うこともできます。 本当に変わったのは、チームが地理的に、異なる国やタイムゾーンに分散できるようになったにもかかわらず、依然として同じ問題に取り組んでおり、これによりまったく新しい複雑さが加わったことです。 時代遅れに聞こえるかもしれませんが、全員が一緒にいて一緒に仕事をしながら、同僚に歩み寄って「私が発見したことを見て、これはどうですか？」と言える対面でのコミュニケーションほど優れたものはありません。 対面での会話は、非公式なコミュニケーションにすぐに移行できる方法であり、アジャイル愛好家にも気に入っていただけると思います。 また、現実には世界が非常に小さくなってしまい、今ではすべてが分散したチームでカバーされており、すべてが非常に複雑になっているため、私も心配しています。

私たちは皆 DevOps の中で生きています

マイケル： 会議プログラム委員会の観点から見ても、カリフォルニア、ニューヨーク、ヨーロッパ、ロシアに人がいます...シンガポールにはまだ誰もいません。 地理的な違いはかなり大きく、人々はさらに分散し始めています。 開発について話しているのであれば、devops とチーム間の障壁の打破について詳しく教えていただけますか? 誰もがバンカーに座っていて、今そのバンカーが崩壊しつつあるという概念がありますが、このたとえについてどう思いますか?

ティム: 最近のテクノロジーの進歩を考慮すると、devops は非常に重要であるように思えます。 以前は、開発者と管理者のチームがあり、彼らは働いて、働いて、働いていましたが、ある時点で、管理者に相談して本番環境に展開できるものが登場しました。 そして、ここでバンカーについての会話が始まりました。管理者は少なくとも敵ではなく味方のようなものですが、管理者と話したのは、すべてが本番環境に移行する準備ができたときだけでした。 あなたは何かを持って彼らのところへ行って、「私たちが持っているアプリケーションを見てください。しかし、このアプリケーションを展開してもらえませんか?」と言いましたか? そして今、配送の概念全体が良い方向に変わりました。 つまり、変更を迅速に推進できるという考えがありました。 製品をその場で更新できます。 ラップトップ上の Firefox がポップアップして、「バックグラウンドで Firefox を更新しました。少しお時間がありましたら、ここをクリックしていただけますか。最新リリースをお届けします」と表示されると、私はいつも笑顔になります。 そして私は「ああ、そうだね、ベイビー！」と思いました。 私が寝ている間に、彼らは私のコンピューターに新しいリリースを配信する作業をしていました。 これは素晴らしい、信じられないほどです。

しかし、ここに問題があります。ソフトウェアの更新にはこの機能がありますが、人々を統合することははるかに困難です。 DevOops の基調講演で私が声を大にして言いたいのは、今ではかつてないほど多くのプレーヤーがいるということです。 たった XNUMX つのチームに関わる全員のことを考えてみると…。 あなたはそれをチームとして考えましたが、それは単なるプログラマーのチームではありません。 これらはテスター、プロジェクト マネージャー、その他大勢の人々です。 そして誰もが自分の世界観を持っています。 プロダクトマネージャーはプロジェクトマネージャーとは全く異なります。 管理者には独自のタスクがあります。 何が起こっているのかを常に認識し、混乱しないように参加者全員を調整するのは、かなり難しい問題になります。 グループのタスクと全員に適用されるタスクを分離する必要があります。 これは非常に難しい作業です。 その一方で、何年も前に比べればすべてがはるかに良くなっていると思います。 これはまさに、人々が成長し、正しい行動を学ぶための道です。 統合を行うときは、地下開発があってはいけないことを理解するので、最後の瞬間にソフトウェアがびっくり箱のように出てくることはありません。 統合と開発が可能になり、最終的にはきちんとした反復的な方法で展開できるようになるという考えです。 これらすべてが私にとって大きな意味を持ちます。 これにより、システムのユーザーとクライアントにとってより多くの価値を生み出すことが可能になります。

マイケル： Devops の全体的な考え方は、有意義な開発をできるだけ早く提供することです。 世界がますますスピードアップし始めていることがわかります。 このような加速にどのように適応すればよいでしょうか? XNUMX年前にはこんなものは存在しませんでした！

ティム: もちろん、誰もがより多くの機能を望んでいます。 移動する必要はなく、ただ積み上げていくだけです。 場合によっては、何か有益なものを提供するために、次の増分更新まで速度を落とす必要があることさえありますが、それはまったく正常なことです。

走って、走って、走らなければならないという考えは最善ではありません。 そんな人生を送りたい人はいないでしょう。 納品のリズムがプロジェクト自身のリズムを決めるようにしたいと思っています。 小さくて比較的意味のないものを次々と生み出すだけでは、すべてが無意味になってしまいます。 何も考えずにできるだけ早くリリースしようとするのではなく、主任開発者や製品およびプロジェクトのマネージャーと話し合う価値があるのは戦略です。 これにも意味があるのでしょうか？

パターンとアンチパターン

オレグ： あなたはよくパターンとアンチパターンについて話しますが、これがプロジェクトの生死を分けるものです。 そして今、devops が私たちの生活に突入しています。 プロジェクトをその場で中止する可能性がある独自のパターンやアンチパターンはありますか?

ティム: パターンとアンチパターンは常に発生します。 話すこと。 そうですね、「光るもの」と呼ばれるものがあります。 人々は新しいテクノロジーが本当に大好きです。 彼らは、クールでスタイリッシュに見えるすべてのものの輝きにただ魅了され、質問するのをやめます。「それは必要ですか？」 私たちは何を達成するのでしょうか? これは信頼できるものですか、意味はありますか? いわばテクノロジーの最先端にいる人たちをよく見かけます。 彼らは世界で起こっていることに催眠術をかけられています。 しかし、それらがどのような役に立つのかを詳しく見てみると、多くの場合、まったく役に立たないことがわかります。

私たちはちょうど仲間たちと、今年は人類が月面に着陸してから1969周年という記念の年であることについて話し合っていたところでした。 これは 1969 年のことでした。人々がそこに到達するのに役立ったテクノロジーは 1960 年のテクノロジーではなく、むしろ 62 年または XNUMX 年のテクノロジーです。NASA は信頼性の十分な証拠があるもののみを使用したかったからです。 それで、あなたはそれを見て理解します - はい、そしてそれらは真実でした！ いや、いや、でも、テクノロジーの問題に巻き込まれるのは、単にすべてが無理をして売り込まれすぎているからです。 人々はどこからでもこう叫んでいます。「ほら、なんてことだ、これは世界で一番新しいもので、最も美しいもので、絶対に誰にでも適しているんだ！」 まあ、それだけです...通常、これはすべて単なるおとりであることが判明し、その後はすべて捨てなければなりません。 おそらくそれは、私がすでに老人であり、人々が駆け出し、最高のテクノロジーを生み出すための唯一で最も正しい方法を見つけたと言うのを、多大な懐疑的な目で見ているからかもしれません。 この瞬間、私の中で「なんてひどいことだ！」という声が目覚めます。

マイケル： 実際、私たちは次の特効薬についてどれだけ聞いたことがあるでしょうか。

ティム: まさにその通り、これがいつもの成り行きです！ 例えば…これはもう世界中でジョークになっているようですが、こちらではブロックチェーン技術の話がよく出ます。 そして、特定の状況では実際に意味をなすのです。 イベントの信頼できる証拠が本当に必要な場合、システムが機能し、誰も私たちを騙していないことを証明する必要がある場合、セキュリティ上の問題などが混在している場合、ブロックチェーンは理にかなっています。 しかし、ブロックチェーンが今や世界中を席巻し、その進路にあるすべてのものを一掃するだろうと彼らが言うとき、どうなるでしょうか？ もっと夢を見てください！ これは非常に高価で複雑な技術です。 技術的に複雑で時間がかかります。 純粋にアルゴリズム的に、わずかな変更を加えて数学を再計算する必要があるたびに…これは素晴らしいアイデアですが、特定の場合に限ります。 私の人生とキャリアはすべて、非常に特殊な状況における興味深いアイデアです。 自分の状況を正確に理解することが非常に重要です。

マイケル： そうです、主要な「生命、宇宙、そしてすべてに関する問題」は、このテクノロジーまたはアプローチがあなたの状況に適しているかどうかです。

ティム: この質問については、すでにテクノロジー グループと話し合うことができます。 もしかしたらコンサルタントを連れてくるかもしれません。 プロジェクトを見て理解してください - これからは、以前よりも優れた、正しくて役立つ何かを行うことができるでしょうか? 合うかもしれないし、合わないかもしれない。 しかし、最も重要なことは、誰かが「ブロックチェーンがどうしても必要だ！」と口走ったからといって、デフォルトでそのような決定を下さないことです。 飛行機の中で雑誌で彼のことを読んだところです！」 真剣に？ 面白くもありません。

神話上の「DevOps エンジニア」

オレグ： 今では誰もが DevOps を実装しています。 誰かがインターネットで Devops について読んで、明日には求人サイトに別の求人が表示されます。 「開発エンジニア」。 ここで注目していただきたいのですが、「devops エンジニア」という言葉に生きる権利があると思いますか? Devops は文化であるという意見がありますが、ここでは何かが腑に落ちません。

ティム: まあまあ。 それからすぐにこの用語について説明してもらいます。 ユニークなものにするための何か。 このような欠員の背後には、独自のスキルの組み合わせがあることが証明されるまで、私はその求人を購入しません。 つまり、「devops エンジニア」という興味深い肩書きがあります。はい、次は何でしょうか? 役職は一般的に非常に興味深いものです。 「開発者」としましょう。そもそも、それは何でしょうか? 組織が異なれば、意味もまったく異なります。 一部の企業では、高品質のプログラマーが、他の企業の特別なプロのテスターが作成するテストよりも意味のあるテストを作成します。 それで、彼らは今プログラマーなのか、それともテスターなのか？

はい、私たちには役職がありますが、十分に長く質問すると、最終的には私たち全員が問題解決者であることがわかります。 私たちは解決策を求める者であり、いくつかの技術的スキルを持っている人もいれば、異なるスキルを持っている人もいます。 DevOps が浸透した環境に住んでいる場合は、開発と管理の統合に取り組んでいることになりますが、この活動にはかなり重要な目的があります。 しかし、あなたが具体的に何をしているのか、そしてあなたに責任があるのか​​と問われれば、人々は太古の昔からこれらすべてのことを行ってきたことがわかります。 「私はアーキテクチャの責任者です」、「私はデータベースの責任者です」など、何でもわかりますが、これはすべて「devops」以前のことです。

誰かが自分の役職を話したとき、私はあまり聞きません。 彼に実際の責任を語ってもらうほうがよいでしょう。そうすることで、問題をより深く理解できるようになります。 私のお気に入りの例は、ある人が自分を「プロジェクト マネージャー」だと主張する場合です。 何？ それは何の意味もありません、私はまだあなたが何をしているのか分かりません。 プロジェクト マネージャーは、開発者であり、コードを書き、作業を行う XNUMX 人のチームのリーダーであり、チーム リーダーになり、人々自身がリーダーとして認識している人です。 また、プロジェクト マネージャーは、プロジェクトに参加する XNUMX 人のメンバーを管理し、他のマネージャーを管理し、スケジュールを作成し、予算を計画する責任を負うマネージャーになることもできます。 これらは XNUMX つのまったく異なる世界です。 しかし、彼らの役職名は同じに聞こえます。

これを少し違う方向に変えてみましょう。 あなたは本当に得意なこと、豊富な経験、才能は何ですか？ あなたはその仕事をこなせると思っているので、何に対して責任を負いますか？ そして、ここで誰かがすぐに否定し始めます。「いいえ、いいえ、いいえ、私はプロジェクトリソースを扱うつもりはまったくありません、それは私の仕事ではありません、私は技術者であり、使いやすさとユーザーインターフェイスを理解しています、私は知りません」とにかく大勢の人々を管理したいのなら、仕事に行かせてください。

ちなみに、私はこの種のスキルの分離がうまく機能するアプローチの大支持者です。 技術者が望む限りキャリアを伸ばすことができる場所。 しかし、技術者が「この会社ではプロジェクト管理しか道がないので、私はプロジェクト管理をしなければならない」と不満を漏らす組織を今でも見かけます。 場合によっては、これがひどい結果を招くこともあります。 最高の技術者は決して優れたマネージャーではありませんし、最高のマネージャーはテクノロジーを扱うことができません。 これについては正直に話しましょう。

今、これに対する需要がたくさんあると思います。 あなたが技術者であれば、会社があなたを助けてくれるかもしれませんが、テクノロジーは常に変化しており、それに合わせて自分自身を再発明する必要があるため、自分自身のキャリアパスを見つける必要があります。 わずか XNUMX 年の間に、テクノロジーは少なくとも XNUMX 回は変化する可能性があります。 テクノロジーって不思議なものですね…

「あらゆる分野の専門家」

マイケル： 人々はこのようなテクノロジーの変化のスピードにどうやって対処できるのでしょうか? その複雑さ、その数は増加しており、人々の間のコミュニケーションの総量も増加していますが、「すべての専門家」になることはできないことがわかっています。

ティム: 右！ テクノロジーの分野で働いている場合は、確かに何か特定のものを選択し、それを掘り下げる必要があります。 あなたの組織が有用であると考える (そしておそらく実際に役立つであろう) テクノロジー。 そして、もしあなたがそのテクノロジーにもう興味がなくなったのであれば、私がこんなことを言うとは信じられなかったでしょうが、そのテクノロジーがもっと興味深く、あるいは研究するのに便利な他の組織に移るべきかもしれません。

しかし、一般的には、そうです、あなたの言うことは正しいのです。 テクノロジーはあらゆる方向に同時に進歩しており、「私は存在するすべてのテクノロジーの専門技術者です」と言える人はいません。 一方で、文字通りテクノロジーの知識を吸収し、それに夢中になるスポンジのような人々もいます。 私はそのような人たちを何人か見てきましたが、彼らは文字通り呼吸して生きており、彼らと話すのは有益で興味深いものです。 彼らは組織内で何が起こっているかを研究するだけでなく、一般的にそれについて話し、非常にクールな技術者でもあり、非常に意識的で目的意識が高いです。 彼らは、本業が何であれ、ただ波の頂点に留まろうとするだけです。なぜなら、彼らの情熱はテクノロジーの動き、テクノロジーの推進だからです。 突然そのような人に出会ったら、一緒にランチに行き、ランチを食べながらさまざまな面白いことについて話し合うべきです。 どのような組織にも少なくとも XNUMX 人はそのような人材が必要だと思います。

リスクと不確実性

マイケル： 名誉あるエンジニアの皆様、そうです。 時間があるうちにリスク管理について触れておきましょう。 このインタビューは、エラーが悲惨な結果を招く可能性がある医療ソフトウェアについての議論から始まりました。 それから、私たちは月計画について話しました。そこでは、エラーの代償は数百万ドルであり、おそらく数人の命が犠牲になります。 しかし今、業界では逆の動きが見られます。人々はリスクについて考えず、予測しようとせず、観察すらしません。

オレグ： 速く動いて物を壊しましょう！

マイケル： そう、速く動いて、何かで死ぬまで、どんどん物を壊してください。 あなたの観点から見ると、平均的な開発者は今、リスク管理を学ぶためにどのようにアプローチすべきでしょうか?

ティム: ここで、リスクと不確実性という XNUMX つのものの間に線を引いてみましょう。 これらは別のものです。 不確実性は、特定の時点で最終的な答えに到達するのに十分なデータがない場合に発生します。 たとえば、プロジェクトの非常に初期の段階で、誰かが「いつ仕事を終えるのですか」と尋ねた場合、かなり正直な人であれば、「わかりません」と答えるでしょう。 あなたが知らないだけで大丈夫です。 あなたはまだ問題を勉強しておらず、チームに慣れていない、チームのスキルも知らない、などです。 これは不確実性です。

潜在的な問題がすでに特定されている場合、リスクが発生します。 このようなことは起こり得ますが、その確率はゼロより大きく XNUMX パーセント未満、またはその中間です。 そのため、遅延や不必要な作業だけでなく、プロジェクトにとって致命的な結果に至るまで、あらゆることが起こる可能性があります。 結果は、あなたが「みんな、傘をたたんでビーチから出ましょう、決して終わらせることはできない、すべてが終わった」と言ったときの結果です。 私たちはこれがうまくいくだろうと仮定していましたが、まったくうまくいきませんでした。もうやめるべき時が来ました。 これらの状況です。

多くの場合、問題はすでに顕在化しているとき、つまり問題が現在発生しているときに解決するのが最も簡単です。 しかし、問題が目の前にあるとき、あなたはリスク管理をしているのではなく、問題解決、危機管理をしているのです。 あなたが主任開発者またはマネージャーであれば、遅延、時間の無駄、不必要なコスト、またはプロジェクト全体の崩壊につながる可能性があることに疑問を抱いているはずです。 何が私たちを立ち止まらせ、やり直すのでしょうか？ これらすべてが機能したら、私たちはそれらをどうするでしょうか? ほとんどの状況に有効な単純な答えがあります。それは、リスクから逃げるのではなく、リスクに取り組むことです。 危険な状況をどのように解決し、無に帰し、問題を別の問題に変えることができるかを見てみましょう。 「そうですね、問題が発生したときに解決します」と言う代わりに。

不確実性とリスクは、あなたが扱うすべてのものの最前線にあるべきです。 プロジェクト計画を作成し、事前に特定の重大なリスクを検討して、「これに今すぐ対処する必要があります。これのどれかがうまくいかなかった場合、他に問題がなくなるからです。」と言うことができます。 夕食を作ることができるかどうか不明な場合は、テーブルのテーブルクロスの美しさを心配する必要はありません。 まず、おいしいディナーを準備する際のすべてのリスクを特定し、それに対処してから、実際の脅威にならない他のすべてのことについて考える必要があります。

繰り返しになりますが、あなたのプロジェクトをユニークなものにしているのは何ですか? 何がプロジェクトを軌道から外してしまうのか見てみましょう。 このようなことが起こる可能性を最小限に抑えるために何ができるでしょうか? 通常、それらを 100% 無力化して、明確な良心をもって「以上です。これはもう問題ではありません。リスクは解決しました。」と宣言することはできません。 私にとって、これは大人の行動の表れです。 これが子供と大人の違いです。子供たちは自分たちは不滅で、何も問題は起こらず、すべてうまくいくと考えています。 同時に、大人たちは XNUMX 歳児が遊び場で飛び跳ねる様子を観察し、その動きを目で追い、「おお、おお、おお」と心の中で言います。 私は近くに立って、子供が落ちたときにすぐに受け止められるようにしています。

一方で、私がこのビジネスをとても好きな理由は、リスクがあるからです。 私たちは何かをしていますが、それらのことにはリスクが伴います。 大人の対応が必要です。 熱意だけでは問題は解決しません。

大人の工学的思考

マイケル： 子供たちの例は良いですね。 私が普通の技術者であれば、子供でよかったと思います。 しかし、どうすればより大人の考え方に移行できるでしょうか?

ティム: 初心者でも熟練した開発者でも同様にうまく機能するアイデアの XNUMX つは、コンテキストの概念です。 私たちが何をしているのか、何を達成しようとしているのか。 このプロジェクトで本当に重要なことは何ですか? あなたがこのプロジェクトに誰であるか、インターンであるかチーフアーキテクトであるかは関係なく、誰もがコンテキストを必要としています。 全員に自分の作品よりも大きなスケールで考えてもらう必要があります。 「私は自分の作品を作り、自分の作品が機能する限り、私は幸せです。」 いいえ、またいいえ。 人々に、彼らが働いている状況を思い出させることは常に価値があります (失礼ではありません!)。 私たち全員が一緒に達成しようとしていること。 自分のプロジェクトに問題がなければ、子どもでいられるという考えはやめてください。 ゴールラインを越えるとしても、一緒にゴールラインを越えるだけです。 あなたは一人ではありません、私たちは皆一緒です。 プロジェクトに参加する老若男女全員が、プロジェクトにとって正確に何が重要なのか、なぜ私たち全員が達成しようとしていることに会社が資金を投資するのかについて話し始めたら...彼らのほとんどはずっと気分が良くなるでしょう。自分の仕事が他の人の仕事とどのように相関しているかがわかります。 一方で、私は自分が個人的に担当する作品を理解しています。 しかし、仕事を終えるには他の人たちも必要です。 本当に終わったと思っているのなら、私たちにはプロジェクトでやるべき仕事が常にあります。

オレグ： 比較的に言うと、カンバンに従って作業すると、テストでボトルネックに遭遇したときに、そこでやっていた作業 (プログラミングなど) をやめてテスターを助けに行くことができます。

ティム: その通り。 最高の技術者は、よく見てみると、自分のマネージャーのようなものだと思います。 これをどのように定式化すればよいでしょうか...

オレグ： あなたの人生はあなたのプロジェクトであり、それを管理するのはあなたです。

ティム: その通り！ つまり、あなたは責任を負い、問題を理解し、自分の決定が彼らの仕事に影響を与える可能性があることを知ったときに人々と接触する、といったようなことです。 それは、ただ机に座って仕事をしているだけで、周囲で何が起こっているのかさえ気づかないということではありません。 ダメダメダメ。 ところで、アジャイルの最も優れた点の XNUMX つは、短いスプリントを提案したことです。これにより、参加者全員の状況が明確に観察でき、全員で確認できるからです。 私たちは毎日お互いのことについて話します。

リスク管理に取り組む方法

オレグ： この分野には正式な知識構造はありますか? たとえば、私は Java 開発者ですが、教育を受けて本物のプロジェクト マネージャーになることなく、リスク管理を理解したいと考えています。 おそらく最初に McConnell の「ソフトウェア プロジェクトのコストはいくらですか」を読んで、その後はどうなるでしょうか? 最初のステップは何ですか?

ティム: XNUMX つ目は、プロジェクト内の人々とコミュニケーションを開始することです。 これにより、同僚とのコミュニケーション文化が即座に改善されます。 すべてを隠すのではなく、デフォルトですべてを開くことから始める必要があります。 言ってください：これらは私を悩ませているものです、これらは私を夜眠れなくさせるものです、私は今日夜に目が覚めてこう思いました：ああ、これについて考えなければなりません！ 他の人も同じものを見ていますか? グループとして、これらの潜在的な問題に対応すべきでしょうか? これらのトピックに関するディスカッションをサポートできる必要があります。 私たちが取り組むためにあらかじめ用意された公式はありません。 ハンバーガーを作ることではなく、すべては人です。 「チーズバーガーを作って、チーズバーガーを売る」というのは私たちの仕事ではありません。だからこそ、私はこの仕事が大好きです。 私は、マネージャーが以前行っていたすべてのことがチームの財産になるのが好きです。

オレグ： あなたは本やインタビューで、人々はグラフの数字よりも幸福をどのように気にしているかについて話しています。 一方で、チームに「私たちは DevOps に移行しており、プログラマーは常にコミュニケーションを取る必要がある」と伝えると、これは彼の快適ゾーンから大きく外れている可能性があります。 そして現時点では、彼はひどく不幸になっているかもしれません。 この状況ではどうすればよいでしょうか?

ティム: 具体的に何をすればいいのか分かりません。 開発者が孤立しすぎている場合、そもそもなぜその作業が行われているのかが分からず、作業の自分の部分だけを見て、私が「コンテキスト」と呼ぶものに入る必要があります。 彼はすべてがどのようにつながっているのかを理解する必要があります。 もちろん、正式なプレゼンテーションなどの意味ではありません。 私が話しているのは、自分が責任を負っている部分だけではなく、仕事全体について同僚とコミュニケーションをとる必要があるという事実についてです。 ここで、アイデア、仕事をうまく組み合わせるための共通の合意、共通の問題に一緒に取り組む方法について話し合うことができます。

彼らが適応できるようにするために、彼らは技術者をトレーニングに派遣したいと考えており、トレーニングについて話し合っています。 私の友人は、「トレーニングは犬のためにある」とよく言います。 人向けの研修もあります。 開発者としての学習で最も優れていることの XNUMX つは、同僚と交流することです。 誰かが何かに本当に優れている場合は、その人の仕事を見たり、仕事などについて話したりする必要があります。 従来のケント・ベックの中には、エクストリーム・プログラミングについて常に話していた人もいました。 XP は非常に単純なアイデアですが、非常に多くの問題を引き起こすので、面白いことです。 一部の人にとって、XP を行うことは、友人の前で裸になることを強制されるようなものです。 彼らは私が何をしているかを見るでしょう！ 彼らは私の同僚であり、見るだけでなく理解するでしょう。 ひどい！ かなり緊張し始めている人もいます。 しかし、これが究極の学習方法であると理解すると、すべてが変わります。 あなたは人々と緊密に連携しており、中にはあなたよりもそのトピックについてよく理解している人もいます。

マイケル： しかし、これらすべてがあなたに快適ゾーンから抜け出すことを強います。 エンジニアとして、自分の快適ゾーンから抜け出してコミュニケーションを図る必要があります。 問題解決者として、常に自分を弱い立場に置き、何が問題になるかを考えなければなりません。 この種の作業は本質的に迷惑になるように設計されています。 あなたは意識的にストレスの多い状況に自分自身を置きます。 通常、人々は彼らから逃げます、人々は幸せな子供でいることを好みます。

ティム: 何ができるかというと、堂々とこう言うことです。 不快に感じているのは私だけではありません。 いろいろな不快なことをチームでみんなで話し合いましょう！」 これらは私たちに共通の問題であり、私たちはそれに対処しなければなりません。 特異な天才開発者はマンモスのような存在で、消えてしまったのだと思います。 そしてその重要性は非常に限られています。 コミュニケーションが取れないとうまく参加できません。 したがって、ただ話してください。 正直でオープンであれ。 誰かにとって不愉快な思いをさせてしまい、大変申し訳ございません。 何年も前に、米国における主な恐怖は死ではないという研究があったことを想像できますか。 人前で話すのが怖い！ これは、大声で褒め言葉を言うくらいなら死んだ方がマシだという人がどこかにいるということだ。 何をするかにもよりますが、基本的なスキルがあれば十分だと思います。 スピーキングスキル、ライティングスキル - ただし、仕事で本当に必要なスキルのみです。 アナリストとして働いていても、読み書きも話すこともできない場合は、残念ながら、私のプロジェクトに参加することはできません。

通信の値段

オレグ： このような社交的な従業員を雇用すると、さまざまな理由からコストが高くなるのではありませんか? 結局のところ、彼らは仕事をする代わりに、常におしゃべりをしているのです。

ティム: 私が言ったのはチームの中心人物であり、全員だけではありませんでした。 データベースのチューニングが本当に得意で、データベースのチューニングが大好きで、データベースのチューニングを一生続けるつもりで、それで終わりという人がいるなら、それはそれでいいでしょう、それを続けてください。 しかし、私が話しているのは、プロジェクト自体に参加したいと考えている人々のことです。 プロジェクトの開発を目的としたチームの中核。 これらの人々は常に互いにコミュニケーションをとる必要があります。 特にプロジェクトの開始時に、リスクや世界的な目標を達成する方法などについて話し合うとき。

マイケル： これは、専門分野、スキル、働き方に関係なく、プロジェクトに関わるすべての人に当てはまります。 皆さんはプロジェクトの成功に興味を持っています。

ティム: はい、あなたはプロジェクトに十分に没頭しており、自分の任務はプロジェクトの実現を支援することであると感じています。 プログラマー、アナリスト、インターフェイスデザイナーなど、誰でも構いません。 これが私が毎朝仕事に行く理由であり、これが私たちが行っていることです。 私たちは、スキルに関係なく、これらすべての人々に対して責任を負います。 大人の会話をする人々のグループです。

オレグ： 実際、おしゃべりな従業員について言えば、このまったく新しい世界のビジョンに対する人々、特に DevOps への切り替えを求められているマネージャーの反対をシミュレートしようとしました。 そして、コンサルタントである皆さんは、開発者である私よりもこうした反対​​意見をよく認識しているはずです。 マネージャーが最も心配していることを共有してください。

ティム: マネージャー？ うーん。 ほとんどの場合、マネージャーは問題によるプレッシャーにさらされ、何かを緊急にリリースして納品する必要などに直面しています。 彼らは、私たちが常に何かについて話し合い、議論している様子を観察しており、それを次のように見ています。会話、会話、会話...他にどんな会話があるでしょうか？ 仕事に戻る！ なぜなら、彼らにとって話すことは仕事とは思えないからです。 あなたはコードを書かず、ソフトウェアをテストせず、何もしていないようです。なぜあなたを何かをさせるために派遣してはいけないのでしょうか? 結局、納期はもうXNUMXヶ月後です！

マイケル： コードを書いてみましょう!

ティム: 彼らは仕事のことを心配しているのではなく、進捗が見えないことを心配しているように私には思えます。 私たちが成功に近づいているように見せるには、私たちがキーボードのボタンを押しているのを彼らに見せる必要があります。 朝から夕方まで一日中。 これがXNUMX番の問題です。

オレグ： ミーシャ、何か考えているのね。

マイケル： ごめんなさい、考え込んでフラッシュバックしてしまいました。 これらすべてを聞いて、昨日起こった興味深い集会を思い出しました...昨日は集会が多すぎました...そしてそれはすべて非常に見覚えのあるものに聞こえます!

給料のない生活

ティム: ちなみに、コミュニケーションのために「集会」を組織する必要はまったくありません。 つまり、開発者間で最も有益なディスカッションは、単にお互いに話し合うときに行われます。 朝、コーヒーを飲みながら店に入ると、XNUMX人が集まって技術的なことについて熱心に議論しています。 私にとって、もし私がこのプロジェクトのマネージャーなら、ただ笑って、自分のビジネスについてどこかに行き、彼らにそれについて話し合ってもらう方が良いでしょう。 彼らはすでに可能な限り関与しています。 これは良い兆候です。

オレグ： ところで、あなたの本の中に、何が良くて何が悪かったのかについてのメモがたくさんあります。 あなた自身もそれらのどれかを使用していますか？ 比較的に言うと、今あなたは会社を持っていますが、その会社は非常に型破りな方法で組織されています...

ティム: 型破りですが、このデバイスは私たちにぴったりです。 私たちは長い間お互いを知っています。 私たちはお互いを信頼しており、パートナーになる前からお互いをとても信頼していました。 そして例えば、私たちには給料がまったくありません。 私たちはただ働いているだけで、たとえば、私が顧客からお金を稼いだ場合、そのお金はすべて私に流れます。 その後、団体に会費を支払い、それが会社自体を支えるのに十分な金額となります。 さらに、私たちは皆、さまざまなことを専門としています。 たとえば、私は会計士と協力し、納税申告書を記入し、会社のためにあらゆる種類の管理業務を行っていますが、誰も私にその費用を払ってくれません。 ジェームスとトムは私たちのウェブサイトで働いていますが、誰も彼らにお金を払っていません。 あなたが会費を払っている限り、誰もあなたに何をしなければならないかを教えようとは思わないでしょう。 たとえば、トムは今、以前よりもはるかに仕事を減らしています。 現在、彼は他のことに興味を持っており、ギルドのためではないこともいくつか行っています。 しかし、彼が会費を払っている限り、誰も彼のところに来て「おい、トム、仕事に行け！」とは言わないだろう。 お金がない場合、同僚とやり取りするのは非常に簡単です。 そして今、私たちの関係は、さまざまな専門分野に関連する基本的な考え方のXNUMXつです。 それはうまくいきます、そしてそれは非常にうまくいきます。

最高のアドバイス

マイケル： 「最善のアドバイス」の話に戻りますが、クライアントに繰り返し伝えていることはありますか? 80/20 についての考えがあり、いくつかのアドバイスはおそらくより頻繁に繰り返されます。

ティム: もしあなたが「クマとワルツをする」のような本を書いたら、歴史の流れが変わり、人々は立ち止まるだろう、と思ったこともありますが... そうですね、企業はよく、自分たちにはすべて問題がないふりをします。 何か悪いことが起こるとすぐに、彼らはショックを受け、驚きます。 「システムをテストしましたが、どのシステム テストにも合格しませんでした。さらに XNUMX か月間予定外の作業が続くのに、どうしてこんなことが起こるのでしょうか? 誰かわかったね？ 何が問題になる可能性がありますか? 真剣に、これを信じますか？

現在の状況についてあまり怒るべきではない、と私は説明しようとしています。 私たちは話し合い、何がうまくいかなかったのか、そして今後そのようなことが起こらないようにする方法を本当に理解する必要があります。 問題が発生した場合、どのように対処し、どのように封じ込めるのでしょうか?

私にとって、これはすべて恐ろしいことのように思えます。 人々は複雑で厄介な問題に対処し、ただ黙って最善を願えば「最善」のことが実際に起こるかのようにふり続けます。 いいえ、そのようには機能しません。

リスクマネジメントを実践しましょう！

マイケル： リスク管理に取り組んでいる組織は何社あると思いますか?

ティム: 私が腹立たしいのは、人々が単にリスクを書き留め、その結果のリストを見て仕事に取り掛かるということです。 実際、彼らにとってのリスクを特定することはリスク管理です。 しかし私には、これはこう尋ねる理由のように思えます。「わかりました。リストはありますが、具体的に何を変更しますか?」 これらのリスクを考慮して、標準的な一連のアクションを変更する必要があります。 仕事の中で最も難しい部分がある場合は、それに取り組んでから、より簡単な作業に移る必要があります。 最初のスプリントでは、複雑な問題の解決を開始します。 これはすでにリスク管理のように見えます。 しかし通常、人々はリスクのリストを作成した後に何を変更したかを言うことができません。

マイケル： それでも、これらの企業のうち、リスク管理に関与している企業は何社、XNUMX% でしょうか?

ティム: 残念ながら、こんなことは言いたくないのですが、これは非常に重要ではない部分です。 しかし、25 つ以上は本当に大きなプロジェクトがあり、少なくとも何かをしなければ存在できないからです。 それが少なくとも XNUMX% だったら、私は非常に驚くだろうとだけ言っておきましょう。 小規模プロジェクトでは通常、このような質問に次のように答えます。問題が私たちに影響を与えるのであれば、私たちはそれを解決します。 そして、彼らはうまくトラブルに巻き込まれ、問題管理と危機管理に取り組みます。 問題を解決しようとしても問題が解決しないときは、危機管理へようこそ。

はい、「問題が発生したときに解決します」とよく聞きます。 確かにそうなりますか？ 本当に決めるのでしょうか？

オレグ： 単純に重要な不変条件をプロジェクト憲章に書き込むだけで、不変条件が壊れた場合はプロジェクトを再起動するだけで済みます。 それは非常にパイムバッキーであることがわかりました。

マイケル： はい、リスクが引き起こされたとき、プロジェクトは単純に再定義されることが私に起こりました。 ナイス、ビンゴ、問題は解決しました。もう心配しないでください。

ティム: リセットボタンを押してみましょう！ いいえ、そのようには機能しません。

DevOops 2019 での基調講演

マイケル： このインタビューの最後の質問に移ります。 あなたは次回の DevOops に基調講演で出席する予定ですが、これから話す内容について秘密のカーテンを開けてもらえますか?

ティム: 現在、そのうちの XNUMX 人が労働文化、組織の暗黙のルールについての本を執筆中です。 文化は組織の中核となる価値観によって決まります。 通常、人々はこれに気づきませんが、私たちは長年コンサルティングの仕事をしているので、それに気づくことに慣れています。 会社に入ると、文字通り数分以内に何が起こっているのかを感じ始めます。 私たちはこれを「風味」と呼んでいます。 この香りはとても良い香りの場合もあれば、うーん、という香りの場合もあります。 組織が異なれば状況は大きく異なります。

マイケル： 私も長年コンサルティングの仕事をしてきましたので、おっしゃっていることはよくわかります。

ティム: 実際、基調講演で話す価値のあることの XNUMX つは、すべてが会社によって決定されるわけではないということです。 あなたとあなたのチームは、コミュニティとして独自のチーム文化を持っています。 これは会社全体である場合もあれば、別の部門や別のチームである場合もあります。 しかし、あなたが言う前に、これが私たちが信じていること、ここが重要なことです...特定の行動の背後にある価値観と信念が理解されるまでは、文化を変えることはできません。 行動を観察するのは簡単ですが、信念を探すのは困難です。 DevOps は、物事がいかに複雑化しているかを示す好例にすぎません。 インタラクションは複雑になるばかりで、まったくきれいになったり明確になったりはしていません。そのため、自分が何を信じているのか、そして周りの人が何を黙っているのかを考えるべきです。

すぐに結果を出したいなら、ここが良い話題です。誰も「わかりません」と言わない会社を見たことがありますか? 人が何かを知らないと認めるまで文字通り拷問する場所があります。 誰もがすべてを知っており、誰もが信じられないほどの博学です。 あなたがどんな人に近づいても、その人は即座に質問に答えなければなりません。 「分からない」と言う代わりに。 やった、彼らは多くの博学な人々を雇ったのだ! また、一部の文化では、「私は知りません」と言うのは一般に非常に危険であり、弱さの表れとして認識される可能性があります。 逆に全員が「分からない」と言える組織もあります。 そこでは完全に合法であり、誰かが質問に答えてくだらないことを始めた場合、「何のことを言っているのかわかりませんよね？」と答えるのはまったく普通のことです。 そしてそれをすべて冗談に変えます。

理想的には、常に幸せになれる仕事に就きたいと思うでしょう。 それは簡単なことではありません。毎日が晴れて快適なわけではありません。時には一生懸命働く必要もありますが、よく考えてみると、次のことがわかります。「わあ、ここは本当に素晴らしい場所だ、ここで働くのは気分がいい」感情的にも知的にも。 また、コンサルタントとして行った後、すぐに XNUMX か月も耐えられないと気づき、恐怖のあまり逃げ出してしまう会社もあります。 これがレポートでお話したいことです。

ティム・リスターが基調講演で到着します 「性格、コミュニティ、文化：繁栄の重要な要素」2019 年 29 月 30 ～ 2019 日にサンクトペテルブルクで開催される DevOops XNUMX カンファレンスに参加します。 チケットを購入できます 公式ウェブサイト上で。 DevOops でお待ちしています!

出所： habr.com