顧客が本当に必要だったもの
-
391
ななしのよっしん
2016/03/09(水) 13:57:26 ID: HU0W6fHbY0
-
👍0高評価👎0低評価
-
392
ななしのよっしん
2016/03/09(水) 17:39:45 ID: rav1xyELEL
-
👍0高評価👎0低評価
-
393
ななしのよっしん
2016/03/11(金) 10:23:51 ID: XA6X6gC70N
-
日本人は特に金さえ払えば思い通りの物が出ると思う傾向強いな
-
👍0高評価👎0低評価
-
394
ななしのよっしん
2016/03/11(金) 10:37:35 ID: 3genOsWRTM
-
👍0高評価👎0低評価
-
395
ななしのよっしん
2016/03/14(月) 21:14:15 ID: acwUrgdQid
-
👍0高評価👎0低評価
-
396
ななしのよっしん
2016/03/15(火) 07:33:17 ID: HjUz4a3Dic
-
👍0高評価👎0低評価
-
397
ななしのよっしん
2016/03/15(火) 07:55:57 ID: 3genOsWRTM
-
まあ選手とコーチはまったく別の才能だっていうのはスポーツの世界でもいわれてることだしなあ…
多分ね、階段式に上がっていく制度の限界だと思うよ。
ホントは現場をしっかり分かってる人が上に立って的確な指示ができれば一番いいんだけど、その「しっかりわかってる」のを見極めるのがしぬほど難しいんだなこれが。
成果を直接出したやつがえらいのか?それをアシストした奴がえらいのか?はたまた指示を出した人間がえらかったのか?
これを正しく評価するには外部の組織を雇うかそういう部門を獄時に作るしかないんだ。
けどね、そんなのはすぐに目に見える成果を出す部門じゃない。だから会社としては不確定なものに金をつぎ込むことはできないのさ。 -
👍0高評価👎0低評価
-
398
ななしのよっしん
2016/03/15(火) 07:57:01 ID: 3genOsWRTM
-
👍0高評価👎0低評価
-
399
ななしのよっしん
2016/03/17(木) 01:05:38 ID: Hhfru4smJr
-
顧客(実際に使う人)と話せる場合でも
通常業務をこなしつつ片手間になるから嫌がられるというケースも多いね
今ある業務にシステムを合わせようとして
どうすれば効率的かや、法律や運用的にどうあるべきかで話せる人はまずいない
そしてシステムをその会社独自に修正するから費用が跳ね上がるっていう
発注側にもある程度の専門知識を持つ人が居ないと、現実的な落とし所への模索が難航するんだよねぇ
専門知識を持った人が居ない場合、それは受注する側にとってはリスクなのでその分請求額を上乗せしておく事になるから、リスク込みの適正価格でもボッタクリっぽくなっちゃう事も多々ある(遠まわしなお断りの意味合いの場合もある)
予算や納期が不足した場合、テスト期間をまず削る事になる(異常系のテストをしないとか、仕様書外は一切考慮しないなど)
結局、一般的なプログラムなら、市販品を買った方が費用も時間も資料もサポートも品質も良いというオチに -
👍0高評価👎0低評価
-
400
ななしのよっしん
2016/03/19(土) 07:10:07 ID: RBGg0XQ59v
-
>>389
顧客側が仕様を曖昧にしておくのは、戦略的な理由もあると思うよ。
例えば画面。
顧客側が仕様を明確かつ詳細にすればするほど、「操作感が悪い」「やりたい事がどう操作すればよいかわからない」などといった問題が発生した場合、開発側の責任に出来る余地が少なくなる。
⇒結果、仕様を決めた社員が社内で責任を取ることになる。
しかし「操作感に優れた、直感的に操作できる画面」のような曖昧な仕様にしておけば、プロジェクトが成功すればそれで良し、失敗すれば開発側の責任にする余地ができる。
⇒結果、修正の費用を開発側持ちにさせる、などの可能性が高まる。
(これは極端は話なので、もしこの仕様で受けたとしたら、開発側にも責任は当然あるけど)
従って、開発側が顧客側に対して、仕様を明確にさせようとすればするほど「めんどくさがられる」応対を受けることになる。
勿論>>399のように、明確にしたくともスキルがない場合もあるので、一概には判断できない。 -
👍0高評価👎0低評価
-
401
ななしのよっしん
2016/03/19(土) 07:21:38 ID: R5dOt1GrRe
-
👍0高評価👎0低評価
-
402
ななしのよっしん
2016/03/20(日) 12:00:19 ID: VNlfJ72A1s
-
👍0高評価👎0低評価
-
403
ななしのよっしん
2016/03/20(日) 12:04:09 ID: HU0W6fHbY0
-
👍0高評価👎0低評価
-
404
ななしのよっしん
2016/03/20(日) 12:20:06 ID: UvgLiI7HRG
-
👍0高評価👎0低評価
-
405
ななしのよっしん
2016/03/20(日) 12:24:59 ID: VNlfJ72A1s
-
👍0高評価👎0低評価
-
406
ななしのよっしん
2016/03/20(日) 12:32:16 ID: VNlfJ72A1s
-
👍0高評価👎0低評価
-
407
ななしのよっしん
2016/03/20(日) 12:38:13 ID: Q/MnxHX3Ms
-
サンプルを作ってそれを提示して見てもらった上で顧客にどれが良いかを確認取るのが良いのだが
そもそもそのサンプルを作って見てもらうという期間が最初の見積で考慮されてないという
>>405
使う側におけるシステムを使う人に沿ってるのはそういうのかもしれないが
依頼する側の窓口たる人物がその自分サイドの使う人の意見を把握してない場合が多々あるのがな
そして作る側はそもそも使う人がどういうのを求めてるのかを想像で作るしかない
それを想像で作った際に窓口となってる人物が「それは違う」と突っぱねて来たりもする
ただの暴走野郎ってのも結局結果でしかないよ、「うるせえコレがいいんだよ!使ってみりゃわかる!」でやった上で運良くうまく行った人とそうでない人が居るだけ
暴走野郎が多いのはそういうのがうまくいかないことを証明してるんじゃないの
だってどう頑張ったって実際に使う人が使いやすいものってのは依頼した側の仕事をやったことがあり熟知してる人であって
システムを開発する側がそれを知るのにも限度があるんだから -
👍0高評価👎0低評価
-
408
ななしのよっしん
2016/03/20(日) 17:05:18 ID: VNlfJ72A1s
-
👍0高評価👎0低評価
-
409
ななしのよっしん
2016/03/25(金) 16:05:42 ID: 7PIFHsnSoh
-
👍0高評価👎0低評価
-
410
ななしのよっしん
2016/03/26(土) 22:20:42 ID: a4c0JJP+3w
-
👍0高評価👎0低評価
-
411
ななしのよっしん
2016/03/27(日) 05:41:37 ID: OxMTom0JJ9
-
👍0高評価👎0低評価
-
412
ななしのよっしん
2016/03/27(日) 06:03:40 ID: ZHoQABUnf2
-
👍0高評価👎0低評価
-
413
ななしのよっしん
2016/03/27(日) 06:36:12 ID: nD0LAbaE4Y
-
👍0高評価👎0低評価
-
414
ななしのよっしん
2016/03/27(日) 10:44:14 ID: HU0W6fHbY0
-
👍0高評価👎0低評価
-
415
削除しました
削除しました ID: nlF5wNbARo
-
削除しました
-
416
ななしのよっしん
2016/03/28(月) 19:21:55 ID: OxMTom0JJ9
-
👍0高評価👎1低評価
-
417
ななしのよっしん
2016/03/28(月) 21:40:51 ID: rav1xyELEL
-
👍0高評価👎0低評価
-
418
ななしのよっしん
2016/03/29(火) 19:09:14 ID: IMIcnRqePM
-
👍0高評価👎0低評価
-
419
ななしのよっしん
2016/03/31(木) 15:35:32 ID: TzyhG1z9tb
-
最新型のブランコを要求するなら問題ないんだ。
顧客がよく知りもせず破綻した条件や実現不能なブランコを求めたり、無理がある前提や求めてる仕様を実現できない予算で求めるから無理が起こるって事。
(この図の例では、『木の枝にブランコの両端を支えるだけの強度があるのか』という問題がある)
この場合の「顧客が本当に必要だったもの」は、おそらくは二つ。
用件を満たしかつ最低限必要な要求条件を満たす(タイヤブランコ)か、顧客が理想の条件に拘泥せず実現可能な目標にシフトするか(この場合、予算を増やして木陰にブランコを建てるか)か。
つまり、顧客の指定している『前提条件』が足を引っ張ってることが、結構多い。
結果、質を落としてでも条件に合わせるか、条件そのものを変更する必要があるのだが、それに気付かずに突き進んだ結果が破綻(この場合切り株)なわけで。 -
👍0高評価👎0低評価
-
420
ななしのよっしん
2016/03/31(木) 23:35:56 ID: ShVB+6xlPK
-
👍0高評価👎0低評価

