私は食料品会社で働いています。 これはどういう意味ですか？
カスタムプロジェクトを開発するのではなく、顧客に販売する製品を作成します。
私のチームのために、私は製品のビジョンを形作り、どの「ウィッシュリスト」ユーザーを作るかを決定し、彼らが必要な理由をチームに（時にはアヒルで）説明します。 ビジネス価値の観点からタスクを説明し、仮説を策定し、テストします。
私の開発要件はあいまいに定式化されることがよくあり、機能は起動後にやり直すか修正する必要があります。
これにより、開発者向けの完璧なコードを書くことができなくなります。 多くのプロダクトマネージャーがこれを行うことを知っています。
そして、なぜ私が何度もそれをするのかをお話ししたいと思います。
製品は痛みを解決する必要があります
プロダクトマネージャーは、高価な（あらゆる意味で！）開発者の時間とエネルギーを無駄にしないために企業を設立する必要があるというビジョンを持っています。
これは、自分の好きなことだけを行うという意味ではなく、エンドユーザーに「一致」させようとします。 製品のタスクは、新しい問題を作成するのではなく、問題を解決することです。
製品チーム
以前は、機能の一部のみを実行する機能チームがありました（たとえば、フロントエンドを作成します）。 開発のスピード、コミュニケーションの中断、チーム間でタスクを転送し、ステータスを追跡するプロセスに満足していませんでした。
製品全体に責任を持ち、独自の機能を実行できる製品チームに移りました。
当社の製品チームには、製品およびプロジェクトマネージャー、複数のバックエンドおよびフロントエンド開発者、テスターが含まれます。
各チームメンバーがそれぞれの役割を果たします。 プロダクトマネージャーは調査を行い、バックログを作成し、優先順位を付けます。 開発者はコードを記述します。 テスターは品質を監視します。 プロジェクトマネージャーは要件の詳細を示し、チーム間のやり取りを整理し、障害物の除去を支援します。たとえば、テスト用の機器、マーカー、ホワイトボードの検索、会議室の予約、会議の開催などです。
私の夢は、他のプロダクトマネージャーと同じように、ユーザーとそのニーズを理解し、タスクを検証し、各機能がクライアントにもたらすメリットについて考えるチームです。
しかし、夢はめったに実現しません。 私の開発者は、誰のために、そしてなぜ彼らがコードを書くのかについてほとんど考えません。 彼らの主な仕事は、完璧なアーキテクチャを構築し、最先端のツールを使用して、新しいテクノロジーを試すことです。
そして、この矛盾は、私と開発者との間の紛争の最も一般的な原因になります。
MVP VS Perfectアーキテクチャ
私たちは非常に急速に変化している分野で働いています。 抽象化の数は常に増加しています。 新製品が登場して死にます。 ユーザーは、ソフトウェアの操作方法を学びたくないので、最小限の労力で問題を解決したいと考えています。 ただし、ユーザーがこの問題をどのように解決したいかを知らないことをよく忘れます。 彼はただ彼女になりたくない。
さらに複雑になる可能性があります-ユーザーは自分が問題を抱えていることを知らないかもしれません。 彼は長年生き、困難に苦しみ、これを標準と考えています。 そして、「あなたの問題は何ですか？」と尋ねると、「いいえ、元気です」とよく聞かれます。
製品チームの仕事は、クライアントの苦痛を理解し、最適なソリューションを提供し、私たちのツールで彼の人生がどれほど魔法になるかを伝えることです。
私たちは、顧客の開発なしでは、彼らが喜んで購入できるソフトウェアを作成することはほとんど不可能であることを認識しました。 プロダクトマネージャーとしての私の仕事は、ターゲットオーディエンスを探し、インタビューを行い、ニーズを特定し、キャラクターとその痛みを説明することです。 しかし、これでも常に成功を保証するわけではありません。 私も男です。私も間違っている可能性があります。
ミスを少なくするために、仮説を説明し、それらをテストするには、MVP（最小限の実行可能製品）を作成するチームが必要です。 成功するために、ほとんどの食料品会社が行うように、私は常に実験したいです。 結局、私がチェックする仮説が多ければ多いほど、そしてそれを速くするほど、ユーザーが高く評価する製品を会社が正確にリリースする可能性が高くなります。
しかし、チームに来て、機能を「ひざの上に」一週間で稼働させる必要があると言うとき、これは不可能だと聞きます。 アーキテクチャについて考える必要があります！ すべてのシナリオを考慮する必要があります！ すべての機能の説明を含む完全なToRが必要です！ そして、1000人のユーザーのうちの1人が私たちが期待したものでなく、彼のためにすべてが故障した場合はどうなりますか？！ このような短い時間でコードを書いてレビューすることはできません！
私は開発者の恐怖を理解していますが、ユーザーとコミュニケーションをとるとき、ほとんどのユーザーが完璧なアーキテクチャを必要としないことを理解しています。 彼らは完璧なコードを見ることはありません。 彼らは彼らの問題の解決策を得た場合、バグに耐える準備ができています（もちろん、最初の段階で）。
デスクで働く
そして今、それでもユーザーが必要としない機能を洗い流しました。
まあ、これに少し時間を費やし、それを手放すのは残念ではありません。 しかし、開発者が魂を込めたら？ 夜寝ないで、「緑色を売る」と完璧なボタンを描きましたか？ すべてのシナリオを考慮して処理しましたか？ テストで簡単にカバーできる柔軟なアーキテクチャを作成しましたか？ 彼は記事を書き、同僚全員に最新のテクノロジーをいかにクールに活用したかを伝えました。
そして、私はすべてのプログラマーが嫌いだと言います。「この機能をやり直す必要があります。」 そして、それはすべてのマネージャーが嫌いなことを聞いたときに起こります。 何もやり直しません。」
したがって、開発者と製品マネージャーの間で最も頻繁に発生する競合が始まります。 そして誰もが彼が正しいと思います。 結局のところ、マネージャーとしての私の仕事はできるだけ多くの仮説をテストすることであり、開発者の仕事は彼が誇りに思う美しいコードを書くことです。
開発者から「まあ、また仕事をやりました」というフレーズを聞いたとき、そうではないことを何度も説明しようと試みました。彼の仕事は会社に利益をもたらしました。これは必要ありません。 私たちは一歩前進しました。 開発者は間違いをしないように助けてくれました。
製品思考
私は常にエンドユーザーとコミュニケーションをとっていましたが、彼らの問題を見ました。 しかし、問題は-チームに私の研究について話すことを考えていなかったことです。 しかし、みんなの仕事は、クライアントの痛みを解決するために、できるだけ早く行うことです。
そして、私は考えました：「開発者は、彼が見たり話したことがない人をどのように考えることができますか？」
彼はすべてのユーザーがソフトウェアを可能な限り柔軟に使用できるようにするためにあらゆることを行いました-あらゆる場面で最大の異なる設定を行い、それぞれがその仕事をする多くのボタンを追加しました-あなたはちょうどそれらを適切なタイミングで押す必要があり、25ページの詳細なマニュアルを書きました そして彼は、誰かがこのすべてを研究するのに数時間費やしたくないとさえ考えられませんでした。 彼はその後、複雑なプロジェクトに対処するのが大好きです！
彼は自分の製品を誰がどのような条件下で使用するかを見たことはありません。 彼の世界では、すべてが明白です-クライアントはすべての設定を自分で把握する必要があります。 そして、何らかの理由でクライアントは怒っています。
そして、彼のプログラムはちょうど仕事に来たキャッシャーの女の子によって使われていると開発者に誰も言いませんでした。 彼女の前には20人の列があり、結果を得るために正しい順序で10個のボタンを押す必要があるたびに。 そして今、彼女はすでに無力さから泣いています。列に並んでいる人々が悲鳴を上げ始め、彼女は何度か負けたからです。
私はこれを知っており、機能を改善する必要があることを理解しています-不要な設定を削除し、アクションの数を減らし、以前に提供されなかった新しいスクリプトを追加します。 しかし、開発者は抵抗します。 彼は同じことを何度もやり直したくなく、新しい「クランチ」を挿入します。 「なぜこれが不可能だったのですか？」-彼から聞いた。
複雑な製品では、新しい機能が必要かどうかはわからないからです。 クライアントは、この機能なしでは生きていけないと言うことができますが、古い方法ですべてを行う方が簡単（または安価）なので、この機能を使用しません。
なぜなら、クライアントはインタビューで複雑なユースケースについて教えてくれなかったからです（または、それを引き出すことができませんでした）。
彼らは分析をハングアップするのを忘れたからです。
マネージャーも間違っている可能性があるからです。
したがって、私はチームでコミュニケーションを確立しようとします。 したがって、私はすべてのチームメンバーに、主に製品とクライアントがそれをどのように使用するかについて考えるように指導するよう努めています。
あなたは私に責任の移動を非難することができますが、私は、ほとんどの人と同様に、認知の歪みを抱えており、私の目がぼやけています。 私はこの問題の解決策について考えすぎていたので、明白な解決策が見えないかもしれません。 推論の連鎖で何かを見逃すことがあります。 私はそれを技術的に実現不可能または非常に難しいと考えるので、単に良いアイデアを捨てることができますが、2時間の仕事があることがわかります。
そして、非常に多くの場合、正しい質問をし、見直し、非標準的なソリューションを提供する人が必要です。
そして、なぜ開発者が私になぜ誰のために機能を提供するのかと尋ねることはめったにないのだろうかと常に疑問に思います。 クライアントの立場に身を置いてみませんか？ なぜ彼らはいつも技術的な負債について私に言わないのに、製品タスクの代わりに静かにリファクタリングをするのですか？
それと同じくらい頻繁に、クライアントが製品をどのように使用するかをチームと常に共有するとは限らないと考えています。 開発者に、今は本格的な機能ではなく、MVPのみを「挽いている」ことを伝え忘れています。 私は彼らの機能がどのような問題を解決するのかを説明しません。ただチームに質問が寄せられることを期待して、タスクをバックログに放り込みます。
夢が叶う
私はいまだにいくつかの機能を処理するタスクや機能を切り捨てる要求を恥じています。 開発者が未完成のタスクを指すと、まだ気分を害します。 そして、チームがタスクに対するソリューションを提供し、私と議論し、ツールの使用方法について質問するたびに、私は幸せです。
チームの全員が製品とその使用方法について考えれば、顧客の問題を一緒に解決し、多くのお金を稼ぐことができます（どのビジネスはこれを望んでいませんか？）そして人々の生活を少し良くすることができます。 各チームが同じことをし、他の誰かの問題を解決することにそのエネルギーを費やすならば、私たちはこれまで本にしか存在しないファンタジーの世界に生きるでしょう。
そして、仮説をテストし続け、何かを速く締めるように頼み、チームにタスクを「売り」、ユーザーからのフィードバックを渡すことを学びます。 そして、彼らが完璧なコードを書くのを止めることで私を憎むのをやめることを期待しています。
PS：記事の著者Stratanovichは 、これまで読み取り専用でしたが、本当に公開したかったのです。