私は現在、小規模なビジネス (従業員 15 人から 20 人、プログラマー 5 人) で働いており、ほとんどのプロジェクトはカスタム ビルドの CMS といくつかの Web アプリケーション製品です。
そこで働き始めてから、多くのプロジェクトに携わってきましたが、プロジェクトごとに仕様が大きく異なります。クライアントが何を望んでいるのか、何を提案しているのか（提案されたフォームフィールド、ディスプレイの簡単な説明など）を伝えるWord文書など、少し詳細な情報を得ることがあります。「このプロジェクト/モジュール/リクエストに最適なアプローチだと思うことを行う」以外は、ほとんど何もない場合があります。
さまざまな種類のビジネスで働いている可能性のある皆さんへの私の質問は次のとおりです。プロジェクトを開始するときに、上司、マネージャー、チームメイトからどのように (大量の紙? Word ドキュメント? Visios?)、どのような情報を取得しますか?たくさんの分析、図面など）？これについて、どのくらい詳しくわかりますか？
私の質問が十分に明確であることを願っています、ありがとう。
仕様..それはちょっと面白いです...どうですか:(.
真剣に多くの企業が仕様は必要ないと思い込んでおり、それは絶対に受け入れられませんが、これは多くの企業でのやり方です. 彼らはワンライナーを想定しており、プログラマーはプログラムが何をすべきか、入力/出力などを知っています。
残念ながら、私の場合、実際に仕様を書くのを手伝わなければなりません..そして私はプログラマーです:(。
ほとんどの場合、口頭での指示が多く、ボイスレコーダーを使用して会話を録音し、終わったら文字に起こします。お客様の言葉から自分なりのスペックを書きます。
それから、優れたコンサルタントとして、私はその報告書を顧客に持ち帰り、それを検証し、署名を得てそれを構築します。その後、顧客は毎日幸せに暮らしています! (いいえ、彼らは 100 回考えを変えます)
私たちは16人の会社であり、小規模小売店の所有者向けにカスタマイズされたソフトウェアを作成およびサポートしています。
私たちが取得するプロジェクトは、（仕様に関連して）3つの一般的なカテゴリに分類されます。
「ここで、このフォームを自動化します。」営業担当者は、お客様がこのフォームを表示したいのは、フォームに記入して印刷し、お客様にとってプロフェッショナルに見えるようにすることだけだと説明しています。私たちのスペックは、注文書やレポートのような一枚の紙です。これは常に誤りです。彼らは、ポップアップルックアップ、他のソースからの自動更新、そして「あなたがそれにいる間」の2倍以上の時間のアドオンを望んでいます。これらは、私たちはその瞬間に生きて、プロジェクトを軌道に乗せることを学びました。完了するまでに、プログラムは元の形式のようには見えません。
小さな変更。背景色が古くなっていることを説明する簡単な電子メールや、レポートを別の列で並べ替えるリクエストのように。これらは、時間の許す限り行います。
大企業の統合。Intuit（QuickBook）やFedEx（送料）などの大企業とソフトウェアを連携させることが求められています。これらは多くの場合、よく考えられたドキュメントとサンプルコードを持っています。ワード文書またはPDFで数百ページを取得します。これらの問題は、仕様が間違っている場合です。統合をテストまたは認定しようとすると、不正確さがわかります。このような場合、通常、最初にプロセスを開発するよりも認証に時間がかかります。
いずれの場合も、本当の問題は、営業担当者がプログラマーに何が必要かを尋ねる前に、顧客に解決策を約束することです。つい最近2週間前に、営業担当者が実際のトラブルに巻き込まれ、払い戻しを行う必要がありました（その担当者はもう会社にいません）。
作品がどのグループに属するかによって異なります。
サポート リクエスト - 変更に時間がかかり、壊れたものを修正する場合は、このグループがあります。これは、フォームが何年も前に作成されたものであり、ユーザーの追加と削除を除いて、物事を壊すことを恐れて触れられていない場合、「その古いフォームの承認されたユーザーのリストにボブを追加する」という単純なものです。
サービス諮問委員会のリクエスト - グループの新しいフォームまたはポータルを作成するためのミニ プロジェクトのようなものであるため、数日以内のアイテムはこのグループに含まれます。これは、一部のサード パーティ製ソフトウェアのアップグレードであり、いくつかのカスタマイズが行われているため、運用担当者が必ずしも簡単にアップグレードできるとは限りません。
プロジェクト - この場合、通常、範囲、予算、および時間の観点から要件を明確にするのに役立ついくつかの Word 文書および/または電子メール スレッドがあります。要件が実際に満たされているかどうかを判断するために最初のプロトタイプを作成するのではなく、プロトタイプを変更することについては、何か言いたいことがありますが、これらには数か月かかる場合があります。もちろん、私の現在のプロジェクトは 1 年以上経過していますが、タイムラインにはまだ数か月あり、完了後にすでに後継プロジェクトがあります。つまり、フェーズ I の後にフェーズ II があります。
Uber プロジェクト - これらは独自の文書化グループに値するものであり、数百万ドルの費用がかかります。通常、すべてを前もって文書化しようとする複数の企業プロジェクトは、ここではほとんどうまくいきません。したがって、これらに対してアジャイルが採用されていますが、アジャイルの使用方法が成熟するにつれて、まだいくつかの成長痛があります。ソフトウェアは非常に堅牢で柔軟性があり、人々の方法に多くの時間とお金を節約するのに役立つはずなので、社内外の開発者の両方が特定のニーズに合わせてスイートをカスタマイズする必要がある既製のソフトウェアの多数のモジュールをインストールすることを考えてみてください。それ以外の場合は、一般的に仕事をします。ここでいくつかの例として、ERP または CRM を考えてみましょう。
プロダクト マネージャーとシニア エンジニアは、データ管理ソフトウェア プロジェクト用に 3 つの計画ドキュメントを作成します。
大まかな要件: このプロジェクトでサポートされているハードウェア/ソフトウェアまたは特定の機能についての 1 ～ 3 文の説明。(10 ～ 15 ページの Excel のようなグリッド)
技術的な詳細: 各高レベル要件のエンジニアリング実装。詳細の量に応じて、各 1 ページまで。(30 ～ 40 ページの特徴の詳細を記入)
ビジネス契約: エンジニアリング スケジュールおよび製品管理部門の市場分析を含む 1 と 2 の概要。誰もがこれを承認します。(分析 5 ページ、技術 20 ページ)
私たちの仕様では、ワークフローやその他の Visio のような詳細は見ていません。優先順位付けされた要件とスケジュールは非常に重要であることがわかっているため、開発とテストの時間を節約するためにいつ物事を切り捨てるかを理解しています。
なし-少なくとも経営陣からではありません。
代わりに、開発者として (特に現在ソフトウェア プロジェクトを率いている)、ユーザー/顧客/その他に連絡を取り、彼らと直接協力して仕様と要件を考え出すことが期待されています。私がチームに要求するドキュメントは、チームにとって役立つものにすぎません。経営陣が意味をなさない、または私たちのプロジェクトに何の役にも立たない文書を要求することはめったにないという点で、私は幸運です。
私は現在、各 60 ～ 80 ページの半ダース程度の仕様を持っています。そのうちの 1 つは、目次のない 80 ページです。良い時代。