タグ

rfpに関するu-chanのブックマーク (7)

  • 客のせいでブラックなんだけど

    客といっても接客業でクレーム来るとかいう話じゃない。 職はIT系でプログラム書いてる。 会社だけで見るとホワイトな方(web系やベンチャー系とかと比べたら普通なのかも)。 数日前に twitter でホワイトバイトとか言って話題になってた、youtubeききながら作業したり、お菓子べてもいいとかはもちろんだし、 上下関係も特にないし、出社が数分送れたくらいで何も言われないし、隣のビルのスーパーに飲み物買いに行ったっていい。 ここまでだとすごくホワイトに見える。 というか、会社単体で見れば残業と給与以外はホワイトなんだと思う。 ただ残業は忙しいときは毎日、日が変わるまで会社にいることもある。 逆に暇な時は社内ニート状態で好きにツール作ってみたりOSSいじったりもできるほどに極端。 で、一見楽そうに見えるが最近はやる気が全く起きないし仕事行くのにストレスがたまる。 これが題なんだけど、客が

    客のせいでブラックなんだけど
    u-chan
    u-chan 2017/07/07
    100%PMの問題。客じゃなく、キミのプロマネ(または社長)が悪い。
  • 今年こそ、社長が喜ぶシステム開発を:日経ビジネスオンライン

    「なぜこれほど時間と金がかかり、しかも望んだシステムが出来上がらないのか」――。 情報システムの開発に対して不満を持つ社長は多い。社長が抱く典型的な疑問と開発を成功させる勘所について改めて考えてみたい。典型的な疑問として次の5点を取り上げる。 疑問1・なぜ時間がかかる 疑問2・なぜ金がかかる 疑問3・なぜ簡単にできない 疑問4・なぜ要望が伝わらない 疑問5・なぜ自動化できない ここから先の記述は社長とシステム開発に詳しい友人との対話形式にする。疑問5点に言及後、勘所を説明する。 疑問1・なぜ時間がかかる 社長:営業のやり方と組織を変えようと準備を始めたが、「情報システムの手直しが間に合わない」と情報システム部門の責任者が泣きついてきた。製品別でやってきた営業組織を顧客別に組み直す、ついてはどの顧客にどの製品を納めてきたか分かるようにしてくれと頼んだ。たったそれだけなのに「半年はかかる」と言

    今年こそ、社長が喜ぶシステム開発を:日経ビジネスオンライン
    u-chan
    u-chan 2015/01/05
    簡単出ないのは事実だがRFPすら作ってない次元だな。これじゃ。
  • サービス終了のお知らせ - NAVER まとめ

    サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

    サービス終了のお知らせ - NAVER まとめ
  • コンサルタントがよく使うRFPの書き方:12項目で網羅的に作成

    情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。 新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト(月単価150万円以上)であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。 そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用い

    コンサルタントがよく使うRFPの書き方:12項目で網羅的に作成
  • 依頼主のレベルが低いほど開発は失敗しやすい

    開発者の能力以外にも失敗の要因はある システムの開発では、システムを使いたい人が自分では作れないので、作れる専門家に依頼することがほどんどだ。どのようなシステムにするかを依頼主が規定し、それに合わせる形で開発者が設計する。このような形態なので、開発が失敗する原因としては、開発者の能力が低い以外に、依頼主のレベルが低いことを挙げられる。 依頼主が要望を出す形態では、要望をきちんと規定するのが、開発を成功させる大前提だ。要望に含める内容は、何でも良いというわけではない。実際に実現可能なのはもちろん、決められたコストや期間内に作れる必要がある。さらに、企業の戦略との整合性を確保し、情報システムの特徴を生かした形で、戦略を支援できる要望に仕上げることも求められる。依頼主が出す要望は、システム設計の基礎となるため、きちんとした内容でなければならない。 出された要望があいまいだと、システムの仕様が適切

    u-chan
    u-chan 2011/06/10
    深く考えないので、思いつきだけで変更を依頼することもある。このような発言をするのは、論理的に考えるのが苦手な人に多い--我が国最高の大学出身者が複数いてもこんな感じで残念なことがあった。
  • https://www.itc.or.jp/foritc/useful/rfpsla/dlfiles/kaihaturfp_v10e.pdf

    u-chan
    u-chan 2011/06/07
  • プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント

    ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16%。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16%だったという。 日においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」(社団法人 日情報システム・ユーザー協会)に調査によれば、システムの仕上がりに満足と回答したユーザーは10%前後に

    プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント
    u-chan
    u-chan 2011/06/06
    ちょうど、今RFPを書いてるところ。「リスクファクター」の件は目からウロコだった。
  • 1