アカウント名:
パスワード:
指示というか勘違いしてる人はいままでたくさんおりまして、「ここんとこちょちょっと変えといてもらえる？5分くらいで出来るよね？」という人(もしくは似たような考えの人)はたくさんいました。たしかに変えるだけならちょちょいで出来ちゃうんですけど、一番大変なのは変更後のテストとかなんですよ。変更はすぐに出来るけど単体テストや連結や総合でのテストを入れると数日かかることを伝えると、私ではダメだと思ったのか他の人に同じように頼みに行き、そして同じ事を言われを繰り返してる人はいました。次の日に「客に頭下げないといけなくなったじゃないか。どうしてくれるんだ？」とか理不尽なことを言われたのは今ではいい思い出です。
具体的な指示をもらえてるんだ「なんでもできるようにしといて」とか「うまくいくようにしといて」とかはないの？※あとから仕様変更するよって意味なんだと思います。
あと、仕様書にかかれてない仕様で「仕様書に書かれてなくてもこんなの一般的な仕様で、入ってないのがおかしいだろ、すぐにいれろ」「え？どのような仕様ですか？」「まだ、決まっていない」とか
> たしかに変えるだけならちょちょいで出来ちゃうんですけど、> 一番大変なのは変更後のテストとかなんですよ。> 変更はすぐに出来るけど単体テストや連結や総合でのテストを> 入れると数日かかることを伝えると、私ではダメだと思ったのか> 他の人に同じように頼みに行き、そして同じ事を言われを繰り返してる人はいました。
良く見る光景ｗ
> 次の日に「客に頭下げないといけなくなったじゃないか。どうしてくれるんだ？」> とか理不尽なことを言われたのは今ではいい思い出です。
これは一概に理不尽とは言えないｗ「一部のテストは時間的に無理なんで、トラブ
>出来ない人がする言い訳のNo1が「簡単に変更できるが、テストが十分に出来ないから無理」だったｗ
よいPGの条件には良いテストを素早く構築できることも含むので妥当な評価だと思いますよ。
＃なんか他にも言いたいことはいっぱいあるけど我慢する。
＞＜ccつきで関係者にメールは必衰ｗ
……出来る限り日本語で書いてください
両者必衰の断りを表す。
＜ccつきで関係者にメールは必衰ｗ
こんなレベルの文章をその都度ccで関係者にばら撒かれたら、それはそれで雇用主としてはたまったもんじゃないだろうな…。と、ふと思った。
なんつーか、そういうレベルの低い仕事の仕方はやめた方が良いと思うよ。どっちも「馬鹿」になるから。何がお互いにハッピーなのかを考えたほうが良い。
まあ、金払いが良い客ならビジネス的には問題ないんだけどさ・・・。
Excel VBAで書かれたツールがあり「これちょっと直してよ」と言われた。
中身見たら明らかにマクロ記録が吐き出したコードそのまんま見て一瞬で気づくバグもちらほら。ソースコメント？ドキュメント？なにそれおいしいの？なシロモノ
「まぁこんなノリでやればいいか」と思ったら「設計書書け、レビューするから」「関数仕様書とフローチャートを作成しろ」「試験項目書を作れ、試験密度とバグ密度をチェックする」「マニュアルを作れ、エクセル（←ここ重要）初心者でも使えるように」「使いづらい、遅い、すぐエラーで止まる。すぐバグ票を作成して原因分析結果を報告しろ（※UI一切変えていません、バグも全て既存）」挙句に「なんでこんなに時間がかかるんだ、しかも品質悪いし、元ツールはすぐにできたぞ！」
いやもう、モチベーション維持するのが大変でした・・・
謝るのが上司の仕事だろ。
まあ、下に当たるのも上司の仕事でそれを適当に流すのは部下の仕事か。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ちょっと書き換えるだけでしょ？ (スコア:4, 興味深い)
指示というか勘違いしてる人はいままでたくさんおりまして、
「ここんとこちょちょっと変えといてもらえる？5分くらいで出来るよね？」
という人(もしくは似たような考えの人)はたくさんいました。
たしかに変えるだけならちょちょいで出来ちゃうんですけど、一番大変なのは変更後のテストとかなんですよ。
変更はすぐに出来るけど単体テストや連結や総合でのテストを入れると数日かかることを伝えると、私ではダメだと思ったのか他の人に同じように頼みに行き、そして同じ事を言われを繰り返してる人はいました。
次の日に「客に頭下げないといけなくなったじゃないか。どうしてくれるんだ？」とか理不尽なことを言われたのは今ではいい思い出です。
Re:ちょっと書き換えるだけでしょ？ (スコア:1, おもしろおかしい)
具体的な指示をもらえてるんだ
「なんでもできるようにしといて」とか
「うまくいくようにしといて」とかはないの？
※あとから仕様変更するよって意味なんだと思います。
あと、仕様書にかかれてない仕様で
「仕様書に書かれてなくてもこんなの一般的な仕様で、入ってないのがおかしいだろ、すぐにいれろ」
「え？どのような仕様ですか？」
「まだ、決まっていない」
とか
Re: (スコア:0)
> たしかに変えるだけならちょちょいで出来ちゃうんですけど、
> 一番大変なのは変更後のテストとかなんですよ。
> 変更はすぐに出来るけど単体テストや連結や総合でのテストを
> 入れると数日かかることを伝えると、私ではダメだと思ったのか
> 他の人に同じように頼みに行き、そして同じ事を言われを繰り返してる人はいました。
良く見る光景ｗ
> 次の日に「客に頭下げないといけなくなったじゃないか。どうしてくれるんだ？」
> とか理不尽なことを言われたのは今ではいい思い出です。
これは一概に理不尽とは言えないｗ
「一部のテストは時間的に無理なんで、トラブ
Re: (スコア:0)
>出来ない人がする言い訳のNo1が「簡単に変更できるが、テストが十分に出来ないから無理」だったｗ
よいPGの条件には良いテストを素早く構築できることも含むので妥当な評価だと思いますよ。
＃なんか他にも言いたいことはいっぱいあるけど我慢する。
Re: (スコア:0)
＞＜ccつきで関係者にメールは必衰ｗ
……出来る限り日本語で書いてください
Re: (スコア:0)
両者必衰の断りを表す。
Re: (スコア:0)
こんなレベルの文章をその都度ccで関係者にばら撒かれたら、それはそれで雇用主としてはたまったもんじゃないだろうな…。と、ふと思った。
Re: (スコア:0)
なんつーか、そういうレベルの低い仕事の仕方はやめた方が良いと思うよ。
どっちも「馬鹿」になるから。
何がお互いにハッピーなのかを考えたほうが良い。
まあ、金払いが良い客ならビジネス的には問題ないんだけどさ・・・。
Re: (スコア:0)
多くの場合、「テストが間に合いませんので障害対応は運用で」⇒「そんなの認めん、今すぐやれやれ」
「現場で診断、修正します」⇒「もう現場は運用中だから、修正したものを休日に載せ替えるだけにして」
軽微なトラブルは営業の顔つなぎ⇒次回発注時には「それはそれ、これはこれ」
いろいろな意味で、経営者ががんばっている（しがらみを作っている）と思う。
Re: (スコア:0)
発注元の内部で人事異動とかがあったら簡単に切られそう。
Re: (スコア:0)
Excel VBAで書かれたツールがあり
「これちょっと直してよ」と言われた。
中身見たら明らかにマクロ記録が吐き出したコードそのまんま
見て一瞬で気づくバグもちらほら。
ソースコメント？ドキュメント？なにそれおいしいの？なシロモノ
「まぁこんなノリでやればいいか」と思ったら
「設計書書け、レビューするから」
「関数仕様書とフローチャートを作成しろ」
「試験項目書を作れ、試験密度とバグ密度をチェックする」
「マニュアルを作れ、エクセル（←ここ重要）初心者でも使えるように」
「使いづらい、遅い、すぐエラーで止まる。すぐバグ票を作成して原因分析結果を報告しろ（※UI一切変えていません、バグも全て既存）」
挙句に
「なんでこんなに時間がかかるんだ、しかも品質悪いし、元ツールはすぐにできたぞ！」
いやもう、モチベーション維持するのが大変でした・・・
プログラムの概念が分からない馬鹿上司の下っ端は大変です (スコア:0)
もう5回もソースコードを書き直してるんですよ…orz
すぐできると思っている（らしい）から腹が立ちます。
とはいえ偉そうに言えるレベルではなく、まだまだ初心者なのでAC
Re: (スコア:0)
謝るのが上司の仕事だろ。
まあ、下に当たるのも上司の仕事で
それを適当に流すのは部下の仕事か。
Re: (スコア:0)
営業職にしたって技術的素養が足りませんね。
…と、彼の上司に伝えるべきでしょう。
同じ組織の中で働くのですから、自分以外も適材適所になる様に、上に対して情報を上げるべきです。
その上で「勉強しなさい」となるか「別の仕事をしたまえ」となるかは、彼の上司の判断。
少なくとも、無理な見積りで会社の信用を落とす人間をそのままにはしない筈です。