需求部分永远是一个项目的key，如果前期需求做不好，走错路、会错意，那么后面所有的程序都是白搭，因为你连客户爸爸的需求都没理解清楚，其他都是无用之功。
原型图远比文字能更好、更直观的表达自己的想法，所以原型设计是一个梳理功能、再次确认需求的重要阶段。因为本人是个典型的处女座女生，所以在工作中喜欢做到尽善尽美，宁愿多加班也要尽可能的做出高保真的原型，目的是为了更好的将我们的产品设计、产品交互以及功能梳理给客户做详细的展示与讲解。
在原型设计阶段，我会根据不同的用户群体做不同的交互设计，例如：我负责的第一个项目，他们的使用群体包括两类，一类是B端用户（政府的工作人员，年龄在30-45岁），另外一类是C端用户。针对这种用户，他们不擅长操作电脑或使用软件，我尽可能的会将交互做到最简单，同样在字体字号上面会做个备注，让美工尽量做得尽量大点（当然，这只是一个建议）。
作为一个年轻的产品经理，经验不足是真的，但有一点是我的长处，那就是从不吝啬多跑几次客户那，和客户当面确认需求，和客户多沟通、多交流。因为原型图相对于文字能直观的表达自己的想法与设计，所以每当我做完原型设计后，都会到客户那做原型讲解，我会尽可能的将自己的想法全部表达出来。
当自己的设计与客户的需求有出入时，做好标记，如果出入比较小，我一般都是当时改好，现场给客户确认。如果出入比较大，我会重新梳理，再次提供新的设计方案给客户进行确认。当然，因为自己本身是技术出身，大学期间也是学的技术，所以设计的方案大部分都是在技术上确认可行的，一旦拿不准主意，就会向技术人员请教，确保设计的可行性，避免天马行空的设计。
因为自己在需求确认阶段及其重视，所以在担任产品经理阶段，经常会和客户保持电话、微信联系，都成了客户的老熟人了。
作为一个这种特殊性质的外包公司的产品经理，PRD文档对自己而言，简直是救命的稻草，它不仅是和技术等人撕逼的证据，同时在这种小公司，也是可以避免背锅的证据。所以在写PRD文档时，我会将客户认为重要的点表达清楚，避免后面因为自己没有表达完整，然后锅从天上来。
和客户确认好需求后，我会召开一次全面的需求评审会议，把美工、技术、测试等人全部叫齐，将需求和设计对接给例会人员。在会议之前，我会将原型、功能清单、PRD需求文档等提前发给例会人员，让他们提前了解项目，以至于更好的在会议上提出他们的问题，我一一做解答，提升会议的效率。
需求评审会议结束后，项目进入UI界面设计、代码实现阶段。
UI界面设计：美工设计好的界面，我会发给客户确认，目的是让客户了解下界面的整体色调以及我们的设计想法，避免后面所有界面设计完、开发完后，被客户全部否认来的强。
开发阶段：人们常说技术人员做出来的东西，会让你觉得那不是你自己亲生的孩子，和设计师设计出来的美美的界面会有很大的差别。这都不是重点，重点是，我们的技术人员还不是自己公司内部人。
所以在开发阶段，我不仅要把控好项目进度，同时还要三天两头跑去对方公司盯着他们做的成果，一旦发现界面做出来严重“扭曲”就会拿设计图和技术人员沟通，沟通不行就撕逼。他们如果不肯配合，我就只能找他们的老板和技术人员沟通了，因为作为一个小姑娘家的，老板们还是不太会为难我的。
系统开发结束后，部署到测试环境，开始进入测试、验收阶段，毕竟公司小，作为产品经理的我是和测试人员一起参与系统测试、验收的，通过建立Easybug，将所有的BUG全部写入进去BUG系统，分好BUG优先级，安排技术人员进行BUG修复。
当然在这个过程中最讨厌的莫过于一BUG未平，一BUG又起，这也和技术人员的能力有着很大的关联。
测试、验收结束后，让客户参与试运营阶段， 亲自参与使用系统或者APP等。一般在这个阶段不会遇到的太棘手的问题，因为前期不管是需求还是测试阶段，我们都尽可能的多花心思处理。
试运营结束后，客户也确认没有问题后，产品正式上线，这算是一个项目告一段落，后面开始进入正式运营阶段。
针对于以上的九个阶段，我都会在项目开始前，进行时间周期的把控，在项目进行中，进行阶段进度的把控。及时采取相应的措施去解决存在的问题，尽可能保证项目按照预定的时间上线。
当然，在整个过程中，最难的莫过于和不属于本公司的技术、测试等人员进行沟通与合作，这个过程有时让你怀疑人生。但还好，内心足够强大的我觉得所有的问题都会迎刃而解，只不过过程会比想象的难点。
以上是我作为外包公司产品经理的工作流程和感触，写的比较口语话，目的是为了更直观的表达自己的想法，如有需要改进的地方，还请各位大佬多多指教~
