あなたは完璧な技術仕様を書くことができますが、あなたの開発者が泣いているならそれは何が良いですか？

球形の製品所有者は、はるか遠くの銀河で働いています。彼はナプキンに流暢にメモを書き、それを開発者に静かに渡します。そしてすぐに彼は100％彼の期待に応える完成品を受け取ります。この製品がブラックジャックと適応性を備えた複雑なクロスプラットフォームサービスであっても。



これは実際に可能ですか？



「いいえ、兄弟、あなたは私たちをだますことはできません！委託条件は長く細心の注意を払って書く必要があります」と白髪の先輩は言います。「TKは本気だ！」-黄色い口のジュンはそれらをエコーし​​ます。「私の妻は短い技術的任務のために私を去りました」とベテランのビジネスアナリストは認めます。



反対させてください。



仕様書の作成に時間がかかる必要はありません。さらに、良い参照条件は悪い条件よりも書きやすいです。もちろん、いくつかのトリックを知っているなら。今日はこれについてお話します。ただし、ナプキンの代わりに、コンフルエンスを使用することをお勧めします。

どうしましたか？

私は11年以上開発者向けのタスクを書いています。アプリケーション、ゲーム、Webサービス、CRMシステム、トレーニングプラットフォーム、およびその他の製品は、それらに基づいて作成されました。この間、私はいくつかのステップで、200ページの設計ドキュメントの作成から簡潔な参照条件に移行しました。そして、もちろん、彼はすべての可能なバンプを埋めました。



毎年、さまざまな会社で、製品、ゲームデザイナー、マーケターがどのようにタスクを設定するかを見てきました。そして、これらのタスクの設計のさまざまな「機能」の結果は何ですか。スプリントの開始が1週間どのようにシフトするか、顧客が何を望んでいるかを正確に把握します。パニックのように、彼らは製品に注がれたばかりの機能を修正します。不明なケースが原因でアプリのスコアが低下するまでの時間。売上がどのように減少し、忠実なユーザーが去るのか。問題のあるタスクをいじくり回さなければならないときに、開発者がどのように燃え尽きるか。



開発タスクを設定する人の多くは、それをうまく行う方法を知らない という印象を受けました。そして、TK自体の品質の問題は注目の的ではありません：彼らは、彼らがタスクと規範を書いた、彼らはそれを理解しない、または何を言うのですか？さらに、やるべきことは常にもっと面白いものがあります。新しい仮説について話し合うこと、会議、休憩などです。その結果、顧客、開発者、ビジネスなど、誰もが苦しんでいます。

TKを書くとき、2つの極端があります

作業している製品が大きいほど、エラーのコストが高くなり、技術仕様の品質が重要になります（ありがとう、キャップ！）。したがって、ランディングページよりも深刻なことをしている場合は、どちらのオプションも適していません。大規模で競争力のある製品では、TKの書き込みは高速で、スマートで、ロックンロールである必要があります。そこに着く方法を見てみましょう。

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. TKはチームリーダーを喜ばせる
   
   必要があります。これは、開発に転送するために特別な儀式や説明を必要としないことを意味します。たとえば、製品が技術的な割り当てを完了し、オフィスのすぐそばでバスに見舞われた場合、これは彼が可能な限り最善の方法で技術的な割り当てを行うことを妨げるものではありません。

これらすべての要件を満たすのは難しいですか？どういたしまして。



逆に、覚えていれば、率直に悪いTKを書くことはできません。これらの要件はすべて、このTKとやり取りする人々の世話をするという1つのことだけに要約されるからです。

私のTKフォーマット

この形式は、ユーザーストーリーとdoneの定義のかなり緩い組み合わせです。



それは長年の進化の結果として現れました。体系的な問題を見るたびに、この問題が将来発生しないようにTKの形式を変更しました。その結果、6月でも簡単に拾うことができる簡潔で視覚的にクリーンなフォーマットになります。さらに、上記の要件を満たしています。



これは私のTKの典型的なストーリーのように見えます：







そして私たちが開発している製品がどれほど大きくて複雑であっても、TKはそのような単純なストーリーで構成されます（それらの数は増えるだけです）。





重要：ストーリーは、大きすぎる機能（たとえば、複数の画面）または小さすぎる（たとえば、1つのボタン）を記述してはなりません。通常、1つのストーリーは1つの機能または製品の仕組みです。たとえば、ストーリーは新しいユーザーの登録を完全に説明できます。新しいランディングページのレイアウトのタスクを設定するには、原則として、1つのストーリーも必要です。



仕事の声明が大きくて重要な場合は、ストーリーのリストの前に簡単に書きます。なぜそれを行っているのか、どのような結果を達成したいのか。そのため、開発者は全体像を把握しています。

一般的に、次のようになります。

例

さて、これがどのように機能するかを理解するために、製品をそのようなストーリーに分割しましょう。たとえば、「ニューラルブート」というアプリケーションを作成することにしました。その中で、ニューラルネットワークは1日もなかった（そして友達がいない）製品と親密な会話を行います。



簡単にするために、トレーニング済みのニューラルネットワークがすでにあり、アプリケーションの形式でそのインターフェイスを作成する必要があると仮定します。



おそらく、TKは次の行で構成されます。

1. ユーザー認証
2. ユーザープロファイル
3. ニューロブーツとの通信画面
4. 画面「ニューロブートカタログ」
5. プロファイルと設定画面
6. 支払いポップアップ
7. 分析接続

各ストーリーを（上記の形式で）ペイントし、開発に送信する必要があります。簡単だと言った。

---

トリッキーなライフハック

毎日製品に取り組むのに役立つテクニックはたくさんあります。委託条件の作成に関連するものは次のとおりです。

ライフハック＃1：繰り返し詳細

現在、私は技術仕様をまったく作成していません。それら自体は、バックグラウンドで、作業の過程で表示されます。新しいタスクが表示されると、すぐにわかります。これを行うには、どのサブタスクが必要ですか。次に、各サブタスクをストーリー形式で修正します（名前のみ、詳細は後で説明します）。



したがって、私はすぐに一般化された参照条件を用意しました。開発のための技術的な割り当てを与えることができる範囲で、ストーリーを詳細に説明することだけが残っています。



詳細も背景にあります。詳細を調べて考えている間、対応する行の中にすぐにメモを書きます。デザインの代わりに、NinjaMockからプロトタイプを挿入します。



このアプローチにより、作業が大幅にスピードアップします。さらに、全体像を見逃したり、事前に詳細を掘り下げたりすることはありません。

ライフハック＃2：魔神と一緒に働いていない

魔神が最悪の方法で願い事を叶えた ような古い映画がありました。



もちろん、正気の開発者は特に害を及ぼす機会を探すことはありません。しかし、時には人々は自分が何に取り組んでいるのか気にしないことがあります。次に、彼らは「書かれたとおりに」タスクを実行しますが、なぜそれが必要なのかを実際には掘り下げません。定期的に、これは大きなファイルと小さなファイルになります。ええ、そうです、プロダクションはレイダウンしました...しかし、チェックする必要があるものをタスクに書いた人は誰もいません-そのような実装が他のすべてを壊すかどうか。



アウトソーシングについては触れませんが、このアプローチは製品では受け入れられません。優れた開発者は、レンガを置くだけでなく、寺院を建てることです。つまり、彼は全体像を見て、何が起こっているのかを掘り下げます。そのような人はしばしば代替の解決策を提供し、落とし穴について警告します。



したがって、TKを可能な限り最善の方法で実行したい場合は、TKではなく、チームの開発文化を改善する必要がある場合があります。一般的に、これはPMのタスクですが、製品も状況に影響を与える可能性があります。特にチームが彼を信頼している場合（たとえば、彼の思慮深くよく設計された技術仕様のおかげで）。

ライフハック＃3：技術的な割り当てをドキュメントから分離する

委託条件は、「何をする必要があるか」という質問に答えます。そして、ドキュメント-「それはどのように行われるのか/どのように機能するのか？」という質問に対して。 TKはタスクの実装前に記述され、ドキュメントはタスクの実装後に記述されます。



キャビネットを並べ替える必要がある場合は、「ここから並べ替える->ここから」という精神でタスクを作成します。しかし、私はワードローブがある家の建築計画を描きません。



TKは、いわば同時に文書化されるように書かれるべきだという意見がある場合があります。これは有害な理論です。委託条件がどのように正確に実装されるかが事前にわからないため、完全なドキュメントはまだ機能しません。さらに、開発者は操作する余地が必要ですが、ドキュメントには記載されていません。そして、主なことは、そのようなTKを何倍も長く書くことであり、それは面倒であることが判明します。



さまざまな製品とさまざまなスタートアップがあります。誰かがドキュメントなしで行うことができます。ただし、それでもドキュメントが必要な場合は、実装後に機能を詳細に説明する6月を雇ってください。既存の機能を説明するために特別なスキルは必要ありませんが、熟練した従業員（製品開発者と開発者）の時間と神経を節約できます。

ライフハック＃4：プログラミングを学ぶ

純粋に経験的な観察：プログラミング方法を知っている製品は、タスクの定式化に優れています。さらに、上級バックエンドオペレーターになる必要はありません。プログラミング言語を習得し、アルゴリズム的思考の本質を理解するだけで十分です。



一度私はまだchthonicに抑え切れずにコーディングされたスペクトラム、そして私の学生時代に私もアセンブラでドライバを書かなければなりませんでした。つまり、私はプログラミングに直接精通しています。もちろん、これは開発者との共通言語を見つけるのに役立ちます。

ライフハック＃5：よく考え、少し書く

最大の問題は、顧客自身が完全に理解していないタスクで常に発生します。たとえば、彼は管理領域に新しいレポートが必要ですが、このレポートがどのように作成されるかを完全には理解していません。同様に、あなたのプログラマーはそれを理解するでしょう。いいえ、そのようには機能しません。



正しく行われる良い問題を書く唯一の方法は理解することです。理想的には、自分で問題を解決できるように問題を十分に理解してください...プログラミング方法を知っていれば。



しかし、あなたがそれを理解したとき、あなたはTKで見つけられたすべての情報をダンプする必要はありません。不要なものを捨てて、重要なものだけを書くことができるのは、タスクを深く理解しているだけです。

---

PS TKは手段であり、目的ではありません。したがって、最高のTKはその欠如である場合があります。いつの日か、技術仕様がまったくないいくつかの製品をどのように発売したかをお話しします。



PPS独自の参照条件やライフハックを作成する場合は、コメントで共有してください。