プロジェクト管理どうしてますか？

デスマに苦しめられるのがプログラマーの宿命？とはいえ、
一応管理はされているはず。

みなさん、どういう風にプロジェクト管理してますか？

うちの会社は自作の線表作成ツールで、線表ひいて管理してました
ただ、やっぱ更新しないやつがでてくるのと、遅れてるのが認識されても
なんらフォローもないし、納期に変更もないので、なんのために
やってるのかよくわかりませんでしたが･･･

細かい管理はしてないなぁ

>>2
計測可能にすることこそ管理への第一歩なわけだから、とりあえずやらないよりはいいだろう
ウチの、「会議があるから今月の線表を書く」状態よりも随分といい

マ板でやれ

>>5
マ板ってネタスレばっかりだからこういう話題ってむかなくないか？
ｍａvenスレもム板のほうがいいと思うし

Web上で管理するツールがあった希ガス。

GanttProject がんばって欲しい。
保存形式が XML なのがいい。
データの設計は間違っていないと思う。
だが現状のユーザーインターフェースがあまりに拙い。

複数ベンダーが関わる開発だと
他のベンダーの成果物の待ちが多く発生して
引きずられてうちもずるずる遅れちゃう

Apache Maven2
とSubversionで管理なり

それからBIRTでも管理
それから、UML

UML!?

デスマに限っていらん資料作ってたりする。
フローチャートとかｗ

それはさすがに無いだろ・・・

あるよ。




今やってるorz

"人生の"プロジェクト管理どうしてますか？

>>15
勿論、成り行き任せ。
#保険屋は人生設計云々とよく言うが、漏れのように既に適齢期を過ぎて尚親の面倒を見つつも
#自分の家族を持つことを諦めているような場合には全く役に立たないんだよね。

>>15
そういうのはマ板がむいてると思う

進捗を「％」で報告させると
10%→30%→50%→70% この辺りから
伸びが悪くなって 85だとか 92だとか、
なかなか 100%になんねー

>>18
nyの不完全キャッシュ

開発の進捗を％で報告させるとそういう問題が発生する。
つくるべき機能の一覧をリストアップしておき
どれが終わったか、終わってないかを報告させたほうがいい。

それぞれの機能の達成率を％で報告させてもいいけど
PG完とか、単体テスト完とかで管理した方がいい。

うちは「まだまだ」とか「あと少し」「もうちょっと」「あとほんのちょっと」とかそんなんだ。

曖昧すぎ

嘘の5,3,8の法則が発動するから、数字でも>21でも大差ないのが実態。

なんだその嘘の5,3,8の法則って

>>24
実際に数量化しないで、適当に答えるのに使われる数字ってことじゃね。

だから、完成までにやらなきゃいけないことを
リストアップして、やった/やってない を管理しないとだめ。

そして気づくと、「完成までにやらなきゃいけないこと」が倍に膨れ上がっていたり。

モニタに貼り付けた付箋で十分。

>27
安易に仕様変更を受け入れてるからじゃないの？

仕様を満たす為にやらないといけない事
が増えるのはよくあること。
仕様変更すりゃいいんだけど。

>仕様を満たす為にやらないといけない事
>が増えるのはよくあること。

それは最初に気づかなかったか、
途中から仕様が増えたかのどっちかだよな。

>>18
インストールウィザードの進捗バーみたいだな

>>28
それは自分の進捗管理だろ

>>29
仕様変更断るのって苦手なんだけど、どうすりゃいいの？
断ると製品として成り立たないレベルが多いんだけど

>>33
先に立てたスケジュールを仕様作成者に見せて確認を取っておく。
このとき、意味の有る確認を得るためには、仕様の各項目と
対応するように作業日数が見積もってあることが必要。
その後、変更があっても仕様作成者に見えるように管理する。

仕様変更の依頼があったら、対応する作業日数を見積もって
スケジュールにはめてみる。収まったらやればいい。
収まらなかったら、スケジュールを盾にして相談すればいい。

>>34
俺の場合、派遣なんで、客と直接交渉する権限なくて
派遣先の担当者にいってもそういうことやってくれない…

権限無いのなら、責任も無いんだから気にするな。
料金以上のことはやっちゃいけない。

>>36
残業代も含めて給料はもらえるけど、年中デスマなのはしんどい
会社やめれば済む話だけど、残ってるやつもいるし、なるべくなら
改善してやりたいんだけどね

スレ違い気味になってきたので、愚痴はおわりにしときます。
すんません

>>33
>仕様変更断るのって苦手なんだけど、どうすりゃいいの？
簡単な仕様に誘導する。

>>33
「仕様変更」という言葉を使うからいかんのであって
既存の仕様の削除＆新仕様の追加という立派な新規注文なのだ。
新たにスケジュールを見積りなおし、期間を延長させる、
それが不可能なら断るということを堂々と要求してよいのだ。

> 既存の仕様の削除＆新仕様の追加
既存の変更もあるけどな
　例えば新機能を呼び出すために既存の箇所の変更が必要だろう？

新仕様の追加でいいじゃん。

だから「変更」を忘れるんだよな...

結局プロマネの能力しだいってことか？
ツールとかで改善されるもんか？

まともなマネージャは、自分が全知全能ではないと自覚しているから
能力を補うためにツールを活用する。
やばいマネージャは、すべて自分の頭でコントロールできると思い込み
ツールなど使わずに……

どういうツール使ってる？＞ALL

いわゆる表計算ソフト

...ほとんど「表」のための機能しか使ってない

昨日WEB+DB PRESS Vol.32 買ったんだけど、そこに載ってた Trac が面白そう。

ｋｗｓｋ

FYI
【バグ】BTS使ってる？【追跡】
http://pc8.2ch.net/test/read.cgi/tech/1088818269/l50

>>48
Tracのことなら俺が説明するよりも以下のリンクを見たほうが早い。

ttp://discypus.jp/wiki/?%A5%BD%A5%D5%A5%C8%2FBug%20Tracking%2Ftrac

俺の会社は　ＰＪＣ　ってアプリケーション　導入したよ。

MS Project使ってる。
それらしいドキュメントをすぐに出力できるので便利。

失敗するプロジェクトの話はよく聞くけど、
成功するプロジェクトってあるのかな？
あるんだったらどんな管理の仕方をしているんだろう？

成功するプロジェクトの管理パターンみたいなのがあれば
ご教授、願いたいです。

ヒント：成功したプロジェクトは話題にならない

>>53
基本的に成功するのが当たり前だからね。

＠ITにあるような教科書どおりのいい環境があれば
いいんじゃね。
あとは管理する人が優秀なら大丈夫

もしくは管理される側が優秀なら大丈夫

>>56
なかなかそっちのパターンは難しいと思うぞ。
上流から泥水が流れてくるんだし

>>45
おれの所もPJCってツール　導入するんだって。。。

XPlannerはちょうどいいチャチさというか、機能の量だと思う。

http://ex15.2ch.net/test/read.cgi/news4vip/1151416092/
↑
オタとブスの妄想恋愛カキコが満載の白痴snegスレです。
ぜひ記念に書き込みをお願いします！

プロジェクトの成功と失敗って、みなさん何を判定基準にしてます？

うちは、たとえば誰か下請けが全員逃げてプロパーが2･3人病院送りになって、
責任なすり付け合って険悪な中連日徹夜して、ろくにテストせずに客に渡して
バグがぼろぼろ出てきても、とりあえず納品にこぎつけてお金のやり取り
(この辺りよくわからん)したら、なんとなく成功って雰囲気になっちゃうんだけど、
他所はどうなんですかね？

その会社がまだ存続しているのならば
立派な奴隷制度確立の成功例だ。

>>62
普通に一部上場してますが（苦笑

よーし、晒せ。

>>61
そ、それは成功なのか？

ちゃんと利益が出て、プロパーの給料も支払われて
協力会社にもちゃんと契約通りのお金が行ってればいいんじゃねーの

>>61
QCD

>>47
trac面白いね。

この程度で良いよ。
でもガントチャートのプラグインがもうちょっとかっこいいグラフを書いてくれた良いんだけどね。

結局、デスマーチとか言ってもほとんどのデスマーチプロジェクトって
成功プロジェクトなんだよな、扱いとしては。失敗にはカウントされてないもんね。

「もの凄い困難なビッグプロジェクト成し遂げましたなぁ。つか、おれらって結構
凄くね？まあビールでも飲むべ。」とか、そんなノリになっちゃうし。最後には。

で、どんな拙いやり方でも「実績ある」って扱いになって、前回踏襲。
年々、輪をかけてひどくなってくし（笑

>>69
それで、それなりの基本給で残業代が全て出るなら、みんながハッピー

最終的にかかった費用が予算の２倍も３倍かかってたら、
どこかで誰かが怒られるか困ってるかしてるはずなんだけどな。

だからっつって、次からはもっと少ない費用でやりましょうって事に
なっても、管理手法とか開発プロセスとかドキュメント体系とか、
本当の病巣は絶対に手が付けられることないもんね。中国人か
韓国人雇って作業単価抑えようとか、オフショアとか
せいぜいそんなのばっか。

でもとりあえず売り上げを計上しないことにはどうにもならないので
赤字になるといってもとってきやがる＞営業様

ところでスレ本来の話に戻すと、皆さんは進捗管理に何を使ってます？
ツールの前に概念として。
本人にパーセントを申告させる？to doベースで何件できたかを見る？

個人的にはtodoベースが良いと思うけど、1件ごとの重みが異なることを
どう吸収するかに頭悩ませてます。todoに落としにくい案件もあるしね。

>>72
本人の％申告はなにがどう対応するのか判らんから進捗としてはアレだな

パーセンテージ申告は、早々に30%くらいまで立ち上がるくせに80%を過ぎてからいきなり遅くなる罠。

>>72
終わった、終わってないが客観的に判別できるレベルまで todo を分けて、
終わるまでの作業時間（日数）見積りを出してもらう。そんで後で申告してもらう。

todo に落としにくいのは本質的に見積もりが難しい案件ってことで、
企画レベルの人に話通しとけばいいんじゃないかな？

あとで申告してもらうのは「終わったかどうか」だけね。％イラネ。

>>73-74
だよねーｗ

>>75さんが理想かな。
todoベースの管理がんばって見ます。

tp://gazo08.chbox.jp/miso/src/1151164628004.jpg

>>1
プロジェクト管理はApache Maven2 + Eclipseで行っているよ

>>11
UMLで仕様書を書くってことだろう

WBSで作業を分解、TODOにタスクを登録。
TODOの管理用には優先度(1〜5)、難易度(1〜5)、難易度の補足で推定工数(0.50時間単位)、
タスク完了時に実績工数(0.50時間単位)を追加。
TODO管理はTracを使用、推定工数、実績工数、ユースケースの識別ID欄をカスタムフィールドで追加。
ユースケースは今回7個に分類してあり、それをTracのマイルストーンに割り当て。
進捗管理はマイルストーンを見て行っている。

ユースケース図書いてUUCPで工数求めたいところだが、ウチはまだそれをできるほど経験がなく、
ユースケースの粒度がいまいち揃えられない。
なので、せめて完了時レビューに使う資料として推定工数・実績工数、ユースケースの識別IDを
Tracで記録してる。

>>81
それ、分析地獄にならない？

>>82
要は経験の蓄積が必要って事
マネージメントシステムがしっかりしていたらPDCAをある程度まわせばそんなに苦じゃなくなる

>>83
いやそういう意味じゃなくて、その粒度の分析を何度も行わないといけなくなるんじゃないかって話。
最初に一回やって、はい終わりじゃないんでしょ？

>>84
だから、そこは経験無いって本人言ってるじゃん
そのノウハウ溜まればそこら辺は”カイゼン”できるだろ

マネージメントシステムの一番のキモはPDCAを繰り返しての”カイゼン”だよ
カイゼンされないマネージメントシステムなんて糞

>>85
ん？経験無いのは第二段落の話でしょ？
第一段落の内容がきっちり出来てるなら、どういう内容でどういう運用してるのか
すごく興味がある。

自分はまだ管理されるほうの人間だけど参考になるスレですね。
どんな手法でも２，３サイクルまわしてPCDAを実行しなくてはならない
というのに激しく同意。
今の上司には期待できないので、自分が中間管理職になる日に
そなえて勉強したいですｗ

えええ？２，３サイクルで済むなら、どこもマネジメントに頭を悩ませてないはずですよ

PCJ　プロジェクトコラボレーション・・なかなか　使えるね。。
開発元のアースインターて会社　はどう？？