タグ

マネジメントに関するp260-2001fpのブックマーク (6)

  • プロジェクトの運営で大切なこと。納得感とコミットメント

    photo credit: orcmid 誠 Biz.ID:新人マネジャー田所晋一の場合:やっかいな部下との評価面談、成功のカギは「納得を引き出す」という記事より。 「上司の詳しい説明があれば、部下にとっては次の期のヒントになる。つまり、上司が期待する水準というのが説明によって理解できれば、次はそこを意識しようと思えるということだ。逆にこの説明がなければ、どうがんばっても上司の好き嫌いで評価が決まるのだと思われてしまう。この差が大きいんだ」 「部下を納得させるためだけじゃない。評価の材料を集めることは、部下の足りない能力をどう伸ばすかという気づきにもつながる。その意味では、評価に手間暇をかけることが、自分のマネジメント力を向上していくことになるんだ」 過去に部下の評価面談をしていた際、全ての部下の仕事振りを普段から公平に見て、納得感を持ってもらえるような評価ができていたかというと…正直言っ

  • 『マンネリ化』

    令和からの働き方について 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 最近の僕は少々疲れている。 しかし、仕事なのでそうは言ってられない。 そんな中 「傲慢SEさん、うちの会社全体のマネジメントって出来る?」 と言うお話をいただいた。 ・・・え!? それって外部の人間である僕がやっても良いの? ってか、それって一般的にはコンサルタント(*1)って言われない?? マネージメントをコンサルタントするというか・・・。 結局この件は直ぐには出来ないので保留することになった。「俺を差し置いて外部の人間がなんで?」という風に他部署の人に恨まれそうだから誰かを立てて後ろから支えたいのが音だった。(*2) さて、こんな相談を外部の僕が聞くくらいである。この会社のマネージメントレベルが低いのは想像できるだろう。そんな中で僕は奮闘

    『マンネリ化』
    p260-2001fp
    p260-2001fp 2009/11/04
    『やりたい仕事をメンバーにやらせると言う事は、マンネリ化してしまい楽しいはずの仕事が普通になり普通の仕事がつまらない仕事になってしまうのだ』目から鱗。よく覚えておこう。
  • マネジメントのスピードが開発のスピードに直結する - プログラマの思索

    倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト(工数)の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS

    マネジメントのスピードが開発のスピードに直結する - プログラマの思索
    p260-2001fp
    p260-2001fp 2009/11/02
    http://kuranuki.sonicgarden.jp/2009/10/post-9.html に関連して。『デザインレビューが開発のボトルネック』『要求を洗い出す作業と、要件を仕様化する作業は別の能力』
  • 優秀なメンバのモチベーションを下げる3つの方法

    photo credit: Mukumbura プロジェクトの中に飛びぬけて優秀なメンバがいると扱いに困りませんか? 設計方針からプロジェクト運営、各種基準の制定など、様々な分野へ口を挟んできて、うるさくてたまりません。 そんな悩みを抱えるプロマネの皆様へ優秀なメンバのモチベーションを下げ、平均的メンバとして平準化する3つの方法を紹介したいと思います。 1. 作業計画を徹底して曖昧にする 優秀なメンバほど自分のタスクを効率よく片付けるための段取りを考えたり、作業の最適化をしたがります。 簡単に最適化させぬよう、作業分担やマイルストーン、全体のタスク量などは徹底して曖昧な状態に保ちましょう。 この不確実な世の中、なんでも計画通り行くわけがないという厳しい現実を思い知らせたいものです。 2. 抜け駆けを許さない 優秀なだけに他メンバと比べて生産性が高く、同じボリュームのタスクをアサインしても

    p260-2001fp
    p260-2001fp 2009/10/27
    プロジェクト管理のアンチパターン。どこか自分達にも当てはまるものがありませんか・・・?要注意ですよ。
  • ソフトウェア開発の諸問題はソフトウェアで解決する - プログラマの思索

    課題と今後の目標 * ソースと要件の結びつけはできる * でも、テストケースとソース、 テストケースと要件の結びつけが できていない * テストケースのバージョン管理って どうやればいいんだろう? * ツールは? * エクセルはもう使いたくない この回答は僕は持っている。 TiDD+TestLinkがその答えになる、と。 下記の記事を偶然見つけた。 プロジェクト管理は専用ツールを使うのが鉄則 - TechTargetジャパン (前略) プロジェクトマネジャーがプロジェクト管理専用のツールを使わない場合、それは彼らがしかるべき教育と訓練を受けていない証拠なのだ。 WordやExcelを使ってプロジェクト管理を行うと、間違いなくビジネス全体に悪影響がある。例えば、リソースの利用可能量やプロジェクトの状態、プロジェクトポートフォリオ全体の健全性が見えにくくなってしまう。プロジェクトの観点から見る

    ソフトウェア開発の諸問題はソフトウェアで解決する - プログラマの思索
    p260-2001fp
    p260-2001fp 2009/09/25
    「プロジェクト管理は専用ツールを使うのが鉄則」ここを特に強調したい。「ソフト開発の問題はソフトで解決」良い言葉。
  • テストリーダへの足がかり、最初の一歩 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    テストリーダへの足がかり、最初の一歩 記事一覧 | gihyo.jp
  • 1