新機能追加
機能を増やすのは簡単だが、減らすのは難しい
新機能を提案するほうが、減らすより楽しいし希望がある
だからこそ意識的に減らす側のマインドが必要
#WIP
既に機能Aがある状態で安易に機能Bや機能Cを追加しない
A,B,Cを同時に解決できるような機能Dを追加できるかもしれない
新たな要件が見つかるたびに0から構成し直す
タスクを寝かす
/shokai/汎用的な小さな機能
/shokai/やる気を出すテクニック
これも新機能追加の話
欲しい機能を聞くのではなく課題を問う
Simpleを意識する
ビルドトラップ
ユーザー目線
UIが複雑になる
機能を追加することでマクロなUXを下げている
これに関しては「下げなければいい」
LINEアプリとかやたら機能多いけどチャット以外ほぼ使っていないmrsekut.icon
しかし、あのメニューのページはほぼ見ないのであそこに機能が増えたところで体感は何も悪くなってはいない
覚える事が増えると工夫ではなく暗記になってしまう
/shokai/暗記はつらいが工夫は楽しい
全ユーザーが、全機能を使える必要はない
ここに書くと紛らわしいが、これは機能追加を促進する側の意見mrsekut.icon
機能が複数あるプロダクトでユーザーにもレベルやクラスタがある場合、疎らにでも使っていればいい気はする
ユーザークラスタA,B,Cがいて
AとBは機能1を使い、BとCは機能2を使う、みたいな
開発者目線
開発工数
バグが増える
バグは正常に動いている2つの機能の狭間に発生する
技術的負債になる
メンテのための工数
1ヶ月後にもっと良い機能を思いつくが、機能が衝突していて矛盾が起こるかもしれない
継ぎ足しの機能追加が重なると整合性を取るために大リニューアルが定期的に必要になる
「やってみなきゃわからない」はわかる
mrsekut.iconもそっち派ではある
だとするなら、その機能追加がどういう課題を解決するという仮説のもとでのものなのかを明文化しておき、期限と目標の数値を設定しておいたほうがいい
「Fleet機能を追加することで、ユーザーの滞在時間がもっと伸びるはず」なら、機能を追加して6ヶ月後にユーザーの滞在時間が5%アップしたら良しとしよう、的な
これは、ちょっと具体的すぎるかもしれないが。
「消す指標」を入れないとどんどんてんこ盛りになる
小さく作る必要がある
では、どうやって追加する機能を決定するのか?
軸に沿って判断する
内から出た提案
経営理念に則ったもの
バグ報告
ユーザーからの要望
データを参照する
ユーザーを信用しすぎるのは微妙な気はするが
この上で、データを見てユーザーの動向を計測し、ファネル分析などの指標を元に優先順位を決めるイメージ
スクボを使う
Cosenseで個別にページを作って整理しておく
個別項目ではなくネットワークとして知覚できるから
関連を眺めることで同時に解決できる可能性がある
https://zenn.dev/satoru_takeuchi/articles/4c649312a03154