俗话说项目不止，问题不止。产品就是用来解决问题的，那么在项目过程中都会遇到哪些问题呢，写下来记录那些套路。也希望跟大家交流一下，大家都是怎么解决的。
1.项目初期---产品（战略层）规划，需求收集阶段
在产品初期一般会经历需求搜集阶段，那么需求的来源都在哪里呢。需求的来源有领导层提出的，业务部门，运营部，客服部反馈的用户意见等等，及公司内外部人员提出的需求。自己通过数据分析需要调整的，产品业务层调整基础框架调整，产品重构等等都是需求来源。那么在这个过程中都会面临需多问题。首先领导层提出的需求。领导层的需求往往有两个方向。一个是大方向的做什么什么功能或者说做一个什么什么样的平台。一个方向就是交互层层面的流程不顺，颜色不好，按钮位置不好啊，什么的。我们内部趣称叫“微调需求”哈哈哈。对于与我来说一般大方向的调整都会遵从领导的。因为领导层最了解行业前沿。即使领导错误的决定额要跟随。因为我们也要有试错的。不断的去尝试这个市场。对于另外一个方向的我一般是回去默默搜集数据分析哪些可以分版本逐步迭代改进。其次业务部门提出的需求他们永远站在自己的角度，要么就是自己也说不准，看市场别人家是啥咱也要啥。弄不清楚这个是否适合自己公司目前发展的现状，而且来恨不得今天给你说的这个功能恨不得明天就能用了。你说你做为一个产品统筹协调呢，你说你怎么办，怎么办。那么你自己要有一个大局掌控和判断的能力啊。自己要有一个判断哪些可以做哪些不可以做。运营部，客服部等等一些其他需求。自己要根据公司的战略需求，项目需求，产品需求区分项目等级呢。在扯一下一般项目分5级，够用了。
2.产品设计阶段---原型设计，业务流程图设计
设计阶段产品出需求原型和业务，产品流程图这个过程是一个反复沟通，确认，调整的过程。这个过程中会出现争议。这个功能不是我想要的，这里不对，不应该这样做了，都是问题。这时候就是你要有足够的产品经验，要有大量的同类产品思维，看过市场上同类产品的做法。比如说业务想要这种功能但是做起来不叫复杂，比较难做。那怎么办，是不是有另外一种做法呢。拿实际例子来讲，我们的客户回访系统想要几天回访一个客户想在过两三天后再次对该客户进行回访想要自动提示，经过自己分析看市场上的客户管理系统其实要一个回访计划列表的功能也可以解决的。
3.需求原型基本都能确定了下面就是---视觉稿交互层面的设计了
在这个阶段跟设计师会有一些意见和做法看法的争论，如果有条件允许的情况可以做用户调研和A/B测试。如果有数据支撑可以按照数据结果来做。其实我个人对设计层面和交互层面的东西一直是你说你说你有理，婆说婆有理的。最好是做一些听取用户的看法。
4.高保真原型产出以后就是开发阶段了
在此阶段你要有PRD文档和高保真原型座位产出物与开发来进行沟通讲解需求。在这个阶段开发需要评估这些需求采取什么样的技术框架和技术语音。会遇到这功能做不了啊，比较难做啊，实现起来时间长啊怎么办，怎么办。那作为产品需要你来推动来把产品做出来呀。首先自己也多少了解一些技术知识点，在需求评审会议之前自己先审视一下，功能逻辑师傅合理，是否是真的需要改功能，在需求评审会议的时候，大家在看你的业务流程图，产品框架图，需求原型的时候，讲解需求的时候多用第三方的口吻叙述，学会讲故事。千万不要说我觉得这个功能很简单的，少有个人主观意识。多用数据支撑和用户意见，领导需求。有些开发出身的产品经理很容易犯这样的错误。You can you do IT对吧。
5.项目测试阶段---专业测试人员测试，全员测试
产品在测试阶段同样也会遇到一些问题，有时候会遇到测试阶段的需求变更，这是最头疼的事儿，同样在开发过程中也会遇到，尤其在开发过程中遇到的需求变更这些需求要一分为二的对待，看那些需求是在开发进度允许的情况下可以添加进去的，那些大的改变是不能加进去的，可否在下次迭代的时候添加进去。那这个时候就要好好审视一下前期的需求调研，用户调研，视觉设计，交互有没有做用户调研，在调研过程中出现了差错。说明前期的方向就是错误的。一般到测试阶段不要在添加大的需求进来否则项目会处在一个无休止的修改的状态，不如早点上线验证需求，在做进一步的迭代和改进。
在此阶段还会遇到一些问题比如做出来的效果与实际需求不符怎么办，气死你。在项目过程中注意节点把控和节点质量评估验收。避免进入到下一个环节项目处于一个失控的状态，否侧项目又处于一个不止何时才能上线的尴尬。
6.项目上线后---产品已进入用户使用阶段
有些产品前期不做用户需求调研，做出来的产品有些用户会反馈流程路径不太对了，bug，等等注意收集用户的反馈，数据指标的反馈。有些产品功能也加了，用户的使用率不高，不能对用户进行更有的促活。那么我们就要反思是不是入口太深了，用户不容易发现。还是设置的门槛过高。要及时调整。
写在最后项目不止问题不止，作为产品的负责人你要面临各种各样的问题，十八般武艺样样都得懂一点儿。要善于协调和沟通。多占在客观的角度去看待问题和描述问题。没有解决不了的问题，促膝而谈，摊开了说，别都事儿事儿的。都是为了工作。都是一个锅里的粥，出了事儿都得单着。只不过作为产品你是只是个代表，出了事儿你背着，有了荣耀那是团队的。不是你一个人的。在产品项目开发的过程中会面临各种各样的问题。只有把各种问题想在前面，说道这里又要扯到项目开发过程中的风险点管理了。这个这次不说了。有问题咱解决问题就。其他别扯。
