免責事項：各組織は固有です-内部構造から、そして外部と通信する前。 そのため、私はワークフロー（またはロシア語を話すのが好きなビジネスプロセス）を普遍的なソリューションとは考えていません。 この投稿は完全かつ排他的であると主張しているわけではありません。同様のアプローチが、チームの現在の構成のSkuVaultで機能し、肯定的な結果を示す可能性が高くなります。 具体的には50人で、そのうち16人は10時間の時間差で別の部分から引き裂かれています。
問題
開発者の生産性を最大化するために、経営陣は従業員に対する人間の態度を除いて、次の論文を始めましょう。
-「要件が理解できない場合に誰に尋ねるべきか」という明確なプロセスを開発する
-要件の適切な説明と分解
-コンテキストの切り替えと気晴らしなし（可能な限り）
緊急事態を解決する「消火器」のチームを撮影しました（システムが多くの企業で使用されているため、問題が絶えず発生しているため）-このように、開発者のコンテキスト切り替えを最小限に抑えました。 （Trenches 2nd editionのKnibergとScrumにこんにちは-消火チームも説明されています-私たちがやってきた良い実践を使用していることに気付くのは素晴らしいことです）。 ここでは、知識の伝達にかなりの時間を費やさなければならなかったことを理解する必要があります。
しかし、開発要件を準備するための特別なプロセスでは、比較的最近まで災害が発生しました。言葉からの正式化はまったくありませんでした。 私たちが見た機能が増え、製品が成長するにつれて、より多くの依存関係が見つかりました。 企業の典型的なシナリオの段差を指数関数的に成長する製品で埋めました。要件の絶え間ない変更、コミュニケーションの不備、シナリオの矛盾、整合性の欠如です。
関係するすべての部門の要件を一般的かつ透過的に準備するために、「要件管理のプロセス」（または製品管理ワークフロー。追加のワークフロー==プロセス）を作成しました。
製品要件管理
目標
大規模でジューシーな新機能のプロセスは、次の目標を達成することでした。
-シンプルで具体的な手順が必要
-各ステップは、責任者の紹介にあり、他のステップに関与するすべての人に対して可能な限り透明である必要があります
-ワークフローは、より多くの議論と多様な外観を誘発するはずです（真実は紛争で生まれます）→誤って解釈された文がなく、要件の詳細が一緒に偽造されるように
-各ステップは、以前よりも高い品質の要件を提供しました。 これは、出口でチェックされる完全性の特定の基準によって達成されます。
手順
プロセスは連続したステップで構成されます。
新しい問題→発見→サインオフ→分析
新しい挑戦
* Atlassian Jiraがあります。
チケットは、マーケティング、サポート、開発者、フィードバック形式で内気な顧客など、さまざまなソースからのトリガーによって作成されます。 この段階では、チケットは十分に空であり、最初のリクエストとそのソースのみが表示されます。
次の段階に進む：次の段階に進むために、製品の所有者/管理者、一般的にはこの責任者が、この機能をまったく実行するかどうかを評価します。
-そうでない場合、チケットは閉じます。
-はい、いつか-バックログを投入します（そして、そこから少し出る=深byがあります）。
-はい、近い将来、チケットは「調査」段階に移行します。
リサーチ
ステップの目標-POは機能の目標を強調する必要があります（達成する必要があるもの、当社のどのようなメリットをもたらすか、どのメリットをユーザーにもたらすか）。 基本的なビジネスプロセスを説明します（PaaSウェアハウス管理自動化システムを作成しているため、この機能がウェアハウスでどのように機能するかについての1〜2文）。
例
出荷機能の簡単な説明
出発地と追跡番号は、当社/サードパーティのロジスティクスオフィスがユーザーに送信した注文で商品の移動を監視する方法です。 配送サービスによって注文のトラック番号が割り当てられるとすぐに、出荷がシステムに作成されます。 システムでは、トラック番号を添付して保存できるようにして、ユーザーが配信情報を確認し、アプリケーションで直接編集できるようにする必要があります。
達成したいこと
当社のシステムを介してeコマースストアと統合しない宅配便サービスを使用する機会をユーザーに提供するため。
どうやって
顧客に電話して商品にトラック番号を付け、これらの商品が添付されている注文の送信に関する情報を確認します。
在庫の仕組み
1.注文を集めた人が品質管理デスクに来ます
2.整合性をチェックする人はパッケージをつかんでチェックし、すべてが問題なければ、ラベルに配達情報とトラック番号を貼り付けます
3.トラック番号がシステムに追加され、製品タブの「配信」に製品ページを開いた全員が表示されます
4.商品ページで配送状況を確認できます
和解
チケットの流れはタイトで迅速なため、利害関係者が一括してチケットを調整することができます。 「じゃあ、どうして、プロダクトオーナーがやるのか！」に取り組んでいる人々の質問を予想して、答えは、製品が大きく（サブプロジェクトとアプリケーションがたくさんある）、製品がない（または2つさえ）と答えます。 さて、この合意にはサポートからの人々がいます。 部門、マーケティング-それぞれに独自の目標がありますが、共通の欲求があります（明らかに、プロジェクトを改善したい）。
ステップの目標：アイデア、その作業の一般化されたプロセス、および市場参入のタイミングを調整すること。
分析と形式化
これは、最大量の作業が開始される場所であり、最も共同作業が多く、さらに最も困難な作業です。 アナリスト、開発者、UX同志、悪名高いPOが含まれています-そして、彼らはすべてユーザーストーリーを書き、プロトタイプを描き、明確化してクライアントとパートナーに実行し、シシフスという名前のフィードバックループを批判し、作り上げます（皮肉と自己批判は決して傷つきません）。
出力で（理想的には）取得する必要があります：バックエンドのチケットがサブタスクである特定のユーザーストーリー、実装のタイミングの推定値-フィーチャーの開発中にサイズ、タイミング、競合を推定できるようになります。 ウォーリング：見積もりは期限内に収まるべきではありません。これは単に評価の便利な尺度であり、さらに数回繰り返されます。
ユーザーストーリーの例（インターフェイスとの対話を例として使用した、特定の目的のためのユーザーアクションの形式化されたわかりやすい説明）。
「ユーザーとして、注文の送信に関する情報を別のタブで見たい」
前提条件：「注文情報」ページのユーザー
1.ページのヘッダーに、「タブ」をクリックしてください。「出発」「出発に関する追加情報について」というヒントがあります。
2.ユーザーがタブをクリックします。 情報タブは、次の順序で配置されます（フィールド値テーブル）：
-配送情報
-追跡番号リンク
-作成日
-キャリア
-クラス
-発送済みアイテム数（リンク）
-送料（リンク）
-費用タイプ
-費用額
-合計
-など
3.ユーザーは[出荷済みアイテム]または[総コスト]をクリックして、注文内の商品の内訳に関する追加情報を表示できます。 情報はモーダルウィンドウに表示されます。
4.トラック番号へのリンクが指定されている場合、それをクリックすると、ブラウザで新しいタブが開き、宅配便サービスの追跡ページに移動します。
4.1宅配便のトラック情報へのリンクがない場合、ユーザーにはリンクではなく空のフィールドが表示されます
5.フィールドのリストの下にある[ダウンロード]ボタンを使用すると、すべての情報をPDFでアップロードできます。
事後条件：ユーザーは、注文ページの[出発]タブで配達情報を見ることができます。
ユーザーストーリーの設計、技術的なサブタスク、サポートからのリクエスト、バグレポートについてはかなり厳しいルールがあります。 馬鹿に対する一種の保護、およびさまざまな種類のタスクのための、タスク追跡システム全体での標準の同じシステム。 彼女のおかげで、誰もが要件を理解し（このチケットを避けている人も）、彼らはタスクを二重に解釈することができなくなります。
まとめると
一般的に、一般に、このワークフローは要件の形式を簡素化および標準化し、チケットにコンポーネントを追加しました。特定のコンポーネントの要件間の競合はありません（関連するすべてのタスクをすぐに確認できます）。 要件の品質が向上しました（ただし、長い観察の後、矛盾に触れ、冗長性について叫びました）。 要件の変更はあまり頻繁に発生しません（最初に考慮される要因が多いため）。プロセスの透明性により、現在の段階を理解できます。 もちろん、システムは冗長になりました。かんばんボードに見られるように、ステップを組み合わせて簡素化する必要がありますが、間違いなく正しい方向に進んでいます=）
PS：ワークフローは冗長であり、よりシンプルな機能には適さないと言う人々のために-あなたは正しい、シンプルなタスクのためのシンプルなスキームが以下に添付されています。
