大项目设计和管理复盘 - 含需求评审如何评审.

技术人人都是xx

大佬的自我介绍和使用说明书

如果成为一个合格的技术管理者_liaomin416100569的博客-CSDN博客

核心每个节点该干什么,每个人是否都完成了. 需要定时提醒.

跨系统,对方的逻辑,不要被忽悠.

今天最好的表现是明天最低的要求

我觉得协同是自己遇到最难的一点.

反思: 遇到沟通协同困难的时候习惯性退缩,苦恼,激动,自我设限. 

改进: 

        1. 自己的计划task是否完整. 在有计划的前提下才能有信心向上要求资源和帮助. 才能协调优先级.才能跟踪

        2. 精进型任务需要其他端人力投入进行case分析,一旦分析过就要有能力把噪音过滤掉. 不然下次再要求投入就很难了.

事情落地能力:

  1. 可见下的计划性,根据task约定时间,如果不够,向上要人力,

  2. 不可见下需要其他端人力case分析精进,并且必须要噪音过滤. 持续性要求投入分析.

容易陷入的坑:

1.  早会只抛问题,抛风险,感觉抛出来老板知道后就可以了.  抛出后, 具体对风险的action是什么, owner不管了, 需要老板定下来, 要么改时间,要么加人.

 2. 只关注action,没有数据支持,可衡量具体化.

 3.  action执行者不把自己当owner, 依赖方需要管理,时间点,和过程风险暴露和解决. (自己经常遇到的坑)

 4.  不要对别人有要求,你缺失了什么信息,你需要主动了解,首先你得知道对方角色应该干什么活, 不要抱怨, 事后再委婉提出. 慢慢你就全才了,成长了. ( 流程不一定在团队内强制,比如需求评审, 但是自己可以主动找产品要缺失的东西,首先你得知道要哪些东西,你得是个好产品. case1: 快捷方式. 技术人人都是产品经理,如何需求评审 我犯的错误,之前大公司流程多,产品专业,要做什么东西,沟通比较好. 到创业公司,经常遇到信息传递不一致, 首先就问对方技术, 需要哪些接口. 以为对方技术对全体了解. .  case2: 抽奖,要求产品了解有哪些活动借鉴,知道有哪些系统. 把方案喂到嘴边 ,同上.  case4: 测试给不出排期和细节的testCase testCase 怎么写)

另外一篇自己总结的文章: 工作方式 ,另外一篇项目跟进经验总结,工作方式,职场核心素养

风险 :

         1. 项目的信息沟通要在各个层面保持一致.

             1.1 需求沟通,正向说反向给产品说  1.2 接口设计调用流程沟通,给设计者说 1.3 代码review,熟悉业务的人代码review. 画出各种if else流程图.  1.4 和测试说,重点风险点,各种case.  帮忙写testCase, 然后归并testCase.

项目四层级:

   1. 目标,可衡量

   2. 时间轴和人 (接口人非常重要,跨团队合作的时候,分组. 任何东西一多,就要结构化, 金字塔思维. 人,事,逻辑学.)

   3. 变化,风险点和风险最终解决方案.

   4. 细化action,谁做,时间点,进度和风险.

类似周报: 1. 分结构流水账  2. 问题和反思. 3.下周最重要三件事.

项目整体流程: 

1. 文档wiki 地址,随时更新. 先定目标和预占人,由技术owner提出, 团队master(负责所有项目的调配)知悉预占人力(按迭代计算),大体时间点. 晨会上每日报备方案变化,人力变化导致的时间点变化.

刚和达成共识. 项目,两个阶段: 

   1. owner 立项阶段, 给出立项阶段时间轴. 在产品方案确认的前提下给出项目相关开发人员,粗粒度全流程时间轴.  以便 master明确所有项目人力冲突. 以便PO了解全貌. (what when who process how. 没有 why和where 5w1h法,how,what(which),when,who,why,where .加个进度process, 之前写文章都是 时间地点人物 ,实际上是7要素: 时间、地点、人物、起因、经过、情节、结果。)

   2. 详细设计阶段, 明确全流程细节时间轴(含灰度,全量),人力. 

   3. 立项阶段各时间点有owner设定,并让相应方给出承诺,如果相应人员给出时间点和owner确认时间点有冲突,那么晨会汇报风险,需要人力调配. 3.1 自己心中有时间点,人,事情  3.2 每天过程管控,提醒,要承诺.

另外每日提醒也是重点,每日跟进. 不跟进无结果.

2. 团队联系人 ,方便互相找人,wiki

3.  各个系统了解,边界,交互接口和字段.

     这块好几个项目都出现这个问题. 技术方案粗预估ok,不需要工作量,但是实际执行中发现很多问题.

     这个需要整理出交互图(h5,natvie, 两个服务端系统之间),然后每个交互上写明 现有的接口,核心type字段,用于逻辑.

    ding ,交互.

    各端的接口的人自己负责,项目负责人负责收集.

   方案要早点确认?   1.一开始h5, h5觉得不急, 就慢点.   2.但是真正方案调研下来,可能就是要走native, 然后又跟着发版走. 统一跳转 ,jsapi

4.  分布式事务一致性,量级风险(流量-降级,存储-分表,内存), 安全风险(https,中间人攻击, 免密登录, 一机一秘钥).

6. 业务流程,了解,边界.

7. 晨会,问题.

8. 排期模块 排期模板

8. 产品异常流程.

         1. 一个用户 新建,查看,编辑流程. 1.1 一个用户新建两个相同的.(不能创建会议名相同的) 2. 两个用户,同时新建冲突检测 (预约不能冲突)

         2. 技术上的中间态, 显示支付中. 审批提交中,审批已提交. 都是审批中. 

         3. 各种状态的流转. 我的预定页面. 状态 (审批单,非审批单)

9. 状态不可逆转. 存储上不可编辑.新建一个新的.设置为新建中,老的数据设置已删除,不给用户展示.

10. 每个问题都要有owner和时间点. 时间点管控是最好的管理方案. 但是细节在于这样才能过程管控.互相之前的资源冲突才更好协同. 早会才能更好得暴露资源瓶颈点,风险点.

    不要最后才暴露结果. 大家更主动暴露问题.

      初审

        交互图,双方产品,定稿 双方技术owner初审,给出意见. (一起或者各自,有时间点,有纪要) 状态流程 各状态下的增,改,删,查交互设计. 多角色交互的逻辑. 交互和需求评审( 产品约会 ) 交互图,各状态,需求评审一审(最好双方技术相关人员到场,一起评审,面基), 反馈评审意见

         状态流程 各状态下的增,改,删,查交互设计.

        多角色交互的逻辑. 各角色的查看逻辑

          每个流程走查后的状态. 交互图

           需求评审如何评审状态?  很简单,思考下每个操作后,1.当前用户如何感知,各个入口查询的值是什么. 2.另外一个用户如何感知,各个入口的查询值是什么 3.另外一个用户能否操作,操作冲突是什么

       二审(如有必要) 一期角色交互不清晰 业务状态不清楚,各状态的交互不清晰. 交互需要定稿 技术评审( 技术owner约会 ) 出模块交互时序图,参数,字段,技术方案评审. (双方服务端,端,一起评审沟通) pc和手机技术评审分开. 这个时间后,出task和时间点. 明确时间点,aone上标识总联调时间点, 服务端上线时间点,端封版时间点.

         变更 一旦交互主动变更,对应的时间点就需要变更,

    早会,钉钉po周知.

项目角度要求, 按迭代走:

1. 有wiki (开发维护,需求稿 需求审批后由提供)

2. 需求交互锁定, . 测试依赖该交互进行设计.

    交互图(边界时序图),字段 接口文档,细节字段.

有时间轴.

     联调时间点 发布时间点. 灰度时间点

晚会:

     同步时间轴(服务端必须在场) 一起对焦现有问题 临时依赖进来的必须,添加进依赖

发布安排:

       依赖方,发布顺序, 服务端灰度时间点, 全量发布时间点.

  1. 时间点. 立项时间点 需求评审不明确. 技术评审点 联调时间点 上线时间点.

  2. 需求评审和技术评审随意. 信息同步不畅,技术方案各端开发未确认.

重构:  

   问题:
1.       周期长,不可控.
2.       改动较大,上线压力大.
3.       大功能入手难度高
4.       重构方案太重
 方案:
1.       小功能入手.
2.       边界和依赖整理出来,被依赖方先行.
3.       不对内部重构,重点理清边界.
4.       后流程,支持模块先行.
5.       不要转换为枚举值.

推进能力提升:

  1.每日周会,信息公开.  (1.不仅仅是大家互相了解,一个小组内你都不了解,那就更没成长了,一亩三分地. 2. 对领导来说,表扬 3.信息公开 4.跟进 推进)

      

  2.长期项目,业余时间.

      每周定时间点,汇报. 要求对方找你.

代保养:
问题:
1.       各开发没有时间了解需求和设计.边开发边整理细节.
2.       项目负责人和开发之间对需求和设计的沟通较少
3.       项目负责人整理的task太粗
4.       小组间对接口沟通,状态沟通不顺畅,理解不一致.
5.       依赖接口等待较久,变更后返工.
方案:
     1. 大的项目项目负责人先初审,了解背景,流程.然后内部沟通后.然后全员参与对应的需求评审.
     2. 项目负责人产出:
                     1. 各流程模块和用户交互图
                     2. 实体和状态机设计.
                     3. 和用户的边界的接口字段要整理出来. 避免设计笼统,实体设计不符合需求.
                     4. 大的task整理. 新流程,原有流程变更.
                     5. 前置条件明确,特别是自动流转的状态.例如分润.
              其他责任:
1.       基于需求文档转述流程,需求. 整体会议.
2.       详解实体设计和状态设计.整体会议.
3.       将拆解的流程交互单独找开发沟通. 不要整体会议.
     3. 开发责任:
                   1. 解析需求文档后整理对应的流程复述给项目负责人听.(项目负责人和开发之间的双向交互)
                   2. 基于项目负责人的设计复述各个流程的读写逻辑.(项目负责人和开发之间的双向交互)
                   3. 整理细节task和时间预估. 最好是以交互图的形式展现. 通知司机端,乘客端(文案). (开发主要责任)

                   4. 约定好需要对方提供的数据,需要和提供方沟通每个字段. (双向交互,单独沟通)

管理上:

       1. 向上管理预期.  别人没有义务来了解你  2.管理自己的预期, 三层预期. 预留自己提醒和沟通时间, 通过提醒及早达到自己的预期

对接 phoenix 问题:

     1. 新人指导沟通时间安排

     2. 新人任务安排力度粗,没有每天晨会沟通.

     3. 上线没有打提前量,很多准备的东西都可以先准备.

  优点:

      各种开关 bug, 路由规则,新老数据兼容性. 开关.