- - PR -
三猿との意思疎通で有効なもの。
«前のページへ
1|2|3
投票結果総投票数:8 | |||
---|---|---|---|
モデル化した画像 | 6票 | 75.00% | |
システムに関係する文章 | 0票 | 0.00% | |
実装に関する文章 | 2票 | 25.00% | |
|
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-01-22 15:09
ども、ほむらです。
ゆーじゅん氏とるぱん氏の書き込みを参考させていただきました。 ほとんどそのままですけど、 あとは、規模に応じて削っていけばいいかな?的に 状態別に役に立つであろうドキュメントを考えてみました。 ----------- 見ざる :事前の説明を受けている 意見を言える立場 打合せに不参加 言わざる:事前の説明を受けている 意見を言えない立場 打合せに参加 聞かざる:事前の説明を受けてない 意見を言える立場 打合せに参加 この3猿(状態の相手)に対して プロジェクトが円滑に進むために必要なドキュメントは何か? ------------ %%見ざる :事前の説明を受けている 意見を言える立場 打合せに不参加 特徴 :打合せに不参加 欲しい物:1)打合せの決定事項 2)決定事項の根拠 3)今後のスケジュール 4)当初のスケジュールとのずれ ※打合せに不参加の為、打合せ内容と、方向性の修正、期限の認識を優先事項として 考えてみました。 有効なドキュメント: ・ ここで有効なドキュメントは何があるんでしょうか。… ロードマップによってスケジュールの予定を残すことはできるけど あとは、意見を言えるという立場の利点も生かせるものがあればいいですよね。 ------------ %%言わざる:事前の説明を受けている 意見を言えない立場 打合せに参加 特徴 :意見が言えない 欲しい物:1)明確な目標 2)個別戦略 3)全体像が見える資料 4)概要を分割した経緯を記した資料 ※発言できないので、仕事を請け負う側と考えました。 目の前のやる事が全てわかってて、 後はやるだけ・・・と言う状態を理想として考えました。 有効なドキュメント: ・ユースケース図 ・コラボレーション図 ・クラス図 ・分析モデル ・外部設計書 ・DB設計 ・ロードマップ? ------------ %%聞かざる:事前の説明を受けてない 意見を言える立場 打合せに参加 特徴 :事前の説明が無い 欲しい物:1)発端 2)コンセプト 3)概要(途中経過) 4)採算性 ※事前説明が無いので内容を把握しに行く事を最優先事項として考えました。 有効なドキュメント: ・稟議書 ・要件定義仕様書 ・要求モデル? ・ユースケース図 ・議事録(変更履歴) ---------------- とりあえず、おもいつくところを書いてみました。 どうせなので、 新人にドキュメントの書き方を教えるときの 命題にできればいいなと思い始めています | ||||||||
|
投稿日時: 2004-01-22 19:04
どうなんでしょう?仕事を請け負う側・・・立場をシフトすれば、発注する側が「客」となり、やはり意見も言える? ん〜?なんか、昔、外に発注して、MessageBoxを想定して「×アイコンが表示され」と書いていたら、Formを作ってそこにアイコン貼り付けて納品されたことが・・・。いや、「!アイコンが」とか「iアイコンが」とか「警告メッセージ」とか「エラーメッセージ」とか書いているんだから、普通MessageBox使うだろう?わざわざ自分で作るか?というようなことがあったことを思い出してしまった。 | ||||||||
|
投稿日時: 2004-01-23 10:52
ども、ほむらです。
------ いわざる立場にあるというのは微妙な立場ではあると思うのですが 僕としては客としての立場よりも 新規に入ってきた人で かつ 即戦力希望 といったような感じで考えています。 なので、直感的に全体を見渡せるであろう資料をチョイスしてみたつもりです。 どちらかといえば、「客」はみざるかなと。。。 「客」が会議不参加というのはあまりよくないですけど。。。 受注した企業が発注した企業と離れている場合、ありえない話ではないと思いますし。 クライアントの担当者が代わったときに有効な資料は何かな〜?とも 考えようと思うのですが、有効な資料が見当つかなくて困ってるんですよね。 あるいは、ほかのサルように準備した資料で十分なのか?とも視野に入れて考えています。 | ||||||||
|
投稿日時: 2004-01-23 19:53
ほむらさん、やっぱりこの問題、「定義」が難しくないですか?というのも、「時間」を定義し忘れていると思います。
見ざる :事前の説明を受けている 意見を言える立場 打合せに不参加 言わざる:事前の説明を受けている 意見を言えない立場 打合せに参加 聞かざる:事前の説明を受けてない 意見を言える立場 打合せに参加 さて、それぞれのお猿さんは、プロジェクトのどの段階から参加しているのでしょう?それによってそれぞれのお猿さんの、プロジェクトに対する理解度が異なりますよね。 というようなことを、『新規に入ってきた人で かつ 即戦力希望』を読んだときに思いました。「新規」は、どの時間の新規でしょう? 例えば、単に『「伝言ゲーム」で、最後まで伝えるには』でもいいように思います。私が過去に経験したもの、つまり「自作メッセージボックス事件」ですが、 客→(営業/技術)→元請け(光って回って走る会社)→下請け(私)→孫請け(そこそこ名の知れた会社)→ひ孫請け(小さな会社)→玄孫請け(学生起業家?!)→担当者(学生!バイトやんけ) と通っていました。この中で、 客:できあがったものを受け取るのだから、当然重要 営業:できあがったものに対して代価を直接受け取るという意味で重要 担当者:納品物を実際に作るのだから、当然重要 の3人に通じる文書。。。 逆三猿・・?? できあがったものを、見なければならない お金をもらうために、言わなければならない 作るために、聞かなければならない | ||||||||
|
投稿日時: 2004-01-26 09:36
ほむらさんこんにちは。
ドキュメントはなくてもいいですが、 その場合、口頭で十分説明できる必要があるということです。 ドキュメントがあったほうがいい場合もあります。 (契約の関係上、普通は必要だと思います) プロトタイプとは、見た目だけという意味で使いました。 ここにこういう入力部を置き、などという絵と文章を書くぐらいなら 実物を作ってこういう感じですと提示したほうが早いと思います。 (人によるかもしれませんが...) | ||||||||
|
投稿日時: 2004-01-26 14:36
ども、ほむらです。
有効なドキュメントを考えられないのは単に僕の経験不足かと思っていましたが 「定義」の曖昧さにも問題があるようですね。 まずはこの辺からしっかりと固めていかなければならないようです。 (Jitta氏より有効な意見をいただけていますが^^;;;) とりあえず、もう少し固まるまで半凍結にさせてください。(申し訳ないです このまま続けても、伸びるばかりになってしまう気がするので。。。。 #でも、意見などあれば、かまわず書き込んでください。 #完全凍結するわけではありませんから^^ -------- Jitta氏の指摘からまずは、時間的なものからはっきりさせる必要がありそうですね。 たしかに、時間については良く考えていませんでした。 作るときは最初からいることが前提としておきながら、 見せるときは新規(追加要員)として直前に来たとか。。 その時点でどのくらいシステムが作られているのかとか。。。 > 例えば、単に『「伝言ゲーム」で、最後まで伝えるには』でもいいように思います。 僕もこの考え方でいいと思います。そのときに何を残すべきなのかなと 考えていたんです。(そしたら、だんだんいろいろめちゃめちゃにw)
ん〜なるほど、逆の視点として考えるわけですか。 ・見なければならない人は 何が必要か。 (何を確認するか?) ・いわなければならない人は 何を言うべきか(どうやって想像を伝えるか?) ・聞かなければならない人は どう聞くべきか(何を必要としているのか?) こんな切り口でいいのかな? この要望にこたえれるだけの資料の存在が、解となりえるわけですね(メモメモ なか-chan氏
僕も昔似た様なことをしていました。。。 こういうのって、具体的にどの変まで実装すれば良いのでしょうか? 僕がやっていたときは、なんか、実物に近いものになってしまっていて 時間もそれなりにかかってしまっていました^^;;;;; そこで質問なのですが こういうのって、見た目だけ作って終わりですか?それとも入力までつくりますか? あと、見た目だけという場合どの程度あればよいのでしょう? たとえば、この会議室のトップページをつくるとしたら? | ||||||||
|
投稿日時: 2004-01-28 00:26
こうやってみると、UMLのチャートって、よく考えられていますね。 顧客から開発担当まで、何をしなければならないかがわかるアクティビティー図 設計から開発担当まで、処理の手順を示すシーケンス図、コラボレーション図 描き分けることによって、顧客から開発担当まで、 何が、何を行うか、行えるかがわかるクラス図 顧客から開発担当まで、どこで、何ができるかがわかる、配置図 設計から開発担当まで、データの変化を示すステートチャート ※このスレッドに対する回答ではありません ※UMLは、便利だけれど、万能ではないと思う | ||||||||
|
投稿日時: 2004-01-28 09:34
るぱんです。
議事録一つにとって見ても同じことが言えるのではないかと。 中身については「内容」とか「詳細」って括られてるだけですし。 Jittaさんも指摘なさってましたが、 どの時間帯でどの書類が必要なのか? ※ここで言う時間帯は「調査」「分析」「設計」「開発」「テスト」などの帯です。 「誰が」「どの段階で」「どの書類が必要か?」 なんでしょうけど、 「どの段階で」「何が知りたいか?」から書類の種類を書き出して、 切り出していくのがいいのかな・・・? |
«前のページへ
1|2|3