ソフトウェア開発プロジェクトの時間追跡について

私の仕事では、ソフトウェア開発に費やした時間を会計処理するアプローチの問題を頻繁に議論する必要があります。 各タスクの時間を考慮する必要がありますか? 毎日報告する必要がありますか? タイムシールドは便利ですか? 誰がいつレポートを記入する必要がありますか? 等 時には、アジャイルの方法論とより厳格な管理方法の対立に直面することがあります。

そのような議論は、論争、視点の対立に変わり、「もちろん、各企業には固有の特性と特性、独自のビジネスモデル、したがってリソースの会計処理に対する独自のアプローチがあります。」という調整的なフレーズで終わります。 概して、リソースのアカウンティングの原則はビジネスモデルに依存しているため、これは正しいのですが、それでもさまざまな関係者やアプローチの蓄積された議論を1か所に集めたいと思います。議論や意見の対立の形で、コメントや読者の声の影響を受けます。

私の意見では、さまざまなオプションは3つの基本的なアプローチに分類されます。

  1. タスクによって費やされた工数の計算
  2. 実装された機能(バックログ/要件)の会計と作業コストの一般的な評価
  3. 機能とリソース制御のリストなしの創造的な仕事


次の側面のアプローチを選択する際の違いと議論を見てみましょう。



3番目の方法については説明できないため、最初の2つの方法について説明し、対比します。 私はさまざまな企業やさまざまなプロジェクト、さまざまなテクノロジー、さまざまな管理スキームで仕事をしなければなりませんでした...

そして、最も興味深い、技術的に洗練された高度な、最も珍しいプロジェクトは、3番目のアプローチに従って正確に作成されました。 インタビューで話したのはこれらのプロジェクトについてであり、基本的に新しい製品が作成され、データベース→ビジネスロジック→ビジネスプロセス→クライアントプレゼンテーション→レポートなどのすべての迷惑なルーチンではありませんでした。 私はこれらのプロジェクトの仕事を誇りに思います。懐かしく思い出し、「これらの建築上の決定を下した」と言うことをためらわないでください。通常、人々は大きな関心を持ってこれらのプロジェクトについて聞きます。 しかし一方で、非常に高価で経済的に疑わしいのはこれらのプロジェクトでした。 今、私はそのようなプロジェクトについて賛否両論を述べる準備ができていないので、2つのアプローチのみを検討します。



タイムシート

各タスクの時間追跡

バックログ

反復および関数に費やされた合計時間の説明

労働時間の会計処理(タイムシート)の独立したまたは統合されたシステムがあり、従業員は1日に8労働時間を費やす情報を入力する必要があります。 詳細の極端な場合

タスクの作業の各段階で費やした時間の固定、またはタスクが1日以上続いた場合の特定の日付によるコストの強制的な内訳を呼び出すことができます。



タイムシートシステムがプロジェクト管理から分離されている場合、2つ目のケース、つまり時計がプロジェクトまたは大規模な高レベルタスクに「借方記入」されるまで、アカウンティングは縮退する可能性があります。



チームには、要件管理システムと選択方法論があります

反復で実装するための多くの要件。 これには、バックログ、要件のリスト、変更と欠陥のリクエスト、SCRUMまたはかんばんタスクボードなどがあります。



反復のためのチーム全体の総コストが考慮されますが、ストーリーポイントまたは複雑度ポイントにおける要件の複雑度の条件付き評価も行うことができます。

「流体」の小さなタスクの説明

特別なタスク「その他の作業」を割り当てることができます。これは、小さな作業が償却される作業時間のわずかな割合を占めます。

作業が特定のしきい値を超える場合、特定のプロジェクトのフレームワーク内で個別のタスクとして開始されます。



マイナス :複数のプロジェクトの場合、エグゼキューターは1つのタスク「他の作業」を作成します。これにより、作業の分散の精度が多少低下します。



マイナータスクはプロジェクトの総コストに含まれます。



疑い :小規模な仕事の会計が不足しているため、仕事が簡素化されますが、主要なタスクを損なうために、小規模な仕事では「行き詰まる」危険があります。

ただし、計画された機能の実装の最終的な有効性の評価により、主要な作業と管理されていない小規模な作業のバランスを十分に制御できます。

事後評価

各タスクについて、実際のコストは既知です。 実行された作業のコストに関する大量の詳細データが利用可能です。



原価計算の精度は、人件費を合計する方法の可用性と品質に大きく依存します。



実行者は設計タスクでの自然な労働損失をマスクする必要があるため 、推定値の信頼性 が低下する可能性があり、間接的に推定値を歪める可能性があります。



さらに 、最も時間のかかるタスク、労働損失の原因を特定し、労働集約度の構造を分析できます。



プラス :事後の個々の機能の実装コストを正確に評価できます。



マイナス :会計のための高い追加費用。



反復全体の総人件費がわかっています。 サブタスクによる詳細なしの機能の総コストが計算されます。



すべての実際の作業と損失が自然に含まれるためコスト計算の精度は非常に高くなります。



見積もりの信頼性高く 、チームはなんらかの方法で詳細な情報を入力したり、架空の情報をコスト構造に入力したりする必要がないためです。



疑い:労働損失の原因分析は定性的であるが、定量的ではなく、定式化されていない。



さらに 、追加の会計コストが低い。

将来のプロジェクトの評価のためのデータの蓄積

タスクの複雑さの初期評価のために精度統計が蓄積され、

高レベルの機能/シナリオの実装のための有限の人件費

使用します。 たとえば、簡略化された形式では、これは、各レベルの複雑さに対して、以前のプロジェクトでの実装の平均集約コストが示された表になります。

すべてのタスクのコストは、実装された機能へのタスクのバインドに関するデータに基づいて要約されます。



さらに 、すべての作品に関する詳細情報が収集されます。



マイナス:予期しない作業はアカウンティングのためにシステムに入力する必要があるため、正しい機能のアカウンティングにそれらを常に確実に割り当てることができず、推定がゆがめられます。



システムには、機能の複雑さのレベルと、実装の実際の総コストがあります。



さらに、集計された評価には、実際のコストのレベルとすべての損失が含まれます。これにより、避けられない損失のレベルも考慮に入れて、将来のコストを見積もることができます。



注: T&Mプロジェクトの場合、推定値を累積するタスクはまったく関係ない場合があります。

プロジェクト監視
従業員に仕事に費やした時間を毎日報告する義務を負わせる機会があります。これにより、従業員は仕事の進捗状況の詳細な写真を得ることができます。



さらに 、開発プロセスの機器による監視を使用することもできます。



マイナス :データの信頼性は、損失をマスクする必要があるため、また人件費を毎日詳細に記録したくないため、大きく歪む可能性があります。

プロジェクトの進捗状況の正式な監視は、機能の実装の進捗レベルでのみ利用できます。 問題に関する詳細な進捗状況と情報は、毎日の「ステータス」に参加している特定のプロジェクトのマネージャーのみが利用できます。



さらに 、要件の実装の進捗に関する情報の高い信頼性。 プロジェクト内の問題は、タイムトラッカーで原因と有罪の問題を特定して修正するよりも、機能を実装するという究極の目標に重点が置かれているため、宣伝しやすいです。



チームの相互作用

労働の会計システムは個別であり、開発者ごとにタスクのコストを割り当てる必要があります。 要件に関する集団作業の場合、それぞれの作業を個別のタスクの形で個別に考慮する必要があります。



少ない:請負業者が自分のタスクに8労働時間を割り当てる必要があるため、他のチームメンバーのタスクへの参加に参加する意欲が制限されます。



マイナス :別のタスクを作成するための追加の管理上の負担。必要に応じて、他の人のタスクを解決するのに役立つ大きな注意散漫。



会計システムでは、それらの集合作業で個別のタスクを作成する必要はありません。



さらに 、最終評価は人件費の個々の指標ではなく、チーム全体で実現される要件に依存するため、チームのメンバー間に努力を再配分し、必要に応じて支援を提供する障害はありません。



さらに 、タスクで一緒に作業するとき、または実行者間でタスクを転送するときの会計システムの複雑さの欠如。

個人のパフォーマンス、モチベーション

労働生産性と従業員雇用の正式な評価の可能性があります。 労働に比例した金銭的動機のスキームが可能です。



Less :パフォーマンスデータを歪曲するインセンティブを持つ。



マイナス :パフォーマンスの改ざんの可能性。



プラス :不正を検出する方法を含む、正式な評価方法を適用する可能性。

個々の評価を強調せずに、チーム全体の有効性を評価することをお勧めします。 金銭的動機付けは、ステージの実装が成功した場合のチームメンバー間の賞の比例分割に基づいています。



各チームメンバーの個別の評価は、非公式な方法でチーム内で形成できます。 ただし、実装された要件の数とその複雑さの有効性を評価することは可能です。



さらに 、パフォーマンスを偽造する複雑さ。

非効率な従業員を排除する

さらに 、システムルールをトリガーするレベルの正式な基準に従って、効果のない従業員を取り除くことができます。これにより、チームの他のメンバーの感情的な負担が大幅に軽減されます。



Less :パフォーマンスデータの歪みと投機的使用に対するインセンティブがあります。



さらに、効果的な従業員は、個人的な関係や感情的な敵意に関係なく、評判を守ることができます。

チームはほとんどの場合、効果のない従業員を目にしますが、個人的な問題が発生します。 チームから追放する決定は、参加者が個人的に行います。



マイナス :排除の必要がある場合の高い感情的ストレス。



少ない:対人関係影響。



ただし、このアプローチを使用すると、前述の欠点に直面しない感情的に安定した健全なチームを形成できることに注意してください。

従業員の感情的な状態
マイナス :費やした時間を常に記録する必要があることに不満がある



少ない :過度のコントロール感と不満の蓄積、および労働時間の損失のすべてのケースを正当化または非表示にする必要性。



プラス :信頼と創造の自由の雰囲気



プラス :チームワークと相互支援の感覚

日常的なプロジェクトの実施

さらに、厳密な制御と圧力は受動的な立場を形成し、従業員が許容可能な生産性で日常的で興味のないプロジェクトに取り組むことを強制できます。



マイナス :十分な自尊心を持つ効果的で生産的なチームは、興味深いプロジェクトに取り組むことを好みます。 彼らは会社を去るまで日常的なプロジェクトを避けることができます。

複雑な非標準プロジェクトの実装

マイナス:厳重な管理は創造的思考を抑制し、チームの優秀な優秀な人々を締め出し、非標準的な野心的なタスクを解決できない平凡なチームを形成します。



さらに 、コスト修正の欠如、新しいソリューションを検索して試す機能、チームの創造性の自由、および結果への焦点により、チームは複雑で非標準の、

特別なプロジェクト。



さらに最初の10件のコメントで、特定のアプローチに投票する可能性があるこれらの側面に関するトピックの議論を構築したいと思います。 ブランチでプラスだけを置くという議論に賛成しましょう。さもなければ、私は選択されたアプローチの明らかに否定的な側面の評価でマイナスをつかむ危険性があります。

しかし、興味のある研究のためではない場合、なぜ他の人が格付けを危険にさらします。 =)

PSもう一度、最初の10個のコメントの構造に注目します。これは、個々のステートメントの評価と記事を補足する新しい引数を収集してオープンな記事を作成する実験です。

当然のことながら、これらの10のコメント以外で誰も無料で議論することはありません。

理想的には、最終的に、ポイントへの投票と最も明白な議論によって補足された記事を見ます。



All Articles