《Spring Boot 实战纪实》缺失的逻辑

前言
(思维篇)人人都是产品经理
- 1.需求文档
  - 1.1 需求管理
  - 1.2 如何攥写需求文档
  - 1.3 需求关键点文档
- 2 原型设计
  - 2.1 缺失的逻辑
  - 2.2 让想法跃然纸上
- 3 开发设计文档
  - 3.1 功能梳理
  - 3.2 数据库设计
- 4 制定开发任务和计划
  - 4.1 时间管理
  - 4.2 任务管理(任务拆分+排期)
(技术篇) 码农的自我修养
5 Java基础
- 5.1 Java环境搭建
- 5.2 Java基本语法
- 5.3 Java流程控制
- 5.4 Java 集合
- 5.5 Java 类与对象
- 5.6 构造方法
- 5.7 封装,继承,多态
- 5.8 Java抽象/接口
- 5.9 Java常用类
- 5.10 Java异常处理
- 5.11 异常的定义及捕获
- 5.12 Java多线程/线程池
- 5.13 Java的反射机制
- 5.14 Java的23种设计模式
6 Spring框架
- 6.1 了解spring
- 6.2 Spring带给Java开发的便利
- 6.2 Spring ioc/aop
7 SpringMVC
- 7.1 了解springMVC
8 SpringBoot
- 8.1 MVC 模型
- 8.2 拦截器
- 8.3 过滤器
- 8.4 POJO
- 8.5 controller
9 MyBaits plus
8 Web基础
- html+css
- javascript
- bootstrap
(实战篇) 打造自己的轮子
- 10 项目架构
- 11 网站母版构建
  - 11.1 thymeleaf介绍
  - 11.2 使用thymeleaf构建网站模板
- 12 首页
  - 12.1 banner
  - 12.2 轮播图
  - 12.3 文章分页
  - 12.4 编码实现
- 13 登录
  - 13.1 功能点介绍
  - 13.2 知识点
  - 13.3 编码实现
- 14 注册
  - 14.1 功能点介绍
  - 14.2 知识点
  - 14.3 编码实现
- 15 用户管理
  - 10.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
- 16 权限控制
  - 10.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
- 17 权限控制
  - 11.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
总结
源码
参考

前言

打造一个产品真不是一件容易的事情。从创意的产生,到原型的设计,再到研发,最后给到用户使用。中间涉及到很多环节,每个环节看似孤立,实则一脉相承。而真正让各个环节融会贯通的那个角色就是产品经理。

一个输入框你要做一周？

如果产品经理说这是个很小的改动,千万别信他

在《ThoughtWorks洞见——一个输入框你要做一周》中,有个有趣的故事。

在某次迭代会议上，PO希望交付这样一个“简单”功能：在应用中，用户可以输入自己的地址，这样我们可以定期邮寄一些宣传册给用户。

PO让作者评估该功能的完成时间,作者经过思考,回答"在理想情况下，大概需要五、六天"。而这一评估,让PO错愕...

回顾过去多年的研发工作,这样的场景几乎每天都在发生。缺失的逻辑(或者遗漏掉的细节)是导致这种预期偏差的原因罪魁祸首。

拿来主义

他山之石,可以攻玉。

约定俗成

不知道从什么时候开始,在设计或研发产品的时候,总会参考业内标杆产品。如,设计IM的一定会参考QQ或微信。好的产品已经对用户有了足够的教育,产品和用户长期的相互磨合形成了用户习惯。

再比如,弹出框，“确定”、“取消”按钮的位置，右确定，左取消，这已是行业的共识，点右边比左边更容易这是经过证实的。

产品设计遵循用户习惯和行业共识是值得鼓励的。

盲目照搬

我曾协作参与过一个APP的研发。这款APP,一年的时间,前前后后参与这个APP设计的产品经理至少有十人。

当你打开这款APP,你能看到抖音,小红书,网易考拉海购等APP的身影,由于公司高度重视,迭代依然在在不断进行。但打脸的现实是,APP并没有太多的下载量。

每一款脱颖而出的产品,都是独一无二的。简单的照搬和组合,而不是结合自己的业务因地制宜,终究只是一个花架子。

面子与里子

产品经理大忌：瞎猜、自嗨。

瞎猜、自嗨

产品经理是一个需要兼具创意思维和工程思维的职业，在产品工作中创意思维会帮我们通过敏锐的观察，逻辑分析及抽象思维能力发现别人发现不了的点；而工程思维会帮我们拆解目标、设置任务、制定流程，通过严格的质量把控和踏踏实实的执行，把这个点变成一个看得见摸得着的产品。

产品经理绝对是魔法师般的存在,将老板(业务方)脑海中的想法,化作一幅幅栩栩如生的原型。

原型的意义,搞开发的技术同学能够体会——"产品虐我千百遍,我待产品如初恋"。原型的的布局就像一盘棋局,一个棋子的移动,都会导致千军万马厮杀。

从这个意义上讲,产品经理岗位的素质要求是极高的。产品设计本身就是产品的一部分,原型就是图纸,图纸的严谨性对后续开发流程极其重要。

用户场景

场景是需求的灵魂

一部鸿篇巨制的电影,其实也是有一个一个小的场景片段剪辑和拼接而成。软件产品也不例外。好的产品每一个功能点背后都有其深刻的应用场景。

这个按钮是否必须存在?这个链接指向哪里？在开发的过程中,经常会有技术问产品童鞋。

没有应用场景的设计就是耍流氓。坚决反对"加戏"。

缺失的逻辑

产品经理更需要的是理性思维。

作为互联网打工人,我们都知道,当产品评审结束之后,原型发布,接下来的工作重心就转移到技术同学那里了。技术同学会进入开发,直至产品发布上线。

但是如果一切都是如此和谐,就没有下面这幅图什么事儿了。

当技术的同学开始干活儿的时候总会发现设计上的一些隐藏的坑:

规则不明确
流程不闭环
与现有功能冲突
...

而这一切都将导致研发延期,甚至上线之后产生重大bug。

在产品设计环节,不妨多做些推导和预演。

产品的生命力

世界是物质的，物质是运动的，整个世界就是永恒运动着的物质世界。产品也不例外,产品是动态而非静态的。

产品是有生命的

"写程序就像养孩子",技术童鞋一定会感同身受。从创意到设计,到技术实现,到发布上线和运维,再到运营,产品也在不断地成长,成熟。

产品的整个生命周期,都包含着产品,研发,运维的心血。

系统性思考

因为产品是有生命的,所以在构思的时候,要以一种整体性,系统性的的视角去规划产品。

很多中小型互联网产品公司,并没有一个人能够清晰地梳理出产品的业务。这或许和人才的流动性有很大关系。所以,不断地换人,不断地在原有系统上加功能,不断地试错。

如果不全面的梳理整个产品线的业务,将会导致大量的人力和资源浪费。

持续赋能才有价值

产品的价值是持续赋能

好的产品,应时时刻刻牢记自己的初心。为解决问题而生,为持续赋能而活。

不断地让产品有价值,让产品走得更远。

工具人 vs 匠人

企业家需要产品经理把控的是大方向、格局包括行业的趋势分析、历史沿革、发展生态链，而不是沉迷于Axure，这样只会因小失大，失去大格局的眼光。

工具人

善用工具,但是要有自己的灵魂。最近一年我参与一个项目,原型图的工具不断在变换,一年之内分别使用了Axure,mockplus,蓝湖,墨刀。工具不断在变,但是原型水平依然没有提升,是谁之过?。

如果一个产品的设计者,只是会使用别人家的工具,而不关注提升自己的产品核心能力,又如何期望打造一款好的产品呢?

匠人

无论你哪所大学毕业，无论你的工种和职称，你身无匠心、手无技巧、提供不了精准、专业、享受式服务，你就不是匠人，而多半是个职场混子。

大概在十多年前的学生时代,偶然读了《于千万人之中，你是匠人》这篇文章,深有感触。而过去的十多年,我们刚刚经历了移动互联网的黄金时代。当表面的繁华褪去,沉淀下来的硬核的好产品又有多少呢？

如今的时代,比以往任何时候更加渴望工匠精神。

参考: