タグ

マネジメントとシステム構築に関するkoemuのブックマーク (2)

  • ウノウラボ Unoh Labs: ベンチャー流Webサービスの作り方(開発チーム編)

    尾藤正人(a.k.a BTO)です 前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。 僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。 二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。 ・最終決断は一人で 何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始め

    koemu
    koemu 2007/07/29
    片手間でサービスの開発を行うのは想像以上に厳しいです。>いよいよ資金調達も自分で考えはじめんといかんかもしれん…
  • デスマーチの構造: プロジェクトは始まる前に失敗している Vol.2

    デスマーチの構造: プロジェクトは始まる前に失敗している Vol.2:ITアーキテクトを探して (15)(1/2 ページ) デスマーチの構造:プロジェクトは始まる前に失敗している Vol.1では「デスマーチ」が知らず知らずの間に始まってしまうという恐ろしい事実を明らかにした。今回は実践的な解決策を提示する。 キープレイヤーを把握して政治的対応を この失敗しやすい「デスマーチプロジェクト」をうまく管理運営していくためのポイントはいくつかありますが、ここではプロジェクトマネージャの立場から2つの点に注目します。まず、何より必要なのは、抜け目のない政治的な対応です。特に、日人の方は苦手なところだと思いますが、実はコンピュータ業界の米国人も苦手としているところです。 政治的な観点で重要なポイントは、誰がキープレイヤーなのかを把握することです。その人物がプロジェクトを続行するかどうかの判断を下すこ

    デスマーチの構造: プロジェクトは始まる前に失敗している Vol.2
    koemu
    koemu 2007/03/02
    システムができると立場を失う人がいる・トレードオフは簡単には結論を出さない
  • 1