プロダクトマネージャーの3分類
デバッグ の過程をまとめる。ほぼ自分用。 PyTorch でも tensoarboard を使ってたくさんログをとる。ログをとればおかしいところはみつかる。 ログすべきもの observation を tensorboard で visualize する。 次の最善手が分かっている observation を手動で作る。policy network が出力する action values を tensorboard に出力する。その action value が最善手に converge するか見守る loss benchmark agent との対戦結果。win rate ではなくて win/draw/lost 数をプロットする。 1 episode の長さをプロットする。self play では徐々に長くなることが想定される self play でなければ average reward
10Xの価値観を表す三冊
会社を創業以来、いわゆる組織の「ビジョン・ミッション・バリュー」のようなステートメントを考えたり、話す機会を何度か持ったのだが、あまりピンとくる言語化ができていない。というか、現時点でこれらを明確に言語化してしまうことで、「言語化できていないが重要な成分」を取りこぼすような気がしてならない。時期尚早だと感じている。 よくワークするステートメントは、「今のメンバーの共通項」を抽出したものだ。会社は良くも悪くも人によって創られ・彩られる。ステートメントだけ独り歩きした大層なものを準備することは本意ではない。 上記の意図から、会社のリクルートページ（2018/8 現在）には「僕らにとって大事だと認識している共通項」を等身大の言葉で掲載している。決して明確なステートメントではないが、いま大事にしていることの共通項は十分伝わる内容だと思っている。
プロダクトマネージャーの仕事(翻訳)
この記事は2013年7月にMediumへ投稿されたGraylockのパートナーであるJoshによる「A Product Manager’s Job」の翻訳記事だ。翻訳記事はこちら。 Performance reviews, evaluations, or appraisals are awful, and we need more of them. it's time to recognize the need for Product teams to evaluate themselves based on the performance reviews of their products.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
