技術者はどのようにして製品設計の議論に参加できるか：停滞した水を活性化する

多くの場合、プログラマーとプロダクト マネージャーは、プロジェクトに関してまったく異なる認識を持っています。ちょうど、2 人の盲人が象に触れたとき、1 人は牛に触れたいと思い、もう 1 人はパンに触れたいと願うのと同じです。明らかに、どちらも十分に合理的ではありません。

CTO クラブのメンバーであり、上海 Zhuyi Software Technology Co., Ltd. のゼネラルマネージャー兼チーフアーキテクトである Wang Zhaofa 氏。

したがって、プロジェクト管理では、反復と増分を導入する必要があります。反復により、ソフトウェアは特定の機能を継続的に改善することができ、増分によりすべての機能を段階的に提供できるようになります。これら 2 つを併用することで、継続的に調整して実際のニーズにアプローチし、リスクを早期に明らかにして回避することができます。プロジェクトコミュニケーションにはよくある誤解が 3 つあります。

神話1: 技術者は常に製品マネージャーを無視する

一部の伝統的な企業では、技術担当者が権限を持つことが多く、プロダクト マネージャーは新入社員または昇進した幹部であることが多いです。プロダクト マネージャーと技術バックボーンはどちらも自分のキャリア プランとビジョンに左右され、会社全体またはプロジェクト全体の長期計画を立てることができません。会社の意思決定者は技術バックボーンとプロダクト マネージャーの間で孤立しており、プロジェクト全体のニーズと目標が崩れることがよくあります。

この現象は、多くの場合、製品はすでに実装されているものの、最終的には技術スタッフにとって「サーバーはデプロイメントをサポートしていない」という状況になり、結局何も行われない、または、製品マネージャーがようやく要件を完成させて実装できるようになったものの、会議でのプレゼンテーション後に技術バックボーンが「営業部門はすでにこの技術を試しており、現在のクライアントはそれをサポートしていません。営業スタッフにソフトウェアの使用方法をトレーニングするには少なくとも 3 か月かかります」と述べ、要件全体が崩壊するという状況に陥ります。

誤解2: 技術者はプロダクトマネージャーのニーズを過度に解釈する

需要を過度に解釈することは、実際には需要を無視することです。

よくある現象として、プロジェクトサイクルが到来した時にプロジェクト全体の進捗状況を確認したが、進捗の半分にも達していないということがあります。会議中に集まった意見は、「プロダクトマネージャーはUIインターフェースが非常に重要だと言っていましたよね？インターフェースは8セット設計しましたが、コアソフトウェアの作業はまだ始まっていません」「この製品は携帯電話、PC、タブレットの3つのメディアを計画しており、それぞれ3つのプラットフォームでテストしましたが、ソフトウェアコードはまだ始まっていません」などです。

誤解3: 技術者は需要に無関心である

技術者が要求に無関心であるという現象は、多くの場合、次のような形で現れます。モバイル プロジェクトに取り組んでほしいのですが、PC クライアントはまだ開発中です。コードを書いてほしいのですが、前のプロジェクトのトレーニングをまだ行っています。

上記の 3 つの誤解、つまり需要と開発の非対称性については、責任、目標、パフォーマンスが鍵となります。保守的なチームに突然新しいプロジェクトを実装するように指示され、実装が達成されなければ罰せられると言われたり、実装が成功した場合はソフトウェアの保守に古い標準が使用されなくなると言われたりした場合、プロジェクト チーム全体の抵抗がどれほど強くなることは容易に想像できます。

コミュニケーションエラーを解決し、楽しいコミュニケーションの雰囲気を作り、優れた作品を実現する方法があります。私は長年Web開発とチームマネジメントに携わってきましたが、ここでは4つの経験を共有したいと思います。

経験1: 1つのことに集中する - 技術者に複雑な作業を依頼したり、過度な要求をしたりしない

人々がよく犯す間違いは、他人に対して要求が高すぎることです。もちろん、掃除婦が優れたコードを書いて、オフィスとキッチンの両方の仕事をこなせるようになることを期待していますが、このような完璧さの追求は、結局何も達成されないことに終わることがよくあります。

したがって、チームを管理するときは、チームに次のように伝えます。実装をあまり多くする必要はなく、1 つのことに集中し、仕事が終わったら幸せに家に帰ればいいのです。翌朝実装するのを待っている要件の増分リストがあります。プログラマーに「要件収集」をさせたり、アーティストに「ついでに CSS を書いてください」などの要件をさせないでください。

このアプローチは保守的に思えるかもしれませんが、効果的かつ安全です。全てのメンバーに多才であることを求めるのは不可能です。従業員が何でもできるなら、なぜ他人のために働くのでしょうか? 彼らはずっと前に自分自身の上司になっているはずです。

経験2: 結果がどうであれ、まずは私のためにやってくれれば、私は責任を取る

プロジェクト マネージャーや製品マネージャーが最初にすべきことは、責任を取ることです。マネージャーとして、チームに植え付けるべき考え方は、「私の要求通りに物事を進めれば、私はすべての責任を取る」というものです。この方法でのみ、メンバーに責任を転嫁するのではなく、前進と後退を敢行するチームを構築することができます。

責任を取るための前提条件は、勇気や決意だけではなく、知恵も必要です。多くの場合、マネージャーが見ることができるレベルは、他のメンバーが見ることができるレベルとは異なります。 iPhone の開発時には、もともと PC 開発に従事していた Macintosh チームのメンバーには理解できないような、画面、センサー、モバイル インターネットなどの技術に投資が行われたと考えられます。しかし、これらの技術は後に製品にうまく統合されました。

私たちのプロジェクト管理には、「舞台裏で作業を進め、その後に点と点をつなぐ」能力も必要です。例えば、UI、ハードウェア、ソフトウェア、要件など複数の側面で前向きに並行して開発を行うようにメンバーを配置し、これらの技術的な「乾物」を後からうまく統合することができます。チームメンバーがばらばらになっても、プロジェクト全体に影響が出ることはありません。

体験3：同じ服をシェアして一緒に働く

平等よりも大切なことは何でしょうか? 仕事に行き、仕事を終えて、一緒にファーストフードを食べ、チームメンバーと一緒に解決策を見つけることは、一枚の紙や高圧的な態度よりもはるかに効果的です。すべてのコミュニケーションの問題がリモート電話会議、QQ、または電子メールで解決できるとは思わないでください。対面でのコミュニケーションは常に最も重要なコミュニケーション チャネルです。

レッスン4: 話す必要はありませんが、参加できるツールがあります

要求に相違があり、実装に弱点がある場合は、会議を開いて解決すればよいと言う人もいます。 「プログラマー」は、言語表現が苦手であったり、言語コミュニケーションに無関心であったりすることが多い（実際、コミュニケーションができないわけではなく、会議では沈黙したり、会議後によく愚痴を言ったり、SNS で異常にアクティブであったりする）。その理由は単純だ。「コードを書くだけでも疲れるのだから、なぜこんなにコミュニケーションを取らなければならないのか」「私はマネージャーでもないのに、なぜコミュニケーションに参加する必要があるのか​​」「私はプログラミング コードでしかお金を稼げないのに、コミュニケーションに参加しても誰もお金を払ってくれない」。

このような現象に対して、管理者はそれを許可し、十分な敬意を払う必要があります。私たちがすべきことは、愚かなメンバーを許可することですが、参加するための他のツールを用意します。これには、オンライン アンケート、月次レポートと週次レポート、チーム開発、ログ記録、レポート収集、さらには誕生日パーティーなどが含まれており、従業員が同じ立場で十分にコミュニケーションをとることができるため、コミュニケーション ギャップを埋めることができます。

原題: 技術者が製品設計の議論に参加するには: 停滞した水を活性化する

キーワード: