开发后的思考与分析

事情是这样子的，我们打算迭代开发这个功能，添加5个功能点，页面算是重做，添加两个状态。所以我打算重构这个功能，原因有二，其一因为之前版本代码臃肿，不适合查找问题，而且存在许多使用问题；其二因为修改的东西有点多，所以得重构，用之前的代码无法完成和修改使用。由于关系到公司隐私问题，这里不贴出相关设计原型，并没有各种文档。

当然，重构后的代码还是满意的，毕竟减少了接近2000行的代码，功能分类，相关备注都有

下面我会通过：工作实际时间、加班时间、存在的问题、问题解决方案、开发流程和我的开发流程设想、以及开发过程中的小插曲来进行分析这次的任务

工作实际时间和工作

加班时间（这里我采用未加班加班的时间，以九点半以上为准）

通过每周执行和加班的时间分析存在的问题：
1.没有一个明确的研发流程
2.产品设计不够详细，功能点不明确
3.频繁修改和添加需求
4.讨论没有做记要，导致测试和验收流程不吻合
5.研发人员有模糊功能未按照产品设计原型开发
6.测试用例未及时整理
7.测试人员提需求未记录保存，与产品验收冲突
8.产品人员未和测试及时沟通需求，测试用例有偏差
9.研发人员细节修改未记录

下面是针对开发流程的分析和我的设想：
现在的开发流程：

产品设计～产品评审～开发（改需求）～测试（改需求）～改bug（改需求）～产品验收测试（改需求）～最终改bug（提需求）～产品上线

1.这里我们可以明确的发现几个问题，就是在开发过程中不断的提需求改需求，夹杂这产品和测试的需求，这样大大的延长开发时间；

2.有时候会因为产品和测试提的需求没有及时把消息传递到整个团队和原型设计里面去，导致测试和产品的的需求有出入，所以产品验收的时候已产品设计为标准；

3.需求设计未明确所以开发延长开发周期；

我建议的开发流程：
产品设计～详情设计（包括产品的细节设计，产品协助测试写好测试用例以及细节，运营人员写好使用说明文档和宣传文档，研发人员的用例图和代码设计和数据库设计）～开发～测试和产品验证～产品上线

所有的修改需求和添加需求下个版本迭代，除非有特别涉及到影响使用流程的需求。影响流程的问题提早发现会减少开发时间，问题发现得越晚，修复时间越长。产品迭代的需求以及优化部分，需要详细的记录以免忘记自己的设想，可以通过访问客户建议以及团队讨论方式开启迭代方案（需要参与人员：开发人员，测试，产品，市场人员以及运营人员），最好要有市场调研结果（这个可以省略，但是涉及到操作习惯或者流程发生改变的情况下这是必须的），做好会议记要。

为什么要迭代这个 络研发暴涨的年代，速度决定生存，先开发出一个版本，虽然它不够漂亮，虽然它不够成熟，但是它可以随着用户的反馈和不断的完善自己，他会是一个非常好用且得到用户信赖的产品。
我的敏捷开发，快速迭代的方针主要适用于，用户量达到一定，为解决一系列问题快速开发，收纳用户建议和大家的使用体验快速迭代升级产品，使之达到成熟，从而扩大市场和用户量

对话小插曲（笑岔气）
产品：这个大概什么时候可以搞完
me：半个月。。。
产品：emmm，太久了，用户等不了那么久，急着用，这是一个特别好的功能
me：一周半
产品：这样吧，一周，我相信你的
me：…（

测试：这么多bug，我感觉周六加班
me：别怕，我今天可以干掉十个，哼，都是些小bug
测试：我就看你这种臭不要脸，还死撑
me：呵…
晚上…
me：咳，九个，极限了（

产品：你觉得这样改如何
me：还行，我感觉还少了点什么
产品：这样，我们问问前端
前端：要不在这儿加一个这个吧
嗯，可以
良久…
产品：我还是觉得那个版本好一点，要不改回去
前端：行吧（

产品：这个需求你看看
me：为什么不直接显示，一定要弹出来吗
产品：其实你的想法和我的一样的，他们说这样做用户的眼睛聚焦在上面的文字内容上面……
me：哦（聚焦码像鸡说的啥）以啊，就按照这么来做吧
产品：要不要前端协助下
me：不用，我可以搞定（

写在最后：我经常跟我的产品说的一句话就是：功能什么样的都可以实现，只是实现复杂度和适应架构的问题，这个功能要做考虑的地方在于用户使用情况和系统损耗是否利大于弊。
既然把这个功能交给我就请相信我，不会的我可以问我可以学，因为我对学习爱的深沉。
希望和大家交流心得，同时还望各位不吝赐教，下方留言讨论