こんな方におすすめ
- 繰り返し発生するお客様の問題を、修正案にしたいサポート担当者。
- 既存の実装と照らして改善を評価したいプロダクトマネージャー。
- 変更をレビューに提出する前に、実際のワークフローで試行錯誤したいデザイナーやエンジニア。
コネクタ
GitHubの代わりにGitLabを使用することもできます。サポート用のコネクタは任意です。無害化したフィードバックの要約から始めることも、接続済みで読み取る権限のあるソースをReplitに示すこともできます。始める前に
ワークスペースでリポジトリベースの開発にアクセスでき、リポジトリを読み取る権限が必要です。プルリクエストを開くには、ブランチをプッシュする権限、またはチームが承認したフォークのワークフローを使用する権限も必要です。 具体的な問題を1つ選び、影響を受ける体験を実装しているリポジトリを特定します。例からお客様の個人情報を取り除いてください。アプリを試すときは、実際のお客様のアカウントではなく、テストデータと開発用の認証情報を使用します。 接続の手順については、リポジトリに接続するをご覧ください。Replitにプロンプトを送る
期待できること
1
問題を理解する
Replitは、ユーザーが提供した、または取得を許可したフィードバックを読み取り、
関連する実装を調べます。提案された説明がお客様の問題と一致しているかを
確認してください。いくつかの報告があっても、すべてのお客様が影響を受けている
証拠にはならず、ソースコードだけでは本番環境での動作を確定できません。
2
改善内容に合意する
何を変更し、何をそのままにするかを決めます。この例では、
目標は新しいサインアップ要件の追加ではなく、必須項目のエラーを分かりやすくすることです。
既存のコンポーネントを再利用し、無関係な変更は分けておくようReplitに依頼します。
3
プレビューで変更を試す
Replitは開発用のセットアップを準備し、合意した変更を加え、セットアップが対応している場合は
アプリを起動します。プレビューを開き、必須項目を空のままフォームを送信してから、修正します。
エラーメッセージ、レイアウト、操作について具体的なフィードバックを伝えてください。セットアップに認証情報が必要な場合は、安全なシークレットのフローを通じて、
権限を限定した開発用の認証情報を入力します。モックサービスを承認する場合は、
実際の連携のテストとして扱わず、その制限を明確にしておいてください。
4
結果を確認する
関連するチェックを実行し、成功、失敗、ブロックされたテストを報告するようReplitに依頼します。
diffを確認し、既存の検証動作が維持されていることを確かめます。
関連する場合は、キーボード操作と狭い画面での動作も含めてください。スクリーンショットは視覚的な変更の説明に役立ちますが、テストやレビューの代わりにはなりません。
5
プルリクエストを準備する
結果に満足し、その制限事項を理解したら、次のように依頼します。GitLabの場合は、ドラフトのマージリクエストを依頼します。チームは、既存のプロセスを通じて
提案された変更をレビューします。リクエストを開いても、マージやデプロイは行われません。
自分に合わせて活用する
トラブルシューティング
フィードバックが曖昧で再現できない
フィードバックが曖昧で再現できない
影響を受けるステップ、期待される動作、実際に観察された動作を尋ねます。
無害化した例を使用してください。考えられる説明と、コードおよび開発テストで
裏付けられた調査結果を、Replitに区別してもらいます。
プレビューを実行できない
プレビューを実行できない
リポジトリのセットアップ手順を確認し、不足している依存関係、サービス、
権限を特定するようReplitに依頼します。動作をテストしたと主張せず、
引き継ぎの際にブロッカーを報告してください。
提案された修正が大きくなりすぎている
提案された修正が大きくなりすぎている
元の問題に立ち返り、役に立つ最小限の変更を依頼します。
より広範な再設計や新しい要件は、フォローアップの作業として分けてください。
レビュアーが変更を求めている
レビュアーが変更を求めている
フィードバックを評価し、適切な場合は既存のオープンなリクエストを更新するよう
Replitに依頼します。修正後は、影響を受ける動作を再確認してください。
リクエストがすでにマージされている場合は、追加の作業を新しいコントリビューションとして扱います。
関連情報
お客様のフィードバックを分析する
取り組む改善を選ぶ前に、繰り返し現れるテーマを特定します。
Replitでコーディングする
リポジトリベースの開発を理解し、チームで始めましょう。