公司内部邮件看来的，转贴在这里。有问题，有解决方案，希望更多的人能有所体会。
发信人: sighsighsigh (哦~~呵呵呵呵呵), 信区: Java
标 题: 带了几个特弱的程序员怎么办
发信站: 水木社区 (Wed Jan 12 02:04:52 2011), 站内
直想骂人
都是刚毕业或毕业一年的小孩，不知道哪个旮旯的烂校专科毕业的
我下达指示已经详细到存哪个表查哪个表的地步了，数据库字段千锤百炼，绝对简洁易懂
只要他们把存取实现利索，系统就出来了
一个人平均就做3~4个模块吧
结果做了干了三四个月了，还不利索，bug一堆，到处是弱智问题，用户体验差得让人冒火
代码……更加不忍卒看，一点破事能啰嗦一大篇，看得我来气
没办法，就当我是个幼儿园阿姨吧，只要他们实现不了的，有困难的，让他们都来找我，我解决，我一个小时解决的问题他能给我拖一个月
这样下去还不行，领着他们重构吧，我写demo，让他们模仿。我真不明白一些问题我得讲解的细到什么程度，难道真得帮他们把代码都写出来？
现在他们一肚子不情愿，觉得拼sql串挺好用criteria不好，觉得我规定成员变量不许用缩写很长很麻烦，觉得功能都实现了还干嘛折腾他们。我靠！不看看你们这个破进度，要是再加功能在这么个垃圾堆上能盖出什么好房子？
更要命的是还有个不懂开发又写过程序的半吊子领导，主键不能逻辑相关我都跟他解释不清，催我的进度，嫌我前面开发的慢，嫌我一直拖着不加新功能新功能，想把现在的几个小孩开掉又舍不得花大价钱弄几个靠谱的程序员
问题是他嫌来嫌去的，向上级汇报的时候给他争脸的还是我，其他子系统，当初他觉得放心的，现在问题一堆。就这样了，他还执迷不悟，继续跟我拧巴。
现在向上得顶住上级的压力，向下又得顶住懵懂程序员的压力，问题是我不是个强势的人，最不擅长的就是施加压力，现在还得面临着下面造反的威胁，要命
–
发信人: bigzergling (sg552)
没办法，你应该也是属于“被项目经理”的人。
好好的中高级程序员不做，非得带领一批菜鸟，只好受这个罪。
发信人: recoba (雷科巴-漂流)
你自己完整的写一个模块，然后让他们照葫芦画瓢
这样的人的水平也就够这样的，指望独当一面?
我手下1W的coder都得我来按着，一点点的改，sigh
发信人: yishuihanxia (中国版柯南)
公司有时候为了省钱觉得招程序员吗，随便学几年的就行，结果水平参差不起，学习能力
又很差。搞得产品质量一直上不去
我现在才觉得管理者有技术背景是多么的重要。。。。
发信人: kabbesy (步子大了，容易扯着蛋)
来点干货吧
其实lz这种情况在非研发型外企里，比比皆是
想降低人工成本，结果不但进度效果差
还累坏了不擅长管理的高级程序员（大多数都不擅长）
还是参考外科手术团队的模式
越底层越核心的代码，由越好的程序员完成的。以质量为优先
越上层，越不可复用，越看起来需要擦屁股磨时间的事情，就越交给低水平的新手。以总人工时间为优先
对java程序员比如完善注释，完善javadoc，完善单元测试
对页面程序员比如xxxx，xxxxxx，xxxxxxxxx（贵版牛人太多，偶不敢瞎写）
最后再辅以良好的技术氛围
每周学习一块内容，交互的讲出来
以及良好的绩效考评及淘汰机制
新人其实很好成长的（而且也乐于学习）
大多数人就算不智慧，但也决不至于笨
新人水平不行，关键还是老师（环境）的错！
发信人: coquille (烟灰)
一大早看到这个帖子。。。
因为在类似问题上也曾吃足了苦头，我打算详细地回复一下，呵呵。
【 在 sighsighsigh (哦~~呵呵呵呵呵) 的大作中提到: 】
: 直想骂人
: 都是刚毕业或毕业一年的小孩，不知道哪个旮旯的烂校专科毕业的
什么样的项目用什么样的人，考虑到复杂度、难度、项目规模、期限等因素，
该用靠谱人士的项目用了不靠谱的人，整个项目组会变成一口大锅，
甚至把其他各项目组的成员也逼成救火队员。
所以项目经理必须要做“预算”，接项目之前，必须先搞清楚是个什么样的项目，
然后必须有向高层“要人”的权力，根据你的预算，把实实在在的数据摆出来，
就说我要多少多少什么能力层次的人，否则我没法保证期限和品质，
高层不给，那是高层的责任了。
接下来项目经理必须对每个被加入的成员做面试，必要时笔试机试都可以考虑，
而不管该成员是否正式员工，前任领导对其评价有多高，自己的评价才是靠谱的。
经过这几步，你说的那种员工已经进不到你的项目组了。
但是出于培养人才的目的，必然新人也是要带的，这就要考虑项目组人才结构，
多少个老头带多少个新人，老头能力（带人方面）性格如何，新人新到什么程度，
都要斟酌一二。。同时新人的“负产出”因素必须考虑并反映到schedule里。
: 我下达指示已经详细到存哪个表查哪个表的地步了，数据库字段千锤百炼，
: 绝对简洁易懂只要他们把存取实现利索，系统就出来了
这种现象很常见的，对于有基础甚至有默契的人，估计你三句话不到人家就明白了，
但是对于没基础的人，就必须做好“把任务粒度分解到是个人都能干”的地步，
否则对于高层来说，底下人没干好活，不是他们不行，而是你没有分解好任务。
像我刚参加工作的时候，遇到的那位头头，就手把手地带着我画流程图，
甚至有时候连伪代码都给我框出来，这么多年过去了，我对他除了感激还是感激。
话说回来，对于新人最高效的方法还是模仿，要给他们例子，比如说某个已经写好
的模块，至少也得有个demo，在项目初期demo是必须做的，也必须找一个最有共性
的模块组织精兵优先开发，然后再作为模范推广，不知道你们是不是这样做的？
: 一个人平均就做3~4个模块吧
: 结果做了干了三四个月了，还不利索，bug一堆，
这个确实无语了，大多数项目的开发阶段也就一两个月而已。。
: 到处是弱智问题，用户体验差得让人冒火
: 代码……更加不忍卒看，一点破事能啰嗦一大篇，看得我来气
用户体验？没有设计书么？设计书没有画面image和机能说明么？
没有的话，不怪他们，只怪你们input资料不完备。
你总不能指望一个新手去给你“发明创造”吧？
拿那么点可怜薪水的人能给你依葫芦画瓢已经不错了，不能指望更多。
（这句话是当初另一个头头对我带人时的抱怨的批评。。）
: 没办法，就当我是个幼儿园阿姨吧，只要他们实现不了的，
: 有困难的，让他们都来找我，
这个感觉属于方法问题，你说让他们找你，实际会发生的情况往往是
谁都不找你。为什么？国内常见现象，心理素质问题，他们在考虑某个
问题到底要不要找你的时候，心理过程往往是比较复杂而且微妙的。
站在他们的立场考虑，
一方面他们可能希望自己表现得强一点，不要什么问题都问；
另一方面，他们确实很难界定到底哪些该问哪些不该问；
还有可能，是挺体谅你，觉得你已经很忙，不该给你添麻烦等。
其实我觉得这只是一个权力尺度的问题，如果你希望他们能问出
有效的问题来，必须得把他们的权力尺度界定好并使之知悉遵守。
比如说在我这边往往就是两条铁律：
1、式样上问题必须问，然后balabala解释定义什么是式样问题
2、如果一个问题自己调查要两个小时甚至不够，而问一下
可能两分钟就能解决的，那么必须问。
说到底，最好的做法不是等他们来问你，而是你主动问他们，
这需要他们的直接上司能充分把握各member的工作内容，
然后每天根据schedule定出一些关键点或小的里程碑，
在某个合适的时间逐一问之：实现没有？怎样实现的？有什么难处？
不知道你们有没有早会和晚会，有的也可以在会上实施，
早会布置工作内容，晚会检查工作进度，如果时间能把握好的话还是有效的。
另外，新人的代码必须review，而且是行级的review，这也应该是铁律。
: 我解决，我一个小时解决的问题他能给我拖一个月
感觉这个也是你的问题，为什么你会允许他们拖一个月？
“允许”是个权力啊。。如果换成我，我认为自己没有允许他们“拖”的权力。
: 这样下去还不行，领着他们重构吧，我写demo，让他们模仿。
: 我真不明白一些问题我得讲解的细到什么程度，难道真得帮他们把代码都写出来？
必要的时候亲自操刀也是难免的了。
: 现在他们一肚子不情愿，觉得拼sql串挺好用criteria不好，
: 觉得我规定成员变量不许用缩写很长很麻烦，觉得功能都实现了还干嘛折腾他们。
这可能也怪你。做项目就像行军打仗，必须有纪律，
在时间充裕的情况下，你可以说服他们，criteria好，好在哪儿，
拼sql串不好，为什么不好；反之，不做任何解释，
“这是决定，你必须服从，有问题我责任，请务必遵照执行！”
至于变量命名之类，难道没有coding rules么？
没有的话，他们把代码写成什么样子都没啥可说的。。
详细的没有可以，但是关键的十条八条你花半个小时还是可以列出来的，
－－一般情况下这十条八条已经能涵盖80%以上的代码了。。
: 我靠！不看看你们这个破进度，要是再加功能在这么个垃圾堆上能盖出什么好房子？
: 更要命的是还有个不懂开发又写过程序的半吊子领导，主键不能逻辑相关我都跟他
: 解释不清，催我的进度，嫌我前面开发的慢，嫌我一直拖着不加新功能新功能，
这个没啥办法的，该好好解释就好好解释，到底是你解释不清还是他听不明白，
要考虑一下，不管是哪一种情况，都可以考虑调整自己的表达方式或详细程度。
一般而言单纯的口头表达没啥效果，要配合图、表等，载体可以是白板、文档等；
而且往往口说无凭，你不能指望你的上司掌握了和你一样丰富的基层细节，
必要时你要列数据，将真实情况作为支撑你的观点的证据详细地列举出来，
才有说服力，也才能让他更好地把握真实情况，理解你的难处，
否则任你叫破喉咙也没用。
: 想把现在的几个小孩开掉又舍不得花大价钱弄几个靠谱的程序员
什么样的价码用什么样的人，没啥可说的。
但是这个问题最好当机立断，人月神话的说法是往一个已经延误的项目里
追加成员往往会导致更严重的延误。要加人，越早加入越好，越往后风险越大。
再说，新加进来的人，不管宣称靠不靠谱，你不都得有个考察的过程？
: 问题是他嫌来嫌去的，向上级汇报的时候给他争脸的还是我，其他子系统，
: 当初他觉得放心的，现在问题一堆。就这样了，他还执迷不悟，继续跟我拧巴。
争脸不争脸的问题有点扯了，项目做好了谁都有脸，
项目做砸了谁都吃不了兜着走，还有什么脸可言？
你跟你的领导其实就一条船上的，利益和方向都一致才对，拧巴个啥呀。。
还有，事实是怎样就是怎样，该怎么报告就怎么报告，
如果你们向高层的报告没有反映真实情况，或者容易引起理解偏差，
那么你还指望高层能做出正确的决策呀？
:
: 现在向上得顶住上级的压力，向下又得顶住懵懂程序员的压力，
: 问题是我不是个强势的人，最不擅长的就是施加压力，
这个确实很难把握吧。
但是一般而言你需要把项目的真实情况和紧迫性、以及上面做出的决策等
传达到每一个member脑袋里，一般而言不是极品的话不会不做出积极反应的。
如果真遇上了极品，那没啥好说的，如实报告，请高层定夺就行了。
: 现在还得面临着下面造反的威胁，要命
造反。。。开玩笑呢。
发信人: sayinger (言者)
原型总做过吧，不少项目是一个原型接着一个原型，基本是不靠谱的业务人员练手的，这种玩意就别锤子改锥的伺候了，纸糊才是王道…
发信人: coquille (烟灰)
嗯，理解你的意思了。
不过我做过的原型都是技术上的原型，是用来验证评估某种技术是否适用的，
业务上的原型倒是没有做过，只是看过一些，正式立项后都是要推倒重来的，呵呵。
发信人: wew (man in the mirror)
这事我觉得不能怪别人
首先比较一下，一张白纸好带还是一瓶子混水好带？
然后，你至少有2点没做到位：
1、前期没有做好架构、或者说架构没有解释清楚，
画上2、3天或者1周简单的画一些UML图，把接口设计交待清楚
省去后面3、4个月的无用功
2、关键时候没有做code review
初期的时候应该多做一些code review工作，把发现的问题给他们指出来
这样才能起到“带人”的作用，这样能够避免他们犯同样的错误
大概2~3周后就可以减少code review甚至让他们互相review
发信人: recoba (雷科巴-漂流)
it公司大部分开发都很忙啊
再说哪有那么多有耐心的人了
我毕业以后从没见过，都得自己咬牙努力看和理解
到了要带人的时候，也都是非应届的，难道还真的手把手的交?
除非有些核心算法交代不清楚，需要认真的画图和好好交流
其他的基本不会了
发信人: coquille (烟灰)
当你某一天带人带到万念俱灰的时候，耐心突然就出来了，呵呵。
人真是一种奇怪的动物，被逼到无路可退或被彻底打趴下的时候，
性格和世界观都可能产生不可思议的变化。。- -。
话虽如此，对于我们来说实际情况还是比较糟糕的，
就算有那耐心也没那时间和精力去坚持做这样的事情，
所以往往都存在体制超编、生产率低、客户评价低、薪酬低的恶性循环的死结。
发信人: canper (洗衣粉)
看了下，写得很好，m了。
不过大家也不必苛责楼主，除了埋怨用户体验差那条有点过了，其他的我还是挺理解楼主的，毕竟就算码农再怎么民工化也不可能靠软件工程让一帮弱人写出好程序。
至于说就不应该让这几个人进项目组，楼主也无奈啊
发信人: coquille (烟灰)
内牛满面。。
看楼主写的那些心里挺不是滋味，做软件难，原来大家都是这么过来的。
历史上一个产业从诞生到成熟可能要经历几百年的时间，软件产业才几年呀。。
想要降低到像建筑业那样的门槛，等到咱们这一代白发苍苍的时候都未必呢。
看《梦断代码》，那么一大票子的大牛，做一个GTD软件，尚且。。。
