初入管理，遇混乱门，求解

0 0

初入管理，遇混乱门，求解5

本人现在处于，身边事情一大堆，却不知如何下手的困境。
事情是这样的，我是公司A组的项目成员，由于B组项目的上线试用和B组一部分开发人员的离职原因。
从A组调入B组进行支援。目前B组每天的BUG提出数量在100个左右(UI和业务)。以xls文档的方式统计且格式不规范(BUG测试是其他部门的在负责)
B组项目的人员分为三个地方。客户现场、公司、研发中心。公司领导让我管理公司这边BUG的修改，任务安排和分配。
现在的主要原因是：
1、我不熟悉B组项目的业务知识。
2、不熟悉B组中的bug那些是项目业务BUG，还是平台、框架问题。
3、bug的修改记录比较混乱。客户现场、公司、研发中心三地都有人在修改bug，基本上是人手一份。
4、我自己每天也有固定的bug完成量目标任务。
5、客户现场、研发中心这两边负责人都是我现在的直接领导。但公司这边的负责人是三个地方最大的。我该听谁的。
我怕有时处理不好，引起直接领导的不满。我一直有不想得罪领导的思想。

有点乱，不过整个事情都描述了，希望项目管理达人或前辈，指点一下迷津。

问题补充：感谢各位前辈的回答，特别是kidneyball和coralsea。另外就是怎样处理以前队员轮为自己的下级（特别是上司轮为自己的下级）这种关系。

项目管理

2013年1月13日 22:17

java880
26
0 0 3

4个答案按时间排序按投票排序

0 0

采纳的答案

上级变下级这个事情有点微妙，要看具体情况。在研发团队里，比较常见的情况这位上级只喜研发，不喜管理，而公司觉得你比较适合管理，就把你提上去了。这种情况，这位前上级事实上就是一个老资格的技术骨干，不过他是你的老上级，相比其他人，你比较难硬起来而已。对于这种情况，我个人觉得应该注意的是：

1. 充分肯定这位上级的技术能力（当然是他自己要有料，不过很少有人本身没料，又喜欢干研发的），在一些重大技术决策时多与他交流。如果你的位置之下还有层级，可以让他当个小头目。就算没有，也可以把一些有潜质的新人交给他带，然后把他和新人作为一个小组来分配任务（也就是变相的小头目）。

2. 与技术相关的东西，多与他交流。技术外的东西（例如管理，招聘，售前物料等等）如果他不喜欢，就不要太依赖他。一来这本来是你自己的活，二来如果他肯干这类活，早就当你的上级了。特别是任务分派方面，应该尽量帮他屏蔽外部干扰，避免随便让外部的人直接找他指派任务，而应该让外部先找你提需求（或者通过其他正规流程），由你定好优先级后再分派给他。

3. 如果你能给他与能力相称的待遇，你可以在待遇上给予肯定，同时在任务分配上紧一点，让他有点挑战（自然要有相应回报）。如果你左右不了待遇，而他的待遇并不突出，则建议你在分配任务评估工作量时采用对齐第二名的做法。也就是说，给他定的任务时限以跟他待遇相同的第二名的人的效率为准。比如说，一个活他干要三天，第二名的人干要五天。你就给他定五天，如果他提前完成但没有主动找你揽活，你就让他随便干点自己喜欢的事情（也就是在工时安排上变相提高待遇）。当然这只是权宜之计，在你能力许可范围内，应该尽量帮他争取与工作能力相称的待遇。

4. 如果他在某些公开场合与你抬杠，往往是因为他是你的老上级，不太拘谨而敢于直言，不要太介意，就事论事就行了。但切记你才是对决策成败负责的人，如果他提出了你之前没想到的观点，要认真思考，做好推翻自己既定方案的准备。但如果双方各执一词，最常见的情况是你觉得A比B重要，而他觉得B比A重要，双方把论据都摆过了，但无法说服对方，这时就应该由你做最后决策。当然如果最后失败，你也要主动承担后果。

2013年1月14日 20:57

kidneyball
205
0 1 13

1条评论

0 0

1,2：自己根据文档和交流尽快熟悉业务的同时，在未完全掌控局面之前，多依赖团队里的技术骨干。鼓励技术骨干参与交流，发表意见。发表了的意见要认真考虑是否应该接受，拒绝也不能把话说绝，不要打击积极性。你在初期的工作应以项目协调管理为主，不宜在技术或架构方面与老队员有尖锐冲突。个人经验是在这个阶段最主要有三种问题：

一是你掌握不了任务的工作量，只能让下面的人自己报工时，初期也没什么好办法，只能由着他们报。因此在分配任务时最好以短会的形式，在会上让各人公开估算工时。只要团队整体气氛良好，一般不会拖延得太离谱。另外你自己要主动关注和记录进度，尽快摸透各人的工作效率。

二是比较激进的技术骨干会趁此机会推销他之前被压下的大改动。在你未熟悉业务之前，建议谨慎对待伤筋动骨或者引入新框架的改动。可以先拖一拖，等你熟悉系统后再定。

三是团队成员互相意见不合或者与你意见不合，找你评理。对于涉及业务的东西如果你不熟悉，不要硬撑着拍脑袋下定论。如果可能的话，协调技术骨干参与讨论（但要严格控制时间，不要浪费骨干太多时间，或者你要把“参与讨论”这个事情作为骨干的日常工作，算工时）。如果一时无法协调，你就如实告之你现在也不能做出最好的决定，然后先暂时挑选容易实现的方案（避免过度设计）。

3：架一个JIRA之类的bug跟踪系统。

4：自己分配好时间，不要揽太多技术细节的活。至少保证每天半个小时到一个小时的进度跟踪时间。1个小时左右review和分配任务的时间，不要让你手下的人没活干。

5：作为基层技术人员，谁给你评估年终绩效，谁就是你的直接领导。永远不要在让其他人觉得你可以自己决定自己工作的优先级，否则被你推掉的人都会觉得你装大牌。对于一两分钟就能顺手做掉的事，你要强调可以“帮忙”做。对于需要一两个小时以上的事，如果不是直接领导分配，你要跟他说“我现在正在做某某事，你的事可能要等一等，如果你很急的话，请找XXX（你的直接领导）定一个优先级”。即使你实际上拿得出一两个小时，也要走这个流程，否则下次你如果拿不出时间，那就变成你“开始不重视”他了。

就算是直接领导给你分配任务，你也要把当前手上的任务说出来，让他定个优先级。否则很容易出现他先给你分配一个工时一个星期的任务，然后每天都给你找其他事，两个星期之后突然问你之前那个任务怎么拖了一个星期都搞不完的情况。

2013年1月14日 12:02

kidneyball
205
0 1 13

添加评论

0 0

上bug管理系统，自己搭，怕麻烦的google code就有这么一套

2013年1月14日 10:39

westmoon
40
0 0 2

添加评论

0 0

1、我不熟悉B组项目的业务知识。
这个问题可以从两方面解决，一是咨询专家（原来的项目成员），二是自己学习
2、不熟悉B组中的bug那些是项目业务BUG，还是平台、框架问题。
同上
3、bug的修改记录比较混乱。客户现场、公司、研发中心三地都有人在修改bug，基本上是人手一份。
需要建立一个规范化的issue track流程和系统
5、客户现场、研发中心这两边负责人都是我现在的直接领导。但公司这边的负责人是三个地方最大的。我该听谁的。
多请示多汇报

2013年1月14日 10:23

coralsea
40
0 0 4