「同僚の雑な仕事に対応するには」記事へのコメント

原因がわかっているなら

[Namany (19002)]

原因を取り除けばいい。

彼が忙しいんなら彼の負担を減らすべきだ。
少なくともバグリポートや機能リクエストが無視されることはなくなるだろう。
それでも改善しないのであれば、そのときは正面から話し合う必要がある。

負担を減らしても仕事の質が上がらないということはあると思う。
雑な仕事で生じている問題はあなた自身の時間を削られることであるから、
別にリファクタリングを専門に引き受ける人材を用意すればいい。

#といっても人は用意できないことも往々にしてあるので、上司に相談じゃないかな？

Re:

[Anonymous Coward]

ですね、そこまでわかってるなら適切なスケジューリングができないマネージャーに対応するには、とでもすべき。
もしかすると予算配分ができない役員に対応するには、とかキャパを考えないで受注する営業にryとか派生する可能性もあるけど。

Re:

[Anonymous Coward]

綺麗なコード・綺麗なドキュメントを前提としたスケジューリングが正しいとは限りませんからねぇ。
例えば、ドキュメントを犠牲にしてでも、より早くリリースしてシェアを取ることを重視しているのかもしれません。

Re:原因がわかっているなら

[Anonymous Coward]

「正しい」の意味により違ってきます。

小さなiPhoneアプリ等ではコードを見れば一目瞭然なので奇麗さが大事だとは思いません。コードが会社のメインの資産になるようなものであれば話が別ですが、その場合でもシェア獲得して早期利益を目指し廃れる前に事業や会社を清算する/売り抜けるのは戦略の一つでしょう。開発者だと短期的に事業を成功させ、開発停滞する前にその成果をもとに条件の良い所に転職するという方法はありです。

綺麗なコードやドキュメントは後々の機能拡張や保守が目的なので長期視点だとまずいでしょう。運が良ければ腐ったコードとドキュメントを元に開発を続けることができるかもしれないですが博打みたいなものです。アジャイルどうのこうのは大規模開発だとまともにできる人が少ないので期待しない方がいいでしょう。

「奇麗」の意味も人によって変わってきます。

人によってはコードと１対１レベルの仕様書があって初めて奇麗なドキュメントがあると思うかもしれませんが、他の人にとってその仕様書は意味のないゴミにしか見えないでしょう。