開発者が製品の所有者に機能のアイデアを提案するのは普通ですか？[閉まっている]

かなり最近、開発者として働き始め、以前はシステム管理者として働いていました。

アジャイル機能を使用するソフトウェア開発チームの私の理解は、「実装する必要がある」コミュニケーションは、製品の所有者から開発者への一方向でほとんど発生するということです。開発者は、技術的負債について製品所有者に懸念を表明することができますが、機能のアイデアを思い付くことは、主な責任の1つではありません。

私が働いている会社は別の見方をしています。開発者は、自分のチームの製品所有者に行って機能のアイデアを提案するだけでなく、他のチームの製品所有者にそのチームの製品に貢献する何かがあると思われる場合は行ってください。アイデアは、私たちはすべて1つの大きなチーム<会社名>であり、すべての開発者は、自分の専門知識を使用して、役立つと思われる機能をプッシュする必要があるということです。

より良い言葉がないため、そのようなアプローチは「通常」ですか？私は消極的すぎますか？イニシアチブを取り、製品所有者にアイデアを押し出すべきですか？逆に、会社はそれを完全に間違ってしまったので、他の場所で雇用を探すべきですか？

機能のアイデアの意味に依存します。

計画ゲームでは、開発者が繰り返しで終わる可能性のあるストーリーに関する情報を提供することは珍しくありません。ただし、これは開発者が独自にストーリーを作成する場合とは大きく異なります。

成熟したシステムでは、開発者が既知の問題を反復して反復させる方法を提案する場合があります。

たとえば、レポートにグラフを追加するなどの機能拡張は問題ありませんが、開発者が真正な新しいストーリーを思い付くと警告音が鳴ります。これに本当の価値があるとしたら、なぜこのための既存の未実装の物語がなかったのか、またはなぜ回顧展で登場しなかったのか疑問に思うでしょう。

多くの開発者が「受動的」である理由は、良い製品のアイデアを思いつく前に、ある程度のドメインの知識と経験が必要だからです。しかし、もし彼らが来たとしても、彼らを提案して彼らを擁護しない理由はありません。

念頭に置いてください-開発者、製品所有者、営業担当者などは全員同じチームに属し、同じ目標を持ち、成功する製品を構築します。ただし、できる限りその目標に向かって取り組みます。

開発者と製品所有者の話では、組織の機能に責任を持つ中間者はいないようです。

まあ、私の組織では、私はその人です。私は要件エンジニアであり、優れた仕様の作成方法を学び、ユーザーフレンドリーなインタラクションデザインを備えた高品質のソフトウェアをもたらす機能を選択しています。（他の組織では、同じ仕事に就くのはUX担当者です。その用語に詳しいかもしれません）。

そして、私はあなたに言うことができます：良い仕様を得るのは難しいです。もちろん、開発者はそれを嫌います。それは彼らの負担です-彼らはソフトウェアを構築するためにあり、利害関係者の間の権力の遊びや怠zyなユーザーのメンタルモデルについて考えるのではありません。しかし、あなたは何を知っていますか？製品所有者にとっても負担です。開発者やユーザーよりも、ソフトウェアにどのような機能が含まれているのかをよく知りません。実行可能な仕様を作成することは習得済みのスキルであり、習得したことがない場合は得意ではありません。確かに、以前のプロジェクトでそれをしなければならなかったので、それを行うことができる多くの開発者と製品所有者がいます。しかし、平均的な製品の所有者または開発者は、それを行うのが当然の仕事ではないため、それに苦労しています。車を運転できるすべての人が車を設計できるわけではありません。同様に、

要件エンジニアなしでソフトウェアを開発できますか？もちろんできます。しかし、仕様の全体の重みを製品所有者の肩にかけることは公平ではなく、プロジェクトの結果にとっても良くありません。特に、彼にとっては非常に困難な仕事に直面しているため、他の人から意見やサポートを得ることが非常に役立ちます。あなたがそのような状況にある場合、貧しい製品所有者を見て「あなたのために何を作るか教えてください、私はあなたを作ります」と言わないでください、彼は本当に彼が必要なものを知りません。しかし、あなたとの議論は、彼が彼の考えを明確にし、彼のアイデアを探求するのに役立ちます。

プロジェクト構造に要件エンジニアがいない場合、別の問題があります。モデレーターがいません。すべての開発者は技術面に、すべての製品所有者はビジネス面にいます。2つの文化が衝突すると、対立が発生する可能性があり、それぞれの側が愚かで不合理な他の1つを判断します（独自の価値システムを使用して判断するため）。そのため、可能性のある機能について製品の所有者と話をしますが、あなたがそれに値しないと思っても丁寧で忍耐強くなります。プロジェクトが成功するかどうかは、2人がうまくやっていくかどうかにかかっており、競合が原因でまったく決定を下さないよりも、次善の決定を下したほうがよい場合があります。デッドロックの競合を防ぐため、階層を確立し、2人のうち1人に最後の言葉を与えると役立つ場合があります。彼が最後の言葉を受け取ったら、たとえそれが不公平だと感じていても、それを延期する。

「受動的」部分について：アイデアがない場合は、活動を示すためだけのものを考え出さないでください。製品所有者がすでに不安であり、自分のアイデアを評価するための良い基準を知らない場合、「何かを持っているだけ」という奇妙なアイデアは、すでに困難な状況をさらに難しくします。優れた機能のアイデアを思い付くのは魔法ではありませんが、知識が必要です。教科書からそれを学ばなかった場合、おそらくあなたの脳がそれ自体のパターンを整理する前に、ユーザーまたはユーザー生成のユーザビリティデータ（分析、満足度測定）にさらされているプロジェクトでは、おそらく数年の開発者の経験が必要になりますそして、あなたは気づき始めます：私たちが解決できる問題がここにあります。ユーザーはこのページで何かを見逃しているようです。それは何でしょうか？その後、共有する良いアイデアがあります。

結論1：要件エンジニアのいないプロジェクトでは、提案があればすぐに提案することをお勧めします。敏感さとタクトでそれをしてください-それはあなたの良いアイデアが芽に挟まれることを意味する場合でも、競合を避けることが不可欠です。

また、要件エンジニアとチームを組んでいる場合はどうですか？

みんなから機能のアイデアを聞くのが大好きです！はい、開発者のアイデアがひどい場合があります（ユーザーインターフェイスをプログラミングロジックに追従させたい場合）。製品所有者のアイディアもひどいものです（太陽と月をわずかな予算で使いたいとき-ああ、ユーザーは何も見返りなく最高のデータ品質で個人情報のページを入力することになっています）。しかし、チームの全員に適した仕様を考案するのが私の仕事です。そして、たとえあなたのアイデアがうまくいかないとしても、それを聞いて私はあなたに懸念があることを認識させます。間違った解決策を選択して提案したかもしれませんが、これはあなたの懸念をそれほど有効にするものではありません。あなたがそれを見つけた場合、おそらく対処する必要があります（または、それが脅威ではない理由を考え出す必要があります）。仕様を担当する要件エンジニアがいる場合は、遠慮なく提案してください。彼らがあなたの声を聞かない場合、彼らは何か間違ったことをしている（「考える」は「受け入れる」という意味ではないことに注意）。

要件エンジニアは、各利害関係者の観点からプロジェクトを個別に（場合によっては同時に）表示する必要があります。私たちは人間であり、しばしば失敗します。あなたが考えている視点の代わりに、あなたが本当の視点を提供するためにそこにいるなら、あなたのインプットは非常に貴重です。

ここであなたの行動をもっと自由にすることができます。感度ダンスをするのが私の仕事です。積極的に攻撃しないでください。これは私の仕事の妨げになりますが、緩みを取ることができるので、自制心や文化的/コミュニケーションの意識をあまり必要としません。また、2つの矛盾するアイデアがあり、どちらが優れているかを誰も判断できない状況で、あなたは浮かんでいません。私はそれを知っているはずです、そしてそれがうまくいかないなら、それは縄の私の頭です。

結論2：チームに要件エンジニアがいる場合は、製品機能の提案とともにそれらに行きます。今回はベルベットの手袋は必要ありません。

そして最後に、要件エンジニアがいない場合、製品の所有者が圧倒されてアイデアに苦労し、上司があなたを鋭く見ていて、あなたが提供するアイデアがない場合はどうなりますか？

いくつかのオプションがあります。一つは、あなたが言ったように、やめることです。すべての組織がそのように機能するわけではありません。この環境が適切でない場合は、より良い環境を見つけてください。長期的にはあなたにとって良いことです。

また、何かが変化するかどうかを確認できます。次のプロジェクトには、より経験豊富な製品所有者（またはよりリーダーシップを持つ製品所有者）を配置できます。しかし、あなたは永遠に失速することはできません。

3番目のオプションは、実際にいくつかの要件エンジニアリングを自分で学ぶことです。これは最近非常に求められているスキルです。あなたがフルタイムの要件エンジニアである地位に就く予定がなくても、このスキルを持っていると開発者としての価値が高まり、チームの他のメンバー（およびユーザー）を理解し、開発プロセスがよりスムーズに進みます。そして、あなたはそれの全体の深さに入る必要はありません。タスク、ワークフロー、メンタルモデル、およびユーザー中心のデータモデルを説明するエントリーレベルのテキストブックを使用すると、ビジネスマンと開発者のチームによって設計されたソフトウェアの多くの改善機会を見つけることができます。ドン' 学者の参考となる最も厚い本（最近のPohlの英語への翻訳など）を参照してください-実際の方法を説明することなく、各小さなステップで可能なすべての方法のリストです。実践志向のものを選択してください。

それを試してみて、あなたがその地域に個人的な興味を持っていないことがわかったとしても、それでも大丈夫です。嫌いなことをするように無理にしないでください。ただし、異なるチーム構造を持つ組織での仕事を探しているはずです。

結論3：直感的な理解を得るのに何年も待つのではなく、本を1つか2つ読んでみれば、提供すべき優れたアイデアがすでにあるはずです。

はい、それは非常に正常です。

よく知られている80％の仕事-Googleの20％のイノベーションモデルでは、時間の20％が好きなことに専念しています。このように、彼らは新しい機能を手に入れるだけでなく、まったく新しい製品とサービスを手に入れます。

私は消極的すぎますか？イニシアチブを取り、製品所有者にアイデアを押し出すべきですか？

それはあなたの性格に依存します。私は本当に情熱的な人々と仕事をしてきましたが、8時間シフトして家に帰る感情のない人々とも仕事をしました。