技術者でない人は、どうすれば小さなプロジェクトの仕様を書くことを学ぶことができますか？
技術者ではない人は、小規模なプロジェクトの仕様を書くことをどのように学ぶことができますか？
私の友人が統計プロジェクトの開発を外部委託しようとしています。
特に、彼はExcelで多くの作業を行っており、スクリプトの作成を外部委託して、現在手動で行っていることを実行したいと考えています。
しかし、私の友人は非常に技術的ではありません。彼は技術仕様を書くのが苦手です。
彼が仕様を書いているときは、Excelで何かを行うことを説明する方法で書かれています（このセルに移動してから、そのセルに値をコピーします）。また、これは過度に冗長であり、例を数回繰り返します。彼がコーナーケースを適切に説明しているかどうかはわかりません。
彼がアウトソーシングした最初のプロジェクトは失敗でした。私は彼がいくつかの詳細を説明しすぎたと思いますが、コーナーケースを説明していません。それや彼が雇ったコーダーは、コーナーケースを熟考して適切な質問をしなかった。よく分かりません。私は彼とIMに乗り込み、5分以内で説明を説明するのに30分かかりました。最後に彼のためにスクリプトを書きましたが、コーダーとの彼のプロセスが失敗した理由を調べませんでした。
彼は私に助けを求めました。ただし、彼の仕様を取得してそれを明確な要件に変換することは、明確に記述された仕様で実行するよりも10倍の作業であるため、関与することを拒否します。
彼が学ぶための正しい方法は何ですか？彼が使用できるリソースはありますか？プログラマーがいる低圧の練習プロジェクトから彼が学ぶ方法はありますか？
彼のスクリプトのほとんどは、統計およびデータ処理指向です。例えばこの列を取り、それに対して平均を実行します。これらの条件下でこれらの行を削除します。したがって、この課題は、Webアプリを仕様化することとは異なります。
この問題に対する2つの適切なアプローチが考えられます。ただし、2つのことを実現することが重要です。まず、要件エンジニアリングは大変な作業です。システムを構築するのに十分なアイデアを正式な仕様に変えるには、多くの時間、労力、および練習が必要です。第2に、適切な要件がある場合（形式仕様から、正式な仕様からそれほど正式でないユーザーストーリーやユースケースまで）、実際にソフトウェアをビルドする（そしてそれをすぐにビルドする）ことは、非常に簡単、安価、そして高速になります。
友人が多数のソフトウェアツールの構築を要求する場合、またはそれらを委託する場合は、少なくともビジネス目標のレベルと運用の概念で、ソフトウェア要件の記述方法を学ぶ必要があります。ソフトウェア要件エンジニアリングに関する2つの主要な書籍は、カールウィーガースによる ソフトウェア要件（第2版） および ソフトウェア要件の詳細：厄介な問題と実践的なアドバイス です。彼が雇うほとんどの人が、少なくともビジネス目標のレベルまたは運用の概念でシステムを説明するある種の文書を欲するであろうと私は予想し、これらの本はそれに入る。彼らはまた、優れた開発者がプロジェクトの早い段階で経験すると思う、要件エンジニアリングの他の側面の方法と理由についても説明します。
2番目のオプションは、ソフトウェア開発と要件エンジニアリング（およびおそらく何らかのシステムエンジニアリングまたはシステムアーキテクチャ）の経験を持つ人を雇って、問題の領域を理解し、ソフトウェアソリューションが必要な場所とソフトウェアソリューションが必要ない場所を特定することです。有益であり、ドキュメントを作成し、おそらく開発作業を監督または実行することさえできます。ただし、これはおそらくより費用がかかり、要求されたシステムだけでなく、必要な要件とアーキテクチャも開発するために、フルタイムのソフトウェア開発者を長期間雇用することになります。
正直なところ、あなたの友人が経験していることは、ソフトウェア開発プロセスを理解していない人にとっては珍しいことではないと思います。私もまた、責任が完全に彼にあるとは思いません。最初のソフトウェアプロジェクトに適切な要件がなかった場合、アウトソーシング先の開発者は、要件を明確にし、洗練し、文書化したはずです。率直に言って、非技術的なユーザー/顧客と協力して適切な技術仕様を開発するための時間や努力を惜しむなら、あなたが関与する適切な人物であるかどうかもわかりません（これはあらゆるエンジニアリング分野で要件エンジニアリングを実行するすべての人の重要な役割です）。
最適なソリューションは、実際には私の2つのオプションの組み合わせだと思います。あなたの友人（そしておそらくあなたも）は、要件エンジニアリングに何が関係しているか、そして確かな要件を持つことがプロジェクトにもたらすメリットについて学ぶべきだと思います。また、ソフトウェア開発者は、要件エンジニアリング、およびソフトウェアプロジェクトに応じて要件を導き出し、文書化、分析、管理する方法に慣れる必要があります。これは、ソフトウェアライフサイクルのあらゆる部分で作業を行う人にとって、本当に貴重なスキルです。
非技術的なクライアントからの仕様が必要なときは、通常、彼らが達成したいことを正確に平文で書くように依頼します。 「Cを押したときにアプリがAからBを実行する必要がありますが、Dの場合のみ」のように。 「Dがそれを意味するから...」の追加ボーナス。
実際、「この列を取り、それに対して平均を実行します」。正しい方向への一歩です。より良い説明は、「テーブルはこれとそれを含む」です（構造が事前定義されている場合）。 「Xの平均を取得」。基本的に、詳細を失わずに可能な限り技術的な方法です。
つまり、実装ではなくアイデアを説明します。
次に、思いやりプログラマーは、彼が依頼した作業の実際の目的を理解し、適切な手順を自分で選択して、自明ではないものについて質問する必要があります。
十分に気を配り、プロセスを理解している人がいない場合、プロジェクトはいずれにせよ失敗します。
ストーリーボードアプローチ を使用してみることができます。
彼に物事のリスト（stories）を書き留めてもらい、そのリスト内で、各ストーリーの機能についてさらに詳しく説明します。 。
彼は Asana のようなツールを使用して、プロジェクトのスコープと機能を具体化し、開発者と対話することもできます。
それを明確な要件に変換することは、明確に記述された仕様で実行するよりも10倍多くの作業です。
アーメン。それも理由を説明しています：
彼が雇ったコーダーは、コーナーケースを熟考して適切な質問をしませんでした。
要件を理解することは、ほとんどのプログラミングプロジェクトで最も困難な（そして最も高価な）部分です。技術者ではない人が要件を書くとき、彼らはしばしば置き換えたい回避策のみを文書化します（「Excelを開き、セルB3をクリックして...」）。彼らが期待できる最高のものは、彼らの現在の困難の正確な複製です！
これを回避するために私が知っている最も生産的な方法は、この人に ユースケース を書くように促すことです。要件を記述する代わりに、システムの使用方法を説明してください。これにより、開発者は、ユーザーが現在行っていることよりも優れたソリューションを提案するために、少し余裕がなくなります。
この問題は、友達の書面によるコミュニケーション能力が低いために悪化しているようです。彼/彼女は彼らのアイデアを効果的に伝えるために仕事をするか、それらから情報を釣り上げるためにプログラマーに支払わなければなりません。どちらのプロセスも苦痛で時間がかかりますが、それを自分で行うことは、誰かにお金を払ってそれを行うよりも安価です。
いずれにせよ、これは一般的でイライラする問題であり、クリエイティブな人々は不完全なアイデアを持っているか、100万語未満でそれを説明することができません。この人は、彼らが本当にやろうとしていることの底をつき、それを実現させようとする、非常に忍耐強く洞察力に富んだプログラマーを見つけようとするべきです。
彼が雇ったコーダーはしなかった...適切な質問をする
それは災害のレシピです。それと、コーダーが求めるであろう期待も尋ねます。プログラマーは、コミュニケーションではなくコーディングを好み、インセンティブなしに習慣を破ることを期待することは非常に非現実的です。
あなたの友人が仕事をやりたいなら、彼らはコーダーとの継続的なコミュニケーションを含むプロセスをよりよく確立します-そしてそれは、コーダーではなくあなたがその中で積極的な役割を果たす必要があるあなたの友人です。 「毎週月曜日に何が行われるかを見せて、毎週火曜日にこれについて話し合うために2時間設定する」などのようなものです。
- 紹介のために、反復およびアジャイル開発方法論の簡単な概要をいくつか提供し（Wikipediaの記事で十分です）、それがどのようにあるべきかについての感触を得られるようにします。
- 彼らが過去の失敗を理解するのを助けるために、ウォーターフォール/ビッグデザインアップフロント（批評を含むもの-繰り返しになりますが、ウィキペディアの記事はそうします）のいくつかの軽量な概要を彼らに提供します-これらは通常、物事を正しく特定することが通常いかに難しいかを説明するかなり良い仕事をします前もって。
私の経験では、技術者以外のお客様がソフトウェアを希望どおりに機能させるための最も信頼できる方法は、機能の説明を永続的に伝達および反復することであり、一度に死ぬように指定することではありません。
彼のスクリプトのほとんどは、統計およびデータ処理指向です。例えばこの列を取り、それに対して平均を実行します。これらの条件下でこれらの行を削除します。したがって、この課題は、Webアプリを仕様化することとは異なります。
それは異なります-Webアプリを指定するよりもずっと簡単に見えます。それは論理的なプロセスです。これは簡単なことです。
あなたの友人は、彼がこのプロセスを実行するときに彼が取るステップを書き留める必要があります。彼は好きなようにそれを行うことができますが、焦点を合わせる重要なことは、正確さ、簡潔さ、明快さです。原稿のように純粋にテキストで行うことができないという理由はありません。コンポーネントやタスクを論理的に分割することでメリットが得られ、フローチャートや図としても機能します。
これであなたの友人は有能なアナリスト/開発者を見つけ、彼らのサービスを少しずつ従事するはずです。彼は彼の期待を説明する必要があります-毎日または少なくとも週に数回、あなたの友人は開発者と会って、進行状況の実演を見る必要があります。あなたの友人は、これらのデモンストレーションの間、開発者に時間を支払いますが、プロジェクトが仕様どおりに実行されていることを確認することは価値があります。仕様への変更-つまり、友人が省略したもの-は交渉する必要があり、おそらく見積り価格に追加する必要があります。
私が「有能」と言ったことに注意してください。これは「平均」と同じではありません。有能ではない「平均」の開発者がたくさんいるためです。あなたの友人が最も安いコーダーを手に入れたか、誰かがオンラインで見つけた場合、彼は問題を予期するべきです。オンラインで仕事を見つけた人がダメだと言っているわけではありませんが、推薦がなければ人を雇わないでしょう。
あなたの友人は単に適切な人を見つけなければなりません。どのようなソフトウェアプロジェクトでも、アナリスト、プログラマー、システム管理者、テスター、プロジェクトマネージャーが必要です。友人が「アウトソーシング」したいこれらの役割が多いほど、プロバイダーのスキルは高くなり、友人はより多くの支払いを期待するはずです。
これを壊してしまって申し訳ありませんが、正式な仕様の書き方を学ぶのは非技術者の仕事ではありません。非技術者にインタビューし、彼らが何を求めているかについてその人があなたに何を言っているかを詳細に調べ、クライアントが本当に望んでいることを決定する（開発者が望んでいるとは対照的に、常に同じとは限りません）、比較的非公式な要件ドキュメント（適切に構造化されているが、クライアントが理解できない専門用語を避けようとするドキュメント）を作成し、クライアントとそのドキュメントを確認します。
クライアントが非公式の要件ドキュメントに満足したら、それを基礎として、必要なものについてより技術的な詳細に取り掛かる、より正式な要件仕様を作成できます。
このプロセス全体は「要件の取得」と呼ばれ、ソフトウェアエンジニアリングプロセスの最初のステップを形成します。実際にソフトウェアを作成することは、ソフトウェアエンジニアリングの比較的小さな部分にすぎません。悲しいことに、多くのソフトウェア開発者は忘れています。彼らが忘れているように見えるもう1つのことは、物事が軌道に乗っているかどうかを確認するために、プロセス全体を通じてクライアントと通信し、クライアントと適切な対話を保つ必要があることです。
非技術者とのコミュニケーションに関しては、彼らと話すときにコンピューターやソフトウェア開発の専門用語を使わないようにすることは非常に重要です。彼らが自分の分野の専門用語を使用している場合は、これらの用語の意味を理解することが重要です。そのため、プロジェクト用語集を作成して、これらの用語の正式な定義を取得できます。結局のところ、あなたは彼らのために働いているので、彼らがどこから来ているのかを理解することが重要です。
専門用語の代わりに、威圧的ではない方法でクライアントと通信することを試してください。プレーンな英語で書かれたドキュメントは助けになりますが、ソフトウェアビジネスの多くの人は人間ではなくコンピュータを書くことに慣れているので、これを見つけるかもしれません難しい。さらに、クライアントは、自分の言語がどれほど明白であるかに関係なく、大量の紙を読むことを好まないので、視覚補助に頼ることができます。ここでは、ダイアグラム、ワイヤーフレーム、ストーリーボードが便利なツールです。
しかし、要するに、核心はあなたの言語を学ぶことはあなたのクライアントの仕事ではなく、彼らの言語を学ぶことはあなたの責任であるということです。