TECHNOSPHEREは、実務家、開発者の50年は貴重であることができ、著者カール・ウィーガーズは、過去50年間で、このような豊富な経験を持つソフトウェア業界の専門家である、彼は63啓示、シェアを蓄積し、整理しました、私はあなたのインスピレーションを願っています。
著者|カール・ウィーガーズ、翻訳者|シャンパン超新星
Zebian | TANGリード
ヘッド図|東ICからCSDNダウンロード
出品 | CSDN（ID：CSDNnews）
以下は翻訳です。
1970年、私は、最初の教会プログラミングクラス（上の大学にいたFORTRANのはもちろん、学生）。過去半世紀では、私の時間の多くは、ソフトウェアでの作業に費やしている：要件、設計、ユーザーエクスペリエンス、プログラミング、テスト、プロジェクト管理、書き込みドキュメント、主要なプロセス改善を、7冊と多くの記事を書いて、コンサルティング、トレーニング。
もちろん、その過程でも、このような有機化学の博士号（読み取りなどサイドクエスト、多数の完成私の論文のすべてのコンピュータコードの3分の1を数年の研究者のために）、。しかし、基本的に、私は、ソフトウェア業界の人たちです。
時間のような長い期間で、私は、ソフトウェア業界についての意見の多くを蓄積しました。この記事では、私はおそらくあなたはそれらを有用見つけるために私をしたいと思い、あなたと63啓示を共有します。
需要について
1.あなたが徹底的にニーズを理解していない場合は、残りの項目は、あなたがどんなに役に立たない、最終的には失敗します。
2.昼食後、あなたが机の紙のノート、保存ボイスメールと電子メールで見つけて、需要とみなすことはできませんすべてがもっともらしい廊下、上のカジュアルな会話を覚えています。これは情報のみのちょうど束です。
すべてのプロジェクトの利害関係者のために3は、プロセス要件（要求プロセス）における利益の交点がほとんど発生します。
4.高品質の需要が不足した場合、より多くの予期せぬ感じるかもしれないコンテンツの利害関係者が最後に配信しました。ソフトウェアでは、事故はほとんど常に悪いニュースと同義です。
5.ニーズを探索では、ちょうど現在のユーザーを考慮しないでください。あなたは、顧客がまだあなたの顧客である必要があります。
6.人々は、単に「コレクト」の需要に行くべきではありません。需要はかなり単純なコレクションより、取得、コラボレーション、発見や発明を模索しています。ビジネスアナリストは、ライブスクライブを乾燥させるだけではなく。
VOCで、できるだけ耳の開発者にcustomer--近いの声 - - EOD、開発者の耳である7.目的は、顧客の需要の声を得ることです。ビジネスアナリストは、それらの間の通信のギャップを埋めることができます。
8.要求獲得のために、人々はしばしば二つの方法でお願いいたします：「テレパシー」と「透視」を しかし、役に立たないとは異なり。
9.いいえどのような私たちの文化の主張を問題では、実際に顧客が常に正しいではありません。しかし、顧客は常に自分の意見を持っていますが、あなたはこの意見を理解し、尊重しなければなりません。
10.反復開発は、需要を必要とします。あなたはすべての要件を取得する最初の議論を期待することはできません。あなたが完全に取得することができないかもしれないことを知っています。効果的な需要開発は、ディテールと明瞭度の緩やかな改善を必要とします。
11. Doが記録を要求することを恐れてはいけません。知識へのアクセスのコスト、低コストレコードの知識と比較すると。
12.一部の機能や特徴は、特許請求の範囲に記載されていない場合、製品に見るために誰を期待されていません。
成果物の開発のための13の需要だけで書かれた需要のセットが、コンセンサスと一貫性の期待ではありません。
14.より現実的な目標は、需要を創出することではなく、需要が建設のための許容可能なリスクレベルのチームを作成するのに十分であるか、完全な、という観点での開発の必要性。リスクは、それが不完全、曖昧または貧しい通信ニーズの場合の出力、不要な、怠慢によるもので、ケースはあまり外に計画を手直ししなければなりませんでした。
15.我々は、読者が私たち自身の「合理的フィルタ」と同様のがありますが、文の同じ期間に、それは多くの場合、さまざまな方法で解釈されていることを前提とすることができるため、需要の発現の私たちは時々、よりカジュアル。この曖昧さは、配達時に予期しないとマッチした期待につながることができます。
16.監査チームは、スタジオを維持し、より小さな規模である必要があります。人々の大規模なグループあなたはオンデマンドで言い表されるべきで合意に言及しないように、ビューを行うことができない火の部屋を残しておきたい場合は、同じであっても。
17.誰かが新しい要件を提案したとき、聞いて最初の質問ですが：「？私たちは、議論の範囲内でこれを行うことがある場合は、」、それに対処しなければなりません。そうでない場合、それは解決しないだろう、あるいは少なくとも今解決されません。答えがある場合は、「いいえ、私たちは、この問題を心配する必要があり、」あなたは、それに対応するために範囲を調整する必要があります。これ、スケジュール、リソース、参加、優先順位や費用対効果の妥協は効果を持っています。
18.あなたは、スコープクリープを経験している場合はどのように知ることができ、文書化し、合意されたプロジェクトのスコープを持っていない場合は？
（一般ダウンタウン割当としても知られる）製品または反復回避「デシベル優先」アプローチに含める特徴とするものを決定するには19。関数は必ずしも、ビジネスの観点から必要な最も重要な最大音量の顧客。
20.プロジェクト関係者は、製品が異なっている間、それを含めてのコミットメントとの潜在的な議論の必要性を理解できなければなりません。
あなたが聞いたときに21二つの用語がありますが、警戒する必要があります。「その需要を想定した」と「暗黙のニーズ。」はっきり予想需要を伝えるために努力しています。
プロジェクト管理について
22.「プロジェクト管理」は、特定の活動を指すものではありません。プロジェクト管理は、管理人、需要管理、リスク管理、機会管理、期待の管理、管理、変更管理、リソース管理、サプライヤ管理の混合物へのコミットメントです。
23.なぜ一部の企業はよくソフトウェアをそれまでの時間を持っていることはありませんか、とそれ以降は常に補うために、時間、お金と人材を見つけますか？これは謎です。
24.誰もがして喜んで彼らのチームはトップの才能を持っていると考えているが、実際には、すべてのソフトウェア開発者の能力の半分が平均以下であるということです。さて、これらの人々はどこ働いていますか？
25. Doが誰を評価しません。他の人が最も適切な応答を評価するように依頼した場合である：「私は最初にそれについて考えてみよう、そして今、あなたと一緒に戻って行きます。」
26.どんなにあなたが他の人に適用されるどのくらいの圧力、彼らは維持することはできません任意の約束を与えることはありません。
27.あなたはどのようなデータはほとんど他には、あなたが交渉において支配的な地位を占めることになる一方で、説得力のあるデータを持っている場合。
28.あなたが録音し、実際に比較して何が起こったのかを評価する場合を除きは、そうでない場合、あなたは常にではなく評価に比べ、推測されます。
29.私は良い言葉を聞くことのような他の側面を考えていないので、それが誰かのあなたの評価に影響を与えます。
品質とプロセスの改善に
ソフトウェアの品質に関しては30：あなたは後で私を支払うことができますが、より多く支払うことに、今私を支払うことができます。
31.完璧のために努力、卓越性の追求。
32.は、常に上司やクライアントを説得するために行うには悪いことしないでください。
33.品質は、あなたの最優先事項であるべきです。このチームは、リワークにあまりにも多くの時間を無駄にする必要はありませんので、その結果は、飛躍的に高品質の天然生産性です。
34.欠陥を見つけることではなく、顧客よりも、ピアを作るために努力しています。ピアレビューの技術は、品質と生産性を向上させることができます有効な技術です。
35.あなたが扱っている人は不合理ではなく、その任意のソフトウェアエンジニアリング技術役に立たない場合。
間違っている人々は、「？何が私のためにそれでだ」自分の本能的な反応は、依頼することです、作業の彼らの方法を変更するように求めていた。しかし、実際には、この質問がされる36。適切な法律は、「我々のチームのために何がいい？」、求めるべきです
37.ソフトウェア開発者は、常に優れたツールを探しているが、少し馬鹿はツール意志だけ鈍い男の子を持った後、覚えています。
人々はプロセスの変更のために、中に現在の仕事に起因する痛みを理解していない点が非常に困難である38。人々はマウスを使って自分の家を知っていない場合のように、彼らに、より良いネズミ捕りを販売することは困難です。
39. Q：どのように多くの電球所有者が必要とするソフトウェアプロセスを交換するには？A：一つだけが、唯一の電球を交換することをいとわなければならない場合。
開発の新しい方法に向けた作業の過程で40は、難易度や組織文化を変える必要性を過小評価しないでください。速く教化より新しい文化に新しいプロセスの実装。あなたは、両方の面で成功を持っている必要があります。
かかわらず、それは無駄にすることを行動に善意、そうでない場合は改善計画であるかどうかの41。
42.多くの場合、常識、良識や経験では、正式な手続きよりも重要である必要があります。しかし、時には、このプログラムの存在は完全に正当化されます。バイパスにに見てする必要性を決定する前に。
作業の新しい方法を採用する組織をリードするには43は、圧力をかける優しく続けてください。
44.最高のパワーは仕事が苦痛である方法を変更するに貢献することができます。人工ではない、外部から現在の非常に本当の痛みのチームを持って痛みを伴うが、仕事を適用します。最終的にそれを改善するための活動の苦しみを軽減することができるものを選択します。
45.あなたが審査に時間がかかるし、教訓を学び、チームのプロセスを改善し続けない限りは、そうでない場合は次の項目は、より良いプロジェクトにより行うことができます期待する理由はありません。
46.あなたは、変更のすべてに目を向けることはできません。最大の利益をもたらすことができ、それらのプロセスの変更を識別し、そして次の月曜日が始まりました。私は冗談ではない：それは次の月曜日です！
47.コンセプトのドキュメントテンプレート「に合わせて縮小」を使用します。中に含まれていてもよいし、その後サイズ、自然と各プロジェクトのニーズに応じて再構築するためにどのような情報を思い出させるために、より配慮する、起動する豊富なテンプレートを使用して起動します。
48.は、多くのチームが少ないとより多くのことを行うために必要とされているがあります。しかし、通常の状況下では、彼らは独自の方法で乗数をしませんでした。効率性と有効性を高めるために何の適切なトレーニングとプロセスの改善がない場合は、より高い生産性は、それ自体を明らかに素晴らしいだろう期待していません。
同じ職場で働く4人に適した49は、上記の異なる大陸に取り組んで複数の開発チームでの非公式のプロセスに拡張されていません。
50.ソフトウェア業界は、再現性があることができ、何も存在しない場合、それは繰り返しプロジェクトの次々に同じ愚かなことをやっています。あなたは、見直しの理解、および継続的な改善によって学ぶ必要があります。
;（2）調整プロセスは、それがより効果的かつ実用的な作り、その後、人々はそれに従うようにする;（3）このプロセスを放棄（1）人々がプロセスに従うようになったので、ということ：あなたが唯一の3つの選択肢を持って前に、人々は、確立された手順に従っていません51そしてあなたは、この手順に従うことをふりをしていません。
その他の意見
52. AIは本物を置き換えることはできません。
53. あなたは週の他の人々を導く場合は技術部門では、あなたは兄です。
54.今日は「すぐにそれを修正する必要があり、」開発プロジェクトの種類は、明日のレガシーシステムメンテナンスの悪夢になります。
ソフトウェアおよびソフトウェア、ソフトウェア、およびハードウェア、ソフトウェア、および人、そして人：55.ソフトウェアシステムがインターフェイスで発生した問題の多く。これらのインタフェースは、優れた研究を必要としています。
常にあまりにも多くの56人々はについて話をする「権利」。他の側面ながら権利のそれぞれの責任です。考え、行動する精神で協力します。
57復興のポンドの設計と同等のオンス。
「ビジネスウィーク型経営」の用心58 - 誰かがそれを約束した優れた結果を読むためだけで、我々はソフトウェア開発で最もホットな新しいものを採用することを急ぎます。
59は、親指と人差し指の間のインチ距離を維持します。ほとんどの場合、これは品質とジャンクの唯一の違いです。ただ、より多くのそれより少しに耳を傾け、あなたの仕事をチェックし、再度、参照リストをテストを実行し、指示を読んで、別の質問を提起。通常、これは廃棄物を改善するための唯一の方法です。
60.あなたは再びソフトウェアの実務前にコミット再コミットそれらのミスに時間がありません。読むと文学のために尊重します。あなたの同僚から学びます。寛大に他の人とあなたの知識を共有しています。
61ソフトウェア開発コンピューティング技術は、50％を占めることができ、残りの50％が通信することです。しかし、ビジネスの分析は、通信の交換で完全です。私たちは、より計算のために考慮しなければなりません。
62.あなたが独立した請負業者やコンサルタントであることを自分自身で生活したい場合は、世界に自身が利用できる宣言する必要があります。誰もあなたを知っていない場合は、どんなに良いあなたのビジネス能力役に立ちません。
ソフトウェア業界では63、私たちはしばしばふり。私たちは、彼らのビジネス目標を理解し、彼らのニーズを知っている右の利害関係者を発見したふりをします。我々は右の要件を伝えるために適切な人材を持っているふりをし、我々は理解し、正確に記録します。我々は、我々の評価が正確であることをふりをし、我々は必要なタスクすべて考慮に入れています。我々は、すべての可能なリスクは、当社の事業にダメージを与えることになるふりを実際に表示されていません。私は愛にふりをするつもりはありません。私はそれに直面しているので、時々、私は、あまり現実好きではない、何もに加えて、私の現実。停止が今ふりをしてみましょう。
英文：ソフトウェアの経験の50年から63回のレッスン
オリジナルます。https：//medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706
著者について：カール・ウィーガーズ、ライターは、ソフトウェアの開発と管理、コンサルティング、自己改善、化学的、軍事史などの分野をカバーする書き込み、彼はまだサスペンス小説を書いています。
翻訳：シャンパン超新星
この記事CSDNの翻訳は、元のソースを明記してください。
【終わり】
推奨読書
☞ オタクの見出し|角9.1リリースされ、ビット線乗車夜間サービス、テンセントはティム3.0、サポートマイクロチャネルのログオン新しいベータ版を閉じました
☞ Huawei社のP40「セル3人の子供」、10854元の最も高価な価格
☞ なしコード時代ません、彼らの雇用を維持するためにどのようにプログラマ？
☞ GitHubのは、仲介攻撃されていると疑われていない、あなたが黒にもはや最大のダークウェブホスティングプロバイダにアクセスすることはできません！
☞ なぜあなたはSaaSのは常に失敗だと思いますか？明らかにこれらの4つの理由が失敗し続けることが考えられて！
☞ 万語良いテキスト：契約ソリディティインテリジェントプログラミングレイダースの準備、推奨コレクション！
あなたは、私が好きなよう真剣に、すべてのポイントを見て
