アカウント名:
パスワード:
でも、その操作手順書の後に「詳細」と書いて、
「操作手順に応じて作成」
とあって、その後ろにソースリストのみってのを見たときは仰け反ってしまった。
＃やるな～。山○。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
仕様書 (スコア:0)
書けば内容はどうでもいい。
そうやって毎回意味のない仕様書を作りつづけるお仕事。
-----
Re:仕様書 (スコア:1)
私の書き方が悪いのか、顧客とは得てしてそういう物なのか、人生は勉強の連続なのだと痛感する毎日です。
打ち合わせの資料(minutes,agenda)にしても、せいぜい併せてA4用紙3枚までが、読んでくれる範囲の限界らしい、ということに、最近気づきました。
＃などと言ってる側から冗長なコメントを書いてみる
Re:仕様書 (スコア:2, 参考になる)
> 読んでくれる範囲の限界らしい、ということに、最近気づきました。
読む資料、使う資料、辞書の様に引く資料。
それぞれ書き方が違うもの。
チェックすることを考慮した書き方っつ～のも有る。
仕様書なんて「間違ってないか？」の確認用であれば、
無事これ名馬、な時には放っておかれた方が良いというもの。
もっとも「要確認」の目的があるなら読まれる様に工夫がいるが。
#と、いうのが目標というか指針かなぁ。(自分ができているとは言わん(^-^;;;)
Re:仕様書 (スコア:1)
> それぞれ書き方が違うもの。
> チェックすることを考慮した書き方っつ～のも有る。
なるほど。
あまりに資料読んでくれないので、危うく今度の打ち合わせ資料は、サスペンスストーリー仕立てで迫ってみてはどうか、とまで考えていましたが、おかげで踏みとどまる事が出来ました。
・・・嘘です。
実際、打ち合わせの議題などは、詰め込み過ぎないというサジ加減も重要なんでしょうね。尺や集中力の限界もありますので、その辺もふまえて3枚程度かなと思ったりしています。
> もっとも「要確認」の目的があるなら読まれる様に工夫がいるが。
勉強になります。
手渡す時に、確認すべきところの概要程度は、淀み無く説明出来るぐらいの準備も必要なのでしょうね。
＃挿絵やコラムを入れてみるという手も有るか・・・？
Re:仕様書 (スコア:1)
なるほど、列車の次期ダイアの打ち合わせ資料はそうやって作っているのですね。
参考になります。
# 変な引用編集をする人
Re:仕様書 (スコア:0)
> ・・・嘘です。
(((笑)))
> 実際、打ち合わせの議題などは、詰め込み過ぎないというサジ加減も重要なんでしょうね。
> 尺や集中力の限界もありますので、その辺もふまえて3枚程度かなと思ったりしています。
本文と「添付資料」に分けるという手もアリ。
「添付資料」にするとそこはすぐに読まなくても良いという意
Re:仕様書 (スコア:0)
＞サスペンスストーリー仕立てで迫ってみてはどうか、
＞とまで考えていましたが、おかげで踏みとどまる事が出来ました。
＞・・・嘘です。
嘘？
踏みとどまらずにサスペンスストーリー仕立てにしちゃったっんすかぁ？？
Re:仕様書 (スコア:0)
でも、その操作手順書の後に「詳細」と書いて、
「操作手順に応じて作成」
とあって、その後ろにソースリストのみってのを見たときは仰け反ってしまった。
＃やるな～。山○。
Re:仕様書 (スコア:0)
仕様書を読むのは顧客ではありません。
そのシステムの運用を引き継ぐ人や次期システムを構築する人です。
で、そういう人は大抵SIerの関係者だったりしますな。
納入者が大手だったりすると特に。
つまりは、仕様書なんて内輪の連中の間でしか見ないものなのです。
Re:仕様書 (スコア:1)
> そのシステムの運用を引き継ぐ人や次期システムを構築する人です。
顧客=エンドユーザー限定？やはり私の書き方が悪かったようです。
> つまりは、仕様書なんて内輪の連中の間でしか見ないものなのです。
見ててくれてるといいなぁ。
でも、その割には、仕様書に書いてある事を「どうなっている」と聞いてくる人が結構いるような・・・。
やはり書き方が拙いのでしょう。
＃とりあえず「ドキュメントに書いてませんか」は禁句