techwithtam/get-to-the-point

本題に入る

意思決定者がすぐに依頼を理解できるように草稿を書き直します。

意思決定者にはほとんど時間がありません。最初の数行で、何が起こっているのか、何を求められているのか、どのような選択肢があるのかを知る必要があります。それを最初に置き、詳細な情報は質問に備えて用意しておきます。

詳細は依然として重要であり、ユーザーはそれらすべてについて説明できなければなりません。詳細は冒頭部分の後か、想定される質問の中に配置します。

手順

1. 意思決定者を特定する。 誰がメッセージを受け取るのか、彼らが最も気にすること、期待する詳細のレベル、行動する前に必要なもの、そして誰に報告するのかを確立します。まず草稿とユーザーの説明を使用し、不足しているものだけを尋ねます。細部にこだわる意思決定者はより多くの質問をするため、より多くの回答を用意します。上長に報告する意思決定者には、そのまま繰り返せるような言葉で要点を伝える必要があります。彼らが行動する前に何が必要かを述べられる状態になったら完了です。
2. 意図を1つに絞る。 このメッセージが意思決定者に情報を提供するものか、選択肢を探るものか、決定を依頼するものかを決定します。それぞれ異なる思考を必要とし、人はある思考から次の思考に移るのに時間が必要なため、複数の意図を持つメッセージは回答が難しくなります。草稿が複数の意図を組み合わせている場合は、今必要なものだけを保持し、他は別のメッセージに移動します。緊急性によって3つすべてを圧縮する必要がある場合は、順序を保ち、それぞれに時間を設定します。メッセージが1つの意図、または時間指定された順序を持つようになったら完了です。
3. アウトカムを定義する。 ユーザーがこのメッセージから必要とするアウトカムと、それがなぜ重要なのかを正確な言葉で述べます。草稿にそのいずれかが欠けているかどうかをユーザーに尋ねます。ユーザーの事実から「このメッセージの後、意思決定者は...するだろう」という文を完成させられるようになったら完了です。
4. 冒頭を書く。 結論から始めます。3つの具体的な文を目指します。何が必要か、なぜ重要なのか、行動しなければどうなるかです。決定の場合、最初の文は決定と推奨事項を述べます。最新情報の場合、最初の文は何が起こったかを述べ、次の2文はそれが何を意味し、意思決定者が何を準備すべきかを述べます。選択肢は冒頭かその直後に、それぞれの影響とともに名前を挙げます。それが意思決定者が選択を支持するために必要な詳細のレベルです。結論がわかれば、読みながら推論を評価できます。結論がなければ、結論を推測しながら読むことになります。意思決定者が冒頭だけで行動できるようになったら完了です。
5. 直接の質問には直接答える。 意思決定者が直接質問をした場合、まず答えを述べ、その後に条件を述べます。イエス・ノーの質問に対する長い条件付きの返答は、たとえすべての条件が正確であっても、回避と受け取られ、ユーザーの信頼性を損なう可能性があります。草稿が明確な回答をサポートしていない場合は、ユーザーに回答を求めます。
6. 詳細を整理する。 冒頭だけでメッセージが十分な場合があります。冒頭の後には、この意思決定者が依頼を理解し行動するために必要なものだけを追加します。それ以外の詳細は依頼からの注意をそらすためです。決定を変える可能性のある条件やリスクはすべて保持します。残りは想定質問に移動します。草稿のすべての事実がメッセージ、想定質問、または「変更点」に含まれるようになったら完了です。
7. 想定質問を準備する。 この意思決定者が最も尋ねそうな質問をリストアップし、それぞれに草稿から導き出した回答を用意します。ユーザーが計画している代替案も含めます。意思決定者は、ユーザーが作業を理解しているかどうかを確認するために、よく1つの詳細をテストします。回答の質は、メッセージの残りの部分への信頼度に影響します。それぞれの回答を質問に合わせて調整し、簡単な確認には短い回答を、深刻な課題にはより詳細な回答を用意します。各質問に回答があるか、「ユーザーへの質問」の下に表示されたら完了です。
8. 明確にするために編集する。 意思決定者が使用しない専門用語、略語、流行語は置き換えます。それらは毎回翻訳する必要があるからです。意思決定者自身が使用する技術用語は保持します。複数の修飾語を含む長い文は分割し、完全で専門的な文を維持します。意味を変えない曖昧な表現は削除します。曖昧な表現は、正しい場合でも疑念を招くからです。実際の不確実性は、それが判断に影響する場所で一度だけ述べます。
9. 媒体を確認する。 媒体を意図、緊急度、および意思決定者の期待に合わせます。情報提供は文章に、選択肢の検討は会話に適しています。決定は、事前に背景資料を送付したうえでの会議に適しています。チャットでの緊急メッセージには、意思決定者がフォローアップなしで行動しなければならない可能性があるため、必要なものがすべて含まれている必要があります。ユーザーが対面でこれを提示する場合は、各ポイントについていくつかのキーワードを提供します。完全なメモを読みながら話すと、伝達が弱くなるからです。意図に反しない限りユーザーの媒体を維持し、反する場合はその旨を伝えます。
10. 次のステップを述べる。 具体的なアクション、担当者、期日で締めくくります。メッセージが誰が次に何をするかを明記したら完了です。

ルール

• ユーザーの事実のみを使用し、ユーザーの文体を保持し、推測したものにはその旨を明記します。
• 欠落している日付、数値、または担当者についてはユーザーに尋ねます。
• かつて誰かに反論されたために、ユーザーがメッセージにもっと詳細を求めている場合、それは想定質問に保持します。反論は日常的なことであり、次は別のことについて質問されるでしょう。

出力

次の4つのパーツをこの順序で返します。

1. メッセージ。 送信準備ができた、書き直された草稿。
2. 想定質問。 各質問とその回答。
3. 変更点。 移動、分割、または削除した各項目について1行ずつ。ユーザーが復元できるようにするため。
4. ユーザーへの質問。 ユーザーが提供または確認する必要があるもの。

返信後

ユーザーが返信や会議の結果を共有した場合、全員が次のステップを理解していることを確認します。次のステップが確定すれば、部分的な回答でも許容されます。確定していない場合は、次のステップを尋ね、なぜユーザーがそれを必要とするのかを説明する、短く直接的なフォローアップを起草します。

結果が明確になったら、影響を受ける人々に向けて、決定、次のステップ、およびその担当者を記した短い記録を起草します。口頭での合意はすぐに忘れられたり誤って解釈されたりするため、記録は全員に同じバージョンを提供します。

例

これらの例は合成です。

ダメな例	良い例	理由
リスクが抑えられ、ベンダーが期限内に対応してくれれば、3月までにはほとんどを納品できるはずです。	はい、ベンダーが金曜日までにアクセスを確認すれば、3月1日までに納品可能です。	質問はイエスかノーでした。意思決定者は回答が得られれば、条件を評価できます。
背景、分析、そして4ページ目の推奨事項。	最初の文に推奨事項、その下に分析。	時系列順では、意思決定者はポイントを待たされます。
移行の今後のアプローチについて認識を合わせる必要があります。	5月15日までにClearlineへの移行を承認してください。	依頼はアクション、対象、期日を明記しています。
すべてのベンダー機能を比較した30行の表。	ClearlineはBellwetherより年間18,000ドル高く、パイロットに合格した唯一のベンダーです。	意思決定者は影響を比較します。完全な比較は質問に備えて残します。
ここでどうすべきでしょうか、そして今日承認していただけますか？	こちらが2つの選択肢とそれぞれの意味です。金曜日までに決定をお願いします。	2つ目のバージョンは選択肢と決定を分離し、決定を検討する時間を与えます。
SIPトランクのポートはクリティカルパス上にあります。	稼働開始日は電話番号の移行に依存しており、これには10日かかります。	ユーザーの分野外の意思決定者は、最初のバージョンを翻訳する必要があります。
皆さん、ありがとうございました。素晴らしい議論でした。	Clearlineを承認し、Nadiaが5月15日までに現在のベンダーに通知します。	最初のバージョンは何も記録していません。2つ目は決定と担当者を明記しています。