BTSをお客さんと共有すると凄く良いシステムになる
プログラマの思索: ツールが開発プロセスを改善するを見て。
と言うか更にリンク先のネタ元の以下2つも見て。
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife
元請け企業が用意すべきもの - @katzchang.contexts
実際に、お客さんとBTS共有して開発した事、何回かあるけど、結果としてはどれも良かった。
デメリットもあったけど、メリットが上回った感じ。
メリットとして感じた物は
- 情報のやり取りが早い
- 打合せのロスが減る
- 平行で同時に質問や回答しやすい
- 内容を各開発者へ伝達するのが楽
- 情報が集約される
- 履歴がお互いに見える場所にあるので、確定した仕様の変更が減る
- 記載した情報の検索が早い
特に、情報が集約される事が凄く大きい。
資料ややり取りが全部BTSに集約される*1ので、プロジェクトの
情報が、BTSに集まる様になる。
なので、お互いに情報が見えるので、仕様変更が減り、開発に工数を集中出来る。
「仕様をこうしたい」って言われて変更して、「なんでこんな動きになってるんだ」って
言われる事って良くある事だと思いますが、BTSでやり取りすると、「なんでこんな動きになってるんだ」って
時に、そのチケットを引用しやすい。
後まあ、実はそういうときって、リーダーと顧客との間の認識のズレみたいなのが原因なのが
多いので、BTSで後で確認出来たり、そもそも、BTSで、お客さんに言われた事が1個1個
お客さんに確認して貰えたりして、認識ズレそのものが減ったり、早期に問題が見つかる事が多い。
認識ズレの例としては、こんな感じ。
顧客）「ユーザーページの下に、(ページの一番上に移動する)TOPへっていうリンクを作ってくれないか？」
リーダー）「分かりました。(/indexへ移動する)TOPへというリンクですね。作ります」
で、そんな細かい事まで確認しないから、リリース後にお客さんから
顧客）「このページで、TOPへをクリックすると前のページに戻っちゃうんですが・・・」
リーダー）「あれ？そういう仕様ですよ？」
みたいな。
(まあ、例は恣意的に作った小規模な奴なんで、この辺もきちっと書いてる事が多いと思いますが)
で、これがBTS使うとお客さんが「/usersページの下に、TOPへっていうリンクを作って下さい」
とかurl書いてくれる様になっちゃったりする上*2
最後、修正した後お客さんに
プログラマ）「対応したので、確認して下さい」
顧客）「/indexに移動しちゃってます。すいません、ページの一番上に移動する奴にしてください」とか
TOPの意味が違ったんだなーって後から見てもお互いにわかったり*3するケースも多く出てきて、
行き違いも減る
直したばかりだと修正も簡単ですしね。
ただ、まあ、デメリットもあって
- お客さんが慣れていない
- 細かい部分の仕様のやり取りが増える
って言うのもあります。
特に、お客さんが慣れていなくて、中々普及しないと大変です。
途中からお客さんも「BTSの方が楽だな」って思ってくれると一気に
使ってくれるんですけどね。
でも、以前GoogleDocsをベースにやり取りした時は、結構お客さんが慣れるまでが短かったです。
Redmineとかと比較して、多少機能が劣りますが「殆どExcelですね。」って言われて、直ぐに
慣れてガンガン仕様の質問とか変更が来ました。
まあ、そういう変更とか、細かい質問とかがしやすくなるので、結構それがデメリットかなーと
思わなくも無いんですが、そもそも詰めてなかった部分って後でもめる部分にもなりやすいので、
そこで労力払うのは、寧ろ必須だと思わなくもない。
後、仕様変更についてはこちらがチケットの対応時間とかリアルタイムで見せているので、
隠しもせずにお客さんに「これは元々こういう話でしたんで無理です」とか「これ時間がかかるので、
別費用にさせて下さい」とか言えば結構納得して貰えたケースが多かった。
まあ、逆に細かい所は仕様変更対応しがちなので(1行で直るレベルとかなら、頻出してなければ
サービスでやろうよ。毎日それが頻繁に来るなら断るけどと思ってる。これは異論ある人居るかも)
で、こうやって色んな所が煮詰まるシステムが作れたのでプロジェクト的には、色々お客さんの
要望取込めて、上手く開発出来たケースになれたのかなーと思ってる。
