大话产品开发工作方法问题.docx

一个LPDT的亲身体验
------大话产品研发的工作方法问题

工作是离不开专业技术的，做工作首先要有一定的专业技术基础，这一点无容置疑，但在实际工作中专业技术不是最重要的，最重要的是工作方法，工作方法也是最难学到。有关方法论的书籍很多，一旦上升到“书”的水平，不但逻辑性要求很强，还要有哲理和深度，它离实际操作的情况被人为的拉远了，没有经历的人是很难看得懂，更别说学到手了，这也说明了为什么MBA要采用案例教学法的原因。
以下案例全部来自工作实际，为了更突出案例的真实性，全部采用真实姓名。我尽量采用正面案例，但有时为了说明观点，也会用到一些负面的案例，并没有对角色本人有任何成见，如果角色本人认为不妥，我将会尊重角色本人的意见，将其真实姓名删除。也是基于这个原因，本案例只作我与大家交流使用，不能提供文档给大家，敬请谅解。
其实我们每个人都有一些弱点，我相信有些工作没有做好都不我们的本意，事实上没有经历过失败我们也成长不起来，所以“负面”一定是好事，负面能让我们成长得更快。
这些方法并不是最优的，大家应该采用更好的方法解决问题，有些方法还可能是最笨的，但它在一些情况下确实有效。
有些案例所表现出来的方法我也不是每次都能很好地使用，包括我本人也不是都能像一些案例做得那么好，应该是我学习榜样，也是我努力的目标。

一、 案例一：
案 例

2010-07-01 17:52我给HZM、ZhZh、ZhYZ、DL发了一封邮件，反映周总在XX中心入网测试中发现的问题：
1、与ShGX的现场（SJWT的网关）语音单通。
2、多路视频同时上大屏时视频卡。
3、一款海康编码器的视频也卡（型号与SJDF的相同，版本不同）。

2010/07/01 18:43DuLing回复：
我已与周总确认，本来我明天想去一次现场，周总说明天暂时不解决“与上海国欣的现场（世纪网通的网关）语音单通”的问题，回头一起解决。明天测试大话务量，今天晚上我会在公司加班测一下。明天给现场准备好环境。请L经理放心。

2010-07-02 11:07我看到DL的反馈，对DL的反馈很是赞赏，于是回复：
谢谢您的及时反馈和大力支持。

2010/07/02 11:39DL回复：
L经理，以后不用这么客气，这都是应该做的。毕竟这是公司级的大事，我们会第一时间积极配合的。请不用担心。
LJH已将设备拿到现场，昨天晚上大话务量呼的还挺好的。

案例分析

任何一个人将信息发出去后都希望能尽快得到回应，所以当我们接收到一个问题反馈或一项工作任务时，应该及时给问题提出者、工作任务安排者反馈你的处理意见。这就是一个最简单的沟通方法，即有去有回，及时反馈很重要，遗憾的是很少有人能够做到，在研发中心更是曲指可数。如果大家都做到对问题及时反馈了，工作效率将成倍增长。
当接到一个问题反馈和工作任务安排时，最好要找到源头，如本例中的周总，而不是中间人L经理。很多开发人员经常对我说“让现场人员怎么怎么弄一下。” “让谁谁谁给我打个电话。”“让他找个包给我看看。”，都成了是大领导的！我是传令兵！应该说“我马上跟某某某联系解决，你就甭管了”。了解清楚问题的真实表现，在了解问题的过程中，有时一不小心你就已经找到解决问题的办法了，并与用户（如本例中的周总）讨论自己解决问题的方式或方法，征求用户（如本例中的周总）的意见，达成一致的处理意见。再回过头来将自己工作过程和后续安排反馈给安排工作的人（他一定很关注问题真实情况、后续措施和计划，如本案例中的L经理）。
本案例涉及到一个人对工作重要性的认识程度，也涉及到积极面对问题（或任务）时的工作态度，入网测试任务是公司级的战略任务，是何等重要，在大会小会上都说过很多，但又有多少人能够真正放到心里去呢？DL的一句“明天测试大话务量，今天晚上我会在公司加班测一下”，没有人安排她加班，而是工作需要（现场人员在焦急等着呢！），她就这么做了，这就是一名优秀员工面对问题（或任务）时的积极的工作态度。遗憾的是这一点也很少有人能够做到，如果经理不明确要求加班，大多数员工一定是到点就下班，这样会将把很多关系人推到火坑里，很严重的！作为一个工作着的人应该有这样的认识。
本案例涉及到敢于承诺、重视承诺的职业素质，一句“明天给现场准备好环境。请L经理放心。”表现出DL敢于承诺、重视承诺的职业素质，试问哪个公司、哪个经理不喜欢这样的员工呢？
本案例涉及到一个持续反馈的问题，由于第一次反馈大多数情况下是下一步的工作计划或工作设想，对于工作计划的执行结果应该再有反馈，直到任务完成。“LJH已将设备拿到现场，昨天晚上大话务量呼的还挺好的。”就是很好的持续反馈。安排任务的人更是这任务的是最终负责人，这个问题或任务会一直放在他的心里，直到你给他反馈最终的结果。
本案例涉及到一个管理者对反馈进行反馈的问题，这种反馈既是对及时反馈表示感谢，对工作表示赞同、肯定和赞赏，又是在提出希望或下达继续进行下去的指令。

二、 案例二：
案 例

2009.8.14《XXX中心通信设备开发任务书200908》发布，成立IPD小组，产品经理和研发代表均为L经理，经k经理推荐，改由ZYZ任研发代表，负责组织研发工作，一方面锻练和培养一下ZYZ，另一方面减轻产品经理的工作负担。事实上，ZYZ在组织开发过程中确实起到了很大的作用，开发工作进展还算顺利。后来由于铁路入网委托测试进展不顺利，项目处于等待入网测试状态。到了2010年初，由于公司组织结构的调整，ZYZ担任M34项目经理，原PDT成员被分配到其它项目组，入网测试项目处于无研发代表和无组织状态，任务书中的各项工作已经没人管了，L经理找K经理商谈项目管理问题，K经理表示ZYZ目前负责的项目太大，已经没有精力管入网测试项目了，后来在项目经理例会上，L经理提出入网测试项目管理的问题，达成还是由ZYZ负责一段时间，LJH慢慢接手的工作安排。
案例分析
本案例反映一个非常普遍的问题，即在进行组织结构调整和资源整合时，很多前一年未完成的项目被忽略了，研发代表接到新项目后，自动地把老项目给丢了，很自然地将老项目交回到了产品经理的手中（因为产品经理没有退路），就好比一个产品经理打下一个山头后交给研发代表去开垦，研发代表开垦到一半就被调走了，不管了（被自动离岗了！），项目组也无声无息地被自动解散了，产品经理正在攻山头呢，但不得不回来接管，或重新组织人马，研发代表到底由谁释放？资源线还是产品线，当然是产品线。
组织结构调整和资源整合必须保证历史和现有的项目或开发任务都有人管，保证项目及项目组织的连续性，否则之间的人员交接和项目重组将会使项目状态倒退到一个不确定的状态，需要付出很多的时间和成本才能到达交接前的状态，将造成极大的资源浪费，出现很多不可预测的问题。
一个组织要有始有终，没有宣布结束或取消，这个组织就必须正常运行，否则会留下很多真空地带，耽误很多事。
如果人员变动，特别是组织结构变动，需要有个正式的交接程序，确保接手者接手后能正常开展工作。
从另一个方面考虑，领导者要清楚的知道任务交接和组织结构重组后的问题将是成堆的，要做出适当的安排，使接手人和新组织有足够的时间消化别人很长时间里走过的路程，尽快达到前人已经达到的状态，后续的工作安排才有保障。

三、 案例三：

案 例

在ZXY项目中发现VOP与XCU之间如果中间断网，VOP没有重新注册功能，导致VOP与XCU之间呼叫无法建立。因此决定在VOP与XCU之间加心跳消息，如果VOP收不到XCU的回复，则不断尝试重新向XCU注册，直到成功为止。

案例分析

四、 案例四：

案 例

某日到ZSY大厦进行软件升级，约好9点之前到ZSY大厦集合，同时有人到LF配合测试，结果9点过了，去LF的人已经到了，但一个开发人员还没有到ZSY大厦。

案例分析

多人一起配合工作，关键是要同步，一个人不同步，将拖整个团队的后腿，只有同步了才能按计划开展工作，否则工作目标将无法按时完成，特别是到用户现场工作，一定要守时，时间可能是你与用户约定的，更多的情况是没有约定的约定，如用户什么时候上班你就应该比用户上班时间早一点到达，比用户晚走一点，等等，只有这样，你才能得到用户的信任和尊重，你的工作也就比较好开展了，否则用户凭什么信任你和尊重你，通过你用户对公司也会产生不信任。

五、 案例五：

案 例
XX500已经进入概要设计，需要对结构进行设计，当结构设计准备开始设计时发现很多设备没有（设计时需要对这些设备进行测量），无法进行结构设计。

案例分析
在工作中，经常到了需要开展的某项工作时因为条件不具备而无法进行，导致工作计划延时。如：
系统集成方案设计阶段应该将设备选型、对外接口器件、外部连线等工作应该完成，概要设计（硬件、结构等）需要的设备需要采购完成，才能保证概要设计工作的按时开始，只有按时开始才能保证按时完成，否则概要设计工作一定会延期。
正确的处理方法是：项目经理在做计划时要清楚地知道某项工作开始的必要条件，这些必要条件必须列入开发计划并要重点跟踪和检查，不但要关注到时的工作是否能按时完成，更要时时关注后续工作是否能按时开始，后续工作按时开始的条件是否已经准备就绪，如果发现问题要及时采取措施，加速处理。至少一半以上的工作延时是因为工作的衔接的问题造成的，做好工作任务（特别是跨部门任务）的无缝衔接是项目经理进行进度控制的一项重要工作，做好了事半功倍。

六、 案例六：

案 例
LJ发出差报告邮件
ZSY出差报告（2010-11-25）
出差人员
LJ
报告人
LJ
工作内容
完成情况
查看FaxSvr down机原因
目前使用守护进程守护发现down机后重新启动Faxsvr
进入机房修改206 BIOS 配置，忽略启动时检查设备错误处理。
经过测试，通过PC-AnyWhere可以正常启动远端被控机
发现XCU僵死情况，测试确认其发生状态
经测试，当FaxSvr重启后，向SCU注册成功后，会导致XCU僵死——无法接受任何的信令请求，例如：VDT无法注册上
与苏工进行沟通，确认在当前的OCX和FaxSvr环境下，无法同时往多个传真机发送传真

遗留问题
FaxSvr会莫名其妙down掉，已抓取出RPT文件。回家后分析对应的代码
FaxSvr down掉后，再向SCU注册成功后，会导致SCU僵死——无法接受任何的信令请求，请测试人员复现状况，排查原因并解决
FaxOCX目前似乎无法支持一份传真同时发往多个传真机的情况（仅仅是怀疑），测试了一下发现使用VDT台子是可以同时发送给多个传真机。需要在家里进行针对FaxOCX和FaxSvr测试，确认问题。

测试人员XX回复邮件
L经理，您好：
研发并未提交传真功能测试版本，如传真功能需要测试，请研发提交相应测试版本及测试任务单，谢谢！

L经理回复邮件：
测试分两种情况：
一种是系统测试：即通过测试任务单进行的测试。
另一种问题测试：针对用户使用环境的专项测试（何连军负责的按ZSY环境进行专项测试）；用户现场发现问题时在实验室重现的测试（如在广东移动发现的ＶＯＰ进程死掉的问题）。主要的目的是100%重现问题，什么叫100%重现？不知道什么情况会出现的所谓“偶尔出现”的问题，通过大量的测试，把它变成在某情况下“必然出现”，这样研发解决问题就快了否则就成了老大难问题。这种测试对测试人员的要求是快速进行测试，问题不等人啊。至于工作量统计项目经理要有本帐记着，不能让测试人员白干了。
另外关于ＢＵＧ问题我有一个想法与大家交流：“偶尔出现”的问题肯定是ＢＵＧ，将这个问题１００％重现出来时抓这条虫的工作才应该算结束，如这个问题“偶尔出现”，相当于这条虫还是跑了，没抓着。抓“偶尔出现”是最难的，也最能体现测试人员的测试能力和开发人员解决问题的能力。测试人员测试时要将“偶尔出现”变为“必然出现”，开发人员解决问题也要将“偶尔出现”变为“必然出现”，这是测试高手和解决问题高手应该具备的能力。我们经常听到“这个问题不出现，我也没办法”，好象很有道理，事实上他放弃一个让自己能力提高和表现自己能力的好机会。告诉大家一个秘密：技术总监（包括测试总监和研发技术总监）就是这么锻炼出来。
（第三种测试：与研发一起进行集成测试）

案例分析

很多开发人员对偶尔出现的、低概率的BUG都表现出一脸的无奈，经常听到开发人员说“没办法，它多久多久都没出现过了”，真的就没有办法了吗？答案当然是否定的。正是开发人员这种守株待兔式的处理BUG方法，导致产品存在很多偶尔出现但影响很大的BUG，那处理这些BUG的方法是什么呢？简单地说就是积极处理，复杂地说也就是下面三条：
第一条，保留现场、观察分析：出现这些BUG时不要急于“消毒”，即通复位、重启恢复功能，而是要仔细查看与这个功能失效有关的所有模块（在同一台计算机运行应用程序有时也是相关模块）的各种运行状态（如CPU占用率异常升级高、指示灯显示异常）、消息收发信息（如消息没有按正常流程出现）、异常信息（如消息错误），以便定位问题。
第二条，制造现场、寻找规律：开发人员自己（或与测试人员一起）复现BUG，因为是黑盒，测试人员不了解系统内部流程，发现BUG后只能描述BUG现象，对出现这些BUG的各种场景往往不太能注意。开发人员亲自去重现这些BUG很重要，BUG解决快的开发人员一定是会自亲去重现BUG的。
第三条，围追堵截、瓮中捉鳖：如果很难重现BUG，那就要在软件中加上调试信息，开始可以粗一点，在各个模块接口处加调试信息，只要这个BUG再出现一次就一定能定位到模块，如果还不能定位问题出现哪里，再在这个模块内部增加调试信息，当这个BUG第二次出现时，基本上就能定位到代码了，通过这个方法，大部分的偶发性BUG只要出现3次基本就能解决。

七、 案例七：

案 例

广东XX项目已经到了要交付的关口，个别功能还没有开发完成，并存在一些问题，用户、集成商和市场都已经很着急，产品经理与工程人员、研发人员到现场了解情况，将开通的工作尽量做好，同时也是为开发人员争取时间在公司将软件问题和新功能开发完成，然而却因为一个开发人员要去租房，周六就无法加班调试软件了！现场人员心急如焚呀。

案例分析

项目经理之前已经到过现场，非常清楚现场的紧急程度，产品经理去现场前也跟他说明去现场的目的：给用户一个定心丸，为开发人员争取一点时间，在公司赶快做完。项目经理应该组织人员在公司加班加点完成开发工作，如果协调有困难应该及时向上级提出，上级一定会想办法解决的。如租房子之事，可以暂时住在宿舍里，等工作忙完了再去租房子。如果有些人员无法协调，可以向中心经理、主管副总说明事情的紧急程度，则一定能将人员协调到位，一起把工作做好。
项目经理对事情的紧急程度是否有足够的认识，是不是有一根急用户之所急的弦，如果有这么一根弦，一切问题都好办，如果没有这根弦，这个项目经理会误事，这个项目经理将很难带领团队，因为没有人会听你的了。
有了这个弦那剩下的就简单多了，只是工作方法的问题了，首先要向相关人员说明事情的紧急程度，然后安排问题讨论、明确目标、明确分工、安排计划、安排加班等，如果你平时已经树立了威信，大家愿意听你的，做到这一步问题已经解决了一大半。但如果你平时还没有在员工中树立威信，这时你应该先尝试着与相关人员沟通（问题讨论、明确目标、明确分工、安排计划、安排加班等），如果无法达到你的目的，及时（注意要及时，事情是不能耽误）找你的上级（上上级、直至老总），请你的上级出面协调、解决困难。

八、 案例八：

案 例

案例分析
个人能力都还不错，在一个项目组里也还凑合，但在一个跨部门的组织里，简直就是一盘散沙，如果是没有正式组织的跨部门（项目）合作，更是难以上青天。

九、 案例九：

案 例

E1接口的调度台由于签订合同比较晚，公司订单下达后需要一定的生产周期，市场答应用户是9月20日到货，但在9月10日应急预演和9月17日正式演练之间用户需要给领导展示项目成果，因此需要我们9月10日前供货并调通，公司没有货怎么办？通过与方案总体单位太极公司的凌工交流，发现用户最需要的是要向领导展示他们的工作成就，因为这段时间是向领导汇报成果的最佳时机，同时也是宣传我们产品的最佳时机，因此决定从开发或测试环境中协调设备到现场使用，满足用户的需要，新货到后再换回来，这个想法得到凌工的认同。同样的道理，ZSY项目的便携卫星模块还没有采购全，与工程项目经理商量用塔里木返回的摔伤的XX300和研发用的发电机先发货，让用户能展示功能，新品到后再换回来，这也得到用户的认可。

案例分析

虽然我们是在卖产品，实际上我们卖的是服务，因此我们要服务好用户，怎么服务？那就是帮助用户完成他的业绩，帮助用户成功，而不局限于产品本身。

十、 案例十：

案 例

在广东XX项目现场发现调度台只能开8方会议，需要在公司重现和解决这个问题，周日（2010.8.29）安排项目经理HZM周一到公司与ZZ搭环境进行测试，重现并解决这个问题。周四（2010.9.2）我忙完ZSY第一次应急预演后回到公司，发现这个问题还没有任何进展，问负责解决问题的ZZ才知道，周一采购的POLYCOM CX200还没有到货，没有搭8个软电话环境。我说解决这个问题使用8个xx3400系统的电话也可以呀，周四（2010.9.2）搭环境进行测试，很快重现了问题，周五（2010.9.3）就解决了，周六（2010.9.4）ZZ就可去广东移动升级去了。如果还在等POLYCOM CX200，到现在（2010.9.10）还不能开展工作。

案例分析

很多开发人员和项目经理都是在等“环境”，不积极想办法，也不向上级反映和求助，导致工作任务或问题解决严重延误，让人哭笑不得。
开发和测试环境对解决问题真的是很重要，但在开发队伍（其它队伍也一样）中“等”的思想太严重，这就是开发队伍给别的部门印象：问题解决太慢、进度太慢的重要原因。只要想办法，只要向团队、上级提出来或求助，有很多“变通”的方法可以解决开发或测试环境问题。有些人可能认为是因为经验不足造成的，我认为这是一个人的惰性或对问题的不负责任态度造成的。只要你积极面对问题，只要你对问题负责，你就会开动你全身的机器，利用身边所有的资源，没有解决不了的问题。

十一、 职业化

案例

案例分析
唐骏曾经说过“作为职业经理人，在选择离开时一定不是出现危机或是产生分岐等原因的时候。职业经理人只有完成了你的既定使命后跳槽才可以提升你的价值，且你的离开已经不会影响XX业务的发展及市场对于XX的评价。”

解决问题牛人必须具有的素质：
第一， 有危机意识
收到问题反馈后，特别是用户反映的、领导关注的、工程售后现场反映的、生产现场反映的问题，又特别是比较重大的问题，现场人员面临着来自各方面的严重压力，有时候都恨不得想找个地洞钻进去，他们多么需要家里人的帮助呀呀！碰到这种情况，此问题的直接责任人（开发人员）和项目经理要有茶饭不思、寝食难安的感觉，全身的组织都要紧张起来，都要调动起来。你要有危机意识，这个问题不及时解决将使用户对产品失去信心、对公司失去信心，现场人员对研发团队失去信心对你失去信心，公司甚至将失去赖于生存的市场，研发团队将失去赖于存在的产品，个人将失去赖于生存的岗位，可能言重了，但一点不为过，没有这点意识，你也成长不起来。及时组织人员进行问题分析，进行工作安排，并将工作安排知会所有利害相关人，让大家知道你在全力以赴，让大家觉得有希望了。要放下所有其它不相关的工作，克服家庭、生活、学习上的困难，很多时候还需要做出家庭、生活和学习上的牺牲，中午你不能再去与别人聊天，不会再上网，你不会再去参加会议或培养，你不会下班就回家，你心中只有一件事：无论如何要解决这个问题，只有这样，这些问题才有可能尽快地解决，才能救用户、公司现场人员、领导于水火之中，你也才能成为大家可以依靠的脊梁。
第二．有坚韧不拔的精神
解决问题的过程不可能一帆风顺，困难永远超乎你的想象，但问题必须是要解决的，如果没有坚韧不拔的精神，你能侥幸解决一些问题，但在很多问题面前你将是失败者，这些失败将严重影响你在团队中的威信，如果你是经理，我可以说你已经完了，因为领导已经不信任你了，团队已经不相信你了，建议你另谋高就，重新树立你的威信，但你要记住：珍惜你好不容易建立起来的威信，不要让失去威信成为你的习惯，否则你这辈子也不会有出息了。
第二， 善于多方求助

第四，善于利用团队力量

项目经理的作用

2011年3月4日项目经理告诉我，2011年3月8日试装有点问题的结构件就回来了，我终于松了一口气，进度一再延误，不管怎么说，总算快熬出头了，三八也算是个好日子，也算是给三八妇女节献礼了。2011年3月10日，我估摸着样机应该装配好了，找项目经理问一下，这一问不想却是当头一棒，项目经理说：其它都装好了，还差几个接线柱没有卖回来。我晕菜！
通过严密的组织和计划，将一个个个体有序地组织起来，朝着一个目标前进，以减少每个人在团队任务中的时间浪费来提高团队效率。提高团队的时间利用率是很难的，但减少团队时间浪费则容易得多，但很多项目经理在这方面做得很少。
那如何制定减少时间浪费的计划呢？那又如何保证计划能按时完成呢？就是要让员工按计划完成该项任务的工作，让员工能按任务开始时间开始这项任务的工作。
让员工按任务完成时间准时或提前完成该项任务的工作：任务一旦开始即开始进行进度跟踪，最好每日跟踪，跟踪时问员工三个问题：一问“XXX任务进展得怎么样？”听员工回答；二问“现在有什么问题和困难吗？”，听员工回答；三问“到XX月XX日还有......(掐着指头计算一下)XX天，对，还有XX天完成XXX任务没有问题吧？”。第一问能了解员工工作进展情况，从中能发现存在什么问题，有些员工也许还会主动地提出一些问题或困难，对于发现的问题或困难，你要给出意见或建议，并得到员工认可。第二问，让员工进一步思考（回忆，有时候员工在工作过程中已经发现有问题，现场他有机会说一说了，并寻求解决）有没有其它问题或困难需要帮助，对员工的问题或困难，你要给出意见或建议，有些要你做出决策，总之，不能让员工因为你没有解决他的问题或困难而干不下去。
让员工按任务开始时间准时或提前开始该项任务的工作：要将员工开始工作各种必要条件考虑全，同时将这些必要条件列入项目计划，对这些影响某项任务准时开始的计划要重点跟踪，有问题要及时处理、及时决策。特别是一个或多个员工的工作开始信赖另外一个或多个员工的工作成果时，项目经理一定要特别关注，一点不注意就很容易造成灾难性的后果，这是一个好项目经理与一般项目经理最大差别。大多数的工作延期均由此产生。
对每个人的每个工作成果进行可验证的检查，确保每个人的工作成果达到目标，对偏离目标的情况，重新确定目标，达成共识，分派任务，周而复始，直至工作成果达到目标。

成为优秀理由

英雄之所以成为英雄，因为他们付出了全部生命的代价，或他们敢于冒着牺牲全部生命的危险去做事。优秀之所以成为优秀，是他们敢于付出了比别人更多的生命（时间）去做事。这是成为优秀的唯一理由，也是不想成为优秀也难的唯一理由，因为它代表着他们对国家、企业或项目忠诚；因为它代表着他们对工作热爱；因为代表着他们对承诺认真；因为它代表着对目标执着；因为它代表着他们对劳动成果爱护；因为它代表着他们对接受自己劳动成果的同事的尊重；因为它代表着他们对用户负责。
优秀的员工一定比别人付出更多去完成工作，不管是在八小时内，还是八小时外。
每天下班就走的员工不可能成为优秀员工，每天下班后就不工作的员工也成为不了优秀员工；每天下班就走的项目/部门经理一定是一个不合格的项目/部门经理，每天下班后就不工作的项目/部门经理一定是一个不合格的项目/部门经理。