Promises, Promises

By Russ Finney

約束、約束

In system building at the implementation stage, one fact is certain, the promise is always remembered and the conditions of the promise always seem to be forgotten. This is especially true if the team has been living in a construction phase vacuum. The best way to avoid this situation is easy - don't go off to a closet and build the system. When discussing detailed functional issues, create an atmosphere in which a client can participate. This is extremely important if it becomes necessary to fudge on a promise. There is an old saying that bad news does not improve with age, and it is appropriate to consider that fact here. The earlier the client is aware that an alternate approach will be implemented, the easier it will be to arrive at a compromise solution which will meet the business requirements.
システム構築の導入段階では、約束した事はいつまでも憶えられているが、その条件は常に忘れられているという確かな事実がある。チームが構築作業に忙しく顧客の事を忘れてしまった時、特にこの事がはっきりする。これを避ける最良の方法は簡単である -- 部屋に閉じこもりっきりでシステム構築をしない。詳細な機能について議論する時、顧客が参加する雰囲気を作るのである。約束が守れなくなる場合、これが非常に重要である。「悪いニュースはいつまで経っても良くならない」という諺を頭の中に入れておくべきだ。代替案について顧客が早く知れば知る程、より早く業務要件を満たす妥協案に達する事が出来るであろう。

Including the client in the decision process during construction also helps to reduce the project risk. In many cases the team may have just walked five steps down the wrong road, and the client brings them back to reality. To experience real tension, surprise a client during the acceptance test with a newfangled change that misses the mark when it comes to handling the crucial business needs. The team motto during construction needs to be: no client surprises!
構築作業中の決定を下す過程に顧客を参加させるのは、プロジェクトのリスクを減少させるのにも役立つ。多くの場合、チームが少し道を外れたとしても顧客がそれを現実に引き戻してくれるだろう。顧客と問題を起こしたければ、検収テストの最中に顧客を驚かしてやればいい。一番重要な業務処理の部分を的外れな流行のスタイルに勝手に変えておくのだ。構築作業中のチームのモットーは、顧客を驚かせない! でなければならない。

Keeping promises, especially when faced with actually implementing them during construction, is a challenge. For some reason, technical limitations have a way of thwarting the best intentions. It is at this point that teams develop convenient memory loss. Did we really tell them we would do that? They must have known that it might not be possible. Surely if we do it this other way they will understand. What choice will they have after it is built anyway? This is a risk which is easily avoided. Just tell the truth. Yes, it may be a little uncomfortable, but by involving the client in making the alternate selection, the chance of acceptance increases dramatically. The purpose of Acceptance Testing should be to examine and prove the functionality the client is already aware of, not to see if the client will accept all of the construction imposed changes.
約束を守る事は難しい。実装の段階では特にそうだ。どう言う訳か、技術的制約で、一番良いやり方が無理になる。するとチームは、都合よく物忘れを始める。「我々は、顧客に本当にそれをすると言ったか？」「彼らは、それが無理かもしれないと判っていた。」「他の方法でやっても、顧客は、間違いなく理解してくれる。」「作ってしまえば、彼らは受け入れるしかないんだ。」こういうリスクは、容易に避けられる。本当の事を言うだけで良い。勿論、それはあまり愉快なものではないだろうが、代替案の選択に顧客を関与させれば承認の可能性は劇的に高まる。検収テストの目的は、顧客が既に知っている機能の検証、確認であり、実装の理由から（勝手に）変更した部分が受け入れられるかどうかをみる事ではない。

Who is the Real Owner?
誰が本当の所有者か？

The team has spent months or years developing the system. They have all put a little part of themselves into the effort. If things have gone well, the team may even consider the result to be a reflection of themselves and their abilities. No one knows all of the features and capabilities of the software better than the project team. It is truly their system. But is it? Now it has to be given away, to clients who have no real appreciation of what it is they are really getting! This is both a high point and a low point for the System Builder. To some, it is like spending years creating a great work of art, and when it is finally completed, hanging it in someone else's living room, never to be seen or enjoyed again.
チームは、システム開発に何カ月も何年も費やした。彼らは、それぞれの持てる物を注ぎ込んで努力してきた。プロジェクトがうまく行ったら、チームはその結果を彼ら自身や能力のお陰とみなすであろう。ソフトウェアの機能や能力については、プロジェクトチームが一番よく知っている。実際、彼らのシステムである。しかし、本当にそうだろうか？今、自分達が手にするものの本当の価値が判っていない顧客に、システムを引き渡さなければならない。システム構築者にとって絶頂の時でもあり、最低の時でもある。誰かが評して、「それは、何年もかけた見事な芸術作品が、完成後は他の誰かの居間に掛けられ、二度と振り返って鑑賞される事がない状況に良く似ている。」と言った。

Fortunately, the real pleasure comes in watching the system go to work. This is the real reward to the system building professional. The first real check that gets generated, or that first invoice that gets mailed, or the first customer request that gets handled through a new screen, those are the rewards, knowing that you have actually made a difference in the day to day life of the business. But letting go is not easy. It all begins with documentation, training, and acceptance testing.
幸い、システムが稼動しているのを見れば本当の喜びが沸いてくる。これが、システム構築者への本当の報酬である。この手で日常業務に大きな改革をもたらしたのだと考えると、最初に発行される小切手、最初に郵送される送り状、最初に画面で処理される注文、これら全てが報酬である。しかし、上手く立ち上げるのは簡単でない。全ては、文書化、トレーニング、検収テストなどから始まる。

Copyright © 1999, Russ Finney, All Rights Reserved