開発者にプロジェクト管理を行わせるソフトウェアマネージャー

私は組み込みシステム会社で働くソフトウェア開発者です。プロジェクトマネージャーがいて、プロジェクトの全体的なスケジュール（電気、品質、ソフトウェア、製造など）を担当しているため、ソフトウェアスケジュールは非常に短いです。

私の上司であるソフトウェアマネージャーもいます。彼は、ソフトウェアのスケジュール、設計文書（高レベルおよび低レベルの設計）、SRS、変更管理、検証計画とレポート、リリース管理、レビュー、そしてもちろんソフトウェアの作成と保守をさせてくれます。

ソフトウェアチーム全体（10人のメンバー）に対応するテストエンジニアは1人だけであり、常にいくつかのプロジェクトが進行中です。

私はこれらのドキュメントを作成するのに80％の時間を費やしています。私の上司はプロセスのバックグラウンドから来ており、必要なのはソフトウェアを改善するためのより良いドキュメントであると考えています。

1. 彼はデザインが最重要であると考え、コーディングは「デザインを書き留める」だけで、それほど長くはかからず、「ハードウェアの準備ができる前にすべてのコードを書く」必要があります。
2. 分散モデルとのコラボレーションが簡単だと彼に言った後でも、中央バージョンと分散バージョンコントロールの違いを理解していません。
3. コードを理解していないため、すべてのバグとその提案された解決策を理解したいと考えています。
4. 検証は開発者が行い、検証はテスターが行うべきだと考えています。ただし、検証では実装が正しいかどうかのみをチェックし（単体テストは作成せず、スケジュールでは考慮されません）、検証はブラックボックステストであるため、単体テストはありません。

私は本当に混乱しています。

1. これらすべての文書を管理する責任はありますか？本質的に、ソフトウェアプロジェクト管理を行っているような気分になります。技術文書は問題ありませんが、開発者がスケジューリング/計画を立てるべきではないと考えています。
2. 私はドキュメントの作成が本当に好きではありません。問題を解決してコードを書きたいです。私の経験では、設計ドキュメントの作成はある程度までしか役に立ちませんが、コードの改善や高速化の解決策になることはありません。
3. 上司はより良い製品を作ることを本当に気にせず、経営者の目には良いマネージャーになることだけに関心があると思います。

私に何ができる？今年は3か月間実際のコーディングを行い、残りはドキュメントの作成とクライアントからのバグレポートの待機に費やしました。

あなたはソフトウェアエンジニアのように聞こえます。

プロジェクトマネージャーは、プロジェクト全体のステータスに重点を置き、効果的な方法でリソースを割り当てて、マイルストーンが適切なタイミングで満たされるようにします。また、障害を取り除き、プロジェクトリソースが特定の職務に集中できるようにします。

設計および技術文書の作成と保守は、ソフトウェアエンジニアとしての重要な部分であり、あなたの役割に適しています。しかし、あまりにも良いことは悪いことかもしれません（分析パライルシスを参照）。

彼はデザインが最重要だと考え、コーディングは「デザインを書き留める」

プロジェクトマネージャーが設計文書を最重要と考える場合、その文書はプロセスの成果物であると期待します。彼があなたの時間の80％を割り当てるのに十分に重要であると感じるなら、それはあなたの無駄な時間ではありません。

それほど長くはかからず、「ハードウェアの準備ができる前にすべてのコードを書く必要があります」。

これは希望的観測であり、ソフトウェア開発がどのように機能するかについてのかなり時代遅れのウォーターフォールスタイルのビューです。どんなに多くのデザインと準備を捧げても、それは常にそれほどきれいではありません。ただし、そのノートでは、明確なハードウェア仕様と適切なテスト環境、およびコードとやり取りするための模擬ハードウェアシミュレーションを用意する必要がありますが、実世界は厄介です。

完璧な世界では、プロジェクト管理は非常に簡単です。世界は完璧ではありませんが、いくら望んでも、実際のプロジェクト管理を非常に難しくしています。これが彼らに大金が支払われる理由です。

（2）中央バージョンと分散バージョンのコントロールの違いを理解していません。

なぜ彼は気にする必要がありますか？マイルストーンにどのように影響しますか？そうではありません。

3）コードを理解しておらず、すべてのバグとその提案された解決策を理解したい

彼の目標はソフトウェアを動かすことであり、あなたもそうするべきです。彼はコードを理解する必要はありませんが、ソフトウェアの動作を妨げる問題を理解する必要があります。ふたりがこの基本的なレベルに目を向けると、あなたの相互の目標は、あなたがより効果的に協力するのに役立ちます。

（4）検証は開発者が行い、検証はテスターが行うべきだと考えています。

この感情の何が問題になっていますか？品質保証の役割のテスターは、機能と要件の検証に関心を持つ必要があります。開発者は、テストに進む前に作業を検証およびテストするためにあらゆる努力を払う必要があります。

私はドキュメントの作成が本当に好きではありません。問題を解決してコードを書きたいです。

単純なプログラマーになりたい場合は、おそらく上司にこのことについて話し、プロジェクトでより良い役割があるかどうかを確認する必要があります。誰かが技術文書を書いて保守する必要があるので、おそらく他の開発者の一人がこれらのタスクのいくつかを手伝ってくれるので、文書の作成に80％の時間を費やす必要はありません。

私の経験では、設計ドキュメントの作成はある程度までしか役に立ちませんが、コードの改善や高速化の解決策になることはありません。

これはほとんど真実です...しかし、10人の開発者全員が時間の80％を誰も読まない技術文書の作成に費やしている場合のみです。これは私が以前に住んでいた巨大な管理アンチパターンです。チームのドキュメントのほとんどを作成していることに気付いた場合、より多くのコーディング作業を実行する権利を拒否されているとは思えません。

問題の事実は、最良の技術文書はコードそのものです。

上司はより良い製品を作ることを本当に気にせず、経営者の目には良いマネージャーになることだけに関心があると思います

製品が彼の病棟であり、プロジェクトと機能が完了せず、クライアントが満足していない場合、彼は気にしていると思います。問題は、必要な品質改善についてのあなたの見方が彼や上層部の経営陣と一致せず、彼らが感じていることに対するクライアントの認識が重要であるということです。

製品にとって本当に重要なことを理解してみてください。プロセスの効率を3倍に高めることができますが、1週間かけてこれを行うと、クライアントが要求する別の重要な機能が犠牲になります。

私たちは皆、上司の目によく似合いたいと思っています。それには何の問題もありません。利己的なのは人間の本性です。これは人生の事実です。

ある程度、プロジェクトマネージャーに同意します。ソフトウェア開発は、コーディング機能をはるかに超えています。:-)

あなたの状況を考えると、私は彼に行き、彼の要求があなたの時間の80％を費やしていることを説明し、開発のためではなくドキュメントを維持するためにこの時間を費やすことが彼にとって重要である理由を理解しようとします（コーディングを超えています）。

参考までに、ソフトウェア会社であるAtlassionは、QA担当者1人につき13人の開発者を抱えており、ほとんどのテスト（計画と実行）は開発者によって行われます。これは、アジャイル2012でのプレゼンテーションの1つと、現在このプラクティスをエミュレートしようとしているチームでこれを学びました。

ただし、チーム全体を前進させるための方法論としてスクラムを試してみることができる場合は、プロジェクトマネージャーと話し合います。あなたの説明を考えると、私はあなたがスクラムを使用しているとは思わない。

あなたのように、私は絶えず変化する計画を維持することに非常にイライラし、スクラムの軽量アプローチはこの不満を克服するのに役立ちました。

私の経験で最もパフォーマンスの高いチームは、作業に必要な最小限のプロセスに直面したチームです。ある時点で、製品から品質を奪う追加プロセスが開始されます。QAが書類の邪魔をすることに関心があるためにバグを見逃し始め、DEVがドキュメントを書いているために機能のコーディングやバグの修正を行っていない場合、問題が発生します。しかし、これが実際にあなたの会社のケースであるかどうかを判断することは、チームの人々だけが答えることができる非常にローカライズされた質問です（私たちではありません）。

上司が非常に間違っている点が1つあります。それは、QAがほとんどなく、単体テストがないことです。adeveloperによって作成されたバグは、定義上、それらの部分の監視です。開発者が常に独自の機能をテストすることを期待し、それ以外のテストがほとんどないことはプロセスの問題です。QAは、ドメインに応じてある程度自動テストに置き換えることができますが、どちらもなければバグをすり抜けてしまう可能性があります（通常、早期に発見するよりもコストがかかります）。

また、厳しいビジネスの観点から、QAの採用は開発者の採用よりも安価です。チームのQA / DEV比率が良好であれば、費やしたお金をより多くカバーできます。

私が見た、または直接聞いたCMMI実装は、すべてプロセスとドキュメントが多かった。あなたのボスは、実装を些細なものにするために文書は十分に詳細にすべきであると信じており、彼の期待が似ていることを強く示唆しています。

文書作成/保守の不均衡なシェアを受け取っている場合、それをより均等に配布するように求めるのは合理的です。他の開発者がコーディング率と同様のドキュメントを持っている場合、コードの作成にほとんどの時間を費やしたい場合。新しい雇用者を見つけることを検討する時が来るかもしれません。

あなたは医療システムについて話している...そのため、安全性が最重要です-したがって、文書化（特にトレーサビリティ）は不可欠です。

1人のテスターは少し軽いように見えますが、それ以外は、はい-あなたはドキュメントを確実に配置する責任があります。

医療の世界での私の経験は限られていますが、航空宇宙/防衛の世界ではDo-178B（現在のC）があります。これは、必要なテストのドキュメントとレベル（より具体的にはソフトウェアの設計保証レベル]、および自動車の世界ではISO26262があります。

ドキュメントが適切に配置されていない場合、製品は認証されません。

しかし、重要なことは、必要なドキュメントを使用して製品を改善することです。ドキュメントを後から考えてリバースエンジニアリングしないでください。