プロジェクト火消しをやっている40代情シス女子、問題の本質を掘り下げる
システム開発の火消しをしています
あまり細かいことは書けませんが、プロジェクトの「火消し」を行っております。
しんどいぞーーー！
火消しのプロセスは、意思決定と、決めたことの道筋をつけること
火消しに必要なことの一つは、意思決定であります。
しかしまあ、メンバーの人たちの問題として、何が問題なのかというのがわかっていないわけです。
ガツンとやってもいいことない。
わかっていたらこんな状況にはならないのです(´;ω;｀)
あとは「切るべきものを切る」ということですね。これ、割と大事なのであります。
こういうのって気を付けないと長期化しますので、プロジェクトが止まってしまいます…！
要求を要件に落とし込める人がいないぞ問題
次にここですね。いや、上流工程って難しいんですよ！
最近よい本がたくさん出ていますが、そこを読んでも「ぽかーん」となっちゃう人が意外に多いのである。
ちなみにこれは良書です。超良書。
なんというか、みなさん「こういう風に言われてます！」っていうんですけれど、それそのものが矛盾していたり、整理されていないもので、製造の人がつくれないんですわ。
勘弁してほしいぞ。
まあもともとの理由は、マネージャーやリーダーの人が何人も立て続けに離脱し、最終的には責任者も責任を問われて組織を去ったという状況があるんですけれど、こんなの、どうやっても失敗するやんけ…。
こんな状態で持ってこられても困るんですよ。どーすんのこれ
まあぼやいていても仕方がありませんので、整理を始めております。
要求を仕様化するプロセス
まあ、プロセス自体はそんなに難しくはないのですが、実際にやるのはかなり大変です。
まず、ユーザがちゃんと要求を出せないです(´;ω;｀)
出せても、それが効率的かどうかは別問題でして、業務そのものを理解している人が情シス側にいないとまーうまくいきません。
これには「ヒト」の問題もあって、心を開いてくれないと、要件に関するやり取り難しいんすよ。
同じことを何度も聞いたりしますからねえ。。。
適切に議論させて、ケースごとに掘り下げていく
もう一つ大事なのは「要求の掘り下げ」ですね。これがまあ、ユーザ側からすると「大体は話したからあとは考えて！」ってなりがち。
とはいえ、関係者が離脱して、ドキュメントもろくに残っていないという状況を踏まえると、頭を下げて議論しなおすしかないわけで。
「いや、あなたのせいじゃないんだけどさー」ってなった。
素直に謝ると意外に優しかったりする
ちなみに炎上中のプロジェクトだと「もう話したじゃん！何回話をさせるんだよ！」というパターンもあるけれどね。こういうプロジェクトって何も残ってないのよ(´;ω;｀)
強く生きていこうと思います
まあ、あまり頑張りすぎるとつぶれますからね。離脱してしまった先輩たちのようになってはいけませんので、ふてぶてしくいこうかなと。
あとは、当然ながら、実務者が増えていかなければ作れないわけなので、人材育成が急務であると。
昔みたいに「見て覚えろ」の時代でもないですからねえ。。。
おしまい。
この記事が気に入ったらサポートをしてみませんか？