タグ

マネジメントに関するn314のブックマーク (14)

  • バーンダウンチャートで子どもの夏休みの宿題を「マネジメント」した話 | Backlogブログ

    Backlog開発チームの藤田です。皆さんは子どもの頃、夏休みの宿題にどんなふうに取り組んでいたでしょうか? 夏休みの初めに一気に終わらせてしまう 毎日こつこつ進める 夏休みの終わり近くになって必死でやる 終わらせない などいろんなタイプがありますね。 私は「初めに一気に終わらせる」タイプでした。毎日こつこつ進めるとかは無理と自分でわかっていたので、先にやってしまって安心したかったのだと思います。「終わらせない」を選択できるほど肝が据わってもいませんでした。 記事は、普段私たちが業務で使っているプロジェクト管理の手法を夏休みの宿題に応用したお話です。小学2年生になった娘と一緒に「夏休みの宿題完遂」を目的に、バーンダウンチャートなどを活用して、プロジェクトをどのように進めたのかお届けします。 夏休みの宿題をマネジメントする事の発端 うちの子にかぎって 私には小学校6年生と2年生の娘がいます

    バーンダウンチャートで子どもの夏休みの宿題を「マネジメント」した話 | Backlogブログ
  • 今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ

    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に

    今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
    n314
    n314 2017/06/20
    確かに。後日回答どころか素人がブログに適当に書いた回答をそのまま伝えることすらあるので超危険だ。
  • ハードな案件のやわらかいプロジェクト管理 - クックパッド開発者ブログ

    研究開発部 兼 クックパッド料理教室の伊尾木です。 暖かくなったり、寒くなったりと気温差が激しいですが、皆さんお体は大丈夫でしょうか。 ところで、最近クックパッド料理教室で、ビジネスモデル変更に伴うリニューアルプロジェクトを実施しました。 (ビジネスモデル変更に伴う全面リニューアル) 私はPMと開発リーダーを担当したのですが、そこで実施した「やわらかいプロジェクト管理」についてご紹介したいと思います。 炎上しそうな予感がいっぱい! ビジネスモデル変更に伴うリニューアルって聞いただけで炎上の予感で胸が膨らみますね。 ビジネスモデルの変更だけでも大きな話なのに、システムの全面刷新まで同時に実施したので、プロジェクトとして不確定要素が多く、管理が難しいものになっていました。 20名弱(エンジニアが8名、他には営業チーム、ユーザサポートチームなどがありました)で8ヶ月程度のプロジェクトでした。一般

    ハードな案件のやわらかいプロジェクト管理 - クックパッド開発者ブログ
  • “エンジニア35才定年説に挑戦する” 開発チームのマネジメント

    Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! のLTで話させていただいた、エンジニアチームのマネジメントについて取り組んでいることを紹介します。

    “エンジニア35才定年説に挑戦する” 開発チームのマネジメント
  • 開発工数と期間(納期)と人数の関係について

    プロジェクトの工数算出というものに対して非常に疑問に思うことがある。 工数とは、各機能を算出してそれらを足していき、そこにある程度のスパイス(保険)を足して算出する感じだろう。 ここに、スパイスというよくわからないものがあるが、このスパイスが経験でズバッと3倍とか、1.5倍とか… ここまでいい加減でないにしても、それぞれの機能に複雑度・影響度を加味した係数をかけて、足していき・・・・・ って、これで実際に工数を出してみても、当にその考え方あってるの?と疑問に思う。 そもそも、 そのプロジェクトはいつまでに完了(納品)しなければいけないのか、とか? 何人投入するのか(できるのか?) が、関係するんじゃないんかなー。 それらは、工数を出してからというかもしれないが。 だったら、導き出せる工数というのは場合の数だけ複数あるのではないだろうか? そんな状況を示すのは、こういう会話では

  • あなたのチームの「いい人」は機能していますか?

    心理的安全性と、Veinの紹介 Psychological safety and introduction of VeinTokoroten Nakayama

    あなたのチームの「いい人」は機能していますか?
  • ダレずに開発を走り切る為の習慣

    重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ

    ダレずに開発を走り切る為の習慣
    n314
    n314 2015/12/30
    “だるさ見積り” なるほど
  • エンジニアからみた良いプロダクトマネージャとは? - サンフランシスコではたらくソフトウェアエンジニア - higepon blog

    エンジニアからみた良いプロダクトマネージャ(以下PM)とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト(製品)マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか?と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分

    エンジニアからみた良いプロダクトマネージャとは? - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
    n314
    n314 2015/07/25
    ここに費用対効果とか時間単価とか利益率とかが合わさるとカオスになりそう。
  • 糞システムにしないため、私ができること『はじめよう! 要件定義』

    「なぜ糞システムができあがるか?」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則(Garbage In, Garbage Out)に従う。 では、どうすればよいか? 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○%ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ/新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具(システム)を“

    糞システムにしないため、私ができること『はじめよう! 要件定義』
  • つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog;

    1分間マネジャーの時間管理 パンローリング株式会社Amazon 「1分間マネジャーの時間管理」を読んだ。非常に面白く、勉強になることが多かった。 このは、マネジャーが時間に追われている状況をどう解決するかについて教えてくれる。このにおいてプロジェクトにおける「次の対応」はサルと表現され、マネジャーが時間を作るためにはこのサルの管理をうまくしなければならないというような話で、時間に追われている状況の改善方法について説明している。書き方自体も時間に追われたマネジャーを主人公として物語風に進んでいくので、非常に読みやすく面白かった。 上に書いた通りの話なので、マネジャーになってなぜか忙しくなったと思う人は是非読んでみると良さそう。確かにそれで忙しくなってるわーみたいなことがいろいろ書かれているので参考になると思う。 このの中でメインとなるポイントは オンケン流サル管理の心得 三つの時間をや

    つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog;
  • ゲーム開発 プロジェクトマネジメント講座

    ゲーム開発 プロジェクトマネジメント講座 2011年10月8日 株式会社スクウェア・エニックス CTO 橋 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか? 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ(コンテンツの範囲)の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース(人員・環境)の問題 • ビジネスの問題 4©SQUARE-EN

  • @IT:明日からできるプロジェクト管理(1)

    デスマーチを止める進ちょく管理の現実解:GanttProjectの導入で進ちょくをコントロールする:明日からできるプロジェクト管理(1)(1/4 ページ) 開発プロジェクトは、何もしなければどんどん混乱していく。計画は破綻し、成果物は四散し、開発要員の心理はズタズタになる。混乱を収拾するのは容易ではない。開発プロジェクトの立ち上げ段階から秩序を導入し、整理整頓されたその状況をカットオーバーまで維持すること。もちろん、それは口でいうほど簡単なことではないのだが、まったく無理なことでもない。連載では、プロジェクトに秩序をもたらすさまざまな手法を、開発プロジェクトの段階を追って解説していく。そして、手法の説明だけではなく、具体的なツールを使って「どうすれば効率的な管理が可能なのか」という現実的な提案も行うつもりである。ここで使用するツールはすべてオープンソースのプロダクトである。効果的な方法を

    @IT:明日からできるプロジェクト管理(1)
  • かつてネトゲで数十人を率いた妻の「マネジメント論」 - chocontaの日記

    から言われたことをいくつかツイッター(URLはこちら)で紹介したのですが、 予想に反してかなりの反響がありました。 そんな「語録」を一度まとめてみました。 2010/06/03 07:44 かつてネトゲで数十人を率いていたという「相手が欲していることは何で、どうやったらモチベーションを高く持ってくれるかを必死に考え抜くの。そうしたら勝手にみんなが動いてくれる。それがマネジメントだよ。やってないから帰りが遅いんじゃないの?」…代わりに会社に行ってもらえませんか? 2010/06/04 07:46 (再掲)近所の豪邸の前で「ここの家主と僕との違いは何なんだあ!」と嘆いていたら、が「今まで背負って来たリスクの差じゃない?例えば受験勉強を頑張ると、落ちたら努力が無駄になるというリスクを背負うんだよね。遊んでいればリスクもないけど合格しない。そういうこと。」 2010/06/08 23:46

    かつてネトゲで数十人を率いた妻の「マネジメント論」 - chocontaの日記
  • 1