《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 编码实现
总结
源码
参考

想要打造出一个好的产品真不是一件容易的事情,需要灵感,需要需求搜集和整理,需要技术研发投入,需要客户的反馈。每一个环节都是很重要的,而作为技术开发者或者或项目经理,对需求的理解和管理是重中之重。有时候甚至应该把自己当成一个主导者来开展工作。

罗马不是一天建成

通常公司是以项目为单位来开展工作的,这里分享一下自己曾经在团队中使用的需求管理的策略,仅供参考。

需求来源可以来自市场、用户调研、运营、测试、开发、用户反馈、产品经理等等。不同部门,不同干系人之间的需要建立良好,顺畅的沟通机制,绝对不是短时间就是能完成的事情。需求管理体系需要长时间的磨合和企业文化熏陶。

从上图可以看出,项目负责人对于项目成功和失败至关重要。要顺利交付一个满意的产品或项目其实对开发人员有着极高的要求,懂产品,懂业务,懂技术。而具备这种综合素质的人才的培养,也是需要长期的经验积累的。

傲慢与偏见

十多年的职业生涯,我见识过太多傲娇的程序员,这似乎是程序员的通病。技术人员总是容易陷入细节。他们倔强,逞强,单纯,爱钻牛角尖。

或许是因为长期和技术打交道。外界给技术童鞋打上了“木讷”,"不善言辞"的标签。而技术的同学却又容易因技术而莫名的自嗨。技术是工具,生活和工作的主体是人,希望技术的同学们放下傲慢和偏见,跳出技术思维。积极的见识不同的人,放下包袱,培养自己与人沟通的能力。

人人都是产品经理

"专人专事"或许是对员工潜能的最大束缚,互联网行业尤甚。"两耳不闻窗外事,一心只想写代码"。这是很多技术同学的心态。笔者建议技术的同学也应该主动培养自己的产品思维。人人都是客户,人人都是产品经理。有个网站人人都是产品经理值得大家去看。

从产品的角度思考问题,你的格局将不再局限于代码的实现。值得注意的是,技术人和工具人(产品经理)的大部分工作就是围着产品转。

锋利的邮件

没有人会对邮件陌生。尽管现在职场中有很多沟通工具,如企业微信,钉钉,QQ,邮件等,但是公认最为正式的还是邮件。通常每个入职的新人,公司都会分配一个邮箱号,这个邮箱大概率就是内部系统账户,它将贯穿你的在这家公司开展工作的生命周期。

工作邮件大致可分为以下四类：

确认邮件——做留存

口头、电话、会议交流的事情，邮件进行确认，这是一个好习惯，为了减少跨部门的扯皮情况发生，我们习惯将重要的决议通过邮件形式进行确认。

需求邮件——有细节

对于参与人员较多的事项,要把细节写清楚、量化出来，这样需求才精确，接需求的人知道怎么做，结果也不会太让你难受。

反馈邮件——有反应

收到别人的需求邮件后，应该尽快反馈。

通知邮件——广播站

通知类型的邮件。如国家法定节日通知,公司组织机构调整等,这类邮件不需要回复。

善用邮件,将会帮助您提高工作效率。《职场大佬告诉你,如何正确的写邮件》值得一读。

需求的搜集

很多公司是在需求管理方面没有严格的制度和完善的流程。这会导致大量的时间浪费,也会引发出工作不聚焦的问题。我想互联网996现象与此有着千丝万缕的关系。

我曾供职于一家saas软件公司,负责业务技术支撑工作。我的组员只有5人,但是我们同时负责了官网,devops平台等工作,其中涉及的支撑部门包括市场,运营,产品,开发,财务等多个部门,需求总是源源不断。但限于没有一套规范的管理体系,需求总是会以不同形式纷至沓来。甚至有人直接过来说需要马上导出报表。这种场景,我想大家是不陌生的。

应对这种情况,首先就是要有一个统一的渠道来搜集需求,比如邮件,杜绝不断有人来打扰你的工作主线。

制定需求搜集表单。实际上很多软件公司也在想办法如何提高协同工作效率,尽可能地减少人力资源浪费。这其中,比较有效地就是工单系统,笔者曾经参与开发过这样的系统,的确能够带来工作效率的提升。当然,为了图省事,可以制定一个需求模板,让需求方按照模板来提需求,也能达到效果。

需求整理

由于认知的差异,信息不对称等原因,需求的信息总是参差不齐,往往需要加工之后才会变得有效。

需求方往往会开门见山的提出诉求,而不会告诉你完成这些需求的背后的逻辑,甚至有些名词可能也会让你捉摸不透。而你需要无效需求进行驳回或者追问,有效需求将加入需求池。

常见的需求管理工具有很多，比如tower,Project,笔者比较喜欢用excel,或者腾讯在线协作文档。

任务池大致如下,仅供参考:

四象限法则

计划总是赶不上变化。

对于任务池的管理又不得不提到时间的管理,在人数和时间确定的情况下,任务其实是不确定的。每天都有可能冒出来一些临时性任务,这样就导致我们的计划无法兑现。

应该将自己绝大多数的时间分配在第二象限重要但不紧急的事情上,有计划的去执行,制定时间表,各个击破。

最后

管理是一门艺术,德鲁克大师的《卓有成效的管理者》（珍藏版）非常推荐大家去看。需要的童鞋可以发邮件给zhikecore@foxmail.com,留言获取该电子书。

参考

《Spring Boot 实战纪实》