【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
良いProduct Managerと良いTech Lead - ワザノバ | wazanova
http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 A16ZのBen Horowitzが、1996年にNetscapeのDirector of Product Managementだったころに、「Good Product Manager, Bad Product Manager」という名エントリーを残しています。また、これに倣って、FoursquareのJason Liszkaが、「Good Tech Lead, Bad Tech Lead」をまとめています。 自分達のあるべき姿を律するため、かつ、悪い手本にならないようにという自戒の意味をこめて、気に入った
エンジニアのベストプラクティスを非エンジニアチームで活かす - ワザノバ | wazanova
http://www.developingsales.com/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 Jeff SzczepanskiはStack Overflowのマネタイゼーションの責任者。エンジニア転じて、営業の組織の長になった人物。 「営業というのは科学というよりは芸術。コンピュータ相手じゃなくて、人間を相手にしているからね。」 「営業が結果を重視するのは、計測しやすく公平な指標だから。どうなるか予想したりプロセスをうまく管理するのは難しいんだよ。」 という話しに違和感を抱き、「誰かが決めた営業戦略に従って営業マンは盲目的に数字の達成だけを求めてひたすら実行する。」という従来の営業手法は、 自分で手を汚してコーディングしない「アーキテクト」と呼ばれる人が仕様書をまとめ、下々のエンジニ
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
GiltのエンジニアチームのTrustカルチャーと自主的に動くスタイル - ワザノバ | wazanova
GiltのCo-founder & CTOのMichael Bryzekが、同社のエンジニアチームについてインタビューに答えています。 まずは、Ruby -> Java -> Scalaと開発言語が変わっていった経緯について質問を受けて。（Ruby -> Javaは、昼の12時にAmazon並みの大量のトラフィックが集中する同社のフラッシュセールスというビジネスモデルに対応するシステムにするために決めたということだった思います。） RubyからJavaへの転換はやや大変な作業だったが、どうにかできた。Scalaへの移行のきっかけは採用。ものすごくできるエンジニアを2009年 or 2010年はじめあたりに採用できたとき、彼が「自分はScalaを２年やっていて、すごくいいので是非JavaでなくてScalaで。」と言ってきたので、試しにつくらせたのがはじまり。それから、関数型言語としてできるこ
[Think IT] 第2回：なぜTracの導入に失敗するのか？ (1/3)
【バグ管理の作法】Trac徹底活用！ 第2回：なぜTracの導入に失敗するのか？ 著者：masuidrive 公開日：2007/12/13（木） Tracの導入現場の今 「第1回：なぜバグ管理システムを使うのか？」でも紹介したように、TracはSubversionと連携するオープンソースのバグ管理システム（BTS：Bug Tracking System）だ。Ruby on Railsなど多くのオープンソースプロジェクトで利用されており、最近では商業開発でもっとも多く使われているツールの1つになっている。 その一方で、Tracの導入効果が出ていないケースも多々ある。それはなぜだろうか？ Tracの肝は「チケット管理」の運用にある！ Tracにはコンテンツを管理するシステムとしてのWiki、Subversionなどのバージョン管理システムのファイルをWebから閲覧するための「リポジトリブラウザ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
