タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

projectに関するshino-sunのブックマーク (6)

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: Wikiでプロジェクトマネジメントする4つの方法

    「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。 Wikiを発展させた開発支援コラボレーションツールMrkrgnao(via:marsのメモ) Wikiを使った「Web向けLotus Notes」Jotspot(via:関心空間ラボ) 社内限定の非公開型ブログイントラブログ さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人の

    わたしが知らないスゴ本は、きっとあなたが読んでいる: Wikiでプロジェクトマネジメントする4つの方法
  • たった2名のメンバーで上流工程を指揮、ベンダとの強力なタッグが成功を後押し

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます センター型集中DB構築/すかいらーく すかいらーくは、全国に約3000店舗を抱える最大手の外チェーンの1つだ。 10万人以上の従業員を対象にするシステムも自ずと巨大になる。 全店舗のネットワークを光回線化する巨大プロジェクトに 当初参加したのは、たったの2名。 情報システム担当リーダーの三瓶隆美氏は、 プロジェクトを成功させるには、少数の精鋭が上流工程を指揮し、 SIベンダとの強力なパートナーシップが不可欠だと言う。 情報システム部門の形態が、ここ数年で急激に様変わりしてきた。メインフレームの全盛期、100名近い情報システム部員を抱える企業は珍しくなかった。だが近年、部門を情報システム子会社として切り出したり、保守・運用業務をSIベン

    たった2名のメンバーで上流工程を指揮、ベンダとの強力なタッグが成功を後押し
  • @IT:初めてのプロジェクトリーダー(4)開発中、リーダーは何をしている?

    1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン(イベント)も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。 納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表(ガントチャート)ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。 どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必

    @IT:初めてのプロジェクトリーダー(4)開発中、リーダーは何をしている?
  • “白けた会議”がプロジェクトを破綻に導く

    「ユーザーとの会議の“段取り”や“仕切り”がまずいためにプロジェクトが破綻するのを,これまで何度も目の当たりにしてきた。メンバー同士の意見が対立して紛糾することもなく,表面的に議事が淡々と進む“白けた会議”になっているときほど,注意が必要だ」――。先月,取材した大手コンピュータ・メーカーのベテラン・コンサルタントからそんな話を聞いた。 このコンサルタントは課題分析や要件定義などの上流工程が専門で,付き合いのあるユーザー企業から相談を受けて,破綻しかけたプロジェクトに途中から“火消し”として乗り込むことがある。相談を受けてまずはオブザーバーとして,ユーザー企業の各現場のキーパーソンが集まる上流工程の会議に出てみると,共通してある特徴が見られるという。「欠席者が少なくないうえに,発言するのは一部のメンバーだけ。しかもそれぞれが自分の考えを言うだけなので,お互いに意見をぶつけ合う議論になっていな

    “白けた会議”がプロジェクトを破綻に導く
  • http://izu.shinzui.org/space/start/2005-06-09/1

  • [はてな] ITエンジニアの幸せはどこにあるか? - higepon blog

    はてなブックマークのホットエントリーに気になるタイトルのエントリーがありました。 「日エンジニアには絶対になりたくない、と心から思った」 izu@San Franciscoというエントリーですが、なんとなく思い当たる節があり妙に納得してしまいました。 そんな私もはてなエンジニアとして入社して2ヶ月ほどが過ぎました。 以前いた会社は大企業で、エンジニアとして幸せになれないと思い転職に踏み切りましたが、これは正解でした。 たった2ヶ月ですが、もう1年以上経ったかのような濃い開発者Lifeを過ごしています。 私の理想とする、いわゆる会社や研究所に所属しているエンジニアの幸せは 尊敬できる技術者に囲まれていること 好きなこと「も」やれる環境であること 新しいものがそこにあること 無駄な会議がないこと 自分にしかできない仕事があること 自分が会社を支えている技術者の一人だと強く実感できること

    [はてな] ITエンジニアの幸せはどこにあるか? - higepon blog
  • 1