
大きな改修を含む施策を終えて
その後の調整も、ひと段落なので、
忘れないうちに学びまとめ。
今回は10人チームですが
100人、1000人になっても同じことができるように。
でないと、もっとでかいことができないのですから。
こんな改修は屁です。と言いたい。。。。ところですが、大反省の連続ってのが正直でした。。。
ってことで、学び。忘れないように。
冷静に振り返って改善点は3つあったと思います。
1 開発マインドを理解すること~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~開発がどう考えて仕事をするか?どこに一番注意して、そして何を一番大事にしてるか?どんな思考回路で仕事をしているか?この開発マインドを知らないとプロマネをやってはいけない!って位のレベルで超重要だと思います。
例をあげます。
・私「ここのリンク文言は『○○の結婚式場』ではなく『○○周辺の結婚式場』にしてほしい。」・開発「他の文言も変わってしまいます。」 「例外をつくってしまうと、他にも影響します。」 「テスト工数も増えますよ。スケジュールが変わります。」 「例外を作ると今後のサイト運営にも影響します。」 「それでもやりますか?」・私「・・・・汗」
リンク文言変更、という表面上では小さな仕様変更においてもその裏側で開発側がケアしないといけないことは数多くあります。
○どうやってこの仕様変更を実現するのか? ○その変更によるその他ページ、文言への影響範囲は? ○それによる工数増は? ○リリーススケジュールに対する影響は? ○テスト工数は? ○開発ミスが起こるリスク増は? ○今後のサイト運営における開発ミスリスクは?引継ぎしにくくならないか? ・・・・その他にもきっといっぱいあると思います。この辺のマインドを理解しないで、「小さな変更点でしょ」と軽い気持ちでオリエンをしてしまうプロマネは絶対に開発とシンクロできません。
今回の例では、該当するリンク文言は動的なものでした。つまり、API側であらかじめ決まっている文言と連動しており、その他ページのリンク文言、その他hタグ、タイトルタグにも利用していました。そのため、本来プロマネがやらなければいけないことは
↓そのリンク文言を変えることで『影響範囲を洗い出し』 ↓その部分だけを変更するのは、その他すべての範囲を変更するのか、を『判断』し ↓変更工数と、今後の『スケジュール』を照らし合わせ可能かどうか確認し、 ↓変更することでの『リスク』を洗い出し ↓変更することでの『メリット』と『スケジュール』『リスク』を天秤にかけ ↓その上で上記のすべてを踏まえてオリエンをするできれば、オリエンの前に開発リーダーに相談すべきでしょう。
『影響範囲の把握』+『スケジュール把握』+『リスク』+『メリット整理』↓やるかどうかのジャッジ↓相談↓オリエン
というプロセスです。
この辺を知らずして、仕様変更のお願いは、開発からしたら
『KY発言』
としかうつらないでしょうね。
恋愛と一緒。相手の気持ちの理解ですね。
2 最初に「絶対に譲れないこと」を握ること~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~そうは言っても。。所詮はエンジニア経験もないですし、全部を理解することはできません!それでもプロジェクトは進めなければなりません。そこで必要なのはこれ。
最初に「絶対に譲れないこと」を握ること
ここで大事なのは「絶対に」というところ。「全部」ではなく、「絶対」。超重要な最後のこだわりの部分です。
というのも、開発の中で、スケジュールや工数の問題などでどうしても諦めないといけない部分が出てきます。そのときに判断をゆだねられるのがやっぱりプロマネということになります。そんな中、その判断を開発メンバーに納得してもらうため、この「絶対に譲れないこと」を最初に握ることが大事になります。
今回のケースで言うとゴールは「SEO」です。狙っているキーワードで上位表示することです。このゴールにおいて大切なポイントは多くあります。 ○ページ数を増やす ○ページの質をケアすること ○重複コンテンツはつくならない ○ペナルティをケアすること ○タイトルタグを意識すること・・などなど。数多くあります。そして今回のプロジェクトで言えば、狙いは「エリアキーワードの強化」でした。今のSEO状況を踏まえると、
「絶対に譲れないこと」=「サイト内リンク構造」
でした。
ただし、このことは最初に伝えていませんでした。もちろん、開発途中でいろいろSEO的に重要なポイントのひとつとして伝えていましたが、「絶対に譲れないこと」という形で伝えていませんでした。
「絶対に譲れないこと」が伝わっていないと、「このプロマネがいっている仕様変更って、本当に効果があるのか?」「意味があるのか?」と懐疑的になっていきます。
逆に、しっかり譲れないポイントをメンバーに浸透しているとどんなに仕様が変わろうとも、大事なところはぶれない一本筋の通ったプロジェクトとなると思います。
日々発生する妥協ポイントの探りあいのなかで、この「絶対に譲れないこと」を無理しても開発側にお願いする機会が出てきます。
そんな時、最初に伝えていれば 「なぜこの仕様変更が必要なのか?」 ↓ 「どうやったら実現できるか?」という思考になってくれるので、開発とプロマネとがシンクロしやすくなるのです。
最初に言ったじゃん!っていえる婚前契約みたいなものですね。。。。違うか。www
3 キーマンを味方にすること~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~開発が中盤、終盤になればなるほど、
色々なことが発生し、スケジュールもぎりぎりとなり開発と妥協点をさぐるケースが多く発生します。それこそ、精神的にも余裕がなくなるため喧嘩っぽい、かなり強いやいとりも発生します。
開発メンバーは、日々のタスクをこなす上でできるだけ開発ミスがないように、スケジュールを遅らせないように、と守りに入ってしまいます。
そのときにどうしても目的を実現させるために必要な変更点、追加点などお願いすることは難しくなります。
そんな中、この「キーマンを味方に付いていてくれるか」が最後にものをいいます。というか、それにかかっています。
ここで味方というのは、仲良くということではなく絶対にゆずれない事を理解し、その温度感を共有していることです。「このプロマネはなんだかんだ、この部分は絶対に譲らない。絶対に。」そしてそこに、納得してもらっていること。
開発キーマンがそのラインを知っていると、土壇場でどうやったらそれを実現できるか、という目線になり、さらに、チームを説得にまわってくれるからです。
このことは、メンバーが5人のプロジェクトのときだけじゃなく、これが10人、20人、100人規模になっても同じことだと思います。
じゃあ、どうやってキーマンを味方にする?となると、この方法は正攻法は分かりません。ここは気持ちですね。テクニックというより。。。仕事変の姿勢や、日々の顔つき、言動、目線までも大事というか。。。
ただ、今回のプロジェクトを振り返ると、大事に事は・まずは自分が「絶対に譲らないこと」をはっきりさせること・そしてぶれないこと。つまり「絶対に譲らない」こと・できるだけ2人だけで話す機会をもつこと・そのゴールのために絶対に譲れないことを何度も伝える・常に冷静でいること。相手がどんな状況でもプロマネは誰よりも冷静でいること。
「ぶれない男」は女性からもモテます。。wということですね。
以上。長くなりましたが、
コメント(0件)
※ログインすると、コメント投稿や編集ができます