目录

  • 前言
  • (思维篇)人人都是产品经理
    • 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,邮件等,但是公认最为正式的还是邮件。通常每个入职的新人,公司都会分配一个邮箱号,这个邮箱大概率就是内部系统账户,它将贯穿你的在这家公司开展工作的生命周期。

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

  • 确认邮件——做留存

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

  • 需求邮件——有细节

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

  • 反馈邮件——有反应

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

  • 通知邮件——广播站

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

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

需求的搜集

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



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

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

需求整理

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

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

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



四象限法则

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



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

最后

  管理是一门艺术,德鲁克大师的《卓有成效的管理者》(珍藏版)非常推荐大家去看。需要的童鞋可以发邮件给[email protected],留言获取该电子书。

参考

11-22 04:44