タグ

ブックマーク / happyman.hatenablog.jp (3)

  • 議事録を書くときに意識すべきこと - Be Happyman!!

    開発現場であってもそうでなくても議事録を書く機会は多いのですが、意外に役にたつ議事録を書くのは難しいものです。ということで、以下自著『プロジェクトを成功させる現場リーダーの技術』より議事録の書き方をまるっと引用。キーワードは「目的・課題・アクション!」です。 会議は避けられない 一口に会議といっても、あらかじめ計画されている定例的なものから、突発的に発生する小さなプロジェクト内ミーティングにいたるまで色々ですが、プロジェクトがさまざまな人との協調作業であり、プロジェクトの生み出す価値がたくさんの利害関係者の合意によって成り立つ以上、会議は必要かつ重要な活動です。実際、大規模プロジェクトでは、プロジェクトの計画段階でコミュニケーション計画として会議体が定義されます。世の中無駄な会議が多すぎると嘆かれながらも、実際問題として、プロジェクトは会議によって進んでいるというのも事実です。 現場リーダ

    議事録を書くときに意識すべきこと - Be Happyman!!
    iga_k
    iga_k 2011/02/25
    本の内容が大サービス蔵出しされてる!
  • 手戻りを防ぐには - Be Happyman!!

    「変化ヲ抱擁」できないこともある。 テストが完璧に終わったと思ってた後の変更は実に痛い。要件や仕様の変更は仕方ないとして、こちらの勘違い、ヒアリング漏れや想定が甘かった場合には、対応しないわけにはいかないからだ。 手戻りを100%防ぐ方法はないが、なるべく手戻りを防ぐようなヒアリングやレビューのテクニックというかやり方の肝はある。 目に見えるたたき台が必要 良く仕様がわかってないうちは、いろいろ細かい質問点はあるだろうけど、まずは全体感を掴むためにたたき台となるものが必要。それはモックアップだったり、UIスケッチだったりする。当たり前の話をしているようだけど、土台となるものがないと話が細かくなりすぎて、脳みそ置いてけぼり状態になることがある。細かいQAを繰り返す前にしっかり土台を作っておくこと。 事前に細かく考えておくこと 同時に、内部の振る舞いについてはできるだけ細かく考えておく、特に状

    手戻りを防ぐには - Be Happyman!!
    iga_k
    iga_k 2007/04/30
  • Re:現場にいないマネージャはメンバーをどうやって評価すべきか - Be Happyman!!

    先日のエントリに関して、メンバーから貴重なコメントをもらっていろいろと考えた。せっかくなので、内容をやや一般化して公開させてもらおう。 前回の、「ブログ等を通じた情報発信を通じて評価しよう」という趣旨に対して、以下の反応があった。 できれば現場は現場だけを考えていたい。つまり、日常的に自分から情報を発するのことはさけたい。極端な話、火をふいているプロジェクトメンバーにはそれはできない。 内気で、自分をアピールできない人もいるはず。 はい。ぼくもかつてそうだったし、今でも忙しいときはブログを書けなくなる。情報発信には元気が必要。そしてそれを他人が強制することはできない。情報発信による評価は、あくまで評価の一部であって、評価制度ではない。あえて言えば、「評価して欲しいという欲求」に繋がるものだ。 「制度としての評価」と、「欲求としての評価」は当然ながら違う。制度としての評価には公平性と経済性が

    Re:現場にいないマネージャはメンバーをどうやって評価すべきか - Be Happyman!!
    iga_k
    iga_k 2007/01/26
  • 1