だめなPMはアホみたいなスケジュールを立てます。
予算もそうですが、スケジュールもお客さんのいいなりです。
私が経験したスケジュールは
まず、残業ありきでスケジュールを立て、かつ工数を削るためテストの工数を極限まで削ります。
もちろん予備日なんて概念はないです。だれかが体調不良で休んだら終わりなスケジュールです。
今回はマネジメントの仕方というよりかは、
若手の方がそのような環境下で働く事についてのデメリットについて説明します。
スケジュールの立て方が残業前提
まず、正しいマネジメントは誰もが知っているように
1日8時間の勤務であれば、朝礼やMTGや他の業務などの時間を取られるため、
仮に1日6時間として見積もって考えます。
その上で、毎日定時で上がる想定のスケジュールがマストになります。
これは残業をしないのではなく、なにかトラブルや仕様変更で急遽対応しなければならないときに残業する可能性があるので
残業前提でスケジュールを組むのはアホの極みです。
その上で、大きな仕様変更、追加または体調不良やテストフェーズでの大きなバグでの解消のため予備日を定めるのが通常です。
これを想定しなければ、徹夜もしくは納期遅れ、低品質の何かしらの負債が発生するのですが、
技術を持たないPMはそのようなスケジュールを立てるので注意が必要です。
このようなPMの下で働く事は、良く言えばストレス耐性が付くとも昔は言われることもありましたが、
ストレスでのメンタルやプライベートの時間を削られるので近年では良く言うこともないです。
完全に悪です。お客様を建前に正当化するため、悪いと思ってやっている犯罪者よりタチがが悪いです。
テストの工数を削る
どんなに優れたプログラムでもバグは少なからずでます。情報工学(統計学)的にある規模のプログラムを実装すればどのくらいバグがでるというのは過去の統計上あります。
プログラマが優れているといってバグがでないのであればテストが不十分であるというのが正しい考え方です。
単体テストではそれなりにバグがなくても、
結合テストなどでは、プログラムのバグだけでなく設計ミスも発覚したりしますし、
UX向上のため改善を行うこともあります。
修正したら改めてテストを実施が必要となります。
そのため、テストには相応の工数が発生します。
しかし、ダメなPMというのは開発の事が分かってないのか、もっとタチが悪いのは分かっている風に装います。
開発の工数はエンジニアと相談したり、過去のプロジェクトから妥当な工数を算出することはあっても、
テストの工数は簡単に削ります。
テストの重要性が分かっていなかったりします。
分かりやすく言えば、「ちゃんと作っていればバグなんてないだろ」みたいな事も言います。
特に営業の人がPMやるとテスト仕様書を起こすこと、どのようなことを書くことを分かっていないこともあります。
未経験者にモンキーテストをやらせて終わりみたいなこともしています。
私のPMは後者で仕様も分かってない新人を見つけてきてモンキーテストをやらせて終わりみたいなことをします。
そんなものでお客さんに納品できないので、隙間時間(残業)でSEがテスト仕様書を書いて、PGがテストすると行ったスケジュールにない工数で品質担保します。
これで業務としては何とか成り立っていましたが、マネジメント面ではPMがスケジュールを管理できていないのでダメです。
結局、残業などで時間を取られていますので、
プライベートの時間も削られますし、一緒に働くメリットがないです。
結論
PMにも、エンジニアからPMになるひとや営業側からPMやる人、その中でも経験豊富なPMやこれから学んでいくPMなどいろいろなPMがいます。
人の意見に耳を貸さず決定事項として苦行を強いるPMとは一緒に働かない方が良いです。
デメリットしかないです。
※すでに炎上していたり、止むを得ない理由があればその限りではないです。
プロジェクトマネジメントは、
1．お客さんの課題を解決するシステムを開発する
2．一緒に働く守りながらより良いものを作る
3．会社の利益に貢献する
この3つを達成することがプロジェクトマネジメントだと思います。
これを意識できないPMであれば、別のプロジェクトにアサインさせてもらうか、
組織的にそのような社風であるなら会社を変えることも検討した方が良いです。
PMの元で長く働く事で得られることは多くないです。(反面教師としては勉強になりますが)
それで辛い思いをするなら、優れたPMの元で働くことをおすすめします。
将来、自身がPMという立場になった時にも役に立つと思います。
コメント