管理中遇到的问题--人,组织上的问题

当跨部门业务项目和技术项目很多时, 还在做手头项目,还未进入提测阶段,又要被拉去评审了,反响很大.

1. 如果你不反馈,组员压力就会很大,就会很不爽. 最终老大又会怪到你.

2. 另外你帮他们去计划时间,他们也会很不爽. ( 别忘记掉通知组员去设计和排期了.那就是你的不专业了)

     和主题无关的ps:

        组员成长最好是另外结合业务的成长,变成owner,解决bug背后的问题,避免再现.不要派活.

       owner的更重任务, 去熟悉更多的业务知识,接触客户,

           1. 去和客户聊,了解业务和需求,了解领域知识, 给自己提需求, 去解决问题.

           2. 发现系统中的问题, 征求大家意见, 看大家愿意不愿意接, 愿意的话才是被认可的. 才能去大概的规划, 估计, 落地.

3. 当一个项目在开发,另外一个项目正在进行的时候就用评审,排期. ( result,流程,气氛,能力的平衡 , 做到无所畏惧的时候,有能力预估判断 )

     result是最重要的,在流程不合理的情况下,要先牺牲氛围和能力,优先保证结果.  想法落地上可以自己去搞起来,力气要用在刀刃上.

     员工解决方案是,给每个项目排期给buffer的时间,这个时间buffer到每个task上,或者多拆几个task.

     (显得不专业), 但不这么搞又被搞死,项目经理的失职.

     方案一: 见效快,员工累. 逼着员工给出时间点和预期. 问每个人现有工作时间点和后续时间点.  (同时鼓励安慰某些有状况的组员,抱怨的组员)

     方案二: backup,主要负责人和次要负责人. 需要指定看代码评审期. 先理解实体,再从代码里读出细节流程.

     方案三: 可以因为其他项目了解需求,评审插入导致项目排期靠后.可以此为依据延后对应项目排期.

    

   方案1:

      1.0  组内沟通,明确back-up. 模块负责人和pair没有. pair做项目用,修复对应的bugfix.

      1.1  和老大沟通,明确人手不足.

      1.2  和产品沟通是否改变模式,逐个模块逐个模块上线. 但一起设计是避免不了的.不一起设计不知道问题.