技術に詳しくない人が小規模プロジェクトの仕様書を書く方法を学ぶにはどうすればよいですか？

技術に詳しくない人が小規模プロジェクトの仕様を書く方法を学ぶにはどうすればよいですか？

私の友人は、統計プロジェクトの開発を外部委託しようとしています。

特に、彼はExcelで多くの作業を行っており、スクリプトの作成を外部委託して、手作業で行うことを望んでいます。

しかし、私の友人は非常に技術的ではありません。彼は技術仕様を書くのが苦手です。

彼が仕様を書くとき、それはあなたがExcelで何かをすることを記述する方法で書かれています（このセルに行き、そのセルに値をコピーします）。また、非常に冗長であり、例を何度か実行します。彼がコーナーケースを適切に説明しているかどうかはわかりません。

彼が最初に外注したプロジェクトは失敗でした。彼はいくつかの詳細を過剰に説明したが、コーナーケースを過小説明したと思う。それおよび/または彼が雇ったコーダーは、コーナーケースを熟考し、適切な質問をしませんでした。よく分かりません。私は彼とIMをしましたが、説明に5分もかからなかったはずの説明を掘り下げるのに30分かかりました。私は最後に彼のためにスクリプトを書きましたが、コーダーとの彼のプロセスが失敗した理由を調べませんでした。

彼は私に助けを求めました。しかし、彼の仕様を取り、それを明確な要件に翻訳することは、明確に書かれた仕様を実行するよりも10倍多くの作業があるため、私は関与しません。

彼が学ぶ正しい方法は何ですか？彼が使用できるリソースはありますか？コーダーとの小規模で低圧の練習プロジェクトから学ぶ方法はありますか？

彼のスクリプトのほとんどは、統計およびデータ処理指向です。たとえば、この列を取得し、平均を実行します。これらの条件下でこれらの行を削除します。そのため、課題はWebアプリの仕様とは異なります。

この問題に対する2つの良いアプローチが考えられます。ただし、2つのことを理解することが重要です。まず、要件エンジニアリングは大変な作業です。アイデアをシステムを構築するのに十分な正式な仕様に変えるには、多くの時間、労力、練習が必要です。第二に、優れた要件がある場合（正式な仕様から、あまり正式ではないユーザーストーリーやユースケースまで、どのような形式でも）、実際にソフトウェアをビルドする（そしてすぐにビルドする）方がはるかに簡単で、安く、速くなります。

友だちが多数のソフトウェアツールを構築するように依頼する場合、またはそれらを外注する場合は、少なくともビジネス目標と運用の概念のレベルで、ソフトウェア要件の作成方法を学ぶ必要があります。ソフトウェア要件エンジニアリングに関する2つの主要な書籍は、Karl Wiegersによるものです。ソフトウェア要件（第2版）とソフトウェア要件の詳細：Thorny Issues and Practical Advice。彼が雇うほとんどの人は、少なくともビジネス目標や運用の概念のレベルで、システムを説明する何らかの種類の文書が欲しいと思うだろうし、これらの本はそれに入る。また、優れた開発者がプロ​​ジェクトの初期段階で経験すると思われる要件エンジニアリングの他の側面の方法と理由についても説明します。

2番目のオプションは、ソフトウェア開発および要件エンジニアリング（および、おそらく何らかのシステムエンジニアリングまたはシステムアーキテクチャ）の経験を持つ人を雇って、問題空間を理解し、ソフトウェアソリューションが必要な場所とソフトウェアソリューションが必要ない場所を決定することです。有益であり、ドキュメントを書き、おそらく開発作業を監督または実行します。ただし、これはおそらくより高価であり、要求されたシステムだけでなく、必要な要件とアーキテクチャも開発するためにフルタイムのソフトウェア開発者を長期間雇うことになります。

正直なところ、あなたの友人が経験していることは、ソフトウェア開発プロセスを理解していない人にとって珍しいことではないと思います。また、彼のせいだとは思いません。最初のソフトウェアプロジェクトに適切な要件がなかった場合、外部委託先の開発者は、要件を明確化し、改善し、文書化する必要がありました。率直に言って、非技術的なユーザー/顧客と協力し、優れた技術仕様を開発するために時間や労力を費やす意思がない場合、あなたが関与するのにふさわしい人物であるかどうかはわかりませんエンジニアリング分野で要件エンジニアリングを実行する人の重要な役割です）。

最適なソリューションは、実際には2つのオプションの組み合わせだと思います。あなたの友人（そしておそらくあなたも）は、要件エンジニアリングに何が関係しているのか、そして強固な要件を持っていることがプロジェクトにもたらすメリットについて学ぶべきだと思います。また、ソフトウェア開発者として、要件エンジニアリング、およびソフトウェアプロジェクトに適した要件の抽出、文書化、分析、および管理の方法に精通する必要があります。これは、ソフトウェアライフサイクルの任意の部分で作業を行う人にとって本当に貴重なスキルです。

技術系ではないクライアントからの仕様が必要なときは、通常、彼らが何を達成したいのかを平易な言葉で書くよう依頼します。「Cを押したときにアプリはAからBを実行する必要がありますが、Dの場合のみです。」「Dは次のことを意味するため...」の追加ボーナス。

実際、「このコラムを取り上げて、平均を実行します。」正しい方向への一歩です。より良い説明は、「テーブルにこれとそれが含まれています」（構造が事前に定義されている場合）です。「Xの平均を取得」。基本的に、詳細を失うことなく可能な限り技術的な方法です。

つまり、実装ではなくアイデアを説明します。

そして、思いやりのあるプログラマーは、任務の実際の目的を理解し、適切なステップを自分で選択して、非自明なことについて質問することができるはずです。

プロセスを十分に気遣って理解している人がいない場合、プロジェクトはいずれにしても失敗します。

彼はストーリーボードアプローチを使用してみてください。

アプリケーションに必要なこと（ストーリー）のリストをメモしてもらい、そのリスト内で各ストーリーの機能をさらに詳しく説明します。

彼は、Asanaのようなツールを使用して、プロジェクトの範囲と機能を具体化し、開発者と対話することさえできます。

それを明確な要件に変換することは、明確に書かれた仕様で実行するよりも10倍の作業です。

アーメン。それも理由を説明しています：

彼が雇ったコーダーは、コーナーケースを熟考せず、適切な質問をしませんでした。

要件を理解することは、ほとんどのプログラミングプロジェクトで最も困難な（そして最も高価な）部分です。技術に詳しくない人が要件を作成するときは、置き換えたい回避策のみを文書化することがよくあります（「Excelを開き、セルB3をクリックしてください...」）。彼らが望む最高のものは、彼らの現在の難易度の正確な複製です！

この問題を回避するために私が知っている最も生産的な方法は、この人にユースケースを書くことを奨励することです（「use」は「loose」で韻を踏む）。要件を記述する代わりに、システムの使用方法を説明します。これにより、開発者は、ユーザーが現在行っていることよりも優れたソリューションを提案するための余地を残しています。

この問題は、友人の書面によるコミュニケーション能力の低さによって悪化しているようです。彼/彼女は、アイデアを効果的に伝えるために作業を行うか、プログラマーに情報を提供するためにお金を払わなければなりません。どちらのプロセスも苦痛で時間がかかりますが、自分で行うのは、誰かにそれをするためにお金を払うよりも安価です。

いずれにせよ、これは、創造的な人々が不完全なアイデアを持っているか、100万語未満で説明できない一般的なイライラする困難です。この人は、彼らが本当にやろうとしていることの底に着いて、それを実現しようとする非常に忍耐強く洞察力のあるプログラマーを見つけようとするべきです。

彼が雇ったコーダーは…適切な質問をしなかった

それは災害のレシピです。それと、コーダーが求める期待。コーダーは、コミュニケーションではなくコーディングを好み、インセンティブなしで習慣を破ることを期待するのはかなり非現実的です。

友だちが仕事をやりたい場合は、コーダーとの継続的なコミュニケーションを含むプロセスを確立することをお勧めします。コーダーではなく、そのために積極的な役割を果たす必要があるのはあなたの友達です。「毎週月曜日に行われていることを見せて、毎週火曜日にこれを議論するために2時間を設定します」、そのようなもの。

• 導入のために、反復およびアジャイル開発の方法論の簡単な概要を提供します（Wikipediaの記事はそうします）。
   
• 過去の失敗を理解しやすくするために、Waterfall / Big Design Up Frontの簡単な概要を提供します（批判を含むもの-再びWikipediaの記事が行います）。前もって。

私の経験では、非技術的な顧客が望むようにソフトウェアを動作させるための最も信頼できる方法は、機能の説明を一発で指定するのではなく、機能の説明を恒久的にやり取りすることでした。

彼のスクリプトのほとんどは、統計およびデータ処理指向です。たとえば、この列を取得し、平均を実行します。これらの条件下でこれらの行を削除します。そのため、課題はWebアプリの仕様とは異なります。

それは異なります-Webアプリを指定するよりもずっと簡単に思えます。それは論理的なプロセスです。これは簡単なものです。

友人は、このプロセスを実行するときに実行する手順を簡単に書き留める必要があります。好きなようにできますが、重点を置くべき重要なことは、正確さ、簡潔さ、明快さです。純粋に原稿のようなテキストではできない理由はありません。コンポーネントやタスクを論理的に分割することでメリットが得られ、おそらくフローチャートや図としてうまく機能します。

今、あなたの友人は有能なアナリスト/開発者を見つけて、彼らのサービスに少しずつ従事するべきです。彼は自分の期待を明らかにする必要があります-毎日または少なくとも週に数回、友人が開発者と会い、進行状況の実演を見てください。友人は、これらのデモンストレーション中に開発者に時間を支払いますが、プロジェクトが仕様どおりに実行されていることを確認する価値があります。仕様への変更（つまり、友人が省略したもの）は、交渉し、おそらく見積価格に追加する必要があります。

私が「有能」と言ったことに注意してください-これは「平均」と同じではありません。有能でない「平均」開発者がたくさんいるからです。あなたの友人がただ一番安いコーダーを手に入れるか、単に誰かをオンラインで見つけたら、彼は問題を予想するべきです。オンラインで仕事を見つけた人はダメであることを示唆するものではありませんが、推薦なしに誰かを雇うことはないでしょう。

あなたの友人は単に適切な人を見つけなければなりません。どのソフトウェアプロジェクトでも、アナリスト、プログラマ、システム管理者、テスター、プロジェクトマネージャーが必要です。友人がこれらの役割を「アウトソーシング」したいほど、プロバイダーのスキルは向上し、友人はより多くの支払いを期待するようになります。

あなたにこれを破るのは残念ですが、正式な仕様の書き方を学ぶのは非技術者の仕事ではありません。開発者の仕事は、非技術者にインタビューし、その人が自分が何を求めているかについてあなたに言うことを明確にして、クライアントが本当に望んでいるものを決定することです（彼らが望むと思うものではなく、常に同じではありません）、比較的非公式の要件ドキュメント（適切に構造化されているが、クライアントが理解できない専門用語を回避しようとするドキュメント）を作成し、クライアントでそのドキュメントを確認します。

クライアントが非公式の要件ドキュメントに満足したら、それを使用して、より正式な要件仕様の草案を作成し、必要なものについてより技術的な詳細に進むことができます。

このプロセス全体は「要件キャプチャ」と呼ばれ、ソフトウェアエンジニアリングプロセスの最初のステップを形成します。実際にソフトウェアを書くことは、ソフトウェアエンジニアリングの比較的小さな部分に過ぎず、残念なことに多くのソフトウェア開発者が忘れています。彼らが忘れているように見えるもう一つは、物事が軌道にとどまることを保証するために、プロセス全体を通してクライアントと通信し、彼らとの対話を維持する強い必要があるということです。

非技術者とのコミュニケーションに関しては、コンピューターやソフトウェア開発の専門用語を使用するのを避けるように努めることが非常に重要です。自分の分野の専門用語を使用する場合は、これらの用語の意味を理解することが重要です。プロジェクト用語集を作成して、これらの用語の正式な定義を取得することをお勧めします。あなたは結局彼らのために働いているので、彼らがどこから来たのかを理解することが重要です。

専門用語の代わりに、あなたはあなたのクライアントと通信する非威圧的な方法を試してください難しい。さらに、クライアントは、言語がどれほど単純であっても、大量の紙を読むことを好まないため、視覚資料に頼ることもできます。ここでは、図、ワイヤフレーム、ストーリーボードが便利なツールです。

しかし、要するに、核心はあなたの言語を学ぶことはあなたのクライアントの仕事ではなく、彼らの言語を学ぶことはあなたの仕事です。