微波信号BLOG

因为我的前任领导离职，所以新换了一位boss。我们几个手下也和他在工作习惯上互相磨合中。我到现在为止的遇到每一个直接领导，都有非常擅长的一面。比如现在这位boss在项目控制和团队沟通上，明显有很独特的的心得体验。最近开会，他总向我们灌输一个理念，即要加强产品经理的输出能力，及时将自己的工作内容抄送给团队成员，增加团队内部信息的流畅度与对称性，不要让信息流通不畅成为团队的瓶颈。

具体的病症就是，他认为我们的工作习惯仍然不够良好，缺少与周围人的沟通（此处指信息沟通习惯而非针对某件事的沟通能力），尤其是团队成员不够了解我们的工作状态和工作进度。作为团队工作的源点，很可能因为产品经理一个人的问题而导致团队工作的拖沓。

在这之前的工作中，产品经理需要沟通最多的就是技术团队。一般整个团队都坐在一起，很多问题在RTX一喊或者站起身来就能和其他人讨论，很快就能有了新的结论和方案，这样大家都按照讨论结果继续执行，每个人接收到的都是最新的信息。团队小的时候，沟通是件很简单的事情。

现在我们在做的这款产品比较庞大，团队人数也比较多。产品经理小组就有四个人，还有技术经理，项目经理，视觉设计师，网页设计师，网页开发，客户端开发和服务器开发，而且作为一款消费型产品，还有一批编辑和运营的同事。产品经理经常需要和不同的成员针对不同的问题进行沟通，而且因为每个产品经理负责一些模块，所以经常不知道其他人在忙什么。经常发生的事情就是产品经理针对某个需求进行了细化或者针对bug进行了说明，或者是产品小组内部进行了方案更新，设计优化，如果不能及时周知到团队其他成员，很可能发生信息不对称，沟通脱节，造成重复工作，浪费资源。

产品经理作为团队的工作源点，几乎所有其他人的工作安排都是围绕产品经理的需求文档来进行的。产品经理还负责沟通各种资源的责任，同时又掌握信息最多的一个人，因此产品经理的工作也是变化最多的一个节点。往往一个变化会影响到后面很多人的工作内容与工作规划。虽然我们极力反对变更需求，但是不确定的事情总是很多，变化几乎是不可避免的。关键问题在于，出现变化后要及时将信息传播到团队每一个人身上，让每个人都时刻保持最新的信息而不是过时的信息，最大限度的减少因为改变带来的损失。

前边说了一大堆的八股文，简单来讲就是要优化工作习惯，做到以下几点：

1.尽量减少需求变更的发生。

2.尽量及早周知团队成员工作的变化。

3.尽量保持团队成员信息的同步，不会出现有人脱节的情况。

4.尽量让团队成员知道自己的工作内容，方便别人安排规划工作安排。

5.每天输出一封工作邮件，抄送团队成员。

（本文图片均来源自liferay）

写成文字不困难，困难的是要养成一个新习惯并且坚持下去。既然已经选择了做产品经理，那么就得按照高的标准要求自己。不能一方面要求平级管理无授权领导，另一方面又经常拖团队后腿，这样的产品经理，显然很难开展工作，妄谈创造优秀的产品了。

前一段时间太忙了，又进入了两个项目一起狂奔的阶段，还有个小三项目要隔三差五的做点小需求更新一下，刷下存在感。三个项目纠缠在一起导致我的时间管理上又出了问题。项目自身有优先级，每个项目内的各项工作也分轻重缓急，虽然每个人都知道先从最重要的事情做起，但不是每个任务头上都明确写着它是一个重要且紧急的，而它是个重要不紧急的。各种事情压在一起还得自己划分一下级别和先后顺序 ，而事情太多了之后，分着分着就乱了。

焦头烂额的忙于应付一件又一件的事情，可是自己也明白这种工作状态还是太盲目了，很可能的结果就是忙了很多事情最后总结时候发现什么都忘了，好像什么都没有做。恰巧某天和一个同行聊天，提到了自己混乱的状态，然后他给我一个提醒说“事情太多的时候，就跳出来看一下，你要干什么以及有啥问题要解决，你的目标就是要把任务完成。把事情打包捋顺搞明白然后在做，一猛子扎进去你就看不见全貌了”。回来以后考虑许久，然后自己实行了一段时间，发现效果不错。

即首先树立一种意识，产品经理是种解决方案，他的任务就是想办法完成产品的目标，通俗的讲就是完成KPI。所有的工作都是为了这一个目标去努力的，中间的所有工作只是一个实现的过程而已。“任务是什么？如何实现？遇到的问题有哪些？如何解决遇到的问题？”将自己手上的任务划分成四个问题，然后针对每一个问题去解决，这样容易从更高的角度来看待工作，而不会陷入到“只见树木不见森林”的境况。

举个简单例子，本季度公司要求将旗下的浏览器推广至市场占有率的第三名，要求紧跟360浏览器和搜狗浏览器的步伐。

然后我们分解任务：

1.任务是什么？

提高浏览器产品市场占有率，量化考核就是至少做到日均覆盖2000w用户。

2.如何实现？

一方面需要运营方面增大推广力度，增加软件换量合作；另一方面要提高产品性能与品质，这是实现目标的基础。

3.遇到哪些问题？

3.1软件换量需要投入资源（需要运营推广费用）

3.2现有开发团队力量不足（需要补充足够的技术力量以及需要足够优秀的设计师支持）

4.问题如何解决？

4.1需要自家软件与对方产品互相推荐，换取足够的安装量。todo：需要与其他产品协调推广问题。

4.2部分重要渠道可以采用付费推广方案。todo：需要向公司争取推广经费，同时需要同事帮忙推进合作事宜。

4.3列取本季度需要完成功能模块，作出技术评估与时间预期。todo：督促技术经理确认实现难度以及资源的调度。

4.4产品需要新版本推广，优化现有的界面与交互行为。todo：争取资深设计师加入，确认新版本产品的风格与交互。

简单来讲，一个大任务已经被分割成多方面的小任务，各方面都已经进行了初步分解。然后按照此方法，将小任务继续不断细化，直到目标变成一个交互稿，一个确定的结论或者一个可交付的需求文档。然后将所有任务按照组织结构做好脑图，这样每个任务的优先级和每个任务的完成度就有了很好的掌控。时常找出结构图看看自己目前忙碌的工作是哪个级别，其他分支的完成度如何。每个阶段都做好了心中有数，这样对着这个树形图忙碌起来也知道自己的进度如何，同时知晓其他同事的工作进度。

而且这样做的另外一个好处就是每天的工作是完成一个个的任务，需要自己主导，或者周知或者参与的各项任务。不会陷入到每天的todo都是要找xxx人去沟通，去协商。自己的工作就变成以任务主导而不是以人物主导。（虽然很多时候产品经理的任务就是找人沟通，但是明确的任务更容易让人清楚目的是什么而且沟通过程不容易出现走偏，事后也容易记录汇总）

所以产品经理的工作就是提出一套能够实现的解决方案，然后将方案不断细化至每一个执行的个人或团队，保证项目周期中各方面的沟通流畅与信息对称，解决遇到的问题，直至最终达成目标。

这样以更高的角度来看待问题，执行工作，就不会出现工作盲目，疲于应付的境况。而且对项目的各种进度有了足够的了解和掌控，也会大大提高产品的存活率和成功率。

最近有新人入职，我负责带一个实习生，回忆了一下自己刚做产品经理之时，现在也能体会到一个新人进入这个行业初的兴奋与迷茫。准备写篇小文总结一下，顺便理理思路，记录一下。

这次想说的的是如何验收产品。网上讲如何做产品的文章很多，前期调研，中期开发，后期测试，上线完工。有时候在和别人沟通中发现，有人把产品文档输出给开发工程师就当作一个节点，因为狭义上来讲，产品经理的任务已经完成了。他们只需等待开发写完代码，测试批准通过就可以上线了。其实这是非常不够的。作为一个产品经理，一定要把产品从头跟到尾，每一个步骤都不能偷懒，否则很可能工作就会出现纰漏。

即使测试同事很认真的走完了固定流程，产品经理还是要自己很认真的把产品过一遍。如果你心理没底，不知道该过哪些内容，那么最简单的方法就是：把产品所有的地方都点一遍。这是最慢也是最有效的方法，同时也是很少有人去采用的方法。因为软件工程的特殊性，彼此之间关联很紧密，有些时候根本不知道哪里就会突然出现问题。只有把整个软件点一遍，心中才有底。

我刚开始实习的时候，老大传我一个公司旗舰软件的第一个测试版，说你来看看有啥问题，帮忙找找bug。我就兴奋的打开软件，然后走走常用流程，一切正常，然后看看有没有崩溃，一切正常。啥问题都没发现，我就交差了。然后他就在我面前随便点了几下，软件就直接弹窗报错了。我当时很惊奇，他怎么这么厉害，一下子就发现问题了。其实后来得知，他已经把这个版本前前后后点了好几遍了，很多问题都烂记于心了，知道哪里有问题，哪里容易出现问题，哪些操作会触犯问题。而我只是把自己当个普通用户，走个正常流程就就交工了，那时候还完全是个外行，不知道怎么验收。

现在我还在跟这个软件打交道，这个已经良好运行一年而且迭代了十几个版本的软件，即使现在都是final版了，我都还能轻松发现很多问题。而我学习产品验收的方法就是不断点击，一遍又一遍的点，当把所有的环节都走完了，还是正常，那么这个软件才符合发布标准。

因为我一直做客户端产品，所以说一些客户端产品验收经常遇到的问题：

1.崩溃。这种事情可遇不可求，有时候别人崩了你好好的，有时候你死机了别人还流畅的很，不要放过任何一个问题，不要被“这是一个个例”这样的理由搪塞。出现崩溃就一定要解决掉，因为这一定某个潜在的bug引起的。如果产品大规模发出去之后，即使只是1%的崩溃率，乘以总用户数以后，也是个很大的数字，会影响到非常多的用户，而且引发大规模的反馈和批评，处理崩溃一定不能放松。

2.功能问题。虽然有需求文档，虽然有设计原稿，但最终的产品未必真的如想象的那样。必须承认很多细节是产品经理在撰写文档设计原型时候无法考虑周全的，只有开发同事真真切切的落实为代码的时候，才能发现这些问题。如果与他们及时沟通，那么产品经理需要抉择拍板并更新文档。但很多时候开发同事就是按照自己的意愿和想法决定了一个功能，一个交互。产品的实现就打了折扣，最悲剧的是产品经理还不知道这个变动，一直喜洋洋的觉得产品的实现很完美呢。

3.UI问题。原则上所有与UI相关的事情都由设计师把关。他们负责出原稿，切图，协助贴图以及检查整体UI问题。但是，产品经理，你们肯定懂得，设计师是如此珍贵的资源，人家答应及时给你设计，你就得感动的痛苦流涕了；如果有恰巧他还帮你切了图并且协助贴了图，你还有啥追求？检查贴图的问题必须自己动手。大部分时候工程师并不那么在乎代码里面的RGB是否与设计图一致，九宫图是否贴的严丝合缝，png是否有偏移和压缩。调整客户端软件的UI和贴图是如此无聊而且没有技术含量的一件事，我见识的所有工程师都深恶痛绝这个任务，所以都能想象的到，里面隐藏了多少问题。这些问题只有产品经理自己去跟进去发现去解决，不要指望设计师了。产品是你的，荣耀是你的，问题也是你的。

4.其他问题。还有一些其他可能要注意的问题：是否为日志版，是否已经签名，是否通过杀毒软件测试，是否通过360管家测试，是否兼容各大系统，是否与其他软件冲突，内置链接是否正确，等等。

5.网站的问题。这里主要是我碰到过的案例：比如有时候去某个新上线的网站，发现浏览器兼容做的不好，打开网页后界面布局错乱甚至乱码的；主页上面赤裸裸的显示找到图片的红叉的；页面某个链接打开是错误的；某些按钮点了都没有反应的；有些区块文字超长未做处理而产生元素重叠等等。

产品发出去，就不能更改了。出现任何问题都只能等待新一个版本覆盖去解决。但是用户不会有这样的耐心，一次崩溃或者一次软件无法运行可能就导致用户直接放弃尝试，结果就是彻底失去一个用户，他们就再也不会给你机会了。即使可以通过应急补丁方式修复问题，但这是一件成本非常高的事情。既然如此，那就一定要在发布前认真验收，千万不可简单兑付，潦草行事，以免后悔莫及。