7.1.1私たちはすべて消防士です
職場が長い間働いている限り、誰もが消火活動を必要とする状況に多かれ少なかれ遭遇するでしょう。
何月何日かは思い出せませんが、もうすぐ仕事をやめようとしていたところ、リーダーから突然オフィスに呼ばれました。ユーザーサイトがあり、当社の機器が時々異常にリセットされたことが判明しました。ユーザーは非常に苛立ち、厳しい言葉を発しました。できるだけ早く処理されない場合は、State Gridに報告する必要があります。
当時、私が働いていた会社の主な製品はState Grid用であり、State Gridの機器調達では統一入札モデルが採用されていることが多かったため、ユーザーからの苦情がその後の入札結果に影響を与える可能性があります。会社のリーダーたちはとても心配で、私は他の2人の不運な男たちと一緒に現場に派遣されました。
着手した瞬間から、どうすれば解決できるのかわからなかったし、どうすればいいのかさえ考えられなかったので、とても緊張しました。夕方の雨で家が水漏れし、実際に神様が加わってくれました。私たちのグループは長距離バスに乗って現場に向かい、降り注ぐ雨が降っていました。また、私たちが住んでいた小さな町も交通渋滞で混乱していました。
そのときはかなり矛盾していたことを覚えています。ユーザーの問題の処理に影響を与えずに、できるだけ早くトラフィックが回復することを望みました。また、時間が渋滞のように止まって、現場で困難な問題に直面する必要がないようにしたいと思いました。風雨の中で、渋滞やパンクなどの異常を経て、ようやく朝2時にユーザーサイトに到着しましたが、もともと4時間しかありませんでしたが、9時間以上かかりました。
この現場での問題は、ようやく運良く対処されましたが、実際に消火活動を体験することができました。残念ながら、これは終わりではなく、始まりに過ぎません。
一度、ユーザーの要件に従ってプログラムを慎重に変更し、慎重にパッケージ化してテストしました。今回は本気だと思っていたので、問題は一応対処するべきだったと思いますが、すぐに電話をかけることは期待していませんでした。そのとき、現場の技術スタッフの不満、ユーザーの怒り、リーダーの不信など、一瞬にして多くの悩みが浮かびました。
かつて、ユーザーは私たちの機器に問題があると疑っていましたが、他のメーカーの機器に問題があると考えていました。ユーザーから、100％問題がないことを保証する保証を作成するように依頼されましたが、ユーザーが満足していないか、他のメーカーが満足していないかのいずれかで、Nを超えるバージョンが作成されました。長い間投げた後、ユーザーはレポートに言及せず、他のメーカーが問題を修正したことを知りました。
かつて、数人の男と20日間以上戦っていました。全員が疲れているのを見て、みんなにゆっくり休ませることにしました。その日、ユーザーリーダーがグループに連れて行って、たまたま現場に行ったことがあります。紙の苦情が会社に送られました。
かつて、現場での工事期間は厳しく、ユーザーはインストールとデバッグの進捗が遅すぎると感じ、夜12時まで残業するように頼みました。その日、建設現場はまだ土木工事中で、江南の寒さが骨に浸透し、その夜3人が降りました。
……
消火活動の苦痛な経験はしばしば疲れ果てます。かつてエンジニアリングエリアの担当者が退職し、ゲストを招いて練習をしていたところ、「早朝にライブ電話を受ける心配がなくて、とても安心できました。」という気持ちで、新しい仕事をしてもらいました。問題なし。
リーダーや技術専門家を混ぜ合わせるのは難しいのですが、結局、なぜ皆が消防士になったのでしょうか。キャリアの成長への道は、職場での悲しい道であることが判明しました。
現実の世界には多くの困惑があり、私たちは考え始める必要があります。理由は何ですか？「その場で苦しんでいて、製品を作ったときに汗をかかなかったので、顧客と一緒に飲みます。」緊張とハードワークの日々を生きるのをやめるために、業界ではよく知られた言い回しがあります。製品の品質を真剣に考え始めました。
ちなみに、入社したばかりの新入社員は、一般的に質の高い意識を持っていません。説得力のある説得ではなく、数え切れないほどの人に囲まれ、励まされ、侮辱される体験をしてもらい、問題を解決してもらいましょう。冷や汗は無数の時間よりも優れています。説教は働く。
7.1.2パッシブ戦略
数年働いて辛い経験をした後は、だれもが強い質感を持っているはずですが、気を付けても効果はありません。品質問題が頻発したこともあり、当社は品質会議を連続して開催し、製品の品質には誰もが気を配るべきだと繰り返し強調しましたが、結局のところ効果はほとんどありませんでした。
過去の経験が深すぎるためかもしれませんが、多国籍企業の研究開発に携わっていた頃、どうやって彼らのやり方や製品の品質を確保するかということに注意を向け始めました。ただし、驚いたことに、通常は全員が段階的にしか作業しません。品質に特化したミーティングはほとんどありません。アーキテクトが製品の品質の問題について話すことはほとんどなく、リーダーシップの中で品質の問題に注意を払うべきレッスンはありません。
奇妙なことに、製品の品質に注意を払っていないのですが、明らかに事実と矛盾しており、当社の製品の品質はユーザーから高い評価を得ています。パフォーマンスは一般的には明らかではないかもしれませんが、いくつかの特別な場合の品質の違いはより明白であり、私の印象では、最も典型的なのは地下鉄のシーンです。地下鉄の使用環境は厳しく、高温多湿であり、使用条件も複雑で異常な場合は影響が大きくなります。世界中の同様のメーカーと比較して、当社の製品は、長期間の安定稼働でユーザーから高く評価されることが多いのですが、その秘訣は何ですか？
製品の機能テストを支援するときに、最初の謎、つまりエラーを修正する製品の能力を発見しました。製品のテスト段階では、常にあらゆる種類の奇妙な問題が発生しますが、問題が送信されるたびに、R＆Dチームが問題を迅速に修正することがわかりました。純粋に機能的な問題の場合、修正速度は速く、理解しやすいですが、多くの問題は明らかに特定が困難であり、そのような問題をすばやく修正できるのは衝撃的です。
後で、彼らの製品には多くのエラーチェックメカニズムが組み込まれていることがわかりました。問題が発見されると、問題の原因を特定するのに十分な情報が得られるため、修正は比較的迅速です。また、これらの多くのエラーチェックメカニズムは、アーキテクチャ設計に実装されています。十分に検討した。
これを実感した後、私が使用した優れたソフトウェアの多くにも同様の機能があることが突然わかりました。私にとって、DOSプログラミングからずっとやってきたプログラマーのベテランである最も典型的なものは、ウィンドウのクラシックブルースクリーンインターフェースです。
これには、異常なエラーフラグ、異常な情報の説明、異常なレジスタバックアップなどの情報が含まれています。異常なソフトウェアが増えると、ダイアログボックスがポップアップし、異常な情報を製造元に送信して問題のエスカレーションを支援するか、経験計画への参加を依頼するように要求します。
この戦略の継続的な反復により、製品の問題はますます少なくなり、品質は当然より高くなります。
7.1.3アクティブ戦略
「華Tuo三兄弟の医療技術」の話を聞いたことがあるかもしれません。3人の兄弟のうち誰が最高の医療技術を持っているかをHua Tuoに尋ねたところ、Hua Tuoは彼の長兄が最高で、次の兄弟がそれに続き、最悪だったと言いました。Hua Tuoは誰もが困惑していると説明しました：私の兄は病気に気づいていないときに病気を治療するので、人々は彼の医療技術についてあまり知りません。私の次の兄弟は、人々が病気になり始めたときに、見て、聞いて、処方することによって患者を治療したので、人々は彼について何かを知っていました。患者さんがとても深刻なときに医者に診てもらったところ、偶然に数人を救うことができましたが、誰もが自分を生き返らせる力があると思っていて、優れた医療技術を持っていました。実は私と兄の間に大きなギャップがあります！
同じことが製品カテゴリにも当てはまります。複雑な問題をすぐに見つけて解決できる人もいます。誰もが彼らはレベルの高い人だと思っています。実際、これらの人はハッキングに長けている可能性が高く、プログラムをより混乱させます。同時に、トラブルを起こすために何もできないエンジニアは誰もが知ることはできません。
製品の品質の問題に直面して、問題が完全に受動的に発生するのを待つのは最善の策ではありません。私たちは率先して、より積極的な戦略を採用する必要があります。これは、私が発見した高品質の2番目の謎です。
製品テストを行っていたときに、コマンドラインから多くのモジュールの実行ステータスを表示したり、特定の変数の現在のステータスを変更したり、スクリプトを使用して複雑なロジックを構成したりできる追加機能があることがわかりました。これはプラットフォームに組み込まれたデバッグ機能であり、この機能を使用すると、製品コードの100％カバレッジテストを比較的簡単に完了することができます。100％のコードカバレッジテストは、高品質な製品を構築するための最も基本的で効果的な部分です。
別の例を挙げてください。地下鉄の機関車がプラットホームの停止状態から開始する場合、電流波形は障害電流に非常に似ている、特に朝と夕方のピーク時に電流が非常に大きくなります。通常の電流と故障電流を区別するにはどうすればよいですか？さまざまなシーンの実際の複雑な動作条件を考慮する必要があり、単純な静的数学モデルでは完璧を達成することは困難です。
この問題に対処するために、高精度のレコーダーを使用して、広州のいくつかの地下鉄路線の稼働状況を一定期間記録し、数百Gの検出データを使用して、シミュレーションテストのためにこれらのデータを仮想機器環境にインポートしました。このリンクの検証後、製品アルゴリズムの信頼性は大幅に改善されました。この戦略は、単に例外を待ってから問題を見つけようとするよりもはるかに賢明です。
もう1つの同様の戦略は、テストケースライブラリを継続的にアップグレードすることです。多くのオンサイトフィードバックの問題は、最終的にはテストケースライブラリのチェックリストに発展します。現時点では、テスト作業は、過去のすべての経験を使用して製品の品質を保証することと同じです。反復時間が増加するにつれて、製品の品質は当然高くなります。
パッシブからアクティブに変わると、少し進歩することで、製品の品質問題に直面したときに私たちをより快適にすることができます。
7.1.4総合品質管理システム（TQM）
アクティブ戦略でもパッシブ戦略でも、模倣して学ぶ方が簡単ですが、残念ながら、実践の過程で、私が模倣したことは多国籍企業で見たものとは少し違うといつも感じています。
私たちが最初に製品を作り始めたとき、誰もが無意識のうちに製品の品質問題に注意を払っていましたが、彼らは歩くにつれてしばしば変化しました。コーディングの際、顧客と企業のリーダーは進捗を強く求め続けます。テスト（想定）の場合、ランダムにテーブルを設定し、簡単な操作を実行することがよくあります。問題がなければ、迅速に対処してください。そして、私たちを待っているのは、製品が出荷された後の長い品質安定化段階です。ここに問題があるか、コントロールがありません。ひょうたんを押してスクープを持ち上げると、恥ずかしいだけでなく、ユーザー、市場、リーダーを刺激することもあります。満足。
社内でのプロジェクトの進行を早めるのは当たり前のことですが、品質の面で手を抜いてはいけません。
僕が最初に働いていた会社ではリーダーシップに変化があり、新しいリーダーはトヨタモデルを高く評価していたので、同社はしばらくの間トヨタモデルのトレーニングを行っていました。当時は新リーダーの三火と思っていたのですが、第一印象は架空のものだと思っていたのであまり真面目に考えず、単純に理解して棚に置いてみました。
その後、多国籍企業の研究開発に携わっていたとき、はっきりとはわかりませんでしたが、いつも何かおなじみのことを漠然と感じていました。その後、偶然にも、トヨタの合弁会社で機器をデバッグするために2回の出張の経験があり、生産ラインのトヨタの変革プロセスも経験しました。
これらの経験のおかげで、トヨタモデルを再理解することができ、また、デミング博士の品質管理理論についても学ぶことができました。実際、多くの優れた日本企業の経営理念は、デミング博士の品質経営理論に深く影響されています。その後、関連する本をいくつか読んだ。たぶん蓄積が原因だったのかもしれない。突然思いがけなくなった。品質と製品を別々に扱うべきではなく、品質は製品開発プロセスに統合されるべきだ。製品の品質を中心とした研究開発プロセスを構築するために、初めて総合品質管理システム（TQM）がコンセプトになりました。
CCTVはかつてドキュメンタリー「素晴らしい国の品質」を制作しました。私はこのドキュメンタリーを何度も見てきましたが、ドキュメンタリーの中に非常に感情的な部分があります。
1947年に、数学の医者はアメリカ社会に品質を緊急に訴えていました：「多くの人々は品質と生産性、または生産性のバランスをとることができないと誤解しています。それらを変更しない限り、彼らは矛盾を持ちます。このような考え方で彼らを見てください。実際、大量生産と品質は完璧にマッチしています。」彼の名前はウィリアムエドワーズデミングです。
デミングの理論によれば、すべてのリンクに品質管理の考え方を取り入れれば、どの企業でも生産効率を向上させ、品質を向上させてエネルギーを節約できます。
1945年に第二次世界大戦の煙が消えたとき、デミングは品質の革命がこれからやってくると信じており、彼の理論は有用であろう。しかし奇妙なことに、1947年の終わりまでに3万人以上のアメリカ人が彼の講義に参加したとしても、デミングはほんの少しの存在感さえもほとんど感じなかったということです。
第二次世界大戦の初期、他の国々は急いでおり、アメリカが世界に供給していました。競合他社がなかったため、当時の同社は利益を上げたいだけで、高品質の製品を追求していなかった。デミング博士は、彼が単なる預言者であることに困惑しましたが、母国では誰も彼を追いかけたくはなく、誰も彼に興味を持っていませんでした。まだ人口統計局だけが彼のアイデアを適用していましたが、当時彼のアイデアは生産管理システムに組み込まれていませんでした。
デミング博士が絶望的だった当時、海を挟んで戦争の失敗で崩壊寸前の国が救世主の出現を切に待ち望んでいた。
南日本の小さな町、宇佐は日本の伝統的な神道で、大和の戦神である八幡の故郷であり、日本には44,000を超える宇佐八幡神社があります。しかし、別のとんでもない出来事のため、ここは「世界的に有名」です。第二次世界大戦後の10年の間に、約100の日本企業の製造工場がここに出現しました。その理由は簡単で、宇佐が英語で「USA」と書いており、宇佐製の商品は「made in USA」と印刷して海外に輸出できることを知っており、アメリカ製だと思わせる。
ソニーの創設者である森田昭夫氏の回顧録には、「私たちは偽造品であり、品質が劣っている」とあり、「日本製」で印刷された製品は、非常に品質が悪い印象を残します。創業当初は、「Made in Japan」という文字を常に小さく印刷していたのですが、アメリカでは小さすぎたため、転載を余儀なくされました。
ほぼ同じ熱意と絶望の中で、日本とデミング博士は予想外に出会った。1950年6月23日、デミングは日本科学技術同盟の招待を受け、日本に1週間にわたる品質管理講義を行いました。アメリカは日本にとっての手本であり、1946年に設立された日本科学技術同盟は、第二次世界大戦中にアメリカの生産管理マニュアルの研究を始めました。しかし、3年以上の間、本の理論は彼らを困惑させてきました。本物のアメリカの専門家への希望をピン留めすることは、最後で唯一の選択肢のようです。
しかし、デミング博士のレセプションバンケットでは、アメリカの専門家が別のアドバイスをしました。「アメリカのモデルをコピーしないでください。品質管理システムを確立できれば、製品は5年でアメリカを上回るでしょう」 。
1950年7月10日、デミング博士は東京の日本医師会の講堂で8日間の品質管理講義を開始し、聴衆には多くの企業の経営者や政府高官が含まれていました。NHKは講演の録音をラジオ番組に変え、何百万人もの日本人が電波による大規模な品質改革運動に参加しました。5年でアメリカを超えた「アラビアンナイト」は日本を感動させました。
ソニーの品質と環境担当の副部長である佐藤弘和氏は、次のように述べています。「ソニーの生産、検査、その他の側面では、デミングの品質管理方法が使用されました。この方法を使用すると、問題が発生したときに、より包括的に分析できます。また、フィードバック情報により、高品質の製品を製造することができます。」
トヨタのビジネス品質改善部長の古谷武夫氏は、「デミング博士が教えた品質管理は、当時の日本企業にとって新しいものでした。非常に新鮮でした。多くの人がこの理論を学び、総合的な品質管理モデルを導入しました。しかし根本的に言えば、製品の品質を向上させるには依然として人々が必要です。」
デミングの理論と現実を組み合わせて、日本はかんばん管理やジャストインタイムシステムなどの品質管理手法を徐々に開発してきました。これらの方法はすべて同じ考えを共有します。品質は人々によって生み出され、提供されるべきです。早くも1902年に、日本のトヨタの創設者であるトヨタ咲は、改良された自動織機を発明しました。壊れた糸がある限り、織機は自動的に停止します。この機械を製造する当初の意図は、お母さんが一生懸命働かないようにするだけです。暗闇の中での日本とデミングの間の「予期せぬ出会い」は、「偶然の偶然の一致」である可能性があります。
トヨタは1955年にクラウンRSモデルを発売し、初めてアメリカ市場に参入し、1970年代初頭にアメリカで大きな成功を収めました。1980年、日本は1100万台を超える車を生産し、米国を一挙に打ち負かして世界一になりました。アメリカの若者たちは、トヨタの車を運転することに誇りを持っているだけでなく、アメリカ国民の自信を破壊しているという事実もあり、この敗北国は、世界で二番目に大きな経済国となっています。
当時、ニクソン米大統領は、「第二次世界大戦の終結と比較して、アメリカは夢にもできない困難に直面している」と宣言した。今年の6月24日、NBCテレビは、テレビシリーズの最盛期に90分のドキュメンタリーを放送することを選択しました。このドキュメンタリーは、ニクソンでさえ夢にも思わなかった事実を伝えています。米国で取り残された学者。そして彼のオフィスは、ホワイトハウスからわずか5マイル離れた地下室にあります。プログラムのビデオテープの配布は4000万を超えました、そしてそれは当時アメリカの映画とテレビ業界で最高の記録でした。このドキュメンタリーの名前は「日本の能、なぜできないのか」です。
もし日本ができるなら、なぜできないのか？心に響く質問は何か。このドキュメンタリーは、私たちの心の質が非常に高い国や企業が経験し、克服した困難の種類を知らせました。このドキュメンタリーは私たちの製品の品質を直接改善するものではないかもしれませんが、私たちの心に種を蒔くかもしれません。私が思うに、最大の成果は認知的思考の変化であり、突然別人になり、多くの現象を見ると独特の洞察が得られやすい。
◇◇◇
このドキュメンタリーでデミング博士が説明した最も重要な点は、品質と生産関係をバランスさせることができるということです。私の当初のコンセプトは、良い品質を得るためには、テストプロセスに注意を払い、テストを繰り返す必要があるというものでした。デミング博士は、「R＆D-テスト-テスト-再テスト」のプロセスは間違っており、品質管理システムを製品に組み込む必要があると語った。例えば、トヨタの自動織機は糸が切れると自動的に止まってしまい、当然糸が切れた製品は生産されません。
同様に、産業用組み込みソフトウェアの研究開発の分野では、品質管理リンクを製品開発プロセスに組み込むことができますか？このような考え方と、多国籍企業での日々を考えることで、多くの価値を得ることができますが、その中でも次の2つのリンクが最も個人的に役立ちました。
従来のウォーターフォールのR＆Dプロセスでは、最初に設計に重点を置き、次にコーディングに重点を置き、次にテストに重点を置いています。デミング博士の理論によれば、このR＆Dモデルは間違っており、最大の問題は、中間リンクがバックログを発生させることです。これは重大な無駄であるだけでなく、問題を隠します。一連の設計ドキュメントを書き込んだ後、コーディング中に設計の問題が見つかった場合、手直しの量は比較的多くなります。
彼らの視点に感謝します。製品開発プロセスは価値創造プロセスです。つまり、プロセスの各ステップは製品であり、提出可能な資料であり、各ステップは単に前のステップから次のステップへの作業のテールを残すのではなく、価値を生み出しています。
最初のリングは、コードの自己検査とコードレビューです。コードは、レビューのためにプロジェクトチームに引き渡される前に自己チェックする必要があります。チームは、部分からフレームワークまで、3回の自己チェック戦略を推奨します。たとえば、1回目はコードの詳細を確認し、2回目はコードフロー全体が適切かどうかを検討し、3回目はアーキテクチャ内の現在のソフトウェアモジュールの位置とインターフェイスが妥当かどうかを検討します。私の個人的な経験では、最初は冗長に感じ、エンコード速度ははるかに遅くなりますが、習慣を形成すると、コードの再調整率は低下しますが、エンコード効率は大幅に向上します。これは、高速と低速の完全な一致です。
チームのコードレビューでは、全体的な状況を把握すること、知識ベースの詳細を確認すること、およびコードの自己検査の焦点とは異なるチームメンバーのトレーニングを強調します。さらに重要なのは、自己レビューされたコードのみに基づいて、コードレビューが実行可能になり、その正当な価値を発揮できることです。
2番目のリングは、統合テストと機能テストに関するものです。初期の段階で製品を作ったとき、最終的な製品がテストチームに引き渡されるべきだという幻想があったので、チームの内部テストは簡単に処理できました。その後、チームを指揮して機能テスト作業を完了した後、このリングについてより深く理解しました。
統合テストは、R＆Dプロジェクトチームの内部テスト作業に属する個々のモジュールを製品に結合するために使用されます。統合テストは、インターフェースやマルチモジュール調整などのリンクに焦点を当てています。機能テストは、製品がプロジェクトの初期段階で設定されたさまざまな目標またはさまざまな業界標準の要件を満たしているかどうかを検証するテストチームの責任です。これは、ユーザーの視点から見た製品のユーザビリティテストの詳細です。
つまり、テストチームは製品テストを100％完了することはできません。さらに重要なのは、テストチームの作業は、プロジェクトチームによって統合された製品に対してのみ実行可能で意味があるということです。
◇◇◇
ドミング博士がドキュメンタリーで説明したもう1つの重要な点は、製品の品質を向上させるためには、人に頼ることが重要であるということです。最初はこの見方を誤解していて、ちょっとナンセンスに感じましたが、多くのことを経験して、ようやくその深い意味を理解すると、伝統的な経営モデルの新たな再構築だとすぐに気づきました。
従来の管理モードでは、プロセスと評価により多くの注意が払われ、従業員はプロセスに依存しています。CMMIなどのソフトウェア開発プロセスのトレーニング経験があるのか、会社がさまざまな研究開発プロセスを強制的に導入した後の混乱を経験しているのかわかりません。これらの経験は苦痛であるだけでなく、プロセスベースのさまざまな評価メカニズム（KPIは多くの場合、年間評価単位に基づいています）でも、チームメンバーは迅速な成功とコラボレーションよりも内部の闘争を急いでいます。
中国でよく知られているCMMIの専門家であるLin Ruiは彼の著書に次のように述べています。企業が本当にR＆D管理機能を改善したい場合は、CMMI条項を忘れて、CMMIに縛られず、すべきことを行ってください。会社がCMMIレベルの証明書を取得したい場合は、近道をとって、恥ずかしがらずに、会社のR＆D管理機能を改善するためにCMMIレベルの評価に依存することを期待しないでください。恥ずかしいですが、誰が顔をたたいているのかわかりません。
従来のプロセスモデルでは、会社は従順な従業員に報酬を与えます（従順でない従業員は、さまざまな評価によって自然に排除されます）。すべての作業が組立ラインのように自動化されることを期待しています。対照的に、デミングの経営思想は、個人の主導権をより重視しています。最も典型的なものは、トヨタのプルライトモデルです。従業員が問題を発見すると、組立ライン全体が停止します。これは、従来の経営モデルではほとんど想像できません。
なぜトヨタの従業員は、組立ライン全体を停止するリスクがあるので、あえて照明を引くのですか？職員の組織構造から手掛かりが見つかるかもしれません。従来のプロセスに基づく人事組織モデルは、一般的に次のとおりです。
リーダーは外部のコンサルティング会社にR＆Dプロセスの構築を依頼し、すべての従業員がプロセスに取り組みます。プロセスがコアであり、従業員は2位です。
デミングの経営思想に基づいて、次の図に示すように、会社の人事組織構造が逆になります。
すべての第一線の従業員は、より高いレベルのサポート従業員によって支えられています。第一線の従業員が明かりを引いた後、バックアップサポートチームが直ちに介入し、問題を迅速に解決します。プルライトシステムの目的は、中間リンクでの過剰在庫や問題の伝達を防ぐことであり、製品の品質を向上させる効果的な戦略です。ただし、プルライトシステムを実行可能にするには、それをサポートするための一連のサポート作業が必要です。これには、チームのサポートだけでなく、フロントエンドのビジュアル管理、かんばんシステムなども含まれます。
この反転した人事組織構造に基づいて、チームの構築に非常に役立ちます。コードレビューを例に挙げます。通常の従業員の中で、チーム内で強力な能力、真剣な態度、および特定のリーダーシップを持つ従業員は、当然、サポートする従業員に成長し、監査人に成長します。このとき、彼のタスクは次のように昇華します、一般の従業員が困難に遭遇したり異常を見つけたりしたときに支援し、休暇を求めたり、ポストを離れたりしたときにすぐに交換したり、ある程度の困難のあるモジュールのコーディングを行ったり、製品レベルの統合テストを行ったりします。
この人事選択システムの継続的な反復により、製品マネージャーは監査人の間に生まれ、製品ラインのリーダーは製品マネージャーの中に生まれ、アーキテクトは当然製品ラインのマネージャーの中に生まれます。この種の自然に成長する建築家は、一般に、リーダーから割り当てられたものよりもはるかに強い、強力なリーダーシップと調整スキルを持っています。
現時点では、従業員の評価はKPIに基づくのではなく、チームの全体的な関心とチームのリーダーシップレベルに基づいています。チーム内で強力なコラボレーションの雰囲気が形成され、個人がより優れたキャリア開発ビジョンを持つことが容易になります。現時点では、すべてのシステムが人々に役立つか、人間の本質の弱点を克服するために使用されています。
「製品の品質を向上させるための鍵は、人々に依存することです。品質は人間によって生み出され、提供されるべきです。」これで、誰もがデミングの見解を理解しやすくなります。業界には冗談があります。フォードの組立ラインは1,000人の手を雇う必要がありますが、予想外に1,000人がここにいます。おそらく、デミングの経営思想は、組立ラインの手を変えて、肉と血、人格、気性、理想、衝動を持つ人々に戻すことです。
◇◇◇
機能テストでは多くの場合、さまざまな自動テスト方法が使用されますが、プロジェクトチームが製品を提出した後でこれらの方法を構築することはできません。製品アーキテクチャの設計、コーディング、統合テストなどで自動テストモジュールの構築に関与しているテストチームメンバーがいる場合、最終製品のテスト容易性が保証されるだけでなく、最後にプロジェクトチームがさまざまな非デバッグデバッグ命令を書くことの恥ずかしさも省略されます。 、そして、テストグループが再利用率の高い自動テストコンポーネントを作成すると便利です。
これはテストだけでなく、生産などの多くのリンクにも当てはまります。品質と人を中心に一連の新しい管理プロセスが確立されています。この自然に派生した管理モデルは、総合品質管理システム（TQM）と私が考えるものです。
消防士—受動的戦略—能動的戦略—総合品質管理システム（TQM）認識は変化し、品質は反復しています。現在、品質は品質だけでなく、経営も重要であり、品質を核とした経営プロセスにより、製品の品質はさらに向上しています。この時点で、私は高品質の背後にある究極の謎を発見したようです：整然と+修正可能=高品質。
総合的な品質管理理論に基づいて、各企業の実際の状況と組み合わせて、長期的な反復により、「標準化」と呼ばれるR＆Dシステムが構築されます。これには、以下の特性があります。
- 新製品を開発する場合、コンポーネントチーム全体からR＆D要員を迅速に動員し、自然にコラボレーションできます。人員の大規模で動的な共同組織をサポートすることは、標準化されたR＆Dシステムの主要な機能の1つです。
- 製品の品質とR＆Dの進捗状況は比較的確実ですが、多国籍企業と提携している場合にこれを実感できるでしょう。
- コードの再利用率が高く、製品開発速度が速く、市場の変化に柔軟に対応できます。
- 複雑な製品の研究開発能力を備えています。
要するに、このレベルに達した企業はすでにかなり強いコア競争力を持っています。それは個人的な英雄を持つ多くの企業の比較からはほど遠いです。Onboarding-team-abstraction-architecture-reuse-quality-standardization、多分それは登るの終わりのない道です。
——————————————
私はXiaomaerです。良心と魂を切望する組み込みソフトウェアエンジニアです。あなたの会社を歓迎し、旅行してください。興味がある場合は、個人のWeChat アカウントnzn_xiaomaerを追加して通信することができます。「異次元」という言葉に注意する必要があります。