どちらも評価は出来ない気がするけど…。「遅い」のレベル次第かな。プロである以上、「期限内に完結させる」というのは最低条件なので、それが満たせているのであれば、多少遅くても後者のほうが評価できるけど、「結果として完成形が出来上がってこない」みたいな話なら、前者のほうがマシかと。ちなみに、前者の場合はマネージャーなりが、開発ルールとしてテストコード必須、とか、環境的にバグを押さえるようなルールを定めることでなんとかなりそうな気がするけど無理？
仕事のできる人間の多くが仕事のスピードを求めるよ。商機は逃すのがヤバイからね。間違いなんか誰にでもあるし仕様変更もあるのだから、毎度毎度完璧に出されるより早い方がより評価は高い。もちろん俺は前者で、俺しかこなせない仕事バンバンもらう。まぁそういうのが理解できん人は毎回完璧で何回もチェックしておっそい人を評価するんでしょうけどね。こういう人たちはルーティーンの仕事をやっているようで社内評価は高いが社外評価は低いようだ。どっちが価値があるかはわからんけど、俺は前者のやつを評価したいね。
Re:3 バグ撒き散らかされるから、それでこっちの仕事が遅くなるんですけどね。。。
Re:2 テストコード必須にして欲しいです。
Re:4 あと何回もチェックしないです。テストコード一回書けば、あとは自動でその後はテスト出来るので。
Re:6 テスター入るのって、開発フェーズ的に結構後の方ですよね。それまでの間、バク撒き散らかされると、それで他の開発者に悪影響及ぶのですよね。あと、テスター入るまでテストコードないってのは結構やばくて、テストしづらいコードが量産されるのがオチです
Re:8 たしかに後ろの方だなー。開発初期中盤の多いバグまでは俺はわからん。。。タスクの設定が大きいのかもしれん。。。
遅くても正確性ですね。それだけ信頼性が高いです。
遅くてもバグがまぁまぁあるというパターンは少なくないと思うが
どっちも出来上がってねえ。しかし、まあどちらかなら後者かな。いい加減なものをどんなに早く上げても評価しない。
Re:11 遅いという表現が適切ではなかったです。テストコード書いたり、リファクタリングを度々行うため、前者よりも相対的に遅いといった意味合いでした。
2時間、今日もバグ撒き散らす人の皺寄せで時間とられた。。。朝の2時間は集中力まだ高い時間の貴重なものなんだから、これで消耗するのは勿体無い。。
バグ撒き散らすのやめてって言ったの？
Re:15 それがその人が開発チームのリーダーなので、どうしたものかと。。。なんて言えば良いやら。
バグ撒き散らすほうが人も修正もかかっちゃうのでは最終的に
Re:18 納期とかの話はアジャイルの自社開発サービスなので気にしないでオッケーです。そもそも、納期があるないの前提は書いてないので。
Re:19 ならば後者だな。前者はただのトラブルメーカーだ。という答えになるので、納期あるなしの前提は大事だと思うよ。
Re:18 このケースだとそもそもギリギリの納期にしたディレクターがカス。いくらクライアントが急げって行っても現実的に間に合わないスケジュールを立てた所から間違ってる。どちらも失格だけど、社内での評価差をつけるのであれば遅いけどバグが少ない奴だろうな。感覚的に遅いよりバグ多い方が印象が悪い
Re:21 激しく同意
Re:16 oh〜御愁傷様です。
昨日は仕様ろくに先読みして詰められないリーダーの皺寄せで深夜遅くまで働くはめに。
ほんとに速いやつはだいたい質も良い。
24 件の回答
どちらも評価は出来ない気がするけど…。
「遅い」のレベル次第かな。プロである以上、「期限内に完結させる」というのは最低条件なので、それが満たせているのであれば、多少遅くても後者のほうが評価できるけど、「結果として完成形が出来上がってこない」みたいな話なら、前者のほうがマシかと。
ちなみに、前者の場合はマネージャーなりが、開発ルールとしてテストコード必須、とか、環境的にバグを押さえるようなルールを定めることでなんとかなりそうな気がするけど無理？
仕事のできる人間の多くが仕事のスピードを求めるよ。
商機は逃すのがヤバイからね。
間違いなんか誰にでもあるし仕様変更もあるのだから、毎度毎度完璧に出されるより早い方がより評価は高い。
もちろん俺は前者で、俺しかこなせない仕事バンバンもらう。
まぁそういうのが理解できん人は毎回完璧で何回もチェックしておっそい人を評価するんでしょうけどね。
こういう人たちはルーティーンの仕事をやっているようで社内評価は高いが社外評価は低いようだ。
どっちが価値があるかはわからんけど、俺は前者のやつを評価したいね。
Re:3
バグ撒き散らかされるから、それでこっちの仕事が遅くなるんですけどね。。。
Re:2
テストコード必須にして欲しいです。
Re:4
あと何回もチェックしないです。テストコード一回書けば、あとは自動でその後はテスト出来るので。
Re:6
テスター入るのって、開発フェーズ的に結構後の方ですよね。それまでの間、バク撒き散らかされると、それで他の開発者に悪影響及ぶのですよね。
あと、テスター入るまでテストコードないってのは結構やばくて、テストしづらいコードが量産されるのがオチです
Re:8
たしかに後ろの方だなー。
開発初期中盤の多いバグまでは俺はわからん。。。
タスクの設定が大きいのかもしれん。。。
遅くても正確性ですね。
それだけ信頼性が高いです。
遅くてもバグがまぁまぁあるというパターンは少なくないと思うが
どっちも出来上がってねえ。しかし、まあどちらかなら後者かな。
いい加減なものをどんなに早く上げても評価しない。
Re:11
遅いという表現が適切ではなかったです。
テストコード書いたり、リファクタリングを度々行うため、前者よりも相対的に遅いといった意味合いでした。
2時間、今日もバグ撒き散らす人の皺寄せで時間とられた。。。朝の2時間は集中力まだ高い時間の貴重なものなんだから、これで消耗するのは勿体無い。。
バグ撒き散らすのやめてって言ったの？
Re:15
それがその人が開発チームのリーダーなので、どうしたものかと。。。なんて言えば良いやら。
バグ撒き散らすほうが人も修正もかかっちゃうのでは最終的に
Re:18
納期とかの話はアジャイルの自社開発サービスなので気にしないでオッケーです。そもそも、納期があるないの前提は書いてないので。
Re:19
ならば後者だな。前者はただのトラブルメーカーだ。という答えになるので、納期あるなしの前提は大事だと思うよ。
Re:18
このケースだとそもそもギリギリの納期にしたディレクターがカス。
いくらクライアントが急げって行っても現実的に間に合わないスケジュールを立てた所から間違ってる。
どちらも失格だけど、社内での評価差をつけるのであれば遅いけどバグが少ない奴だろうな。
感覚的に遅いよりバグ多い方が印象が悪い
Re:21
激しく同意
Re:16
oh〜
御愁傷様です。
昨日は仕様ろくに先読みして詰められないリーダーの皺寄せで深夜遅くまで働くはめに。
ほんとに速いやつはだいたい質も良い。