老印问题: 给老板写了起草了这么一封信

又是老印问题: 给老板写了起草了这么一封信, 大家帮看看

我们的开发团队十来个人. 开发人员后台三个, GUI三个. GUI小组, 一个老印女在公司
资格老是lead developer, 我和另一个老美去年新加入的公司的, 半年多了, 也是senior, 但项目被她领导. 我们都归一个管二三十人的美国人老板直接管.

这老印人还不错,懂的也多, 就是项目质量太差, 程序里漏洞百出. 因为一起工作, 她
又是lead, 我常常要我帮她fix bug, 非常头痛. 我一直希望把每个人做的都分开, 因
为我的程序质量比她好太多了, bug非常少. 但她还是把我们三个人的任务混在一起,
大家互相改来改去, 害我背了不少黑锅, 又不好跟大家说都是她的错.

一个月前老板在会上看进度, 大发脾气了一把. 其实都是她的bug, 大家以为是我们两
的, 也许以为就是我的. 我在会上委婉得说了一下问题症结所在. 本来事后想找老板再
说说, 想想觉得没意思, 就放弃了.

今天类似情况又发生了, 大家又以为是我们两个人的责任. 可能还以为主要责任在我,
因为bug都是我fix的, 实际上都是她的写的. 另外, 那老美今天会后立马给几个人发了信,表明几个bug不是他的责任.

也不想把关系搞僵了, 在这公司我也就是等绿卡(2005 PD, 今年应该能拿到), 没啥野
心. 给老板一人写了这么一封信, 大家看看如何?


I was thinking about talking to you after Phase I. I did not do that because
I thought as a team we should work out together instead of clarifying
responsibilities. So on phase II, my task were X and Y, but I spent more
time helping other developers fixing bugs. And for those 40 bugs(全大组的,
大半是GUI) still reported by QE, I took 17 of them. Only three of them are
really my phase II bug (two are requests to add colon or question mark in
text). Another three are either requirement clarification or historical
issues as you can see from the attached list.

I am not blaming anyone. XXX(老印女) still takes much more responsibilities
than B(老美) and me, so it is not fair to have her accountable for all bugs
from her code. ( That’s why I take the initiatives to fix the bugs. On the
other hand, I do not want to look bad in meeting because of the initiative.
). On client side, often two or even three developers are working on the
same page, and fixing each others’ bug. This approach helps in some ways,
but is not efficient and very easy to cause new bugs. For example, we three
are all working on the new XXX page. When developing new YYY feature, 80%
of my time was spent on fixing old bugs on this page.

The three developers on service side have well defined responsibilities(
might be one reason they have fewer bugs). Possibly we could gradually have
a more clearly defined responsibilities for client side as well without
sacrificing the flexibility and teamwork. Also, unless necessary, one
should avoid fixing other developers’ bug(it is too easy to create new bugs
when fixing others’ code).

Thanks for your consideration, please let me know if you have any questions
or want to meet!