プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
プロダクトマネジメントクライテリア
プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
カジュアル面談 逆質問テンプレ - yuiseki
御社のミッション、ビジョン、バリューを教えて下さい 御社では、日々の業務でどのようなソフトウェアを作っていますか？ 御社の主要な顧客のカテゴリーとマーケットを教えて下さい 御社の事業が、顧客にどのような価値を提供してどのように対価を集めているのか教えて下さい 御社の事業の立ち上げの経緯や意思決定や試行錯誤のプロセスについて、もしご存知でしたら、なるべく詳しく教えてください 御社の事業の今後の展望や計画について教えてください 御社の日々のソフトウェア開発で、ソフトウェアエンジニアとして、夢中になれる魅力や醍醐味を教えて下さい 御社の技術構成や開発プロセス、開発スタイルについて教えて下さい 会社のことは忘れてください あなたが最近、話を聞いたり自分で触って、驚いたり熱中したり感動したりしたソフトウェアがあったら教えて下さい あなたがこれまでの生涯でソフトウェアを開発していて一番愉快で面白くて最
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
2021年が濃すぎて振り返りきれない｜松岡玲音
昨年初めてnoteで一年の振り返り記事を書いてみて、なんか良かったので今年も振り返りを書こう！と思ったのだが、2021年があまりに充実しすぎていて、振り返りきれない😇 ので、2021年に立てたOKRだけでもまずは振り返り、2022年の目標を立てることでお茶を濁していくことにする。 2021年の目標（OKR）の振り返りObjective 1: エンジニアとして継続的に成長し、事業に貢献する2020年は、メルカリUSという新たな環境で結果を出すためにがむしゃらに仕事をした年だった。数字に出るような成果を残すことはできたが、エンジニアとしてちゃんと成長できているのか？という課題感があったため、1つ目のObjectiveに、「継続的な成長」を盛り込んだ。 KR1: バックエンド、データエンジニアリング、情報検索についてそれぞれ課題図書を数冊決め、読み切る - 達成度: 60%「Webを支える技術
プロダクトの成功に必要な 3 つのステージと 20 のタスクについて：現場の動き方をまとめました｜Fritz | Lead Product Manager @ Mercari
こんにちは、フリッツ です。プロダクトマネージャー（以下 PM）になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました（ありがたい）。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、（自分の今までの）現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し～数年目の PM の方のお役に立てる記事になっていれ
2年半のエンジニアリングマネジャー経験から学んだこと - valid,invalid
2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ
「独学でプログラミングを勉強しても実務に通用しにくい理由」を読んだ感想 - 文系プログラマによるTIPSブログ
なんか難しく考え過ぎなんじゃないかな〜、と思ったり、思わなかったり。 こちらの記事を読みました。 主さんの意見としては以下のようですね。 １．独学では妥協をいくらでもできる ２．興味の範囲内のことしかやらない。 ３．自分の実力に合わせた実装しかしなくなる この意見への批判とかではないですが、私の見解では大分異なります。 treeが思う独学が実務に通用しにくい理由 何故通用するのか 皆どうやってプログラムを学んだのか 現場の人間はそんなに有能なのか ではプログラム以外で通用しにくい部分はあるか？ 雑感 treeが思う独学が実務に通用しにくい理由 通用しますよ。余裕で。 これでは話がこれで終わってしまうので、もう少し詳しく書きます。 何故通用するのか 皆どうやってプログラムを学んだのか 日本は他の教育先進国と違ってITはゴミ扱いされ、義務教育の間は実践で使えるレベルのIT教育は行われません。従
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
チームでのプロジェクトを成功させる秘訣34項目「コラボレーション・パターン」
これまでにない全く新しいものを生み出す時や未知なる領域の問題を解決しようとする時、複数の人でのコラボレーションが重要になりますが、「コラボレーション・パターン」はそうやって複数の人間が一つのことに取り組む際に、アイデアを積極的に出し合い、メンバーが互いを高めあいながら、個人では考えられなかったような結果を出すことができるようパタン・ランゲージの考え方に基づいて作られた34項目。対立や分裂で破滅的な結果が起こることもある集団での作業を、ポジティブな結果に昇華させます。 コラボレーション・パターン ― 創造的コラボレーションのためのパターン・ランゲージ http://collabpatterns.sfc.keio.ac.jp/index.html コラボレーション・パターンは全部で34項目あるのですが、パターンは大きくわけて「未来への使命感」「方法のイノベーション」「伝説を作る」の3つのまとま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
