-
产品篇
一、 基操--产品一定是对产品和业务最最熟悉的人之一
一个不熟悉现有产品和业务的产品怎么可能设计出最优的产品方案，能保证不出错不遗漏，业务能闭环走通就不错了。
1、根据【 产品定位】 来确定开发内容，不能所有的产品都按照一套固有的逻辑来做，要懂得变通，不能为了凑工作内容而产出需求，无效的不适用产品定位的需求会极大的增加团队的工作（每个部门的时间、精力、代码维护甚至变成废弃代码难以维护、后续持续跟进），在人员和时间充足的情况下可以做，但是一定是优先真实需求、刚需
第一种情况：针对确定客户使用的软件产品， 应该与业务需求提出方、最终功能使用方一起去确定真实需求（很多情况下业务提出方和最终使用方是一致的，但也可能有的时候看起来是一致的而实际不一致，比如提出方其实是最终使用功能的业务部门的某个领导，而实际操作的可能是一线员工）
第二种情况：ToC的软件产品，应该关注C端用户的需求（痛点）以及功能上线之后的用户反馈、使用情况（埋点统计），很多的时候是需要产品给用户制造"痛点"，那么这些能否成为吸引用户的功能，也是需要更多方面的统计来跟进功能的使用情况。
第三种情况：ToB的软件产品，这种其实跟ToC又是不一样的，虽然背后操作的可能还是个人，但是很多方面也要考虑进去。
2、输出产品需求形成文档依据，并跟业务部门确认（非常关键，不然所有的工作都白做），之后最好是做一做原型逻辑跳转图，好处很多（下方说明）
（1）最基本的：业务部门确认无误，业务闭环，流程相对合理，可以走通；关联业务逻辑基本包含，前端操作设计都要有；
是人都会犯错，遗落几个小的功能点这没什么，但是在一次版本迭代过程中，涉及到的【相关改动大面积关联业务、重要业务对应变更】设计缺失，这是非常严重的错误
（2）原型逻辑跳转html，原型逻辑跳转html的好处是多方面的：
（1）产品自己能确定自己的设计是合理的逻辑是通的
（2）测试方和开发方不必在工作过程中去梳理思考一些隐藏的细节问题，打断测试方和开发方的连续性的工作
（3）这个工作如果没到位，后期开发、测试、产品梳理和沟通的成本是很高的，产品质量甚至都会受到影响。
（4）假如是面向内部业务部门的产品，还可以再次向业务部门直观确认是否符合业务部门需求，但一般不需要给出。
3. 更新和同步
文档做好版本记录，做到产品文档和UI逻辑跳转html一定是最新的，做到需求逻辑逢改必更新，颜色区分标注版本迭代内容部分，并通知到相关各方人员（UI设计、开发人员、测试人员），如果变动部分大，前期给过业务部门UI逻辑跳转html的需要进行一次简单的沟通。
二、很多产品都不是无中生有，先模仿后超越，要懂得借鉴好的产品思路，另外还可以去尝试学习不同方向的产品经理的技能
-
UI设计篇
1. 熟练掌握专业内的软件，设计出【符合产品需求和用户使用习惯的美观的界面】，同样基本也是可以采取先模仿后超越的思路
熟练掌握专业内的软件，设计出符合产品需求和用户使用习惯的美观的界面，以设计出的软件简洁漂亮易操作为目标。但是基于现实，有时不得不考虑对研发同学作出妥协。
2.建立标准和规范：在同一个项目中不能过于随意设置边距大小、字体颜色字号、弹框样式等等，应该对不同目的、不同层次的内容建立设计标准和规范，如果担心风格单一，哪怕建立几种标准都是可以接受的，但是在同一个项目中一定要有标准和规范
在同一个项目中不能过于随意设置字体字号，边距大小，弹窗样式，大多数情况应该遵循统一的标准或者几个标准，这对于项目代码的规范性和复用性（设计图有标准，代码才能更好的设定对应的公共标准，以后风格调整修改公共标准就能做到全局修改）、降低代码量、开发效率、稳定性、降低维护成本都会有很大帮助。
3.关于IOS和Android端交互是否需要一致的问题：功能稳定和适配性良好优先，这是我的答案
目前看到的是小公司往往格外要求UI一致，大公司反而是尊重各个平台的特性不同处理；
个人猜想：小公司的一个原因是UI设计人员少、测试人员少，出不同设计后续一系列的成本高，然后就可着开发同学怼；最怕就是啥也不懂一味以各端一致性为追求的；大公司人员充足，可以接受不同的设计，这样更尊重平台特性，对开发同学也更友好。
-
开发篇
-
情况一：产品或者设计的产出粗糙
产品需求文档评审会，一般比较短暂，加上研发同学可能还处在另外一个项目的开发过程中，并没有对产品细节设计发现问题，开发过程中发现问题一定要找产品和设计确认，不能自作主张等待测试去提，这时处境就会很尴尬。问题很多可以在合适的时机和方式反馈给负责人，必要的时候需要申请增加相应的工时，工作中对事不对人，把手头的事情做好，其他的不用考虑。
-
情况二：好的团队管理出好的结果
在产品和设计的工作做的相对细致和标准的情况下，研发同学就可以专心于代码逻辑的实现，即使有一些小的疏漏的地方，也不会对研发过程产生很大的影响，及时反馈变更即可。
-
基于情况一和情况二之后的流程涉及到的就是前后端的合作
先问个问题，如果前端总感觉没有接口不确定页面该用哪种方式去布局去实现，或者接口出了发现有的界面还要再写一遍，请问这时候问题出在哪里？
缺失返回数据的结构甚至是各个字段的定义，尤其是数据结构，所以说开发前两端一定尽量去确定数据结构甚至是各个字段，这样就能减少前端开发的困惑和可能产生额外的工作量，但是这对于后端同学要求会高一些。
-
开发中需要注意的一些事项（持续补充... ...）
1、研发同学一定是根据产品需求文档和UI设计图来开发的，严格遵守设计才能避免后期出现自身的问题。
2、关注项目主业务流程，保证主业务流程没问题，其他的问题相对来说都是小问题，其实这个也有一部分取决于测试人员，毕竟bug的提出权在他们手里
3、对于测试不好验证的问题，尤其是涉及到主业务流程的功能，开发过程中仔细查证接口传递数据以及服务器端返回数据是否正确，从逻辑上得到验证而不是从现象上来验证当前功能。
4、上线的安装包尽可能做到公司所有现有机型安装验证，避免在加固或者打包之后部分机型出现问题。
5、老代码一定要尽最大可能逻辑上看懂，不能只根据开发机型来验证逻辑，并且问一下可能能问出特别条件下的逻辑问题。
6、对待代码要严谨，要仔细理清代码的作用，确认代码的作用才能保证删除或者保留不会影响现有逻辑，尽管有些代码看上去很糟糕。
7、前端代码尽可能保持简单，一些数据和涉及到钱的都由后台去处理，出现问题后台随时可以修改上线，但是移动端出现问题就会比较尴尬，因为打包审核上线的时间不可控，影响会比较大
8、虽然有的时候开发时间被压缩的比较紧张，如果再加上产品设计粗糙可能会使整个开发过程更加紧张和烦躁，但是自测一定尽量要通过，要仔细细心，尤其是UI显示上尽最大努力不出错，尽量给测试人员充足的时间验证重要的业务流程
-
测试篇
1、测试人员的逻辑性是十分重要的，否则会出现很多不是问题的问题
2、认真测试发现项目中的一切问题，但是要分清主次，严重bug，普通bug还是优化点，在时间有限的情况下，优化点和不好解决且不重要的点可以先延后，在合适的时间反馈目前延期的问题，项目直接管理者最好在不忙的时候问一下，安排一下，也不需要测试去重新提出。
-
总结
所有流程都能做到基本规范，最后将本次需求版本变动的各个部门的文档留档，这一整套下来，对后续项目长期维护来说非常有益，也不会过度依赖项目组某个或者某几个成员，项目组成员的变动影响也会降到最低。
-
其他的一些零零散散的看法
- 注意到一些大公司的产品，不重要的部分，比如二次确认弹窗直接使用原生的不加修饰的弹窗，大公司人员能力和配备都是比较好的，然而他们还是把资源尽可能的倾斜到主业务中去，反观小公司在人员并不充沛的情况下盯着比如一个二次确认弹窗，显示信息的弹窗来回折腾，还美其名为注重细节。
