タグ

モチベーションに関するdd0125のブックマーク (4)

  • 成功しやすい職場には「コミュニティ」の強さがある | ライフハッカー・ジャパン

    2年ほど前から、The Energy Project社では、定例の「コミュニティ・ミーティング」を開いています。そこでは、仕事だけでなく個人的なことも含めて、お互いの近況を報告し合います。ミーティングは、ひとりずつ順番に「今日の気分はどうですか?」などの質問に答えることから始まります。ほかのメンバーは黙って耳を傾けます。 私がこのミーティングの大切さに当に気づいたのは、チームに危機が訪れたときでした。昨年10月のある週末、チームメンバーのひとりが、23歳になるご子息を亡くしました。大変残念で悲しい出来事でした。月曜日の朝、チームメンバーは会議室に集まりました。チーム全体を、痛み、悲しみ、困惑、恐れが覆っていました。誰もが命の儚さを知り、愛する者たちを想い、悲しみに打ちひしがれた同僚に、同情を寄せていました。 数週間後、休暇をとっていたその同僚が職場に復帰しました。初日にコミュニティ・ミー

    dd0125
    dd0125 2013/04/12
    職場で自分や他人の気分を伝え合うこともいいことだと思う。職場に感情を持ち込むなってあるかもしれないけど、実際それがモチベーションとかに繋がってるわけなんだから
  • [悪徳商法?支店]: エンジニアのモチベーションを根こそぎ奪う!たった7つの魔法の言葉

    1.テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 2.とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ

  • プロジェクトを円滑に回すには 島国大和のド畜生

    色々バタバタしてる最中に、twitterで呟いたらわりと反響があった言葉。 個人的にプロジェクトを円滑に回す仕組みに重要なのは『直接手を動かさない人は最大1名』『ブレない為に権力は一極集中』『問題点を早期に洗い出す為に、チーム単位+偉い人で高頻度レビュー』辺りだと思っている。正直たったコレだけの事を実行するのが組織の中では難しい。 組織にもっとも不要な人というのは『批評家』なのだが、『批評家のポジションは居心地が良すぎる(作業がない、責任がない、口だけでいい)ので、隙あらば誰もがそこに向かう』そして、組織にとっての重しになる。これがプロジェクトで手を動かさない人が増える理由の一つ。 当に能力のある人でも、ある分野では見当違いな批評家になるというのは良くあることなので(意識無意識にかかわらず)だからこそ、発言に責任を伴うかどうかが重要。 とにかく、プロジェクトを船にたとえると。 1.船頭が

  • "RSA Animate - Drive: The surprising truth about what motivates us" | Universal Subtitles

    dd0125
    dd0125 2012/04/05
    開発者のモチベーションを保つには
  • 1