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

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

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

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

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

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

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

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

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

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

另外一篇自己总结的文章: ,另外一篇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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