タグ

managementに関するtuxedokatzeのブックマーク (5)

  • 意思決定できる人の手順の型 - Konifar's ZATSU

    意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

    意思決定できる人の手順の型 - Konifar's ZATSU
  • VPoE READMEを書いて3ヶ月経った振り返り - Konifar's WIP

    2022年1月からKyashで VP of Engineering(以下、VPoE)という役割で開発組織全体を見ています。VPoEになった背景はまた別途書くとして、この3ヶ月は反省も学びも多かったので振り返りを書いておきます。 自分がVPoEになった時、VPoE README というドキュメントを社内に共有しました。同じ内容をKyashの採用GitHubリポジトリで公開しています。 github.com 今回はこれを自分で読み返して引用する形で振り返ってみます。先に注意をしておくと、体系だった話やどこでも応用が利くような話というよりは、完全に自分個人の振り返りの内容になっています。 README書いてよかった READMEを書く目的を以下のように書いていました。 VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。その一

    VPoE READMEを書いて3ヶ月経った振り返り - Konifar's WIP
  • 差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです - スタディサプリ Product Team Blog

    こんにちは。 今回は差し込みの多いプロダクト開発におけるスケジュール精度の上げ方として、バーンアップチャートの利用をおすすめしたいと思います。 どんな人に読んでほしいか Product GrowthやEnhancementに携わっているけど、やることが多くて思ったように進捗が管理できない人 ↑のようなProduct Manager(PdM)やProject Manager(PjM)とのコミュニケーションが多いけど、期待に対してうまく動いてくれないことをもどかしく思ってる方 TL;DR 3ヶ月や6ヶ月程度でタイムボックスを切りましょう タイムボックスの中でやりたいことを全部リストアップして見積もりをしましょう 終わったタスクのcloseと新規タスクのリストアップを繰り返すと、自然と「やりたいことが全部できるのかどうか」が見える化します バーンアップチャートとは 下記のようなものです。 図中の

    差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです - スタディサプリ Product Team Blog
  • 接触確認アプリ「出来は良くなかった」 デジタル相苦言:朝日新聞デジタル

    ","naka5":"<!-- BFF501 PC記事下(中⑤企画)パーツ=1541 -->","naka6":"<!-- BFF486 PC記事下(中⑥デジ編)パーツ=8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下(中⑥デジ編)パーツ=8826 -->","adcreative72":"<!-- BFF920 広告枠)ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag PC誘導枠5行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">\n <div class=\"

    接触確認アプリ「出来は良くなかった」 デジタル相苦言:朝日新聞デジタル
  • エンジニアリングマネージャーでいるのがつらくなったときは - めるノート

    そういうときがよくあります。 マネジメントを仕事にしたのは今の会社が初めてだけど、きっとこれから先も会社に所属している限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 ...時が経つのは早いもので、コードレビューを受けるのがつらかったわたしも、気がついたらチームリーダーになっていました。 今では、当時自分自身が書いた記事を読んで、レビュアーとして考える日々を送っています。 煽りタイトルで申し訳ないのですが、マネジメントを始めてまだ1ヶ月しか経っていません。 けれど、なんとなく、 コードを書く時間が減ってしまったことに対する不安 自分は何も生産していないのではないか 今後のキャリアどうしよう? 職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安 Slackから目が離せない あそこで話している人たち、何を話しているの

    エンジニアリングマネージャーでいるのがつらくなったときは - めるノート
  • 1