做产品的这几年来大大小小遇到的问题不计其数，大到整个产品的方向，小到一个图标的像素与颜色值，今天我就来说说我这几年来所中过的枪，所踩过的翔。下面所说的问题如果你也中过，踩过那就与君共勉，没中没踩者请做好防弹准备。

一、无从下手问题

我接下来该怎么做，这是我在产品群里面听到的与我刚开始做产品时遇到的一个问题，而遇到这个问题的产品汪们一般有一个共同的特点就是，入行不久的野蛮生长型产品汪。野蛮生长型产品汪是之前一个同行定义的，我觉得野蛮生长这几个字形容的很贴切，野蛮生长型产品汪有这些特点，没有经验、没人指导产品工作、大多数奋斗在创业公司，而且还是挑大梁的，对产品知识的强烈渴望。在这个APP泛滥的年代，这类产品人员会越来越多。

对于一个没任何经验，也没人指导，还要去做决策与把控一个产品的人来说，有一种凌乱和无力感。有这种感觉的原因是因为所做的决策没有足够经验或者足够产品知识去支撑。也就是说没底气。而现在书上说的东西看了会觉得很虚，不实用。前段时间我的一个朋友刚入行做产品没多久，公司交给了他一个项目，他要我推荐一些书给他看，我就把我刚入行所看的书推荐给他，他说这些用户研究，用户体验，信息架构什么的讲的太虚了，不实际。看了还是不知道怎么做，问我有没有像工具书那样，教你第一步怎么做，第二步怎么做的书，现在是有很多这种方法论方面的书籍，但这些书对于没有任何项目经验的人来说看了，只知其表，不明其理啊，会造成天天用户体验什么的这些专业名词挂在嘴边。

第一个问题，感觉产品知识很虚，虚的原因归根结底还是没有经历一个从0到1的完整的产品流程，只有经历了，书上所讲的知识才会引起你的内心共鸣，没有经历过的脑袋当中很难有这些概念或者说这些概念不强。

第二个问题，很迫切的想要知道接下来该怎么做，产品知识比较广而杂，遇到问题后很难从杂乱的知识储备当中拟定有底气的解决方案，光凭自己看书或在网上看文章博客获取知识很难吧这些知识串联起来，形成一个自己的产品知识体系。所以前期要做的是把所获取到的知识归纳整理，形成自己的产品知识链条，再次获取到新的知识的时候。把这部分的知识对号入座的归纳到你的知识链条下并加以分析与理解，当你的产品知识达到一定的储备量的时候，你再遇到问题的时候你的思路就比较清晰了、不会像之前那样漫无目的毫无头绪的瞎抓 。这里推荐用思维导图的方法去整理知识，好处谁用谁知道。

二、团队配合问题

当时在小公司小团队时这个问题不显著或者说不严重，后来到大团队时我发现这个问题就比较严重了，主要的就是，各自做各自的，不相配合，有两个方面。

第一个，产品团队内部工作流程混乱，不管是小型项目也好，大型项目也罢，多多少少会出现以下的一些情况，没有产品规划，团队成员不知道为什么要做这个产品，也不知道下一阶段要实现那些功能，产品的目标用户群是谁也不知道，或者对目标用户群比较模糊，需求评估，优先级定义，等这些需求分析必须要做的工作没有按照需求分析的流程走，当然，苦逼的产品经理有时候会身不由己，大家都懂得。产品成员各自有分工，各自会负责一些功能模块或者独立的产品，没有考虑到功能模块之间的耦合度和关联关系，都只负责自己的事，没有站在全局的角度去思考问题，有关联的模块事先也没沟通好，导致的后果就是改需求，严重的会导致产品出问题。在写产品文档的时候，一些很重要的功能没有与开发商量，自己理所当然的就往下写了，结果在开发过程中需求频频出现问题。

第二个，产品团队与其他团队配合的工作流程混乱，产品团队与，开发团队，运营团队之间配合出现问题，主要的点有这些，1，开发按照自己的想法进行开发，产品也没有及时去评审开发结果，直到上线时才发现开发出来的东西与自己想要的差得太远 。2.因为产品团队事先没提运营方面的需求或者双方沟通的不够，上线后，运营团队准备不足，导致发布后效果不佳等问题。总结发现，很大一部分问题是因为团队之间沟通不够与协作不畅导致的。目前国内外有一些不错的团队协作工具，如trello、effevo等，可以利用这些工具把各个团队链接起来，其中effevo中很赞的是缺陷管理功能很灵活，字段与流程都可以自定义，适用性很强。这样测试、产品、开发等团队把任务、计划等都记录在这个上面可以很好的提高效率，辅助沟通，帮助记录，从而避免因沟通与协作不够而出现的问题，例如：开发把任务写在上面，这时就很清楚的知道每个需求完成的时间点，从而对每个需求进行跟踪检查，这样就可以很好的保证产品质量。

三、沟通问题

主要遇到的沟通问题是，信息不同步，信息传达不准确，偏重口头沟通。

信息不同步

主要是有的成员知道，有的成员不知道，有可能出现的问题就是不知道的成员做的一些工作有可能白费了。最近就遇一个比较典型的问题，在开发过程中，因为时间原因开发计划有小变动，而这个变动没通知到测试（自以为测试知道了），庆幸的是没造成工作白费。

信息传达不准确

主要是对信息理解的偏差，按照自己的理解和想法去执行，也没有与信息发布者进行反复确认，从而导致工作返工，造成资源浪费。

偏重口头沟通

经常遇到的就是有些需求没写到需求文档中去，或者是漏掉的，在开发过程中就口头与开发讲解，有些逻辑复杂的需求，在口头讲解的现场是无法想得很全面的，也没有及时更新到需求文档上面去，会造成需求实现有偏差或者隔了几天都忘了这事了。解决这个问题的方法就是永远不要“我以为”加沟通、沟通、沟通重要的事情说三遍。

四、需求变更频繁问题

需求变更频繁问题在团队中是一种司空见惯的现象了，貌似到了变更是正常的，不变更就不正常了的一种境界了。变更可以原谅，但不要频繁。

变更的原因可能是因为外部或者内部的原因。外部原因是指公司环境，市场环境，老板的决定等原因，这些原因可能是无法抗拒的，但内部原因是可以避免，如：尽量避免自己的逻辑不清晰，加强对文档质量的把控，不清晰或者不确定的地方多与团队成员沟通，不要抱有到时候再说的想法等。

以上是对自己刚入行所遇到一些问题的归纳与反思，希望对你们都有帮助。

本文系作者@杰森森 投稿发布，未经许可，不得转载。