ソフトウェアプロジェクトの管理：プロセス、ツール、テクニック

創造的な仕事がどのように行われるかについて、さまざまなアイデアがあります。 多くの人々にとって、クリエーターは洞察の瞬間に彼の創造物を作成する人（詩人、芸術家、発明家）です。 洞察を管理しますか？ やばい！ これは不可能です！



それにもかかわらず、常に創造性を管理するタスクは関連していました。 投資家、マネジャー、および州は、開発された創造的な製品がいつリリースされるかについての予測可能性を望んでいます（本、飛行機、コンピュータープログラム、または映画）。



創造的な仕事は、個々に（1人のクリエーター-科学者、芸術家、作曲家、または詩人）、および集合的に（異なる専門分野の人々のチームが作品の作成に取り組むとき）実行できます。 この記事では、世界中で販売されているアプリケーションを作成する、3か国のプログラマー、アーティスト、デザイナーの分散チームの例を使用して、クリエイティブチームの管理の問題に集中したいと思います。 毎年1,000万枚以上が販売されています。 年間収益は10億ドルです。



レストランを開きたいとしましょう。 クライアントはどの基準で評価しますか？ もちろん、これはキッチン、デザイン、サービスです。 通常、メンテナンスプロセス中に最大数の「グリッチ」が発生します。 人的要因が大きい場合。 かなり若いウェイトレスが顧客を引き付けているようです。 しかし、彼女の気分は悪くなり、慈悲深い態度の代わりに、彼女は失礼になり始めます。 その結果、顧客を引き付ける代わりに、顧客は勇敢です。 これは、ソフトウェア開発業界では容認できません。 さまざまな専門分野の専門家が相互にやり取りし、コミュニケーションの障壁やあらゆる種類の主観的なものをゼロに減らす必要があります。 そのため、大規模な国際チームで働く場合、人々間の非公式な関係は正式なビジネスプロセスに置き換えられ、主観的な評価（良い、クール、クール）の代わりに、メトリックと品質指標が使用されます。



大規模なプロジェクトでは、たとえ彼の給与が過剰に思えたとしても、市場で適切な専門家を購入する方が収益性が高くなります。 映画を撮影するとき、プロデューサーはスクリーンライターにこれを行う方法がわからない場合はダイアログを書くように教えませんが、市場でダイアログを書くためにスクリーンライターを買うだけです。 アプリケーション開発でも同じことを行います。 異なる国のチーム間で誤解がある場合は、1つのチームが長い旅に出されます。 数十億の収益があるので、出張のコストは重要ではありません。主なことは、製品を時間通りにリリースすることです。

制御オプション

実際のプロジェクトを管理するプロセスは、常にパラメーターのグループの制御に基づいています。 1つの変数の関数によって考えることを教えるのは学校でのみです。 残念なことに、一部の指導者は学校の習慣を採用し、管理上の問題に対する普遍的な救済策、つまりすべての病気に対する一種の薬を見つけようとしています。



例。 モバイルゲームの開発に携わるある会社では、カードにタスクを書き、このカードをボードに置くのが慣習でした。 ボードにはいくつかの縦縞が並んでいた。 各バーは問題の特定の状態に対応していました。 新しいタスクは左端のレーンに配置されました。 その後、彼らが進むにつれて、彼らは徐々に右に移動しました。 成功の主な基準であるリーダーシップは、ボード上のカードを左から右に移動することを検討しました。 このアプローチの欠点の1つは、多くの理由でタスクの作業を中断できることを考慮していないことであり、請負業者は一時的に別のタスクに切り替えることができます。 別の欠点は、作業中のタスクの数です。 このプロジェクトでは、1か月以内に200のタスクを完了する必要がありました。 ボード上に非常に多くのカードを配置することは物理的に不可能であることは明らかです。



以下は、プロジェクトマネージャーが制御する必要があるパラメーターのリストです。



1.タイミング。

2.ボリューム（有用な機能の数）。

3.作業量。

4.ユーティリティ（コンシューマーの値）。

5.技術的および技術的な複雑さ。

6.外部品質（消費者の観点から）。

7.内部品質（スペシャリスト、エンジニア、デザイナーの観点から）。

8.リスク。

9.チームの心理的状態。

管理プロセス

パラメータを制御するために、プロセスが使用されます。各プロセスは、アプリケーションの特定のツールと手順のセットになります。 以下で説明するプロセスの一部をリストします。



1.タスク管理。

2.時間管理。

3.品質管理。

4.リスク管理。

タスク管理

予定

作業量と従業員間のタスクの配分の評価。

タスク制御システム

目標

1.作業量を評価して記録します。



ご注意 従業員は自分でクラスを作成するのではなく、事前に承認されたリストのタスクに従事する必要があります。



例。 ある仕事では、「このタスクをどの時間枠で完了する必要がありますか？」という質問に答える上司がいました。常に同じ答えを返しました：「昨日」。 後に、私がボスになったとき、私はミラー状況がプログラマーで起こっていると確信するようになりました。 あなたは誰かに「この仕事をいつ終わらせますか」と尋ねると、答えは「明日は昼食。 最悪の場合、夕方までに。」 しかし、もう1日経つと、タスクはまだ完了していません。 そのような状況にできる限りまれに陥るには、定期的に残りの作業量を促すツールが必要です。



2.従業員間でタスクを分散します。 すべての従業員にタスクがあり、そのうちの1人がアイドル状態ではないことを確認してください。



注：ロシアの経済開発大臣（2012年5月21日-2013年6月24日）によれば、アンドレイ・ベロソフ、わが国の労働生産性は、計算方法（ http://www.forbes.ru / kompanii / 245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii ）。



例。 暖房本線での事故がどのように修理されるかを見たことがあるなら、おそらく1人の労働者が穴を掘っていることに気づいているでしょう。



また、従業員が一部のタスクを無視して他のタスクに悪影響を与えないようにする必要があります。



例。 ピーターズバーグのハイパーマーケットの1つでは、配管部門の売り手はイタリアのトイレとホットタブの近くにいることを好みます。高価な配管設備を販売するためのプレミアムが高いためです。 その結果、バイヤーがカップリングまたはクリンプを購入する場合、相談する相手はいません。 これは、売り手がいくつかのタスクを実行し、他のタスクを無視する方法です。 従業員は自分で設定するか、「よりおいしい」タスクを選択します。



3.異なるタスク間の依存関係を見つけます。



注 （Vasilina Abu-Navas、ビジネスコンサルタント、プラクティショナー協会）：タスクは、他の従業員のタスク、プロジェクト全体またはその一部と一貫している必要があります。 というのは、労働者との例を続けると、労働者がピットを掘り、お金を手に入れ、10人すべての「ボス」が報告し、翌日、注文が緊急にピットを埋めるようになったことが判明するからです。 彼らはこれについて長い間知っていました、彼らは単に警告するのを「忘れました」。 そして、「掘る」人は、いつものように、彼らのタスクのパラメーターを指定しませんでした...または、労働者は穴を掘りましたが、彼はもう少し広くまたは少し深く掘らなければならなかったことが判明しました...それは タスクは関連しているかもしれませんが、同時に調整されていないか、正確ではありません。



4.何らかの理由でブロックされているタスクを判別します。



例。 Kommersant新聞の基準によれば、ジャーナリストの資料、アーティストのドローイング、フォトジャーナリストの写真は、夕方6時までに提出する必要がありました。 編集者には特別な人、リライタもいます。リライタの仕事は、すべてのテキストを単一のスタイルにまとめることです。

説明

タスク制御システムは、スプレッドシートの形式で提示できます。



表1. GPSモバイルナビゲーションシステムのタスクリスト

役職	ステータス	責任者	面積	残存労働時間（時間）
交差点検索画面を追加	新しい	イワノフI.I.	住所検索	24
ロシアの地図のデータベースに美容院を追加する	進行中	ペトロフP.P.	場所を検索	8
新しいカードデザインスタイルを追加する	完成しました	シドロフS.S.	地図	0
サンクトペテルブルクの環状道路を通ってルートが構築されていない理由をご覧ください	ブロックされました	ドミトリエフD.D.	ルートビルディング	12

パラメータ

名前は、変更の本質を簡潔に説明しています。 理想的なケースでは、タスクが完了したかどうかを判断できる検証可能な基準を含める必要があります。



例：

• 交差点の検索画面を追加します。 （ 注：テストされた基準は画面です。そこにあるかどうかは不明です。）
• サンクトペテルブルクの環状道路を通ってルートが建設されない理由を見つけるため。 （ 注：テストされた基準は、環状道路を通るルートの建設です。）

タスクの名前には、タスクが属するプログラム領域（サブシステム）の名前が含まれる場合があります。 これは、どのスペシャリストを割り当てる必要があるかを理解するために、タスクを一見するのに役立ちます。



例：

• データベース-場所の検索-ロシアのデータベースに美容院を追加します。 （ 注：タスクは、技術的な観点から、データベースを変更する必要があるため、技術的な観点から、ユーザーの観点から、ナビゲーションシステムのこのセクションで変更を確認できるため、場所を検索するための2つの領域を直ちに参照します。）
• インターフェイス-マップ-マップのデザインに新しいスタイルを追加します。 （ 注：このタスクは、ナビゲーションシステムの2つのセクションに直接帰属させることもできます。ユーザーインターフェイス（マップデザインのスタイルを選択できる場所）、およびマップビジュアライゼーションサブシステムです。）

サブシステムは、タスクの名前だけでなく、別の列でも示すことができます。 これにより、「統計を打つ」ことができ、プログラムの特定の部分に関連する作業量を評価できます。



プログラムのサブシステムごとに従業員の資格、知識、および経験の要件が異なる場合、そのような統計情報により、適切な専門家の必要性を評価できます。



円グラフは、統計を視覚化するのに最適です。







図1. GPSモバイルナビゲーションシステムの作業範囲



タスクのステータスにより、どのタスクがすでに完了しているか、どのタスクが実行されているか、どのタスクがまだ開始されていないかを判断できます。 タスクがブロックされたことを通知する特別なステータスを持つことをお勧めします。 従業員がこのようなステータスを確立した場合、これは何らかの理由でタスクが不可能であることを意味します。



例。 アーティストがこれらのアイコンを描画する時間を持っていない場合、タスク「アイコンを置き換える」は完了できません。



残余労働投入量には、タスクの実際の評価、つまりタスクが完了するまでの残り時間が含まれます。 それは各就業日の終わりに請負業者によって与えられます。 したがって、タスクは定期的に再評価されます。 これにより、進行状況を監視し、チームが最新の状態に保てない場合に特定の措置を時間内に実行できます。

使用する

最初に、プロジェクト計画段階でタスクがタスク制御システムに入力されます。 主な困難は、すべてのタスクを予測し、タスクを完了するのにかかる時間を正確に評価することがかなり難しいという事実にあります。



プロジェクトを反復的に（2週間ごとまたは1週間ごとに）作業することをお勧めします。 （反復性は、いくつかの完成した作業を迅速に行い、フィードバックをすばやく得るのに役立ちます。）各反復の開始時に、詳細な計画が実行され、その結果、反復タスクが選択されます。 必要に応じて、タスクの詳細を説明し、その文言と評価を指定します。

ソフトウェア

タスクを管理するには、既製の無料または低コストのタスク制御システムを使用できます。

• ExcelまたはGoogle Docsスプレッドシート
• Redmine- http://www.redmine.org
• Jira- https: //www.atlassian.com/software/jira
• BugZilla- http: //www.bugzilla.org
• DropTask- http: //www.droptask.com
• Hansoft- http: //www.hansoft.com

複雑で洗練された高価なプロジェクト管理システムは、RedmineとExcelの共生に置き換えることができます。

時間管理

予定

プロジェクトの実施スケジュールの評価と監視。

タスク燃焼チャート

目標

許可：



1.現在の残存ワークロードを評価します。



例。 タイムラインを管理するための最も一般的なアプローチは、「金曜日までにタスクを完了する時間はありますか？」という目によるコントロールです。最も印象的な形で、ロシアとドイツの会社でこのアプローチに出会いました。 私の最初の営業日に、ドイツ人のオーナーが私のところに来て、こう尋ねました。「私は3ヶ月で誕生日を迎えます。 私の誕生日にゲームをリリースできますか？」



2.計画からラグの量を決定します。



3.各従業員とチーム全体の進捗を評価します。



ご注意 この場合、ダイアグラムのファミリーがあります。

チャート

図2.従業員の進捗（実際と予測）

説明

曲線を作成するために、補助表が作成されます。最初の列には従業員の名前がリストされ、残りの列には特定の日付の時間単位の従業員の残業量が含まれます。



1桁の代わりに、実際に残っている時間と、計画に従ってどれだけの時間を残すべきかという2桁が示されます。



表2.従業員の進捗

氏名		08/31/14	09/01/14	09/02/14	09/03/14	09/04/14	09/05/14
イワノフI.I.	本当に	38	32	28	20	14	8
	計画	38	30	22	14	6	0
ペトロフP.P.	本当に	40	32	26	18	11	0
	計画	40	32	24	16	8	0

注 （Anton Yakovlev、プログラマー）：説明したアプローチは、Excelを使用する場合に明らかに便利です。 他のシステムでは、アプローチが異なる場合があります-Hansoftは独自にこのような図を生成できます。

パラメータ

図は2つの曲線です。 それらの1つ（点線で描かれている）は、作業量の計画された減少を示しています。 あるべき姿。 2番目の曲線（実線で描画）は、作業量の実際の変化を表しています。 これらの曲線の各ポイントは、一日の終わりに残った計画または実際の作業量です。

使用する

曲線は、各従業員に対して個別にプロットされ、チーム全体としてもプロットされます。



各就業日の終わりに、データ（時間単位の残りの作業量）がテーブルに入力されます。 データは、「残り時間がかかる」タスクテーブルの列から取得されます。



タスクの条件が増加した理由が分析され、その後、会社の特別な知識ベースに入力されます。

品質管理

予定

適切な製品品質の確保。



例。 2013年、ロシアの離婚数は、登録された結婚数の54.5％に達しました（ http://womanadvice.ru/statistika-razvodov-v-rossii ）。 ソフトウェア開発業界におけるこのような多数の「結婚」は、単に受け入れられません。 州は離婚件数の削減に関心を持っているという事実にもかかわらず、そのような悲しい統計の理由は州によって収集され分析されていません。 しかし、ソフトウェアを開発するとき、これは行われます。



大企業は、開発の前に製品の品質を計画します。 プロジェクトの作業中に発見される欠陥の数だけでなく、修正されない欠陥の数も予測します。



例。 プロジェクトの1つで3万（！）の欠陥が見つかりました。 これらのうち、15％は修正されていません。 これらは重大ではない、または非常にまれなエラーであるにもかかわらず、4,500のエラーでアプリケーションがリリースされたと言えます。

欠陥予測

目標

1. プロジェクトの複雑さを評価します。
2. 品質の微調整に必要なリソースを評価します。

説明

アプリケーションが定期的にリリースされる場合（たとえば、毎年新しいバージョン）、予測は履歴データに基づいている必要があります。 これは、以前のバージョンの統計と新しいバージョンの予測指標を提供する表形式で表示できます。



表3.モバイルナビゲーションシステムGPSの欠陥数の予測

面積	2013年（現実）	2014（予想）
ユーザーインターフェース	243	250
ルートビルディング	113	100
住所検索	53	50
場所を検索	17	20
地図	194	200
ナビゲーション	89	100
音声	67	50
合計	776	770

パラメータ

「地域」列には、プログラムのサブシステムがリストされています。 それらは、さまざまな理由で論理的な分割によって取得できます。 時々、プログラムはユーザーの観点から部分に分割されます（下の表のように）。 他の場合には、技術的な基準が使用されます。



中央の列は、実際の履歴データ、つまりプログラムの以前のバージョンでプログラムのさまざまな部分で検出された欠陥の数を示しています。



最後の列は、予測データを示しています。次のバージョンを開発するときに、プログラムの1つまたは別の部分で検出される欠陥の数です。

使用する

プロジェクトが開始されると、品質管理部門がバグの予測を作成します。 履歴データ、予想される作業量、アプリケーションの新しいバージョンの要件の複雑さ、およびチーム自体の経験が考慮されます。



予測はサブシステムによって提供されます。 精度を高めるために、2つの異なるモデルが使用されます。 最初のモデルでは、さまざまな技術的基準に基づいてプログラムをサブシステムに分割します。



例：

• ユーザーインターフェース
• データベース
• 音声
• アルゴリズム

2番目のモデルは、ユーザーの機能に応じてプログラムをサブシステムに分割します。



例：

• 地図を描く
• ルートビルディング
• ナビゲーション
• 住所検索

異なる予測モデルが互いに補完し、テストします。



欠陥の数の予測は単純な形式ではなく、作業を計画するための深刻なツールです。 プロジェクトに引き付ける品質によってエンジニアの数を決定するのに役立ちます。 予測では、プログラムを安定させるのに必要な時間を計算することもできます。



欠陥数の予測は、かなり保守的なツールです。 経営者はそれを非常に渋々レビューします。なぜなら、それを下向きにレビューすると、再現が難しいエラーが検索されないという事実につながる可能性があるからです。 適切な基準がない場合、品質エンジニアは単にリラックスして、自分の仕事をできる以上に悪くすると思われます。



例。 プロジェクトの1つでは、実際の欠陥数は予測値を下回っていました。 統計によると、品質エンジニアは仕事に対応できませんでした。 予測よりも少ないエラーが見つかりました。 実装された要件の数が少ないために、かなりの数の欠陥がないことが客観的であるという事実にもかかわらず、マネージャーはプログラムに隠れたエラーがあることを恐れていたため、予測を長期間修正しなかったが、週末に処理を手配することを好んだ。

欠陥検索計画

これは、サブシステムおよび時間ごとの欠陥数の詳細な予測です。 原則として、時間単位ごとに週が選択されます。

目標

1. 品質管理を担当するリソースを長期にわたって配布します。
2. 品質エンジニアの作業を制御するメカニズムを取得します。

注：欠陥検索計画は、すべての品質エンジニアの基準を設定します。 これは、プロジェクトの週ごとに欠陥の総数を分配することにより、以前に作成された予測に基づいています。 品質エンジニアのチームは毎週の割り当てを受けます-所定の週内にプログラムで発見する必要のある欠陥の数。 週ごとの割り当ては、日ごとおよび従業員ごとにさらに詳細に設定できます。 その結果、各エンジニアの毎日のタスクが取得されます。

説明

欠陥検索計画は、品質エンジニアのチーム全体の望ましいパフォーマンスインジケータがプロジェクトの各週に入力される表です。



表4. GPSモバイルナビゲーションシステムの週間欠陥検索計画

面積	09/01/14	09/08/14	09/15/14	09/22/14
ユーザーインターフェース	5	5	10	12
ルートビルディング	3	3	5	7
住所検索	5	5	5	8
場所を検索	0	1	2	3
地図	3	5	7	8
ナビゲーション	8	10	10	12
音声	0	1	2	3
合計	24	30	41	53

パラメータ

サブシステムの名前の反対側の各セルに示されています

特定の週内に検出される欠陥の数。

週末の終了日は列見出しで設定されます。

チャート

計画に基づいて、S字曲線である欠陥検索スケジュールが作成されます。



縦軸は発見された欠陥の総数を「パーセント」で示し、横軸は時間を表します。



スケジュールは、プロジェクトの主要な日付であるアルファ版、ベータ版、最終版も延期します。





図3.プロジェクトの全期間の欠陥検索計画のグラフィカル表現

使用する

視覚的には、曲線上の3つの段階を区別できます。



最初の段階は、プロジェクトの開始から始まり、アルファ版のリリースで終わります。 現時点では、アルファ版の前に、欠陥を見つけるのではなく、プログラムの開発が優先されるため、曲線はそれほど大きくなりません。 すべての要件がまだ実装されているわけではありませんが、行われたことは完全には実装されていない可能性があります。



第2段階では、アルファ版とベータ版の間で、曲線が非常に集中的に成長します。 これは、この時点で計画された要件のほぼすべてが既に実装されており、追加の品質エンジニアがプログラムのテストに関与しており、プログラマーが要件の実装から欠陥の修正に切り替えるためです。



ベータの少し前に、多くの欠陥は残っていません。 最も明白なものはすでに発見され、修正されています。 明らかではないエラーが現れ始めますが、それを見つけて修正するのはより困難です。 曲線はその成長を遅くします。 また、しばらくすると、明らかでないエラーも修正されたように見え、曲線は拡大しなくなります。 この時点で、プログラムのベータ版がリリースされています。 そして-新しいエラーが検出されない場合-最終バージョンがリリースされます。



アルファ版の時点では、テスト部門はすべての欠陥の30％を発見しているはずです。 ベータ版では、すべての欠陥の98％が発見されるはずです。

リスク管理

予定

プロジェクトを複雑化または混乱させる可能性のあるリスクを想定するには、リスクが発生した場合のアクションプランを作成して、その結果を中和します。



注：システムエンジニアリングには、「故障モードと影響分析」と呼ばれる方法論があります（https://ru.wikipedia.org/wiki/FMEA） 。 米国国防総省の標準によれば、この手順はシステムの潜在的なエラーを分析し、システム全体およびさまざまなサブシステムの両方に対する影響の結果を判断し、エラーを重大度に関連して分類します。



リスク管理は、失敗の種類と結果の分析に似ています。リスクを特定し、プロジェクトに対するそれらの負の影響を評価し、負の結果を中和する解決策を見つけます。

リスク登録

目標

1.特定されたリスクを説明します。



注：多くの企業の特徴的な問題の1つ（分散さえしていませんが、従業員は同じオフィスにいます）-人は経験を共有しません。 標準エラー、リスク、決定に関する情報の交換はありません。 すべてを白色光の中に引き出して、会社全体がアクセスできるようにする必要があります。



注 （Vasilina Abu-Navas、ビジネスコンサルタント、Praktik協会）：さらにあります：ソリューションをすぐに説明する必要があります（可能であれば、完璧なソリューションを見つける必要があります）。 つまり リスクを特定するだけでは十分ではありません-すぐにそれを防ぐ方法を考えなければなりません。 そうでなければ、リスクは「熊手」のままです。



例 （Vasilina Abu-Navas、ビジネスコンサルタント、Association "Practician"）：私たちのクライアントは、1か月間2,500万ルーブルの運転資本を凍結するという仕事をしていました。 財務ディレクターは休暇中だったため、税金を除くすべてのリスクを考慮に入れたようで、このタスクが解決されることを知っていたため 、彼は何も言わなかった 。 資金を解凍するための優れた計画を立て、それを実行しました。 その結果、利益税が課せられます。 このリスクを考慮に入れると、収益を不動産の取得に費やすことができ、それにより税金の支払いを避けることができます。



2.各リスクの重要性とその発生の可能性を評価します。



例。 会社のオフィスにmet石が入ることによりプロジェクトが終了するリスクは非常に重要です。 それでも、その動作の可能性は非常に低いため、このリスクを簡単に無視できます。



例。 GPSナビゲーターを開発しているある会社は、マッププロバイダーの変更を決定しました。 変更の理由は簡単です。ライセンスコストは2倍低く、カードの記述形式は同じです。 それにもかかわらず、新しいサプライヤのカードに切り替えるコストは、会社に2〜3人年かかりました。 これが、発生した技術的問題の解決にどれだけの労力を費やしたかです。



3.リスクが機能する場合のアクションプランを提供します。



例。 小さな女の子向けに1つのゲームを作成する場合、期限に間に合わない重大なリスクがありました。 このリスクにはいくつかの理由がありました。新しいチーム、開発が進行中のなじみのないプラットフォーム、適切に機能する技術インフラの欠如です。 リスクを軽減するために、一連のミニゲームの形でゲームを整理することが決定されました。 そのような各ゲームは非常にシンプルで、グラフィックや他のキャラクターが豊富ではありませんでした。 さらに、プレーヤーは移動の自由を奪われました。 あらかじめ決められた方向にしか移動できません 開発プロセスが非常に簡素化されたため、最終品質のミニゲームが5人日で作成されました（これは、アーティストの仕事を考慮しないエンジニアの仕事を指します）。



4.除去の責任者にリスクを分散します。

説明

以下の例のように、特定されたすべてのリスクは特別なテーブルに入力されます。



表5. GPSモバイルナビゲーションシステムのリスクテーブル

リスク	重要性	確率	重さ	どうする	責任者	状態
プログラマが10月15日までにサプライヤから新しいカードを受け取らない場合、リリースに含まれません。	平均	低い	2	email	..
1- ,			9		..	, ''

各リスクは、式に従って記述され



ます。<特定の日付>の前に何かが<完了>されていない場合、<負のことが発生します>。



各リスクは、その重要性の観点から評価する必要があります。プロジェクトがトリガーされたときのプロジェクトの負の結果。通常、低、中、高の3つの評価のスケールに制限されます。



リスクが発生する可能性も評価する必要があります。評価のために、低、中、高の3つの値に制限することもできます。



リスクの重みは、その重要度と確率に基づいて自動的に計算されます。これを行うために、推定値は次のように数値に変換されます。「低」値は1、「平均」-2、「高」-3になります。重量は2つの評価の積として計算されます。たとえば、リスクの重要性が高く、その発生の可能性も高い場合、リスクの重みは9になります。

使用する

限られたリソースで、まず第一に、最も重要なリスクに注意を払う必要があります。

リスクを説明する場合、発生した場合、または発生の可能性や重要性を減らすために、アクションプランも追加する必要があります。リスクごとに、その中和に責任を持つ人が任命されます。

おわりに

1. ソフトウェア開発プロジェクトは、個人と集団の両方です。
2. . , .
3. (100 – 200 ), . .
4. . .
5. , : , , , ..
6. 各管理プロセスは、アプリケーションの1つ以上のツールと方法に縮小されます。ツールには、タスク制御システム、タスク燃焼チャート、欠陥数の予測、欠陥を見つけるための計画、リスク登録簿があります。

著者はヴァシリーナ・アブ・ナバス（協会「開業医」）、I.L。に感謝します。Vikentieva（TRIZ-CHANCEシステム）、Eduard Galiaskarov、およびAnton Yakovlevが記事の準備に協力してくれました。