侵蝕軟體項目開發的10種典型錯誤

10 classic mistakes that plague software development projects

By Justin James

Takeaway: When you combine project management pitfalls with software development challenges, you have a recipe for some big (but often preventable) problems.

Project management is never an exact science, but when you combine it with the vagaries of software development, you have a recipe for disaster. I have seen a fair number of common mistakes that project managers make when working with software development projects. Some of these mistakes are not exclusive to software development, but they are especially prevalent and damaging in that context.

1: The “pregnant woman” mistake

Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again — the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true.

Every person you add to a project adds friction to the project as well –  things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just can’t be split up to be done by many people or teams at once. They simply have to be done “one foot in front of the other.”

2: The wrong metrics

Managers need metrics for variety of reasons: measuring “success” or status, performance reviews and analysis, and so on. The mistake I see too often is that the easier it is to collect a metric, the more likely that it’s not measuring anything useful. Of course, the easiest metrics to collect or understand are also the most likely to be used. Let’s take “bug tickets” as an example.

It is easy to count how many tickets get entered. But that is not a good measure of quality, because how many of those tickets are user error or truly “features”? So managers often look to the next level of metric: ticket resolution rate (tickets closed per day or week or iteration or whatever). If you have ever dealt with a help desk that constantly closes tickets for things that aren’t actually fixed, causing a proliferation of tickets, you know what it’s like dealing with an organization driven by this metric!

Instead of actually getting work done or helping the user (for example, leaving tickets open until the user accepts the resolution), the organization exists solely to open as many tickets as possible and then close them as quickly as possible, so it can get its resolution rate up. A better number would be the hardest to measure: ratio of true “bug tickets” created in relationship to features deployed, changes made, or something similar. Needless to say, that is not an easy number to understand or to collect and report on. The result is that organizations choose to make decisions based on the wrong metrics rather than the right ones, due to convenience.

3: Estimating times too far out

A common problem I see with certain project management methodologies is that they like to play “just so stories” with timelines and time estimates. Project manager who honestly think they know what pieces of functionality any given developer will be working on more than a month or two out (unless it is a very large, broad piece of functionality) are likely to be disappointed and mistaken. Software development is just too unpredictable. Even if you can prevent or account for all the usual things that alter timelines and priorities, there is still little guarantee that things will take the time you think they will.

4: Estimating times too broadly

Another typical issue with time estimates involves not breaking tasks down into small enough pieces. If I’m told that a piece of work will take one week, I’ll ask where exactly that number is coming from. Unless someone has analyzed all the minor pieces of work in the whole, a “one-week” time estimate is nothing but pure conjecture and should be disregarded.

5: Failing to account for tasks

How many times have you seen a deadline blown because it was established without accounting for a critical task like testing? That is another reason why you cannot and should not ever accept a task on a timeline that is not broken down into its component tasks. There is a chance that the estimate omits something important.

6: Poor communications

It is important to keep everyone in the loop on project status, but it is easy to forget to do it. This is where a lot of the mistrust between IT and the business team comes from: The business does not feel like it has a good handle on what’s happening with its projects. And the more it feels left in the dark, the more likely it is to start trying to micromanage or force things to happen the way it feels it should be done. You can mitigate this problem by letting people know where things stand, both on a regular basis and when milestones are accomplished or the status changes.

7: Disconnected business priorities

There is often a wide gap between the priorities of projects within the development organization, the priority of the project in the view of the overall business, and the priority of the project in the eyes of the requester. A common issue is that a “high priority” project for one department is not viewed as important by the business because it does not generate revenues, and so the developers also downgrade it. Everyone needs to be on the same page with priorities, and a large part of that is to ensure that business units are not evaluated on the basis of projects that the overall business considers lower priority.

8: Constructing a wall of process

When the development team feels overwhelmed, one of the natural reactions is to establish a lot of process to slow things down. I have worked at places where even the most simple of changes required a change request form to be filled out (on paper, of course), in triplicate, physically disseminated, agreed upon, cross-signed by managers, and after all of that, there was still a 45-day minimum time until the work was to be done! Needless to say, this organization was not seen as a “partner” or an “important lever for getting work done” in the business, they were seen as a cost center and treated as such. The wall of process is typically a stopgap measure to deal with deeper issues in the process or company’s culture, and while it is easier to put up the wall than to deal with those issues (and in some companies, the issues are irreconcilable), the wall of process is counterproductive and leads to a hostile environment.

9: The “hit-the-ground-running” myth

When adding people to a project, it is tempting to assume that they can hit the ground running. No one hits the ground running in the world of software development, and those who say they do are mistaken. Every project has an acclimation period, and the farther along the project is, the longer that acclimation period is — there is more and more code to understand and get a handle on. Failing to take this into account will get you into hot water. It may take only a few days or weeks for a developer to come into the project at the beginning, but it could take months for a developer to be fully productive when added to the project long after it has started

10: Multi-tasking

This is another “skill” (like “hitting the ground running”) that people think they have, but they really do not. The more you ask people to multi-task, the worse their work will be and the longer it will take. This applies to multi-tasking at the minute-to-minute level (juggling emails, phone calls, actual work, etc.) as well as the hour-to-hour or day-to-day level (handling multiple projects). The more you demand from people, the more the wheels fall off. To make it even worse, multi-tasking not only is likely to mangle the work, but it grinds people up and sends them looking for another job eventually… forcing you to bring in new people in the middle of a project and causing even more issues.


*****************

ソフトウェア開発プロジェクトを蝕む10の典型的な過ち

プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。

1．「人数を増やせばよい」という誤解

Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。

プロジェクトに人を1人投入すれば、その分だけプロジェクトに摩擦が増える--他の人に追いつくのにかかる時間や、他の人の作業とすりあわせをするのにかかる手間などが増えることになる。実際わたしの経験では、ある点を超えると、人が増えれば増えるほど、特に最初の数カ月間は、仕事のスピードは上がるどころか、かえって遅くなってしまう。そして、多くの人やチームに同時に分担させられない仕事も多い。そういった仕事は、一歩ずつ順番に進めて行くしかない。

2．間違った指標を採用する

マネージャーは、例えば「成功」や状況の度合いを測ったり、業績の評価や分析を行ったりといった、さまざまな理由から指標を必要とする。わたしが非常によく見かける間違いは、集めるのが簡単な指標ほど、何かを測るには役に立たない可能性が高いということだ。もちろん、集めたり理解したりするのが簡単な指標ほど、使われることが多い。例として、「バグチケット」を考えてみよう。

入力されたチケットの数を数えるのは簡単だ。しかし、これは品質を測る指標としてはよいものではない。なぜなら、それらのチケットのうち、どれだけがユーザーのミスが原因か、実際に「機能」の問題が原因かがわからないからだ。このため、マネージャーは次の段階の指標である、チケット解決率（1日または1週間、1リリースなどの、特定の期間当たりに閉じられたチケットの数）に目を向ける。もし、実際には解決していない問題のチケットを閉じるのが常態化しており、チケットの増加を招いているヘルプデスクを扱った経験があれば、この指標を元にして動いている組織を扱うのがどのようなものかはよくおわかりだろう。

実際に仕事をしたりユーザーを助ける（例えば、ユーザーが問題が解決したと認めるまでチケットを開いたままにしておく）かわりに、組織はチケット解決率を上昇させるために、できるだけ多くのチケットを開き、できるだけ素早くそれを閉じようとしてしまうものだ。設けられた機能、施された変更などに関して作成された本当の「バグチケット」率や、それに類似するものなど、より役に立つ数字は、計測するのが難しいだろう。言うまでもなく、これは理解や収集、報告することが簡単な数字ではない。そのため、組織は、便利さゆえに、正しい指標よりも間違った指標に基づいて判断を下すことを選択することになってしまう。

3．現実離れしたスケジュールを組む

一部のプロジェクト管理手法でよく見られる問題は、スケジュールや時間の見積もりに関して現実離れした想定で決めがちだというものだ。どの開発者がどの機能部分に1カ月か2カ月以上作業するかは分かっていると本気で思っているマネージャーがいたとしたら（非常に大きな、幅広い機能でない限り）、おそらく間違っているし、失望する可能性が高いだろう。ソフトウェア開発は非常に予測が難しいものだ。スケジュールや優先順位を変えてしまう可能性のあるあらゆることを防げるか、それらがすべて想定に入れられたとしても、想定通りの時間で仕事が進むという保証はあまりない。

4．時間の見積もりが大雑把すぎる

時間の見積もりに関するもう1つの典型的な問題は、作業を十分に小さく分割しないというものだ。もしわたしが、ある仕事に1週間かかるだろうと言われたら、その数字はどこから来たのかと聞き返すだろう。その作業に含まれている小さな作業をすべて分析したのでない限り、「1週間」という時間の見積もりは単なる推測であり、無視すべきだ。

5．作業を計算に入れ忘れる

テストのような必要不可欠な作業を計算に入れずに決められたために、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。

6．コミュニケーション不足

常に全員にプロジェクトの状況を周知徹底しておくことは非常に重要であるにも関わらず、忘れられがちだ。これが原因でIT部門と事業部門の間に不信感が生じることも多い。事業部門が、プロジェクトで起こっていることを十分に掌握していないと感じるのだ。また、暗闇に取り残されていると感じるほど、事業部門はIT部門に対してマイクロマネジメントをし始めようとしたり、やり方を強制しようとする。関係者に対して、定期的に報告をし、また一定の節目を迎えたり状況が変わったりしたときに状況を知らせておけば、この問題を緩和することができる。

7．ビジネス上の優先順位を無視する

開発を進めている組織内でのプロジェクトの優先順位と、全体的なビジネスの観点から見たプロジェクトの優先順位、そして開発を要求している側から見たプロジェクトの優先順位の間には、大きなギャップがあることが多い。よくある問題は、ある部門にとって「優先順位の高い」プロジェクトが、収益を生まないためビジネスの観点からは重要視されず、このため開発者もそのプロジェクトの優先順位を下げてしまうというものだ。全員の優先順位が一致している必要があり、そのためには、ビジネス全体から見て優先順位が低いと見なされているプロジェクトを元に、事業部門が評価されないということを保証する必要がある。

8．手続きによる壁を作る

開発チームが追い詰められていると感じる場合、それに対する自然な反応の1つは、物事のスピードを落とすために、多くの手続きを作ることだ。わたしはどんな簡単な変更でも変更申請書（もちろん紙で）を3通作成して稟議にかけ、関係するマネージャーのサインを集める必要があり、その上で作業が終わるまでに最短で45日間かかるという職場で働いたことがある。言うまでもないが、この組織はビジネスでは「パートナー」や「仕事をするために重要な相手」と見られることはなく、コストセンターであると見なされ、そのように扱われた。手続きによる壁は、手続きの中にあるより根が深い問題や、企業文化の問題に対処するための対症療法であり、壁を作ることはそういった問題そのものを解決するよりも簡単だが（一部の企業では、問題が解決不可能な場合もある）、手続きによる壁を作ることは非生産的であり、敵意に満ちた環境につながる。

9．「すぐに本格的な作業を始められる」という神話

プロジェクトに人を増やす時には、すぐに本格的な活動を開始できると仮定しがちだ。ソフトウェア開発の世界にはすぐに本格的な作業を始められるということはあり得ないし、そういう発言をする人は間違っている。すべてのプロジェクトには順応期間があり、プロジェクトが大きくなるほど順応期間も長くなる。これは、あらかじめ理解し、掌握しなければならないコードの量が多くなるからだ。これを計算に入れるのを忘れると、大きなトラブルになる。プロジェクトの初期にはこれに数日から数週間しかかからないかもしれないが、プロジェクトが始まって長い時間経ってから参加した開発者が生産性を完全に発揮するには、何カ月もかかる可能性がある。

10．マルチタスク

これも、多くの人が自分が持っていると考えているが、本当には持っていない「スキル」の1つだ（「すぐに本格的な活動を始める」スキルと同じように）。マルチタスクを要求すればするほど、仕事の質は落ち、時間もかかるようになる。これは、数分単位のマルチタスク（電子メール、電話、実際の仕事などを切り替える）にも、数時間から数日単位のマルチタスク（複数のプロジェクトを処理する）にも当てはまる。人材に対して多くを要求するほど、歯車の狂いは大きくなる。さらに悪いことに、マルチタスクは仕事をダメにしがちなだけでなく、人間を押しつぶし、最終的にその人は他の仕事を探し始めることになる。その結果、プロジェクトの最中に新しい人材を迎え入れざるをえなくなり、さらに問題は大きくなってしまう。