ネクタイ
開発者と顧客に関連するトピックを上げたいです。開発は楽しみです。 神話または現実とは何ですか？ 開発プロセスが、開発者と顧客の両方の当事者に喜びをもたらすような方法で設定されている企業はありますか。 結局のところ、最終的に、双方の目標は同じです-最終製品に対する満足度。
比較的複雑で時間のかかる製品については、Web開発でさらに議論することを控えます。
標準プロセスを検討してください。 会社があります-顧客、彼女は製品が必要です。 開発者の会社があり、彼らはこの製品に命を吹き込む必要があります。 単純に思えますが、利益相反はありません。目標は1つです。 しかし、ここでは当然ですが、顧客は最短時間で製品を必要とします。これは市場の要件です。 繰り返しますが、開発会社は安くはありません。 一般的に、顧客は高速で安価で高品質を必要とします。
多くの場合、背後にいる顧客は既に開発者とのコミュニケーションの経験があります。 そして、残念なことに、多くの場合、否定的です。 製品は時間通りにではなく、またはまったく行われていませんでした。
なぜこれが起こったのですか？ 繰り返しますが、標準プロセスに戻ると、顧客と開発者とのやり取りの最初の段階はどうですか？ 顧客は、非常に抽象的に、彼のアイデアを提示します。 開発者は、ランタイムのかなり抽象的な見積もりを提供します。 これは、最初の最も重要な間違いが発生する場所です。製品、条件、負荷などについてはほとんど何も知らずに、時間が推定されます。 自分が知っていることしか評価できないと仮定するのは非常に理にかなっていますが。 しかし、開発者と顧客はすでに最初のtrapに陥っています。できるだけ早く評価を行う必要があります。 結局のところ、ビジネスプラン、グラフ、および開発者とは関係のない一連の論文を承認する必要があります。
クライマックス
建築の世界から例えをします。顧客は、一定の数の窓と2つの入り口を持つ4階建ての家を建てることを求めます。 「まあ」とビルダーは考えています。「それは非常に簡単で、すでに8階建てと9階建ての家を建てました。 したがって、この半分の時間を8階建ての建物から構築します。」 また、顧客は納期に満足しており、将来の家のドアのアーチに彫ることを勧めます。 「やめて、どのアーチ？」ビルダーは尋ねます。 「何と同じように」顧客はまだ親切に驚いていました。 「私たちが家を建てている地域では、すべての家にアーチがあるはずです。」 そして離れて行く...
これは、データが不十分な状態でプロジェクトを評価するためのオプションの1つの例です-専門家の評価、すでに完了したプロジェクトに基づく評価。 しかし、残念ながら、非常に複雑なプロジェクトを検討する場合、すべての「類似点」は評価者の頭にあるため、指で空に落ちるのに近いことがよくあります。 そして、これをどのように理解できますか？プロジェクトは、「抽象的な説明」段階で「類似」の概念に適合していますか？ まさか！
デノウメント
その結果、このような評価の後、開発者が「内部の内容を思い出すのが恥ずかしいほどにできた」という製品を好まない製品を得ました。 顧客にとっても：「まったく違うものが欲しかったのですが、彼らは常に締め切りを延期しました。結局、他の人を雇うには遅すぎたので、何が起こったかについて同意しなければなりませんでした。」
それで何？
問題があります。おそらくこれを疑う人はいないでしょう。 しかし、解決策はどこにありますか？ 残念ながら、特効薬はありません。 条件を完全に評価することはできませんが、理解できますが、顧客との緊密な心のこもったコミュニケーションを「即座に」評価することさえできません。 すべての詳細、下請業者の有無、タスクのさらなる「洗練」が計画されているかどうかを調べます。 実際、多くの場合、顧客に対する明確化は、開発者のアーキテクチャの変更であり、これはタイミングに影響を及ぼします。 非常に重要なポイントは、注文の実行中に、顧客とのコミュニケーションであり、詳細を明確にすることだけではありません。 特定の決定を行う理由を説明してください。これは相互信頼にプラスの影響を与えます。