アカウント名:
パスワード:
日本での事情に限定します(外国の状況には詳しくないので)が、記事の分析通り、要件定義を軽視しすぎていると感じます。要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく・「なぜこの要件なのか(要件が変更されたのか)」を最前線の開発担当者にも伝え、利用イメージを共有するといったことが重要になると考えます。
私た
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……>私たちがこの辺を端折ってしまい>私たちも要件定義フェーズから
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……
イメージしているのは、要件定義担当の開発者です。
本家の原文だと、(1)要件定義担当者:stakeholder(直訳は「利害関係者」なので、客先も含めた表現です)(2)プロジェクトマネージャ:manager(3)開発者:developer, devと分けられています。
先の文章では「私たち」で(1)を指しましたが、(3)の人が(1)を敵視するのではなく、開発プロセスの一部として(1)(3)に分かれているだけで、利害相反も上下関係もない立場であってほしいと思っています。
また、(1)と(2)を同一視することもありますが、むしろこれを分離しないと開発プロセスは良くならないのではないかと感じます。スケジュールは(2)の立場で決めますから、(1)に引っ張られて無理なスケジュールを設定してしまうことがないように、顧客を相手にする(1)とチーム内を相手にする(2)は、適度な緊張感をもって活動すべきだと考えます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
要件変更と工数見直し (スコア:2)
日本での事情に限定します(外国の状況には詳しくないので)が、記事の分析通り、要件定義を軽視しすぎていると感じます。
要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、
・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える
・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく
・「なぜこの要件なのか(要件が変更されたのか)」を最前線の開発担当者にも伝え、利用イメージを共有する
といったことが重要になると考えます。
私た
Re:要件変更と工数見直し (スコア:0)
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……
>私たちがこの辺を端折ってしまい
>私たちも要件定義フェーズから
Re:要件変更と工数見直し (スコア:1)
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……
イメージしているのは、要件定義担当の開発者です。
本家の原文だと、
(1)要件定義担当者:stakeholder(直訳は「利害関係者」なので、客先も含めた表現です)
(2)プロジェクトマネージャ:manager
(3)開発者:developer, dev
と分けられています。
先の文章では「私たち」で(1)を指しましたが、(3)の人が(1)を敵視するのではなく、開発プロセスの一部として(1)(3)に分かれているだけで、利害相反も上下関係もない立場であってほしいと思っています。
また、(1)と(2)を同一視することもありますが、むしろこれを分離しないと開発プロセスは良くならないのではないかと感じます。スケジュールは(2)の立場で決めますから、(1)に引っ張られて無理なスケジュールを設定してしまうことがないように、顧客を相手にする(1)とチーム内を相手にする(2)は、適度な緊張感をもって活動すべきだと考えます。