アカウント名:
パスワード:
技術的に失敗することが明らかなんだけど、上司や顧客にそれを言っても理解しない(主に知識が足りないので理解できない)ような時に、警告はしたよっていう証拠を残しておくこと。また、そのままプロジェクトが邁進した結果、結合テストやシステムテストあたりで問題点が発覚した時に、責任を回避したり、最悪、炎上した案件から逃げ出すための方法を用意しておくこと。これに尽きると思う、個人的には。なんかもう慣れてきたけどね。
サイジングとかやってるとたまに起きる。「それじゃ性能足りねーよ」って言ってるのに予算ありきでシステム組んで、いざ本番で負荷かかりすぎてマトモに動かないとか。本来、同時に使うことなんか想定されてない複数のミドルなんかを1つのサーバにインストールした挙げ句、「それぞれの動作環境は足りてるのになんで書いてある処理性能が出ないんだ」って言い出したり。
同じく。
たとえば「ここでこれをしとかないと、あとで手痛いしっぺ返しが来る」とわかりきっていることを、耳を貸さないしわかろうともしないし理解できない上司に説明することとか。
だいたいにおいて、「技術が無くてもマネジメントできる(キリッ)」と言ってるマネージャーにろくな奴はいない。そして日本ではそういう神話がまだ生き残っているため、ろくでもないマネージャーの方が多いという。
マネジメントできないマネージャーなんて、責任とって腹かっさばいて死ねばいいのに。
タイムリーにも日経BPに、身につまされる話が出てますね…
「“できない人”にいくら教えても“できる人”にならない」問題についての対話http://business.nikkeibp.co.jp/article/tech/20131010/254456/ [nikkeibp.co.jp] 1人が「人は育てられない」と言い切り、隣にいたもう1人が「残念だけれどこれまでの経験からしてその通りだと思う」と同意する。2人は異なる職種の方である。もう1人が「そんなことは絶対ない。たとえコンピテンシーであっても後から開発できる」と反論する。 押し問答になったのは筆者が「カン(直観)を後から高められるという意見があります」と言ったからかもしれない。2人は「カンが鋭い人はもともと鋭い」と応じ、もう1人は「カンも能力、したがって開発できる」と言い、話は収束しなかった。
「“できない人”にいくら教えても“できる人”にならない」問題についての対話http://business.nikkeibp.co.jp/article/tech/20131010/254456/ [nikkeibp.co.jp] 1人が「人は育てられない」と言い切り、隣にいたもう1人が「残念だけれどこれまでの経験からしてその通りだと思う」と同意する。2人は異なる職種の方である。もう1人が「そんなことは絶対ない。たとえコンピテンシーであっても後から開発できる」と反論する。
押し問答になったのは筆者が「カン(直観)を後から高められるという意見があります」と言ったからかもしれない。2人は「カンが鋭い人はもともと鋭い」と応じ、もう1人は「カンも能力、したがって開発できる」と言い、話は収束しなかった。
こちらは心が痛くなるような質問のコンボで、もうやめて。。
「できない人」にいくら教えても「できる人」にならないのかhttp://itpro.nikkeibp.co.jp/article/Watcher/20130823/499762/ [nikkeibp.co.jp]こういう言い方をしたらいけないのかもしれないが、結局は生まれつきですよ。できる人に機会を与えれば、自分でできるようになる。できない人にいくら懇切丁寧に教えても、できる人にはならないね 「やり直すのですか」 「要件が定まっていないのに、どうやって開発するのですか」 「進捗管理も大事ですよね」 「なぜ正直に報告しないのですか」 「徹夜か何かをして、遅れを取り戻そうということですね」 「徹夜も増員も駄目だとするとどうするのですか」 「なんとかするとは、何をするのですか」 「お客さんにどう説明するのですか」
「できない人」にいくら教えても「できる人」にならないのかhttp://itpro.nikkeibp.co.jp/article/Watcher/20130823/499762/ [nikkeibp.co.jp]こういう言い方をしたらいけないのかもしれないが、結局は生まれつきですよ。できる人に機会を与えれば、自分でできるようになる。できない人にいくら懇切丁寧に教えても、できる人にはならないね
「やり直すのですか」 「要件が定まっていないのに、どうやって開発するのですか」 「進捗管理も大事ですよね」 「なぜ正直に報告しないのですか」 「徹夜か何かをして、遅れを取り戻そうということですね」 「徹夜も増員も駄目だとするとどうするのですか」 「なんとかするとは、何をするのですか」 「お客さんにどう説明するのですか」
>「できない人」にいくら教えても「できる人」にならないのかこれって、単に「失敗(問題)を認めない人」なんじゃなかろうか。スケジュールが遅れても、見積が超過しても、最初に設計した機能が実現出来なくても、長時間稼働でメンバーが死にかけて(死んで)も、かかった工数分の金が回収できれば「失敗」とは思わないんじゃないかと。金の回収の担当が別だったりすると、自分のやったことが「失敗」という認識のないままずるずる業界にいすわり続けたりして。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
大変、の意味によりますがね (スコア:5, 参考になる)
技術的に失敗することが明らかなんだけど、上司や顧客にそれを言っても理解しない(主に知識が足りないので理解できない)ような時に、警告はしたよっていう証拠を残しておくこと。
また、そのままプロジェクトが邁進した結果、結合テストやシステムテストあたりで問題点が発覚した時に、責任を回避したり、最悪、炎上した案件から逃げ出すための方法を用意しておくこと。
これに尽きると思う、個人的には。
なんかもう慣れてきたけどね。
サイジングとかやってるとたまに起きる。
「それじゃ性能足りねーよ」って言ってるのに予算ありきでシステム組んで、いざ本番で負荷かかりすぎてマトモに動かないとか。
本来、同時に使うことなんか想定されてない複数のミドルなんかを1つのサーバにインストールした挙げ句、「それぞれの動作環境は足りてるのになんで書いてある処理性能が出ないんだ」って言い出したり。
Re: (スコア:1, 参考になる)
同じく。
たとえば「ここでこれをしとかないと、あとで手痛いしっぺ返しが来る」とわかりきっていることを、
耳を貸さないしわかろうともしないし理解できない上司に説明することとか。
だいたいにおいて、「技術が無くてもマネジメントできる(キリッ)」と言ってるマネージャーにろくな奴はいない。
そして日本ではそういう神話がまだ生き残っているため、ろくでもないマネージャーの方が多いという。
マネジメントできないマネージャーなんて、責任とって腹かっさばいて死ねばいいのに。
Re:大変、の意味によりますがね (スコア:1)
タイムリーにも日経BPに、身につまされる話が出てますね…
こちらは心が痛くなるような質問のコンボで、もうやめて。。
Re: (スコア:0)
>「できない人」にいくら教えても「できる人」にならないのか
これって、単に「失敗(問題)を認めない人」なんじゃなかろうか。
スケジュールが遅れても、見積が超過しても、最初に設計した機能が実現出来なくても、長時間稼働でメンバーが死にかけて(死んで)も、
かかった工数分の金が回収できれば「失敗」とは思わないんじゃないかと。
金の回収の担当が別だったりすると、自分のやったことが「失敗」という認識のないままずるずる業界にいすわり続けたりして。