つまり、自分で書いた指示に従う方が上手くいくってこと？それとも、自分が関わったからこそ、より良いUXが得られるってこと？

こういう従業員が負の価値を加えるケースは多いよね。

そうかもしれないけど、私は機械工学のグループで、コードを書いたり自動化したりできる唯一のメンバーなんだ。大きな企業で、かなりのITサポートグループがいて、社内でかなりのソフトウェアを作ってるけど、私たちのチームはその多くをひどいと見なしてる。だから、アプリケーションを作り直したり、「ひどいけど代替できない」ソフトウェアを補完するツールを作ったりして、仕事を楽にしてるんだ。私は社内のITの人たちよりソフトウェア開発が得意だとは思ってないけど、実際のエンドユーザーとしての視点があるから、自分たちのニーズにどう応えるかが分かるんだ。自分が使うから、効果的にするモチベーションも高いしね。だから、このタイトルには最初共感したけど、このコメントは予想外だった。でも、正式なソフトウェア開発やプロジェクト管理に詳しくないから、あなたの意見が多くのケースで正しいのは分かるよ。

逆に、このPMはエンジニアに貴重な教訓を与えたね。彼らはおそらく、毎年繰り返す必要があるだろうけど。ユーザートレーニングみたいなもので、セキュリティトレーニングに似てる。

そうそう、元のソフトウェアがなぜこんなにひどい設計だったのかについては全く触れられていないよね。理由を知りたいとも思っていないみたい。あなたの結論の方がもっと正しいと思うけど、PMに責任を押し付けるつもりはないよ。アジャイルやスクラムの儀式では、責任が分散されて、開発者はひどく設計されたチケットを急いで処理させられるから、結果的にひどいソフトウェアが生まれるんだ。誰が予想できた？「現代」の肥大化したソフトウェア組織のシステム的な問題に感じるね。

俺は小さなテックスタートアップを運営していて、年間収益は約200万ドル。時々サポートが人手不足になって、俺もサポートに入ることがあるんだ。そうすると毎回、顧客が不満を持っている問題がたくさん見つかるけど、それがエンジニアリングチームに戻ることはないみたい。たぶんサポートの担当者のせいか、サポートの性質のせいかもしれないけど、彼らは問題をエンジニアに報告するよりも、自分たちで「解決」するのが好きみたい。

それに、エンジニアがちょっと自信過剰で、ユーザーが製品をどう体験すべきかを知っていると思っていることもある。もしユーザーが「製品の持ち方が間違っている」なら、それはユーザーの問題であって、ボタンの押し方を知っている人が作った愚かなデザインの問題じゃない。デスクトップLinux周辺の人たちは、ユーザーの不満を無視することについて本を一冊書けるだろう。頑固なエンジニアがPMやユーザーよりも自分の方が正しいと思っていると、本当に進展が難しい。ただ、そういうエンジニアをユーザーからの攻撃にさらすと、エンジニアにとっては優しいPMが「これは間違っている」と言っているのではなく、フラストレーションを抱えた人たちが彼を生きたまま皮を剥こうとしているように見える！それは恐怖を引き起こすけど、同時に彼の自尊心を粉々にする。誰かがエンジニアの天才作をまるで知恵遅れのハムスターのように非難しているから。俺の視点からすると、PMがバカだと示すことではなく、エンジニアを謙虚にさせることが重要だと思う。彼らの自尊心はまた育つから、このプロセスは繰り返す必要がある。

うん、最初に思ったのは「これがPMが全てに手を出す前のソフトウェアの書き方だな」ってこと。エンジニアを運用作業をしてる人と一緒に座らせると、PMがいなくても全然やっていけるし、みんなもずっと幸せそう。PMは素晴らしい存在になり得るけど、私の経験では、彼らは非常に領域意識が強くて、エンジニアリングや顧客側のことについて驚くほど知らないことが多い。

Hacker Newsのコメントの第一のルールは、エンジニアのせいじゃないってことだね。

そう、OPもスレの中でそれを認めてるよ。 > コメント者: プロダクトマネージャーがいないみたいだね [...] > OP: ハハ、いないよ :) シリーズAを調達するまでプロダクトの人を雇わないことを誇りに思ってるんだ。これのおかげで、すごくスリムに、素早く動けて、顧客が本当に欲しいものを作れた。私たちのプラットフォームは決して簡単ではないけど、初期の頃には製品を3回も作り直したし、3回目の書き直しで今の規模にまで成長したんだ。