読んでたら文章で決めた方がいい箇所とモックで決めた方がいい箇所がある気がしてきた
uiuxデザイナーが駆逐された理由はこれよな。今思うと理想ばかり掲げてるやつは可視化されない分凄そうに見えてただけで、間挟まないでやり取りできたほうが質がいい
画面への指摘をどう要件定義に落とし込むかなんよな、、、
訓練されていない一般職の人は文章だけでシステム仕様やアプリ動作を想定するのは難しい。物を出す方が進みが早い。一方でアプリ内アンケート機能の要件定義が甘いのでどうせまた同じような別機能を作るとかありそう
わしゃ昔からポンチ絵フロー図とモックと文章のセットで要件定義しとるで
これは私もやってみて良いなと感じたことなり
AIで作った画面モック見せると、一般人にはほぼ完成品に見えるため、簡単にできるじゃんと工数を買い叩かれる恐れはある
“文章で要件を固めてからモックを作る（それぞれ別の画面を頭に描く）のではなく、モックを先に作って画面で要件を決めた。あとから変えるとテーブル設計からやり直しになる箇所だけ、先に決める”
システム開発経験が少ないと文章だけで完成品を想像するのは難しい。なのでユーザー向けには画面イメージを元に説明してフィードバックを求めるというのは昔からやっていたと思う
自分も入社して最初の仕事はこんなんだったな。さらっとAccessで画面作って客先と仕様詰めて実装する。なんで新人が一人でやってるのか謎だったけど、利益率は社内トップだった(利益額としては誤差)
今までも言葉だけではなく、ワイヤーフレーム程度は作るのが大道では。だだし、言語化しないと双方ともに記憶だよりになるし、トレーサビリティが確保できない。
プロトタイプ開発を再発明しなくてもいいのよ。操作イメージがつくとフィードバックが出しやすいのは昔から知られている。AIを効率的に使える部分。
モック駆動開発？
流し読みだけど、それって見せ方が重要な要件だったてだけじゃね？見せ方以外の要件たくさんあるだろ。モックで解決するんならもともと目的や実現したいことにたいして要件定義の進め方が非効率だっただけじゃね？
パッケージカスタマイズだとこうはいかんよなよいう気はする。あとめちゃくちゃ画面数があるでかいやつ。文章だと読み解けないのは同意する
文章で要件定義するのをやめた。AIでモックを先に作ったら、認識ズレが実装前に全部見つかった - Qiita
読んでたら文章で決めた方がいい箇所とモックで決めた方がいい箇所がある気がしてきた
uiuxデザイナーが駆逐された理由はこれよな。今思うと理想ばかり掲げてるやつは可視化されない分凄そうに見えてただけで、間挟まないでやり取りできたほうが質がいい
画面への指摘をどう要件定義に落とし込むかなんよな、、、
訓練されていない一般職の人は文章だけでシステム仕様やアプリ動作を想定するのは難しい。物を出す方が進みが早い。一方でアプリ内アンケート機能の要件定義が甘いのでどうせまた同じような別機能を作るとかありそう
わしゃ昔からポンチ絵フロー図とモックと文章のセットで要件定義しとるで
これは私もやってみて良いなと感じたことなり
AIで作った画面モック見せると、一般人にはほぼ完成品に見えるため、簡単にできるじゃんと工数を買い叩かれる恐れはある
“文章で要件を固めてからモックを作る（それぞれ別の画面を頭に描く）のではなく、モックを先に作って画面で要件を決めた。あとから変えるとテーブル設計からやり直しになる箇所だけ、先に決める”
システム開発経験が少ないと文章だけで完成品を想像するのは難しい。なのでユーザー向けには画面イメージを元に説明してフィードバックを求めるというのは昔からやっていたと思う
自分も入社して最初の仕事はこんなんだったな。さらっとAccessで画面作って客先と仕様詰めて実装する。なんで新人が一人でやってるのか謎だったけど、利益率は社内トップだった(利益額としては誤差)
今までも言葉だけではなく、ワイヤーフレーム程度は作るのが大道では。だだし、言語化しないと双方ともに記憶だよりになるし、トレーサビリティが確保できない。
プロトタイプ開発を再発明しなくてもいいのよ。操作イメージがつくとフィードバックが出しやすいのは昔から知られている。AIを効率的に使える部分。
モック駆動開発？
流し読みだけど、それって見せ方が重要な要件だったてだけじゃね？見せ方以外の要件たくさんあるだろ。モックで解決するんならもともと目的や実現したいことにたいして要件定義の進め方が非効率だっただけじゃね？
パッケージカスタマイズだとこうはいかんよなよいう気はする。あとめちゃくちゃ画面数があるでかいやつ。文章だと読み解けないのは同意する