1-crm项目-需求分析和表结构设计
一、crm需求分析
""" 为什么开发这个crm? 我需要把这个作为一个通用的crm, 开发这个项目要解决企业的痛点 几个角色,销售,学生,讲师,老板, 从场景梳理出来需求
解决一个销售人员的痛点: 1,聊得多了记不住 2,出现两个销售人员抢单的问题, 3,辞职了怎么办?学生都带走了, 需求: 1,存储学生信息, 2,办理报名手续, 3,跟进记录,一个学生需要跟进多次,所以是一个一对多的关系,需要分表 4,各种维度查询学生信息, 解决学生的管理的痛点: 1,学生要培训,考试,交试卷,要做阶段性的考核,检查,对学生进行管理, 2,最好是每一个学生的培训都有记录, 3,每一个学生的业绩最后有问题,都是有原因的, 4,学生都是比较懒的,学生时间是不固定的,需要监督,需要考核
在线教育的痛点,时间问题(学生时间不固定这是劣势),空间问题(哪里都可以学这是优势),
需求: 1,交作业
2,查成绩,
3,请假
4,我的合同 5,我的推荐,推荐别人来加入, 6,投诉建议, 解决讲师的痛点: 1,有一个评估 2,跟踪每一个学生的情况,看看学生的学习效果, 需求: 1,点名,
2,查看成绩, 3,创建上课记录, 4,查看成绩,考核结果,
5,问卷调查,问问学生的感受
解决老板的痛点: 1,有多少学生,学生的来源,分析这个来源是否产生了学生,是否还需要继续投入这个渠道,比如百度竞价排名,可以是招商, 2,每个学生业绩怎么样, 3,老板需要看报表,数据都是零散的,不利于分析,聚集起来就利于分析,就知道该往哪一个方向发展, 需求: 1,销售报表分析 2,教学质量分析, """
二、考虑系统架构
"""
考虑系统架构 架构设计需要考虑的因素: 1,用户人群,是怎么样的,这个crm主要面对企业内部用户,所以对于各方面的要求不是很高, 页面不需要太炫,甚至安全程度也可以适当降低,公司一般要求越快开发出来越好, 2,用户量,针对企业内部用户量不多,如果是微博,每天上亿用户,用户量特别大,使用django就不合适了,需要使用tornado,
django天生就是做内容管理的,就是通过不同形式把内容展现出来, 这个crm就特别适合django做,微博会有高并发的问题, 3,业务场景,业务比较简单,就是页面点击什么,然后就从数据库查询就可以了,没有复杂的后端逻辑,就是增删改查,
所以要求是什么?
1,安全性要求不高
2,美观性要求不高
3,越快开发出来越好
4,不需要高并发
5,不需要复杂逻辑,就是查询
用到的技术: 1,django 2,jQuery,本质就是对原生js的封装, 3,bootstrap 做完这个项目之后,涉及到数据的curd操作,你就都会了,直接就能用, """
三、设计表结构
""" 需求分析完了,架构设计完成,下一步就是设计表结构, 大部分的交互都是和数据库交互,必须要确定好表结构,否则后续会出现问题,会有很多的坑,不断的出现坑,就填不过来了, 但是肯定会有问题,因为业务是复杂的,多变的,牛逼的开发,架构师,就能把路铺好,提前想到一些坑, 通用相关的表: 1,账号表,是否要用django自带的,要注意,
这是通用的,django提供了这种通用的东西,有自带的认证模块,
2,角色表,
name,
3,菜单表, 销售相关的表: 1,客户信息表:没有报名的是学生,报名的是学生,报名的学生要到报名表,
name,可以是空,blank=True,null =True
qq,这个需要唯一标识,不能为空,unique=True,
qq_name,
phone,可以为空,
source_choices = ((0,"转介绍"),
(1,"qq群"),
(2,"百度")... )
source,SmallIntegerField,使用这个可以减少存储的空间,
referral_from,推荐人
consult_course,咨询了什么课程
content,咨询的内容,Text类型,
tag,多对多,一个标签可以给多个人,一个人可以多个标签,
2,学生跟进表,
customer,跟进那个客户
content,跟进内容
consultant,谁跟进的,外键,账户表,
data,跟进时间
intention_choice = ((),())
intention,跟进意向
3,报名表,需要一个学生表,一个学生可能有多条报名信息,可以报多个课程,
customer 关联学生表
class,报了什么班
consult,销售是谁
contact_aggres,布尔类型,学生同意
contact_approve,合同审核,销售审核,只有这两个都是True,才是合同生效了,
data_time,
联合唯一,学生和班级,
4,缴费表,
customer,关联客户表
amount,金额,
course,关联课程表,
data,
5,标签表, name,
讲师相关的表: 1,课程表-----这是固定的
name
price,PositiveSmallIntegerField,正整数,
period
outline,大纲
2,班级表-----一个班级只能是一个课程,
course,课程
semester,学期
teacher,老师,
branch,校区,所有的choice字段都可以拓展成为一个表,
type_choice = ((),())
type,面授,还是网络
state_data,开班日期
end_data。
class_Meta:
联合唯一,校区,课程,加起来联合唯一,
3,上课记录表,一个课程每天都要有记录,一对多的,因为有很多的学生,
from_class,来自哪一个班级
day_num,第几天,一天一次上课记录,
teacher,老师
has_homework,是否有作业
homework_title,可以为空,
homework_content,可以为空,
out_line,本节的大纲
data,
联合唯一,班级和第几天,
4,学习记录表,------一对多,不能是和上课记录多对多,你同一个时间只能听一个上课记录,
student,关联学生报名表,
course_record,关联上课记录表
attendance_choice,出席是否
attendance
score_choice,分数,
score,
班级表---->上课记录表---->学习记录表
5,校区
name
addr。
核心的表就是这些, """
##################
角色和需求 1,销售人员, 1.1,要对学生进行维护,可以对学生进行查看,新增,删除,修改,跟进等操作 代码上的要求: 增删查改各使用一个页面,然后根据每一个表的配置来控制,展示的字段,筛选字典,查询字段,批量操作,要求是可配置的, 1.2,最复杂的是学生查看页面,有查询,有筛选,有批量,有表头,有列表,有分页, 1.3,要有学生报名的业务, 1.4,学生池的概念,可以把没有成交可能的放入学生池,也可以把你认为有可能成交的学生拉入自己的名下, 2,讲师 1.1,要批量生成上课记录,对学生考勤 1.2,每天的作业成绩需要录入 3,学生 1.1,要交作业, 4,老板 要看报表, 5,登陆,注册,菜单展示,权限控制,
########################
技术改变命运