権限のない責任は無意味 - 技術ベースの解決策?

https://stackoverflow.com/questions/133847

02-07-2019
|

質問

私の父はいつも「権限のない責任は無意味だ」と言っています。

しかし、開発者として私たちは常に次のような状況に陥っていることに気づきました。

ソフトウェアに「バグがない」ことを保証する責任はありますが、バグ追跡システムを実装する権限はありません
プロジェクトの期限を守る責任はありますが、要件、品質、チームリソース (プロジェクト管理の 3 つの部分) に影響を与えることはできません
等

もちろん、これを回避するために言えることはたくさんあります - 新しい仕事を見つける、上司と戦うなど...

しかし、この問題に対する技術的な解決策はどうでしょうか?つまり、どのようなコーディングができるのかというと、 自分で これらの問題の一部を修正するようチームを説得する必要はありません。または、追跡されていないバグが原因で損害を被っていること、品質上の問題により期限が守られていないことを証明するにはどのようなツールを使用できますか、またこれらのツールを使用してより多くの成果を得るにはどうすればよいでしょうか。上司でなくても「権威」？

***例 - 上司があなたのところに来て、「なぜそんなにたくさんのバグがあるのか!!？！？」と言います。 - 私たちのほとんどは、「私たちにはそれらを追跡するのに適したシステムがありません！」と言うでしょうが、これは通常私の経験の言い訳として見られます。では、あるレポート (マネージャーはレポートが大好きです) を指して、「ほら、これが理由です」と言ったらどうなるでしょうか?

解決

あなたにできるのは最善を尽くすことだけです。ソフトウェアを成功させる鍵が自分の手、つまりチームの一員だけにあり、すべてに対して責任を負う必要はない、などと考えないでください。

あなたは明らかにあなたのソフトウェアに悪影響を与える環境にいますが、彼の行動をすべて変えることはできません。そのため、あなた自身の環境から始めて、独自のバグ、期限、要件、品質、リソースでは解決できないチームとして作業を開始することをお勧めします。残りの混乱は面倒ですが、仕事では最高のパフォーマンスを発揮するように努めてください。

上司に自分の計画や進捗状況の報告を示し、必要なときに追加のリソースを要求し、上司がリソースを与えるか与えないかによって自分の計画がどのような影響を受けるかを上司に示す、自主的なチームとして働きます。

これに関する詳細なアドバイスは、 PSP そして TSP ウィキペディアの記事

上司に良い仕事を見せ、自分の締め切りを守れば、きっと上司はあなたをさらに信頼し、あなたのアイデアをチーム全体に広めてくれるでしょう。

他のヒント

バグ追跡システムは必要ありません。必要なのは自動テストです。単体テストなど。Makefile を使用して自動テストをセットアップできます。経営者によってブロックされている道は常に見つかりますが、それは仕事の制約内でできることがないという意味ではありません。もちろん、答えは「別の仕事を探す」かもしれません。今すぐ別の仕事を見つけることができない場合は、できるようにいくつかのスキルを学びましょう。

簡単な答えは、自分でツールを使い始めることができるということです。

あなたの 自分の 仕事。コードを修正してほしい場合は、バグを報告するように伝えてください。その方法を教えてください。何もインストールせずに実行できることを確認してください。彼らは状況の最新情報を望んでいますか？バグをチェックするように伝えてください。コードの変更について尋ねられますか?ソース管理履歴クエリの作成方法を教えてください。または箱に表示してください。これを見せ始めてください作品.

そして、彼らから同じ結果が必要な場合は、彼らに足回りを要求してください。ソース管理で変更が見つからない場合は、バックアップテープから手動でリビジョンの差分を取得するよう依頼してください。彼らの仕事、あるいはソース管理やバグ追跡の仕事を彼らに代わって行わないでください。

そして最も重要なことは、この仲間からのプレッシャーをかけるとき、 よろしくね. 。ハエも蜂蜜もすべて。

彼らがそれを理解しない場合は、あなたが唯一であり続けることができますプロの開発者あなたの会社やグループで。少なくとも、履歴書を埋めるのに役立ちます。 「製品の品質を向上させるために CVS と FogBugs をセットアップし、他の人に指示した経験」 など。

追跡されていないバグがチームの高品質なコード作成能力に悪影響を及ぼしていることを示すための具体的なツールについては、バグの影響を示す前にバグを追跡するものが必要であるため、ここでキャッチ 22 が得られます。追跡できないものは測定できません。じゃあ何をすればいいの？

類似の例として、最近、電子メールでコードレビューを行う方法がばかげていると感じた男性がチームに加わりました。そこで、彼はオープンソースツールを見つけて自分のボックスにインストールし、数人のオープンマインドなチームメンバーにしばらく試してもらい、その後チームリーダーにデモを行いました。数週間以内に、彼はすべてのチームにそれをデモする機会を得ました。その新人は会社全体に影響を与えていた。このゲリラ的なツール採用の話をよく聞いています。

重要なのは、決定を下す権限を持っている人を特定し、彼らが何を重視しているかを見つけ出し、実装したいものが彼らの価値を提供するという十分な証拠を収集することです。

組織の中間または下位からリーダーシップを発揮する方法についてより詳しく知りたい場合は、John Maxwell の著書を参照してください。 360 度のリーダー.

品質とその生産性への影響に関するレポートが必要な場合は、次のものが最適です。http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html ケイパー・ジョーンズは数冊の本を出版しており、今でもカンファレンスに出席しています。優れた IDE 以外では、開発者/IT グループはソースコード管理 (VSS、SubVersion など) と問題追跡を必要とします。

会計士が複式簿記を使用せず、残高も考慮せずに一連の勘定科目を作成するように求められた場合、会計士がそうすることを期待する人は誰もいないでしょう。

しかし、複式記入は 13 世紀頃から会計士によって標準的に使用されてきました。

私たちが職業として、それがなくてもオンワンが機能するほど根付いた標準的な慣行を確立するには、長い時間がかかるでしょう。

申し訳ありませんが、今後このような問題に直面することになると思います 多くの 来年。

質問に直接答えられなくて申し訳ありませんが...

あなたが言及する失敗はコミュニケーションの一つであると強く感じます。職場環境やプロセスを改善するために必要な権限を活用できるほど十分に尊敬され、十分に信頼されるまでコミュニケーションスキルを磨くことが、専門家としての私たちの責務です。あなたが提案する方法。

つまり、職場でのコミュニケーション不足によって生じるすべての問題を解決できる技術的な解決策は存在しないと思います。

むしろ、テクノロジーのせいで直接対面でのコミュニケーションが減少しています。

申し訳ありませんが、また話が逸れてしまいました。ご自由に downmod してください。

コーディングだけでできるのは、自分のソースファイルを整頓し、適切にコメントを付け、テストでバグ数を少なく保つことだけです。ただし、進捗状況やバグを追跡するには外部ツール (bugzilla、yoxel、trac、ガントダイアグラムツール、Mylyn for Eclipse、ブログなど) が必要になります。このような場合、人々、規律、良い習慣、そしてリーダーシップが圧倒的な力となり、ソフトウェアツールや個人からのオファーは単独で勝つことはできません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow