戻る
ソフトウェア開発プロジェクトで構築される製品に対する誤解やビジョンの欠如は、クライアントとプロセスを担当するチームとの協力関係において非常によくある問題です。これらの脅威は、達成された結果に直接的な影響を及ぼし、しばしば納期の遅れや予算の損失につながります。このような危険はどこに現れ、どのように戦うべきかをご覧ください。
画像出典：Perfectdigital.com
大きな齟齬やビジョンの欠如が、次のような形で現れる可能性があることをよく示していると思う。 ソフトウェア開発プロジェクト すべての参加者と関係者の間で。 問題はしばしば、クライアントが（理論的には）最終的なプランを提示する最初の段階から生じる。 製品 のビジョンを提示する。 チーム.そして、さらなる誤解、誤った解釈、そして最終的には......。 プロジェクト すぐに間違った発展の道を歩むことになる。
上のグラフを分析しながら、起こりうるすべての脅威を段階的に提示し、それに対抗する方法を提案する。さっそく本題に入ろう！
製品ビジョンには最初から齟齬がある。なぜか？その理由はとても簡単で、誰もが現実を自分なりに解釈し、心の中に何かを思い描き、そのビジョンを相手に正確に示すことができないからです。あなたが作りたい製品を言葉で説明しても、開発チームはあなたの意図とは異なる方法であなたのビジョンを理解する可能性が高い。
もちろん、これを避けることは可能だ。できるだけ早く視覚化を開始し、スケッチに基づいて製品の機能性の個々の要素について議論する必要があります。興味深いことに、最初のスケッチは通常、最終製品とは何の共通点もない。しかし、この段階で最も重要なことは、ビジョンを首尾一貫したものにすることである。
なぜ1枚目と2枚目の写真がこんなに違うのか、不思議に思いませんか？プロジェクト・リーダーは常に製品ビジョンをよく見る。しかし そのような人物は、基本的に全責任を負うことが重要である。 ソフトウェア開発 プロセス, 製品に関する問題やニーズを十分に理解している。.プロジェクトリーダーは明確な "大局観 "を持たなければならない。ご覧の通り、どちらの画像も機能面では違いはない。ただ見た目が違うだけなのだ。この点をよりよく理解するために、1番目の写真に戻ろう。プロジェクト当初、スケッチはなく、それがすでに誤解を招いていた。製品の機能性は正しいが、デザインはまったく違う。
アナリストや開発者は、ユーザーのニーズや確立されたビジネス目標を知らないことがある。彼らはプロジェクト全体のほんの一部分しか見ておらず、それが彼らの主な焦点となっている。これは特に、多くの開発者が同時に作業するような大規模なプロジェクトの場合です。
別の例を使うこともできる。例えば、プロダクトオーナーによって、解決すべき問題が間違って記述されていることがある。このような場合、不完全な情報が提供されることになり、開発者や設計者はそれに基づいて独自の解釈を行い、製品は意図した開発経路からどんどん外れていく。
それを変えるには？私が思うに、良い解決策は、プロジェクトの要となる人々に、プロジェクトに関する詳細な知識、いわゆる "全体像 "を持たせることである。そうすれば、誤解が生じた場合にも、その誤解を解くことが容易になります。 ソフトウェア開発プロセス 正しい道に戻る。したがって、覚えておいてほしい。もし誰もが、開発された機能のほんの断片しか見ていなければ、ビジョンにおける誤解が脅威となる可能性が高い。
ここでの問題は単純だ。商品は売れなければならない。例えば、庭のためのシンプルなブランコが、並外れた要素を持つように。アイデアは、潜在的な買い手を納得させることだ。マーケティング部門と営業部門は、その製品がユニークであることを示すためにあらゆることを行うだろう。
ドキュメントの欠落は非常によくある問題です。時には、以下のような文書が 製品開発 は不必要な時間の浪費のように思える。これは間違いだ。私はよく言うのだが、変更というのは紙の上で行う方が、実際の現場で行うよりも早いのだ。 コードそしてそこには何かがある。加えて、変更を追跡するためにドキュメントを参照することが容易になる。信じてほしいが、ドキュメンテーションのないプロジェクトは、ビジョンを見失う危険性が非常に高い。
この段階は、サーバーに環境を置くことを指す。プログラマーとアナリストの話と同じように、完全なデータがなく、コミュニケーションギャップがあると、必要な環境の一部しかできていないことがある。
コミュニケーション不足、UXの欠如などの結果だ。エラーの出現は開発時間を増加させる。そして時は金なり、ですね。 私のヒントは、アジャイルに従ってプロジェクトを進めることだ。そして、最高のコミュニケーション・スタンダードを維持し、明確な予算ガイドラインを守ること。そうすることで、このような問題を回避できることは間違いない。
顧客は、製品を作り上げることだけに集中し、それだけで終わってしまうことが多い。しかし、私たちは多くの変化と技術革新の時代を生きています。だからこそ、常に技術サポートを維持する必要があるのです。突然動かなくなるような事態を避けるためだ。この点も忘れてはならない。
最後のポイントに到達した。最初のグラフと最後のグラフの不一致を見てください。結局のところ、どちらもクライアントの視点に関連している。なぜこのようなことが起こるのでしょうか？調査結果は常に、回答者の実際のニーズとは異なります。調査員の質問に答えながら、ユーザーは自分の良い面を見せたいと思うものです。だから 正直に答えないことが多いむしろ、自分が答えるべきだと思う方法で。基本的に、彼らは他人の否定的な評価にさらされたくないのだ。ここでちょっとしたヒントがあります。「良い答えも悪い答えもない」と指示書に書いておくことです。
他に違いはどこに現れるのか？人々はしばしば、自分が本当に欲しいものを知らない。ユーザーは、最初は製品に10の機能が必要だと言っていたのに、後になって実際に使うのは例えば3だけだということがよくある。
では、どうやってこの問題を解決するのか？ユーザーに何が欲しいか、何が必要かを尋ねるだけでなく、信頼性を維持するために、できれば本物のアイテムで、製品へのテストを許可する。製品を作る際にテストが多ければ多いほど、結果が正確である可能性は高くなる。
のメンバーになることがある。 ソフトウェア開発 プロジェクトに参加する際は、私の例を思い出し、上記のような誤りを犯さないように結論を出してください。そして、これらの概念は、ゼロから製品（アプリケーション）を構築する上で非常に重要であることを忘れないでください：
- 優れたUXとテストによって、ユーザーが本当に必要としているものを知ることができる、
- プロジェクト内のコミュニケーションを円滑にすることで、問題やニーズを深く理解することができる、
- に従って製品を開発する。 アジャイル,
- 技術サポートもお忘れなく。
続きを読む
– リモート開発者を効果的に管理するには？CTOのためのガイド
Japanese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Korean 
Spanish 
Dutch