記事

プロダクト計画

曖昧な相談を、チームが動ける判断へ整理します。課題の定義、調査、対象範囲、開発に進む前に集めたい証拠を扱います。

予算の出発点は画面数ではなく、利用者が完了させる仕事と例外処理です。権限、既存データの取り込み、外部連携、失敗時の復旧まで含めて考えます。

業務のどこに独自の価値があるかから考えます。一般的な仕事は既製品を調べ、運用を変えると顧客への価値が失われる部分は独自開発を検討します。

調査の価値は意思決定を変えられることにあります。誰が仕事をし、何が問題で、成功を何で確認するかを明確にします。

リポジトリは所有と引き継ぎの一部です。別の担当チームが個人アカウントに依存せず、ビルド、公開、監視、復旧できる状態を目指します。

新しい要望は情報であり、そのまま開発指示になるわけではありません。合意した要件への不具合、新しく判明した要件、好みを分けます。

役立つものを、一緒に。

最初のプロダクト、複雑な業務、見直したいソフトウェア。現在の状況をお聞かせください。