老大~我这波位置可不是白占的~~~~

K12的项目算是没什么大问题了，是时候来一波总结了~~

首先列出项目中遇到的问题

1.排课中日期和时间的概念是不是分别指具体到哪一天和哪个时间段？
2.如果时间的概念是具体到时间点，那么安排课程时间的时候，是有固定的时间段设定还是由排课人员自由设定？
3.如果是类似学校上课的时间段，那么课程时间是怎么规定的？
4.排课每天只排一节课？
5.需不需要过往的排课列表？
6.排课一般可以排到当前日期之后多少天？
---------------------------------------------------------------------
1.教材管理等页面中的编辑功能可否统一改为查看，查看页面中增加编辑按钮，点击编辑后所有选项变为可编辑模式？这样编辑入口会比较深...   v
2.教材确定错误  v
3.查询框内容重复 v
4.细节说明
5.侧边菜单 v
6.新增排课改为弹窗v
7.测验排序按照拖拽排序v
8.测验新增课程指导和回答时间v
---------------------------------------------------------------------
1.是否所有或大部分删除操作都标记为失效？
2.教材无图片v
3.多级联动框改为输入框v
4.外教管理列表筛选框中有年级属性，列表中无

5.外教管理列表筛选框中年级属性加入“未录入课程”

---------------------------------------------------------------------

1.教师资料编辑页面，密码修改方式

2.新增教师资料，邮箱去重

3.密码组成方式确认

4.只有教师存在状态属性，其他模块的删除全为物理删除

5.安排课程的新增弹窗中，讲道理应该是先确定课程再来确定课件，现在是先选定课件再选择课程，沟通可不可以将两个模块交换位置

6.冗余数据没有更新

7.新增单元、课件、测验时没有默认的父级元素，需手动添加   v

8.新增完之后返回，继续新增需要从父级元素跳转进去才有新增按钮   v

9.没有密码的加密Util

10.删除哪些部分需要验证，是否删除一本教材，这本教材下的单元、课件、测验全部删除？确定删除规则

---------------------------------------------------------------------

1.新增完成，页面变为查看页的问题，有编辑 新增 返回 按钮

2.重新查询的作用

--------------------------------------------------------------------

1.表单验证

2.表单的默认排序

3.侧边栏高亮

4.对排课中的项目进行编辑的时候获取数据错误，请求无反馈

总结：

         通过k12这个项目，算是完整的体验了一个项目从开始到验收的过程。

         首先，最开始需求分析阶段可以说是比较敷衍的，匆匆忙忙根据之前的原型画了脑图，听老大讲了一下基本的要求就开始画原型了。那算是我到修真院这一个半月以来画原型的工作量最大的两天。之后还一直在改改改...

         现在看来，当时那么匆忙的画原型导致了两个大问题。

         1.对需求的了解不够，因为只做了脑图，分析的用时也很短（一共俩小时...）所以，只能算了解了这个项目的框架，知道了他的作用，他的主体的逻辑和层次，然而对细节方面的东西根本不了解。这也是后来频频改动原型的原因之一。

         2.原型图各方面的交互和限制产生了很多漏洞，因为只靠大体思路就把原型画了出来，所以看原型的时候，对每个地方的操作，各个部件的作用都有点观念先入为主的影响在里面，自己看到哪个地方，就不由自主的想：这个地方是怎么操作的，那样可以实现什么功能，恩，这边没问题了。自己一厢情愿的让这个后台按照自己的想法在走，却少问了几个问题.....如果用户没有继续往这边操作，而是直接跳转了其他的地方会怎样？这是同一个页面，但是用户通过不同的入口进入，页面的一些规则会一样吗？这个框的作用是什么，定位是什么？可以用它来体现别的功能吗？对细节的东西想的太少，对每个操作，每个文本框，每个按钮的条件想的太少。

         经验教训：大师兄之前跟我们开会说，一个项目花在需求分析上的时间可能会达到50%，当时我听到是有点惊讶的，但是现在想来就觉得正常了。只要能把说所有的需求和逻辑理清楚，那接下来就只需要做就好了。不会像之前那样，只课件和测验那部分的原型就纠结了好长时间。原型画到一半思路就卡住了，只能跑去翻资料，问需求。这样反而耗费了更多的时间和精力。

         然后就是细节是个很烦人的东西，因为你需要从各个不同的，刁钻的角度去考虑各种情况，然后想好解决方案，把需要注意的地方可能会发生的情况标注在原型图上。但是因为对需求分析的不够，原型的主体部分都画得磕磕绊绊的，更别提细节了。所以在需求分析阶段就应该做出一套详细的流程图来，对流程图中的每一步操作的前置条件后置条件想清楚，每个环节的改变会对整个产品的各个模块产生什么样的影响都要有一个缜密的逻辑推理过程。争取在功能流程上不留漏洞。

--------------------------------------------------------------------------------------------------------------------------------

         到了开发阶段，理论上讲如果需求理清了，业务中所有情况都考虑到了，原型中所有的地方都给了相应的说明，开发的时候就不用管了。只要开发人员能正确的理解需求，那么最终出来的东西应该是没问题的。然而人无完人，谁思考问题能那么的滴水不漏呢？另外，需求也不一定就是完全确定的，谁能保证需求不会变呢？所以，开发过程中改原型、改需求、改功能就不可避免了。大师兄和老大都说过，你用一天时间画的原型，开发可能需要耗费几个人几天的时间。你花五分钟做的改动，交给开发可能人家要撸一天的代码。刚开始开发k12的时候，发现了问题，拍拍脑袋：这么一改就行了嘛~然而虽然是个小改动，却也影响到了其他的地方，然后仔细一想，其他的地方也都要改。到了这个时候，随时准备跑就好了，因为程序员大老爷们可能已经准备好了刀......

         经验教训：开发阶段尽量少做改动，这也是为什么需求分析阶段需要把功课做足的原因。如果要做改动的话，那就得充分发挥聪明才智了。思考各种解决方案，并且根据各个方案造成的影响，产生的效果，增加的代码工作量选出性价比最高的一个来。比较完美的解决方案是影响最小，效果最好，代码最少的~~最完美的解决方案是： 不 要 出 现 问 题~~~

--------------------------------------------------------------------------------------------------------------------------------

         到了测试阶段，就要对整个产品的各个方面进行测试了。我认为测试环节比较能体现一个产品经理沟通能力的重要性了，如果你前期需求讲解讲的好，业务方面的问题能跟开发讲明白，那么在他们认为做完了的时候，bug就会少很多。测试的时候出现了问题，一沟通发现，开发人员没正确理解他所做的东西是干什么用的。这种情况发生的多的话，在测试前期会很痛苦，因为点哪都觉得不对，放眼望去全是bug。那还测个锤子啊...这时候就好像给你一把笤帚，让你把垃圾场打扫干净一样.....所以，我觉得在测试前期，可以有bug，但一定不是那种一眼就可以看出来的bug。其次，测试的时候也要讲究方式方法，不能因为录入数据量比较大，就sdfsafds、12312132之类的随便输。k12中有教材-单元-课件-测验的层级之分，如果乱输一气，每跳转到下个层级你可能就忘记上个层级的父级元素是谁了，那么就算错了也看不出来。

         经验教训：虽然老大说让产品经理去推动整个项目的进展是件扯淡的事，但是我觉得在开发前期，多催催开发老爷们看看story，了解了解需求还是很有必要的，省的开发的时候跑偏了。然后测试的时候，要先考虑好数据怎么填，填什么有利于测试的进行。我在测k12的时候是这么总结的：命名教材的时候要含有年级和名称（如1.1）、单元要有年级、教材名称、单元名称（如1.1.1）、课件要有年级、教材、单元、课件名称（如;1.1.1.1).这样的话，随便给我一个课件，我就知道是几年级哪本教材几单元的哪个课件，测功能的时候也会心中有数。还有对每个操作每个功能的测试都要从各种刁钻的角度试一下，看似一个日期选择框，点一下跳出日历来让你选择日期，但如果这时候在框里输入了文字怎么办？如果还提交成功了怎么办？这样一条脏数据会对系统产生什么影响？细思极恐啊~~

-------------------------------------------------------------------------------------------------------------------------------

         测试解决了绝大部分的bug之后，终于测不出什么问题来了。这个时候应该可以交付了吧。然而你测不出bug来，不代表别人测不出来。即使没有bug，用户也不一定对产品完全满意。

         经验教训：项目交付之后，仍要时刻跟客户保持沟通，根据客户提出的问题做出合理的答复或修改，哪些东西是可以改的，怎么改。哪些东西是不能改的，为什么。这些都要确认好，帮助客户做出正确的选择。真正需要改的地方，要及时通知开发人员优先来改。子曰：上个屁股还没擦干净管下一个干嘛~~