《不安^2》プログラムマネージャになりますた

漏れも来月からプログラムマネージャになります。
別プロジェクトでプログラマやりつつです。
いっちょやったるでー。

というわけで、プログラムマネージャについて語りましょう。

プログラムマネージャってなんでつか？

Windows3.1にあるだろう。

ファイルマネージャを忘れんなよ。

>>3
Windows2000にもあるで。
progman.exeを実行してみぃ。

マネージャ。
女マネージャ。
かわいい女マネージャ。
かわいいEカップの女マネージャ。
かわいいEカップのエロい女マネージャ。

なるほど。

>>1 いいね。

>>5
ほんとだ、知らなかった……。

>>6
その前半はいったい(w

「かわいいEカップのエロい女マネージャ」を
「プログラムマネージャ」にコンバートするにはどうしたら良いんですか？

うちのﾏﾈｰｼﾞｬ、予算だけは管理するけど、工数管理してくれんのよ。
だもんで、残業代はまっさきに削られる。

ｳﾄｩ

こんな時刻にPMがマ板見るかよ。ﾎﾞｹが。

だから「プログラムマネージャ」だってば。

>>8
名刺にプログラムマネージャって印刷しる。

プログラムマネージャの仕事

・コーディング規約の管理。

>>13
最初だけじゃねーか(w

>>1 がんがれage

…。


ごめん。プロジェクトマネージャーだよね？

おはようございます。>>1です。

>>15
そうです。間違えますた･･･…。プロジェクトマネージャです。
朝からｳﾂなので氏んできます。

こんな香具師がマネージャーになるプロジェクト・・・
きっとデスマ(略
だめぽ銀行からの刺客！？

おつかれさまです。>>1です。

>>17
だめぽ銀行じゃないです。

とりあえず、今日は原価管理シートもらいますた。
ふーん、漏れの原価って月100万いかないんだ(泣
だから、請負金額安いんだ(泣

予算的に、あと1人くらいしか使えないって聞いてたけど、
ほんとにそうみたいですた。

>>18
ジョブ爆発させて、火消しに出てこられんようにな（ｗ
でも単価は結構下落中だぞ？今は。　驚いた。

>>19
うっく。なんとか火消しの手は借りんようにします。
先輩PMによくほうれんそーして。

優秀なプログラマが1人となると、さて、だれがいいかな……。
漏れ、この会社に転職してまだ1年もたってないんで、
だれができるか知らなかったりします。(困

>>20
そうそう、先輩ＰＭによく相談しろよ。　でもアホな先輩に相談すると
人間不信に陥るから気をつけてな（ｗ

やばくなったら周りを巻き込め。　マネージャの仕事は考えることだぞ。
このまま行って大丈夫か、他に見落としは無いか、チームの士気はどうか
気を配ってな。　一番先頭で戦うってことを忘れるなよ。

自分がＰＧも兼ねるなら必要ないけど、技術判断をゆだねるつもりなら
優秀なＰＧが必ず１人いるようになる。　先輩マネージャに相談しろ。

>>21
なるほど、リスク管理についてはぜんぜん頭にありませんですた。
リスクになりそうな項目をまぜ列挙して、それぞれ対応策を練っておくんですよね。
これはさすがに経験豊富な人に相談せんと、手も足も出なさそう……。

プログラマは予算上1人が限度っぽいけど、優秀じゃなかったらどうしたもんかな。
漏れがPGもやるほど余裕がありゃいいんですけどね……。

<font size=5>！</font>

巨乳にしとけって、無能でも諦めがつく。

ｾｰﾀｰに巨乳って漏えるよな。

貧乳にスク水って萌える

>26
スク水ってなに?

スク水＋切り裂きジャック＝萌える

スク水着た切り裂きジャックが萌えるのか？

>>27
「スクール水着」のヲタ界隈での言い方。

おつかれさまです。>>1です。

漏れもこの板にいる以上、ひとりのプログラマなわけですが、
社内にCできる人が少なくて、別プロジェクトにひっぱられそうです。
PMやる気になってるので、ハラハラしとります。
漏れの上司と、ひっぱってこうとした別プロジェクトの営業とが
やりあってます。
ひっぱりだこは嬉しいような気もすこーししますが、けっこう不安……。

この板にいる諸氏、
「おまえは技術あるからPGやれや、あいつは技術ないからPMやらせとく」
ってな調子でPGやらされてたりしませんか。

>>22
そのとおりだ。　リスク管理これ重要。
全ての事態は予測されていなければならない。

バグが出るならどこか？どの程度の影響か？その時の言い訳はどうするか？
ジョブを制御下においているということは、想定外の事態が一切発生しない
状態を言う。

あと、ＰＭは本来優秀なＰＧでなくてはならなくて、コードを見なくても
いくつかＰＧに質問するだけでどこに問題があるのか予測できなければならない。
舵取りがタコではエンジンが優秀でも港につくことは出来ないよ。

>>32
バグが出たときの言い訳なんてうちのマネージャせんぞ。
いつもいつも

　す　ぐ　な　お　し　ま　す

って帰ってくる。直すのはオレラだっちゅーのにな。

プロジェクトリーダーとプロジェクトマネージャーってなにが違うの?

>>33
まだまだってことだろ？（ｗ
俺の場合は、バグが発覚した時には、対策品がもう出来ている。
品質をコントロールするというのは、そういうことでつ。

>バグが発覚した時には、対策品がもう出来ている。

すげーな(藁

>>36
何気にフツーだよ。
精度を上げると、いつバレるかも予測出来るようになる。
いやマジで。

>>35
今度から、うちの仕事引き受けてほすぃ！
まえ、頼んだとこ、作り込みがあまくて、
バグバグバグゥ！！！運用する側になって改めて思う。
「バグほど顧客をむかつかせるものはない！」

>>38
あに言ってんだ！　年度末に向けてどこも一杯の時期だぜ！
断りまくりでごめんなさいだ。

うちのモットーは、バグがないのは「当然」だが、客の
ニーズを引き出せだ。　当初の機能を満足すると、贅沢なもので
こんなこと出来ないか？と言ってくる。
これも予想して、「もちろん既に実装済みです。　シフトキーを
押して起動してください」と答える。　効果テキメン（ｗ
イチコロでつ。（さりげなくいうのがコツ（ｗ）

>>39
馬鹿の見本のような奴だな。

まぁいいじゃねーか（ｗ

>>39
そうなの(^^？
漏れが作るか、開発を先延ばしにするしかないと？
それか、またバグだらけで納品するようなとこに頼むのかよ！
どうしようかな、マジで。何げにすっげえ深刻。

そういうのは裏実装しといて改造ってことで仕事もらうのが正解

>>42
今はどこも忙しいんじゃないの？　大体毎度下期は予算の関係で
仕事量が増えるものだけど。（だからみんな３末に一旦納期がくる）

>>43
改造ではした金貰う場合もあるけど、より大きな信頼というものを
得ることが出来るのよ（ｗ　以降がやりやすい。

まあ、フリーでやってるんならその手を使うだろうな

こんばんは。>>1です。

>>32
リスクすべてってのはまあもうちょっと経験積んでからですね。
先輩PMから過去のリスクアーティクル(って言うのでいいのかな)を
もらっていけば、けっこう網羅できるような気はしますけど。

>>33
まあバグは直さないとﾏｽﾞｰですしね。
「すぐ」ってとこはその場で言えないような気も。

>>35
バグが客先で発覚したときに……ってことは、
パッチリリースみたいのはしないで、ばれないうちは
そのまま使ってもらうってことですか?
って、さすがにそれはないか。


で、来週にも始まりそうな予感。
予定よりはえーよ。いったい漏れの知らないところで
なにが動いてるんだ……。

>>44
漏れが客なら、けっこう微妙に思います。
「先回りすげーな」という気持ちもあるけど、
「なんで仕様どおりにつくんねーんだよ」という気持ち、
「なんで最初からそういう機能を提案しねーんだよ」という気持ちもあります。

>>46
＞パッチリリースみたいのはしないで

つーかですなー、タイトスケジュールをやるようになると判るけど
納期と品質はトレードオフになるのよ。　お客さんは早く欲しいと
言うしね。　だからギリギリのところを正確に見切るとこうなる。
全ての事態を予測することを突き詰めるとね。

>>47
そういうお客さんの心理も折込済みです。
大体ね、信頼無い時に提案したってまず言われた事を
ちゃんとやれてからだろ？と聞いてもらえないよ（ｗ
（もうひとつ。　提案しといて出来ないほうがダメージ大きいだろ？）

やろうと思えばここまで出来るというだけ。
常にやれとかこういうのが良いと言ってるわけじゃないよ。
でも技術のひとつとして、覚えても損はないさ。
がんばってね。

>>47
蛇足なんだけど
＞「なんで最初からそういう機能を提案しねーんだよ」

経験を積めば判ると思うけど、ユーザは成長します。
最初はその機能の有用性が理解できなくても、実際使うことにより
理解できるようになることもあるのです。
そこも読めるようになるといいと思うよ。

>>46
パッチリリースについてだけど、もう少し書いてみる。　参考になればね。

開発したソフトが既に５０台１００台のPCで稼動開始した後に、
開発サイドでバグを見つけたとしても、それが直ちに客先の業務に支障を
与えない限り、即座にパッチをリリースすることはためらう。

何故ならその作業のために、作業が発生しミスが発生し、本業が停止
する可能性があるからだ。

このため、こちらではいつか必ず訪れるその時（つまり、その問題を
解決しないと客の仕事が進まなくなった時点）に備えた対策版を用意
しておくのだ。　この時点では、遣らないリスクは増大し、遣るリスクが減少する。

当然先のお客さんの工程も把握していて、ここでそういう修正時間を取ったとしても
問題がないことを確認済みであることは言うまでもない。

最終的にお客はクレームを付けに来た１日を失うだけに被害を最小限に留めた。
通常の対応であれば、そこから調査デバッグ検証実装現調などで数日が潰れたはずだ。

そちらを選択するかはマネージャの自由だよ。

>>50
>開発したソフトが既に５０台１００台のPCで稼動開始した後に、
>開発サイドでバグを見つけた

そういうことなら納得いきます。
私はまた検収中にバグが見つかったのかと思いますた。

検収中なら、即座にパッチリリースになりますよね?

>>51
検収中にバグが発覚したことなどありません。
検収中というのがどの程度の期間のことを仰っているのかわかりませんが．．．
数日のテストでボロが出るソフトであれば、かなり品質としては悪いでしょう。
（他にもたくさんバグが仕込まれていることと思いますので、そこだけのパッチを
作成するより出直した方が良いと思います。　パッチの嵐を予想しなければなりません）

検収上げるのに長期に渡るテストが必要なデカイ奴の
場合は、準準本番、準本番、本番というスケジュールを
引きます。　当然本番に至る過程においては、一定の
割合で（仕様を含めて）不具合が発生することは、関係者
一同共通認識として持っています。

マネージャとしては、この場合においてもどのあたりで
どの程度の問題が発生しそうかの予想はつけれるようになった方が
良いでしょう。　（技術的にも政治的にも）

（＾＾）