今天到了武汉，是我第二次来武汉了，下了飞机出机场，外边很乱，不知道在哪里打车，一辆出租车来到我们边上，拉上我们，一眼看上去就是那种本地人，开到大路的时候，师傅才问我们去哪里，我们告诉他，我们去武大，珞瑜路的如家，于是他问我们，你们熟不熟悉那个地方，我们告诉他，珞瑜路熟悉，那个如家没有去过，他再问我们，我们打算出多少钱？我们说你打表吧，他说他不愿意打表，于是我们问他，你要多少钱，他说至少140，最后，讲到120元，其实贵了，我们也知道，但是，在半路上，而且很重的资料，我们都烦了，120就120吧。

到了地方，离如家很远，他就把我们丢下了，我们让他绕过去，开到酒店门口，他说，他也不熟悉路，帮我们倒车，尽量离的近一点。我们没有办法，两个人抬着很重的资料，来到如家门口，一到才发现，这家不是公司给我们定的那家，而我们定的那家离这家也就2站路，哎，这么重的资料，我们不可能抬两站路。于是门口打车，所有司机一听说地点，马上说他是汉口的，对武昌不熟悉，好像是经过培训似的。呵呵，最后，没有办法，就住这家吧。

呵呵，太有意思了，武汉人！

 

公司有很多问题，特别是供应链的问题，大家都感觉到了，可以怎么解决呢？真是一个头痛的问题，而且公司如果不解决这个问题，工程师就没有信息，也没有长期留下来的意愿。

我们的供应链，为了成本考虑，不断导入国内一些小的厂商，而这些小的厂商良莠不齐，品质千差万别，对于我们这样的一个大的系统，随便一个物料出问题，最终出现的问题就是无法交货。无法交货最终的影响我们在客户中的信誉，长此以往，怎么发展。

我记得很多公司很小的时候，都和我们公司合作，后来，人家就慢慢长大了，费用就高了，我们公司承担不起，我们也就不和人家玩了。我们公司就像一个永远长不大的孩子，只和四岁以下孩子交往，等别人长大以后，人家变得成熟了，我们就不和人家玩了，于是，我们永远只能处在四岁以下年龄段。

所以，我们公司想要长大，必须变得成熟，那么我们必须改变我们概念，我们的玩法也要变，例如，我们以前玩非常幼稚的四岁孩童玩的小鸭子，我们现在应该变了，我们也要玩玩手枪，再往后，我们也要玩玩篮球等等。

现在我们要玩的就是资本运作了，我们一切都要正规化，我们不要再和四岁以下的儿童玩了。我们要选择一些合格的供应商，发展一些大的供应商，最好能够互相入股和参股，把大家都变成栓在一条绳子上的蚂蚱，这样基业才可以长青。

我觉得，必须这样，否则，我们在这家公司，长此以往，我们都变成四岁以下的儿童。

该发展的公司，五年应该有一个大的变化了。

Old MacDonald had a farm, e i e i o
And on his farm he had some cows, e i e i o
with a moo moo here and a moo moo there
here a moo there a moo
everywhere a moo moo
Old MacDonald had a farm, e i e i o

Old MacDonald had a farm, e i e i o
And on this farm me had some ducks, e i e i o
with a our our here and a our our there
here a our there a our
everywhere a our our
Old MacDonald had a farm, e i e i o

Old MacDonald had a farm, e i e i o
And on his farm he had some ducks, e i e i o
with a quack quack here and a quack quack there
here a quack there a quack
everywhere a quack quack
Old MacDonald had a farm, e i e i o

Old MacDonald had a farm, e i e i o
And on this farm me had some Cows, e i e i o
with a mu mu here and a mu mu there
here a mu there a mu
everywhere a mu mu
Old MacDonald had a farm, e i e i o

我们公司有一个习惯，好像老板不在，员工就放羊了。所以，我们搭建架构的就是希望有人追着，有人跟着去干活，这样，会把我们的部门领导累死，而且做不好，很多工程师可能觉得做工作没有一点自己掌控的空间，没有一点成就感，就想产线工人一样，慢慢的，对工作失去兴趣，对岗位失去了兴趣，后面就选择离职了。我们毕竟是研发，而不是工厂！

英国著名的教育学家斯宾塞最早提出自主学习的主张，他曾经说过一句话：“教育的目的是有一天能够不教。”是啊，不教才是教育的终极目的。试想想，即便终其一生，我们又能教给孩子多少知识呢？因此，授之以鱼不若授之以渔。

同样，我们管理的目的也应该是某一天不管，那一天，我们公司的管理层整天能够游弋在高尔夫球场，然而公司的发展还是很好，那么我们的管理就成功了。

我们应该如何搭建一个架构能够使我们的员工具有主动性，如何培养主动性，需要我们在管理和培养意识上跟上，同时，我们还需要调整我们的管理架构，让员工充分发挥自主性和创造性，也有一定程度上允许员工犯错误。

这样的架构如何搭建呢？

公司为什么决策这么慢，而且很多问题都是要到老板哪里去决策。一个重要的原因就是钱的问题，我们公司钱的使用不是采用预算制度，这样，很多关系的到钱的问题，几乎都是需要钱的，其实公司的事情几乎都是关于钱的问题。

所以，这个地方才是公司决策体系混乱的根源所在。我们无法把一些问题局部化和专业化，很多一牵扯到财务的问题都是需要老板的问题，所以，决策就非常麻烦。

怎么吧？我们应该如何重新架构这个问题？我一直在思考。

项目一定要学会规划清楚

S42G目前定的目标是下周一，也就是，3月31日给TF出货，目前有很多问题。

1）  Bug的问题

2）  备料生产的问题

3）  和TF确认的问题。

 

1）  Bug的问题可能是当前最重要的问题，目前该项目主要有如下的Bug

a)         S3/S4混合休眠大面积听04的问题，这个问题，在EVT的13台上也出现过，当时确认已经解决，这次怎么又出现了？

b)        DOS下烧Inverter的问题，目前没有方案。电源的意思是开机过程有频繁的开关Inverter的动作，所以会烧，但是这样说法是不对的，因为无论怎样开关Inverter，都是不允许烧的。

c)        DOS Boot显卡会出现几次开关背光灯管，需要验证其他机器情况，今天需要联系SIS，要求SIS解决，但是，我们同时验证华硕等大厂的SIS集成显卡机台是否有这个问题。

d)        USB的问题，目前USB信号在裸板状态会有（会导致带着某些USB设备，无法过POST和BOOT），但是整机已经确认没有这个问题，初步分析可能是和地的属性有关系，具体原因需要进一步分析，目前可以先不Care。

e)         SD卡的问题，需要进一步确认是否和卡槽有关系，如果是卡本体问题，而不是卡槽问题，可以先忽略。

f)         与T7 Cpu导致的开关机等问题，可以先不去Care。

g)        关于切屏的问题和休眠选项问题，属于系统的limitation，先不Care。

h)        S42P上公共的问题：

1.         摄像头的问题

2.         喇叭的问题

3.         灯号的问题

4.         3D的问题

5.         Touch Pad问题

2）  生产备料的问题

a)         如果下周一出货，那么在周四的时候，必须进行PCBA生产需求单，而周五必须进行组装，这样下周一才可以出货。

b)        如果周四下午打板子，那么周三早上必须给出打板需求单

c)        这样今天主要验证，可能影响打板的问题。

3）  和TF确认的问题：

a)         BOOT过程闪屏的问题

b)        Vista等几个Limitation问题

c)        切屏的问题S42p上的公共问题

今天就进行了项目组的s42g的Bug Review，从9：30开始，到了11：00才结束，为什么这么长呢？

第一，   Bug太多了，例如s42g就有50个Bug

第二，   有些Bug本身讨论事件过长，例如，USB的问题。为什么这个Bug会讨论这么长的呢？第一个各方观点不一致，第二，就是没有人最终敢去决策。

 

如果避免Bug Review的会议时间过长呢？我认识做到如下几点，

1）  第一点，在Bug Review前期，测试部分把Bug发给项目组各个成员，以及重要评审人员，重点通知到他们，要求他们在Review之前，先把Bug先看了。另外，系统工程师和测试工程师在Review之前，先把Bug进行梳理，按照严重性区分问题，并且把不同的问题进行归类。

2）  第二点，在Bug Review的时候，会议由SE主持，SE首先简单回报项目总体状况，有多少个Bug，多少个严重问题等。然后，按照严重性，我们重点讨论前5个问题，如果项目问题特别多，也就是十个问题。

3）  第三点，项目的问题讨论，SE先做阐述，然后，各个工程师发表自己的意见，稍微讨论一下，最后，SE做总结，分配各个部分的工作。特别问题不好决策的时候，再请部门负责人。当然，能够会下找，就会下找。SE要注意，该决策的时候一定要决策。

 

总之，

1）  会下缺少有效沟通

2）  会上缺乏有力组织人和主持人

3）  遇到问题，缺少果断的决策人

 

 

关于项目的第一批出货，目前PMC和PM互相的意见都很大，这个我有所理解，而且，我本身也意见很大，按照道理，我不应该直接关注项目的，但是目前的状况是如果我的视角离开一会儿，可能就会出问题。我总结了一下，还是PM对于我们产品状况不熟悉，缺乏管理方法。

我一直认为，我们到了后期出货的具体时间点能够定下来，也就是可以给客户承诺交货时间的时候，我们应该安排项目第一次出货倒计时了。可以，韩总认为，项目计划原来做好了，就按照计划执行就可以了，我不同意这个观点，连奥运会这样好几十万参与的项目都需要倒计时，我们这样的项目，我更觉得需要倒计时，其实，这也可能是精确控制时间最好的方法，我们不可能因为奥运场馆没有装修好，就让全世界人民等着吧，事实已经无数次证明这样的方法，是精准控制的最好的方法。

PMC定出排产和出货时间，计算出每一个物料到位的时间，然后分析每一个物料当前情况，对于已经承认的物料，确定批量到货事件，对于还处在研发中间的物料，安排合理的时间安排，然后把这些任务分别下达给PM和采购，然后PM在一步一步分解给项目组。

这样，我相应，一定可以达成出货的目标的。奥运会和宇宙飞船都能准时开，一个小产品真的就那么难？

所以，目标明确是关键，市场和产品要明确传递这个目标事件，PMC合理分解，PM把这个目标进一步分解，并且把这个目标深入传递到公司的每一个人，大家齐心协力，肯定能够完成。

其实一个优秀的PM如果能具有SE的能力，这才是我们真正要求的PM，但是，由于现实要求问题，我们的PM无法对技术等深刻掌握，所以，我们才硬生生的把一个PM本来的角色分成了现在的PM和SE两个角色。我们希望项目的管理技术方面问题由SE来完成，而项目管理的其他方面问题由PM来完成，这样，PM和SE可能形成两种关系，一种是从属关系，一种是并列关系。从属关系的状态下，SE把技术方面的信息等问题反馈给PM，PM根据这些信息然后制定相应的措施，然后下达给项目完成。并列关系，PM和SE明确分工，技术问题方面信息获得、方案制定和措施指令下达全部由SE完成，而PM则是完成技术以外的相应项目管理工作。第一个方式，对PM要求较高，而第二种方式，PM会变成一个比较尴尬的角色，因为项目开发的主要任务可能是技术相关，这样会导致PM对于项目无所作为。

PM的考核问题比较复杂，我们也应该从PM的对于项目的作用出发去讨论好的PM会怎么样，而差的PM会怎么样。第一，一个优秀的PM，能够制定一个合理的Schedule，或者因为某些异常情况，修改Schedule也是非常合理的，第二，一个优秀的PM，作为项目的信息中枢，能够及时掌握项目当前状态和各种必要信息，并且能够对这些信息进行归纳分析，预测可能出现的问题。第三，优秀的PM，能够根据自己分析的异常情况，分析制定对应策略，或者请求专业部门经理支持，防止异常时间的处理。第四，优秀的PM在异常情况发生的时候，能够根据当前局势，制定合理的策略，处理紧急情况，是项目走入正常轨道。第五，好的PM具有良好的沟通能力，能够把自己下达的指令清晰传递给项目组成员，而且，能够鼓励项目组成员完成相应的任务，同时，在项目需要的时候，能够清晰的把项目到状况和困难传递给公司管理处，能够从公司管理层获得资源等方面的支持。

相反，我们可以看出一个差的PM可能会在那些方面做得不到位了。第一，差的PM无法制定一个合理的进度计划，而且不能够把这个这个进度计划有效的传达给项目组成员，让项目组成员清楚自己的任务。同样，当项目进行出现异常时，修改项目进度不能达到最优化，使得很多任务不能够使用最小的人力物力最快的完成。第二，一个差的PM，对于项目组的各种信息无法正确和全面的获得，或者是获得一些表面信息之后，无法看出其背后的更多信息量是什么，又或者是无法从这些信息，分析出可能发生的状况。第三和第四，一个差的PM，面对异常发生的时候，束手无策了，无法制定出相应的应急方案，，第五，一个差的PM，无法团结项目，无法把自己的指令下达到项目成员，无法让项目组成员执行，或者无法从公司得到有效的资源支持。

上面，我只对好的PM和差的PM做一个定性的对比分析，实际的考核方法，需要专业手段和更深入的设计分析等工作。

前面我们定义，PM的主要功能就是汇总项目的各个部分信息，分析项目目前状况和可能存在的问题，然后制定或修改和发布项目任务包。PM所需要做的工作就是提供准确的进度信息，当某一任务包可能会出现问题的时候，PM需要向相应的资源部门汇报该状态，且请求该资源部门给与帮助。当然，如果任务包的Delay已经既成为事实了，那么PM所起到的作用就是向人力部门准确反映该进度延迟原因，也就是说PM是参与考核的，其参与考核的作为就是提供分析数据给人力部门，但是PM不参与直接对于项目组工程师的绩效打分。

项目日常最一般的工作，就是一些项目任务包执行，例如，涉及原理图，PCB画板，执行EVT，Review Bug，Review进度，项目组需要出差申请车辆等等。

原理图设计和PCB画板都专业性工作一定是专业的项目组成员完成，组织专业会议，我觉得最好是SE组织，另外，PM也必须参见，这里是PM得到技术信息最好的方式，当然，如果PM和SE的关系分工较好，可以技术性问题全部放给SE来做，而PM从SE处得到技术方面的信息。但是，PM最好是自己能够具有一定的技术敏感性，能够准确的得知项目的技术状态，把握项目技术信息，这样的会议，可以由PM组织，这样便于PM更准确地把握技术信息。项目组出差申请车辆的问题，我个人认为，不应该是项目PM申请，最好是研发的部门秘书或者文员做比较好，当然，对于资源有限的公司，完全可以由工程师自己申请，PM申请也没有什么不可以的，如果PM有空闲也可以由PM申请，为什么这样讲呢，因为PM根据自己的计划安排，需要机构工程师去试模，当然申请车子等等，不应该PM再提供的东西，而是资源部门提供的东西。

首先，PM的定位多种方式，我们在这里重点讨论哪一种方式适合我们公司的问题。例如，ＩＢＭ的方式，ＩＢＭ的ＰＭ项目经理其实是产品经理，都是好几十年工作经验的老工程师担任，对于市场技术等有深厚的功底和敏感性。这种方式当然不适合我们的情况。

目前我们公司有很多中对于ＰＭ的观点，我从人直觉上是错误的。例如，要求ＰＭ推动各个项目组工程师，我觉得这种观点不是完全正确，这样会形成保姆式管理。要求ＰＭ管理项目要细节化，细到不能再细为止，我认为这种观点不对，这样只会增加系统的混乱性，而不会增加系统的高效性。我认为应该明确各个角色的权责，各司其职，提倡本位主意。

从２００５年我带ＰＭ部门以来，我一直忙于琐碎的项目中间，虽然也买过很多项目管理方面的书籍，但是一直没有花时间去认真学习和笑话吸收，特别是很多高校的项目管理书，都是千篇一律，形式化特别严重，无非是前掉ＰＭ的进度事件管理，资源管理，风险管理等方面。我觉得这些书不是特别符合我的需求，下面我以自己这么多年很多角色工作过的经历，来认真分析ＰＭ这个角色，到底该做那些事情，其权利责任是什么？

首先我建立一个ＰＭ的工作模型，如果大家都能认可我这个模型，我们讲基于这个模型进一步深入讨论ＰＭ的各个角色功能。

 

信息收集分析/决定决策和指令

获取信息

获取信息

发布指令

发布指令

制定或修改进度

对比进度

汇报项目进度请求支持

给与资源支持

 

 

 

信息收集分析/决定决策和指令

获取信息

获取信息

发布指令

发布指令

制定或修改进度

对比进度

汇报项目进度请求支持

给与资源支持

按照我的模型，项目管理的作用就是从项目和外协开发的供应商处获取项目状态信息或者项目需求信息，然后对比项目进度，综合分析，制定或修改进度，和向项目成员发布执行任务保命令，或者调整执行指令。另外，当项目需要的时候，需要向公司管理层汇报进度，和请求资源等支持。

如果按照该功能定义，那么项目管理的主要功能包含如下几个方面：

1，  信息中枢，也就是项目管理者需要几个跟踪项目进行状态或者需求。

2，  分析中心，项目组的信息来源很多，很多信息复杂，需要项目管理者从这些复杂信息理出头绪，找出正确和有用的信息。

3，  制定进度和修改进度

4，  从目前项目状态，对比已经制定的进度计划，分析可能潜在的问题。

5，  向公司管理层汇报项目进度等信息，必要的时候，请求支援。

6，  项目根据进度等各个方面的信息，制定项目组个成员的下一步工作任务，发布执行指令。

 

PM管理工作到底应该有多细？个人认为，把握尺度有两个原则，第一，就是保证任务包的专业性，也就是某一个专业可完成的尺度。当然，如果一个人工作包事件跨度过大，可以适当介入，但是，这样也会有弊端，就是导致专业人士的反感。

后面，根据这个模型，我们将进一步深入讨论如下几个议题：

1，项目组的日常工作与PM的工作

2，PM与SE的分工与协作

3，PM与绩效管理之间关系

这些主题在以后的日志中将逐步讨论和分析。

从2005年，我接受PM以来，我一直有一个非常深刻的感受，就是公司项目管理等，需要保姆式的管理，任何一个环节，或者提醒的疏漏，可能就会导致重点问题发生，或者至少Delay，以前，我们一直把这个问题归为员工的工作方法和态度问题，现在看来，这样的问题是一个普遍现象，不能单单而归于员工的工作方法和态度问题。

先举一个例子，昨天s42p同方外观上线50台，发现外观有问题，需要机构紧急解决这个问题，于是我这边决定几个机构工程师昨天晚上连夜也要分析找到原因和解决方法，于今天早晨7：00出发，确保八点钟之前到工厂，赶上s42p的上线。这个里面有好几点，就的明确说明，如果一步不到位，可能就会出问题，第一，机构几个人，必须在这里加班，直到找到方案为止，第二，PM必须申请车，第三，必须告诉司机7：00出发，第四，必须让司机和各个工程师一起交流，决定行车路线，因为司机要去接每个人，第五，我必须让白煜实时跟踪解决方案，确保方案有效性，同时不要带出新的问题。当然，再次强调，这里分析问题，是为了查找原因，而不是为了追求工程师的问题。而这次C面变形的问题，也是在50台小批量上线的时候，我拍工程师紧急跟线，才发现而紧急解决的，如果不跟线那么可能由此又酿成大的问题。

同样光盘的问题也是这样，虽然我再三提醒了，但是我们没有深入去问，结果就是出了问题。

 

为了会出这样的问题，很多人慢慢认识到这是一个流程的问题，问题出现是我们没有流程，或者有了流程没有按照流程去走，我觉得这样的认识比说工程师的问题又进了一步。但是，我觉得还是不够，因为，我们也梳理流程这么多次，这么多年，怎么就是没有根本改变呢？

 

我觉得这个问题出现的最根本问题在于，我们公司规划的问题，也就是公司没有大的方向而导致问题，没有宏观规划，导致每一个案子，每一件事情都是临时想起来的，一个项目刚刚立项，恨不得明天去买，这样，不靠流程去做事情，当然就得靠人来完成了。

还有一天新员工特别的多，很多人对公司的做事方式方法根本不了解，当然，就搞不定很多事情，这样，就会老的优秀员工更忙，挨骂的机会更多，走的机会也更大。

而且，紧急的事情太多了，掩盖了我们正常的事情，结果导致正常的很多流程都忘了该怎么走，就像这次s42p和s42g的问题，没有经过PVT就生产，多么可怕。最后做的，好像不正常的流程被当作正常流程来要求大家，结果全部都乱了套了。

 

 

 

还在我懵懵懂懂时
只想着童话般的诗
管它未来生命中将会面临的事
为了明天我情愿
情愿跟着你往前飞
飞到未来飞到一样的梦里
其实我根本没有看仔细
对感情一点也没有看清
只是从来不曾怀疑而来到这里
早已给你我全部的心
难道不能够把一切证明
你真的明白何谓真心
也许你并不是我唯一的伴侣啊
虽然曾经最需要你给我鼓励
相信你对我付出的是真心真意
我不会我不曾更不可能忘记
希望你别再把我紧握在你的手里啊
我多么渴望自由自在地呼吸
你知道这里的天空是如此美丽
就让我自己作些决定

昨天晚上，从工厂回来，韩总开车，走梅林关进关，然后韩总走南平快速，然后在福龙路，哪里转到了香蜜湖路。当时，我一下子糊涂了，非常迷茫，这到了哪里？怎么一下子就到公司了。自从福龙路开通以来，我一直没有走南平快速了，所以，没有从南平转福龙的概念，我还是以前老的关键，是走南平，然后到西丽哪里，走一段广深高速，然后到公司。

今天下午，我自己开车送XWD李总的时候，我过福龙路隧道的时候，忽然豁然开朗，原来，昨天晚上是从这里下的南平快速。

很多坐车的人在城市里绕行的时候，都有这样的感受，就是经过几个立交桥，或者是几个拐弯之后，马上就迷失方向了，到了地方之后，下了车，才忽然有感受，哦，原来到了这个地方？你是怎么绕过来的？我经常问坐在我旁边的人，你知道到了哪里吗？对方迷惑的摇摇头，不知道，有些人会说，哎，我的路感不好。

其实，这不是一个路感的问题，这是一个心有成竹，和大局观的问题，因为车子的行车路线是开车的人规划的，到了那个地方该怎么走都是他自己规划的，他当然知道怎么走了，当然知道到了那里了。同样，如果，你事先告诉旁边的乘客，我讲如何如何走，那么，熟悉路的乘客也不会迷茫。

人生也是这样的，我们人生为什么会迷茫呢？是因为很多时候，我们的人生不是走我们自己规划的路，或者，我们自己根本就是没有规划，我们有时候，不得已被带到这里，来到这个地方，干着这份工作，当然会迷茫了。

呵呵，怎样才能掌握人生的主动权，而不迷茫呢？那么就是规划自己的人生，让自己的人生按照自己的轨迹而运行，这样人生才不会迷茫。