碰到不给力的同事咋办？
我是个码农，刚过试用期。一直和同事A负责系统某个组件的开发和维护。这个组件比较重要，纯C写的，以前写这个组件的人已经离职了。在我入职前，由A接手。
A资历比我老，好像老板也比较器重他。但通过代码和交流，看的出来他没有太多和底层相关的经验，对很多关键的东西了解不够。逻辑不够清晰，代码比较混乱，算法和设计能力都不过关（至少以我的标准看来）。老板不是搞技术出身的，但是是学Info的，宏观的技术知识他是懂的，但为什么委任A负责这个，我不清楚。。
现在是每次A开发点东西，我需要帮他做Code-Review和测试。A自测完的东西，往往一堆漏洞，到了我这里经常还有一堆Bug。而且由于代码混乱不堪，难以理解，看的让人想吐血。。
每次我都是帮他改错，重新整理代码，告诉他下次要注意，之类的。。他也很不好意思，也认可我的工作。但可惜情况没有改观。为了照顾他的面子，每次开例会时，我也只是简单的说，程序有些不稳定，已经修正了之类的套话。。
这次他自测认为稳定的版本，我已经找到了20多个Bug了。而且我相信还不止这些，这让我非常接受不了。
每次我都想把他的代码全部删了，自己重写一遍。。那样可能比改错还快些。。
现在由于是我们两个一起负责，出了问题大家都是有责任的。尤其是程序在客户那里如果出了大的岔子，那压力是非常大的。。我觉得跟A在一起干活，会吃不少哑巴亏。。
我想和老板谈谈，让他知道这个情况。因为在我看来，A的能力有限，不能胜任这个工作，老板在人事上应该选择更合适的人代替他。但我不知道在德国职场如何委婉一些和上司谈这些问题。
如果点名道姓的说A不行，能力不够，似乎老板也不好接受，毕竟是老板委任的A，那么背后总是有原因的。
大家有好的建议么？？
我的想法是
你们俩完成这项工作，已体现了你的能力和实力。
你认为你比他还强，老板可能也知道，你搭档也知道，不要以为你不说别人不知道。（千万不要急于说出）
但老板用人有很多因素。没准你当老板也会这样用人哦！
如你们之间没有厉害，建议你坚持做好你自己的是，你自己写的不要有错哦！
关系搞好比你天天思考这些好处多。
设想若他很给力，你的能力如何体现？你有干什么？
你才过试用期，不也说明你的能力，不要急。
问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改错，重新整理代码”。如果你技术水平高到可以轻松加愉快地做到这些，那做了也无所谓，问题是你看的“想吐血”，那你就别看呗。
你只需要找到Bug，粗略分析一下，无需具体分析错在哪里并帮他改错（这正是你想吐血的原因）。告诉同事，这个测试用例没有得到期望的结果，错误可能出现在某个部分，然后让他自己去分析修改。
同事知道你的水平，如果他搞不定，自然会来找你，这时候你再出手。但是你也没必要玩命儿地去分析，争分夺秒地出活儿。该Pause就Pause，该喝Kaffee喝Kaffee。一天改一个Bug也没关系，反正是同事搞不定才来找你，他自己可能一天也改不好呢。
你可能会问那项目延期怎么办？那就让他延呗，你在这个项目中不是男一号，犯不上操那份心。上司知道出问题的是他的部分即可。如果上司意识到这个问题，任命你为男一号，那你再玩命也值得。
通常情况下，你想轻松加愉快地工作还是快马加鞭，呕心沥血，只取决于你自己，即使你是男一号。通常无论你怎么选，你的工资单没啥变化。 最重要的是你要让你老板知道你做了多少事情 而不是A是否胜任此工作 如果我是你的话，我会先干一阵子再采取办法
Teamarbeit，要么遇到能抱的大腿，要么遇到需要你罩着的小弟，照你现在描述，这哥们的确是能力有限，短期也提不上来，但你也是新来的，公司里老板和其他人对你信任不足，这个时候提出来，容易被人贴上自大和不能teamarbeit的标签
从技术上理性上你现在在吃亏，但找老板说，还得考虑点感情上的因素，不要因小失大。你有能力迟早会发光的，但能力包括技术上和人情上的技巧。
其实你同事挺不错的了，虽然能力有限，但身为老人也虚心接受，没给你干起来。遇上稍微不那么厚道的，还没等你报告你就先被坑了。 不要表示出自己对别人的评判，比如别人的能力和能不能胜任。
只针对自己的工作烦恼在会议上提出来，表达出希望找出更能提高工作效率的解决办法，达到更好完成任务的目的。 aktueller 发表于 2014-8-8 00:50
不要表示出自己对别人的评判，比如别人的能力和能不能胜任。
只针对自己的工作烦恼在会议上提出来，表达出 ...
你知道，有些时候，尤其是技术工作，人的能力够不够，是生产力和效率高不高的直接因素。。当然我也没有能力找到一种方法或者发明一种技术，让能力不够的人能更轻松的完成工作。。
我觉得目前的问题是A的设计能力不够，使得他在处理稍微复杂的工程时不能通过良好的设计将问题简化，模块化。这造成了他的逻辑过于复杂，也更容易犯错误，踩坑。 所以才需要外来移民呀! 顶一下楼上的。
个人看法，有时候确实帮别人排错还不如自己重写一遍。这种情况干脆重写。
你自己把代码都写了，以后这个项目就是你一个人的 ：）
自己先出点成绩，才好跟老板谈具体怎么操作。 最直接的方法不是最有效的，签定他有没有负责一个项目的能力是他的老板的工作范围和权限，有管理能力有经验可以弥补一些技术缺陷，你这么直接一说损人而不利己。
就事论事说改太麻烦工作量太大，试试跟A说你直接重写行不行，如果A不是个小心眼的，以后这个项目都是你写的，这才是干货
这是一个磨合的阶段，你要学会逐渐在技能上全面超过他，并提高自己的软技能比如语言沟通和交流能力。 再过一段时间你的老板才会意识到你可以取代他，到时候就是老板做决定的时候了。 呵呵，你们公司Review的人可以和写代码的人一起改代码，QS不过关啊 tracywyt 发表于 2014-8-8 09:36
呵呵，你们公司Review的人可以和写代码的人一起改代码，QS不过关啊
要改的话都是2个人同时确认改动的内容后，再提交。至于用谁的用户提交到CVS，这个倒无所谓。。 本帖最后由 和路雪 于 2014-8-8 10:06 编辑
adgjl 发表于 2014-8-8 09:30
问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改 ...
无所谓一号二号。一个人开发的内容，另一个人必须审核并且充分理解。
不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。
我自己也要开发，他也必须为我做Review，但他一般找不出来错。
你说的办法我也想过，即只提出Bug，让他自己去解决。这样会导致，几天后他改了一堆东西，我又得重新看一遍。。那时候我已经忘了不少细节了。。这样还不如我一开是直接找到他，分析之后当场改掉来的快。。
另外软件缺陷的修复和发现，在开发阶段成本是最低的。。在交付后出了问题，找出缺陷的成本很高，压力也很大。而且查找缺陷很可能就是我和他两个人一起找，因为你不能当场确定是谁写的内容挂了。。
我还是宁愿在开发阶段把东西做好，不想频繁在客户那里救火。。即使最后不是我的责任，也会给我带来不少烦恼。 上面的好些都说了，让你不要过于自信，急于求成。除此之外，你老板信任的是他 而不是你， 反之，你对你的老板的信任也不如他对你老板的，
真要经受考验的时候，我估计也是他更比你更值得托付，考验并不是光在技术上的。等你真正成为公司的资产，你在发表单干的意见不迟。 R2D2 发表于 2014-8-8 10:41
上面的好些都说了，让你不要过于自信，急于求成。除此之外，你老板信任的是他 而不是你， 反之，你对你的老 ...
我没有想取代他或者怎么样。。只是不想成天干这种无聊的替人改错的事情。我还巴不得他是大牛，带着我玩，让我轻轻松松呢。。 即使是Teamarbeit也有分工吧，也不是2个人出一份代码吧，即使是出一个组件，也有分工吧，照我看，你只要完成你自己的那一份就行了，你也是职业人士吧，拿钱做事，不需要做义工，即使不赚钱也要赚吆喝吧，Vorwurf大可不必，但让老板注意你的努力也是需要的。 楼主的想法可以理解，搞计算机的都明白，我实习的时候的做法就是睁一眼闭一只眼，老IT的经验可能局限在几年以前的技术侧面，新事物立刻接受不太现实。
改动过大时，直接自己重新写，然后跟你说的A同事好好聊聊你为什么这么写。同事之间应该是互相交流，让别人理解你的想法是最重要的。而不是急于去把你的想法摆到更高的层面上去讨论。一切事情都要循序渐进的去操作。 R2D2 发表于 2014-8-8 10:51
即使是Teamarbeit也有分工吧，也不是2个人出一份代码吧，即使是出一个组件，也有分工吧，照我看，你只要完 ...
C程序挂了就整个进程崩溃了。在客户那里挂了，找问题能把你烦死。。你也不能当场确定因为什么原因挂了，即使有日志或者Core文件什么的，也不能百分之百当场定位原因。
总之就是崩溃了大家日子都很难过。。 和路雪 发表于 2014-8-8 10:05
无所谓一号二号。一个人开发的内容，另一个人必须审核并且充分理解。
不然一个人离职了或者休假了出了 ...
你现在做这些的目标是什么？踢走A换一个高手来？踢走A自己上位？
既然这小组是A负责，代码是否能按期完成，是他需要操心的事。你的任务是发现错误，给提示信息让他修改，至于什么时候能修改好，不需要多操心。如果一直出问题，A感觉压力太大，自己会走人的。要么总是出问题，老板自然会想到换人。 和路雪 发表于 2014-8-8 09:05
无所谓一号二号。一个人开发的内容，另一个人必须审核并且充分理解。
不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。
我自己也要开发，他也必须为我做Review，但他一般找不出来错。
你说的办法我也想过，即只提出Bug，让他自己去解决。这样会导致，几天后他改了一堆东西，我又得重新看一遍。。那时候我已经忘了不少细节了。。这样还不如我一开是直接找到他，分析之后当场改掉来的快。。
另外软件缺陷的修复和发现，在开发阶段成本是最低的。。在交付后出了问题，找出缺陷的成本很高，压力也很大。而且查找缺陷很可能就是我和他两个人一起找，因为你不能当场确定是谁写的内容挂了。。
我还是宁愿在开发阶段把东西做好，不想频繁在客户那里救火。。即使最后不是我的责任，也会给我带来不少烦恼。
“一个人开发的内容，另一个人必须审核并且充分理解。不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。”
公司要求的没有错，但这是个目标和原则，不代表能实现。你不能期望随便给你一个人就能充分理解一个程序。如果同事水平不行，那对你来说（而不是对公司）最好的解决方法就是你写80%的程序，他写20%。这样出了问题你能很快找到问题，因为大部分是你写的。
那你怎么和和他提出来你写80%呢？很简单，发现他的错误不帮他分析，让他自己改，可能错误越改越多，没关系，一个小程序他就写了一个星期，自然你写的部分就占80%了！
“软件缺陷的修复和发现，在开发阶段成本是最低的”，这根本就不是轮到你考虑得事儿。如果你写了80%的程序，出了错误找Bug仍然“压力也很大”，那就是水平问题了，神仙也没办法。
这个结果是对你和对公司最理想的结果（客户那边程序出错少，你不用“频繁在客户那里救火”，挑自己的Bug应当压力小），至于同事，自然你休假他的压力大，你只能做到尽量讲解，让他能理解多少是多少。
这还是处于能者多劳的阶段，再高一个层次，一个真正的高手其实应该寻求的目标是能者并不多劳，你并不比别人做的多，但是你做的是他们做不了的，那才是轻松加愉快的阶段。 我挺幸运的，我是组里最2的。。虽然我不像LZ同事一样写出那么多bug，但是我debug的时候也没少到处问{:5_369:} Darkpriest 发表于 2014-8-8 10:13
我挺幸运的，我是组里最2的。。虽然我不像LZ同事一样写出那么多bug，但是我debug的时候也没少到处问{:5_369 ...
那你就自觉少干点活，省得给别人添麻烦{:5_346:} adgjl 发表于 2014-8-8 11:07
“一个人开发的内容，另一个人必须审核并且充分理解。不然一个人离职了或者休假了出了问题很难解决。这是 ...
说的有道理。我会思考下怎么改变目前的工作方式。谢谢你。 和路雪 发表于 2014-8-8 00:00
你知道，有些时候，尤其是技术工作，人的能力够不够，是生产力和效率高不高的直接因素。。当然我也没有能 ...
碰到和你差不多的问题，但我不是新来的那个。新来的年纪大，问题也挺多，总是把简单问题复杂化，系统里定义好的东西，非得自己再起个名字重新定义一遍，两行的就用一次的代码也得封一个函数，也不考虑一下别人看你的代码累不累啊。估计他自己看着都累，结果自己编出来的一小段东西不好使，自己找了两天了，还没找到问题。上次憋了一个星期的编出来一个文件，代码乱的一塌糊涂，根本没法交，我做个差不多的也就两个小时。
关键是一点都不虚心，号称编了30年的程序了，不要别人帮忙。我靠！就TMD这水平？ zhnde 发表于 2014-8-8 12:27
碰到和你差不多的问题，但我不是新来的那个。新来的年纪大，问题也挺多，总是把简单问题复杂化，系统里定义好的东西，非得自己再起个名字重新定义一遍，两行的就用一次的代码也得封一个函数，也不考虑一下别人看你的代码累不累啊。估计他自己看着都累，结果自己编出来的一小段东西不好使，自己找了两天了，还没找到问题。上次憋了一个星期的编出来一个文件，代码乱的一塌糊涂，根本没法交，我做个差不多的也就两个小时。
关键是一点都不虚心，号称编了30年的程序了，不要别人帮忙。我靠！就TMD这水平？
还有更奇葩儿的，写的10页A4纸打印出来的代码70%是Kommentar，代码本身80%是抄来的。然后整个代码根本不能工作因为丫不知道怎么测试(不会用Eclipse直接Word里写的)。然后丫把这代码给了我隔几天问我代码是不是很棒。我还只能说不错(平时对我不错)。结果说完这厮很兴奋非扯着我一行行跟我讲解这代码怎么好(这哥们儿花了一礼拜鼓捣出来的代码，Leichtbau专业出身这半年因为一起做项目非让我给他个小玩意儿编编，号称计算机是第二爱好除了捣鼓车)。整个下午俩小时我都在虎躯一振霍然身起拿电话听筒抽丫嘴的念头里度过的。 Linux_Handy 发表于 2014-8-8 12:48
还有更奇葩儿的，写的10页A4纸打印出来的代码70%是Kommentar，代码本身80%是抄来的。然后整个代码根本 ...
代码写在word里面~~好吧这是我见过最奇葩的了
看来我们组好很多。我们三个年轻人，想法相对统一，另一个老头子，最大爱好是和稀泥，而且是很专业的那种。所以一般的有什么需要出头的事情基本都是我们年轻人去做，不过毕竟我算是新的，还是让我们三个里的“长辈”去做。他很有想法，在公司里时间也比我长一些，大概三五年吧，所以搭配的还不错。我觉得teamarbeit不是说要替别人做什么的，而是保证自己的一份尽量做好。替别人做的结果我觉得往往是吃力不落好，因为被替的人心里可能会觉得你抢饭碗，无论他是不是有能力保饭碗。另外你也很累，万一有个问题出来，责任在你。 tracywyt 发表于 2014-8-8 09:36
呵呵，你们公司Review的人可以和写代码的人一起改代码，QS不过关啊
pair programming。很多公司都这么做啊。 Linux_Handy 发表于 2014-8-8 12:48
还有更奇葩儿的，写的10页A4纸打印出来的代码70%是Kommentar，代码本身80%是抄来的。然后整个代码根本 ...
什么奇葩。。。
我都不是码农也从来不会在word里写代码，那个人脑残么。 本帖最后由 chinapope 于 2014-8-8 15:58 编辑
和路雪 发表于 2014-8-8 11:02
C程序挂了就整个进程崩溃了。在客户那里挂了，找问题能把你烦死。。你也不能当场确定因为什么原因挂了， ...
LZ, 你工作这么用心。不得不服啊。
小弟我同是码工作3年不到，有点看透，不是自己的责任，不要去担。
天塌下来了，有长汉（那些年薪高得多的Senior们）顶着。
页:
[1]
2