开发后的思考与分析

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

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

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

工作实际时间和工作

我的工作实际时间和工作

第一周	1.完成总进度的百分之50，总体页面框架和实现，以及其中的流程功能操作
第二周	1.其他项目插入 2.完成总进度的72%
第三周	1.前两天半时间其他项目介入，完成。 2.完成总进度的92%。 3.第三天下午讨论新增功能点，项目流程大改，并且pc端显示页面重画。 4.由于个人为了让几个展示页面格式和显示风格统一，未按照需求页面开发，重新编辑代码
第四周	1.完成总进度的99%。 2.并且讨论流程控制需求，未记录
第五周	1.测试并且修改bug和优化显示，由于之前讨论结果没有及时保存，只能通过我写开发流程编辑草稿式的测试用例
第六周	1.过产品验收确认，优化，加需求和修改需求，有几个流程控制中途讨论结果未及时更新，导致返回讨论前的需求，pc端审核页面没画。 2.开启另一个小任务并且完成
第七周	1.优化和新需求，其他项目几个小bug，周五还在加需求，并且还有一个小需求未完成下个版本迭代。 2.产品验收。
第八周	功能上线...

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

未加班时间（周记）

第一周	周一、周三
第二周	周五
第三周
第四周	周二、周五
第五周
第六周	周一、周四、周五
第七周	周一、周五
第八周	...还没到

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


针对以上描述的问题，我的解决方案如下：
1.产品设计的详细设计应该和开发人员，测试人员，市场人员共同确认，编写详细开发文档，测试用例，市场描述文档
2.需求和文案修改或者新增，消息联动，产品，市场，研发，测试。并且记录在下一个版本迭代翻案中
3.对于研发时需求修改，如果是特别需求必须在研发过程中修改或者是发现重大问题下，可讨论并且记录下来，然后代码调整。并且修改需求记录下来，测试和市场文档修改
4.对于研发人员，不可直接修改需求和设计，需要修改的地方开会讨论或者下个版本迭代。功能逻辑理清
5.对于产品设计，设计人员尽可能详细的描述功能点和操作，相关人员必须明白这个功能干啥的，这个标志放到这里的作用，甚至可以细致到颜色和像素的描述
6.对于测试人员，测试用例文档应当在研发结束之前应该出来；测试人员不能直接修改需求和添加需求，有问题及时反馈，研讨这个需求是及时修改或是下个版本迭代
7.对于前端人员，我的前端工程师是最棒的，改？小意思给我一首歌的时间。


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

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

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

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

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

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

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

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


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

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

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

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

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