『システム部の失敗』
華やかに始まったプロジェクトも時の流れとともに衰退し、今となってはあの時の栄光と熱意はどこに？といったチームの惨状を見ることはしばしばあります。 ユーザーに提供するサービスの場合は、そのユーザー離れにより衰退していく様を利用する立場としてよく目にしますが、社内情報システム部門のそれは構築・運用チームは存在しており、その会社のシステム基盤として維持・管理はしていかないといけないんだけど、チームとしての士気は下がりきっていてどうしようもない状況というのはより悲惨な光景かもしれません。 何でそんな状況にいたったんでしょうか？ プロジェクトの始まりは極めて華やかだったりします。 予算が確保され、タスクフォース的にその道のプロが要員計画に組みこれます。 そこには下請けやコンサルタントなども含めて大量の外部リソースが流入してきます。 プロジェクト運営において、外部リソースを使うのはスケジュールであった
『エンジニアの情熱と暴走モード』
若いエンジニアに仕事を頼むと、時にやりすぎなところがあったりして悩むときがあったりします。 それはあらぬ方向に突っ走られるというよりは、頼んだ以上のことを実装したりするといったシーンです。 それって別にいいことなんじゃないの？って思われるときもあるのですが、プロジェクトを管理しているとそこに時間を割くのではなく他に手を回したい、でも作ったものはそれはそれで素敵な機能なんで叱るに叱れないといった状況に悩んだりするわけです。 特に経験の浅いエンジニアは作る楽しさを覚えて間もなかったりもしますから、予想以上に工数かかっているなって確認してみると想像で突っ走ったりしてとんでもないものを作ろうとしていることはしばしばあります。 ちゃんと仕様を伝えていないこちらも悪いところがあるのですが、あまり細かく管理していくのもエンジニア自身の成長の妨げになりますし、自分もそうやって自由に作ることでスキルを磨いて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
