タグ

見積に関するdaisuke-mのブックマーク (6)

  • 【Web制作などの依頼で「概要」しかわからないのに「とりあえず見積が欲しい」と言われたとき、私はこんなことに気をつけています】|今村だけがよくわかるブログ

    Web制作などの依頼で「概要」しかわからないのに「とりあえず見積が欲しい」と言われたとき、私はこんなことに気をつけています】 どうもです。いきなりですが、私は毎年この年末から来年の3月末あたりまで、段階的に仕事周りが騒がしくなって来る時期だったりします。決算期の都合もあるんでしょうかねぇ。似たような状況の方も多いのではないかと思います。ほんと、最近依頼が多いです。 ところで、仕事の依頼があるって嬉しいことです。 普段あまり交流のなかった方から突然の依頼や、または、人づてで紹介を受けたりなど。紹介を受けるってことは「仕事ちゃんとしてくれるよ」ってのを認めてもらえた証拠だと思っています。気でうれしいです。 と、ここで「依頼」についてちょっと掘り下げたいな~と思いました。題に入る前に、少しだけ前置きにお付き合いくださいますと幸いです。 ・・・「依頼」っていろいろありますね。 「ハマる依頼」

    【Web制作などの依頼で「概要」しかわからないのに「とりあえず見積が欲しい」と言われたとき、私はこんなことに気をつけています】|今村だけがよくわかるブログ
  • そのプロダクトを作るのにどれくらい時間がかかるのですか?

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    そのプロダクトを作るのにどれくらい時間がかかるのですか?
  • プログラムを理解させるには?

    K&RのCで書かれたプログラムを渡された(もう少し正確に言えば、VisualStudioのWizardで作られたものにK&RのCでコーディングしてある(C++ですら無い)ので純粋なCでは無いが果てしなくK&RのCだ)。あと、これを作った人はどうにも「ポインタ」の概念が無いらしく、無駄に多次元配列だったり、配列のアドレス渡しとかが多用されている。 作業指示は、これを流用して、C++/CLIかつ.netFramework3.5使用かつ新規案件に対応せよ、との事。 個人的にはどう見積もっても3人で4ヶ月かかる量なんだが、予算が1人で1ヶ月、と言って来た。理由は「Cからの流用だから」。 参ったな。自分としては、C++/CLIはもはや別言語だと思っているんだが。 どうにも上司と顧客に説明出来ない。説明出来ないのは、自分が理解していないせいだ、と言われればそれまでなのだが、自分の感覚で言うと、高段者が

    プログラムを理解させるには?
    daisuke-m
    daisuke-m 2011/08/07
    奴らは数値化できないものを理解しないのだ。
  • 工数見積もりの見える化

    なぜ工数の見積もりが必要なのか 最近ソフトウエア業界で話題となっている工事進行基準でも、「工事進ちょく度の計算根拠となる工事原価総額が信頼性を持って見積もられなければ工事進行基準を適用することができない」と述べられているように、ソフトウエア開発における工数見積もりの重要性はますます高くなってきている。 「見積もる」という言葉を広辞苑(こうじえん)で引くと、「1. 目で見て大体を測る。目分量ではかる。2. 物事のあらましを考え計算して予測を立てる。つもる。概算する」とある。ソフトウエアの工数見積もりは、2.の意味、つまり、対象となるソフトウエア開発のあらましを頭に描き、投入されるであろう、あるいは、投入すべき工数を予測する、ということになる。 ソフトウエア開発管理の主な観点はQCD(品質、コスト、納期)である。厳密にいえば、工数(人月)はコストとイコールではない。しかし、工数に基づき算出され

  • 技術者の仕事を価値に変えるには、単価を超えるしかない。 - GoTheDistance

    人月単価からの脱却というテーマも毎年のように浮かんでは消えていくのですが、その時その時で思うことは変わっていくので、現時点の考えをちょっと整理してみたいと思います。 どこでも言われていることですが、人月の最も絶望的なところは「成果で価値を図ることが出来ず、も杓子もみんな同じ」になることです。初心者でもプロでも、同じ値段。だって手間賃+αだから、と。おごちゃんがSIerでは、1人が1人分しか稼げないという指摘をされており、僕もこの点においてSIerに絶望しています。個人が飛躍できるエコシステムが、どこにも無い。生産性が高くても給与が上がらないとか、人月見積もりは生産性がどうという主張は「りんごは赤い」という話に聞こえるので、逆に大丈夫かと心配になる。 初期費用が少なく借金することもなく、極論するとたった1人でも圧倒的な成果を出せるレバレッジが効くのがIT(知的成果物)の一番のメリットなのに

    技術者の仕事を価値に変えるには、単価を超えるしかない。 - GoTheDistance
    daisuke-m
    daisuke-m 2010/04/01
    紹介されている報告書も興味深い。長いが、流し読みでも一読の価値あり。
  • 見積りとコミットメントは分けよう

    多くの組織における根的かつ共通の問題は、見積りとコミットメント(約束)が同一のものとして扱われていることである。 ある開発チーム(アジャイルか否かに関係なく)は、顧客が望むもの一式を納品するのに、利用可能なリソースを踏まえて7か月かかるだろうと見積もった。 チームメンバーはこの見積りをマネージャに提出したが、マネージャは見積りを部長に、部長は顧客に知らせてしまった。 そして、いくつかのケースにおいては、その見積りが、チームの「伸縮可能なゴール」を奪ってしまうことになる。 ここでの問題は、チームの7か月という見積りが合っているか間違っているか、ではない。 問題は見積りがコミットメント(約束)に変化してしまったことだ。 「我々は7か月かかると見積もりました」という言葉は「我々は7か月以内に終わらせます」という言葉に(誤って)変換されてしまう。 見積りもコミットメントも重要だけれども、それらは

    見積りとコミットメントは分けよう
  • 1