当年的马小三事件的结局是什么? - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>WaterWorld - 未名水世界

当年的马小三事件的结局是什么?

当年的马小三事件的结局是什么?# WaterWorld - 未名水世界

u*r2013-01-17 08:01

1 楼

这样的问题我是loser, 那时候痛苦的经历是自己熬了几个晚上帮着coding.
后来总结的教训是,
1. 对差的programmer, 要想的他尽可能的无能, 这样你对他的工作就不会
太失望了. 划分明确的任务, 尽可能细化,
2. 帮他计划test plan, 多帮他做些code review.
3. 勤快些, 多写些书面的design给他. 不要用口说.
最后, 不要多抱怨手下无能, 说一次两次就够了, 再多说, 只能表示你的无能.
总之, 自己多做些, 尽量发挥programmer积极性. 手头无权无人也只能这样了.

s*r2013-01-17 08:01

2 楼

看了邱XX的故事，想起当年的马小三事件，有人知道结局吗?

T*e2013-01-17 08:01

3 楼

说得很有道理。
以前我们GROUP里有一个人水平巨差。
无论是需求，DESIGN，还是CODING，没有一样能让人放心。
刚来的时候，头让我带一带他。结果都快把我急疯了。
后来组里其他人，包括头，也带过他。
最后居然我算是对他最NICE的。
遇到这种人，我们头那种非常NICE的人也没脾气。
又不能开掉，也没法进别人，只好挑容易的活给他干。
项目DEVELOPMENT后，让他去做QA，
我们其他几个去做re-engineering。
也算是人尽其用吧。
当然还有狠招就是把这种人整走。不过你这种CASE，
他人际关系超好，你还是别玩火了。自己累点吧。

l*g2013-01-17 08:01

4 楼

T*e2013-01-17 08:01

5 楼

从技术的角度讲，你能做的是：
做一个好的architecture design，尽量让个部份之间的影响小些。
从PROCESS的角度讲，建议使用extreme programming，
缩短DEV-QA的周期而增加循环次数。
分工方面，不要让他做那种重要的部份。最好是别人的
进度都不要DEPEND ON HIS。
suppose你会去做一个task dependency diagram.
另外就是管理的小技巧了。好的MANAGER是可以通过工作
培养出手下人的好的工作习惯的。对于普通的PROGRAMMER
来说，这种好的工作习惯往往比纯粹的TECH SKILL更重要。

【在 T**e 的大作中提到】

: 说得很有道理。
: 以前我们GROUP里有一个人水平巨差。
: 无论是需求，DESIGN，还是CODING，没有一样能让人放心。
: 刚来的时候，头让我带一带他。结果都快把我急疯了。
: 后来组里其他人，包括头，也带过他。
: 最后居然我算是对他最NICE的。
: 遇到这种人，我们头那种非常NICE的人也没脾气。
: 又不能开掉，也没法进别人，只好挑容易的活给他干。
: 项目DEVELOPMENT后，让他去做QA，
: 我们其他几个去做re-engineering。

l*e2013-01-17 08:01

6 楼

good suggestions, let me get my cents here.

yes, elaborate on the execution details. nail down every details of
designs, and then clarifiy before doing anything. a good weekly/bi-weekly
status summary and progress report would be helpful.
quality control is just another name for test. if you get everything
on paper, then you can execute and feedback.
yes. get everything designed before hand, thus you, the peer, your
manager, the peer's manager knew what to expect and check for
progress.
somehow