聊一聊如何提升团队开发效率

  又是一年年底了,又到了忙着总结,忙计划的时间了,相信每年的总结计划里,大家都有提高团队开发效率的计划。列了一大堆提升计划和目标。然而,这些计划真的执行了吗?这些目标都完成了吗?

  过去的一段时间我一有机会就跟其他开发人员交流,并去试着从开发人员自身的角度去发现一些痛。有的开发人员抱怨限制太多,没有意义的事情太多。有的则痛诉产品一天3变,早上定的事情,没到中午,就要改。确实问题限制太多,束缚了开发人员的手脚。

  那么我们如何去发现解决这些实际的问题。从而真正提升团队的开发效率呢?

  让我们先回归本元,从单个开发的维度,去思考。假设:开发人员一天的工作时间是8 h,绝对开发时间是4 h,其他工作时间就是4h。那么如果想将一天的产出提高一倍,该怎么办呢? 有两个办法,1. 把绝对开发时间的效率产出,提高一倍。2. 绝对开发时间增加一倍。说到这里有些人可能会说,你肯定是疯了,或是这是不是明摆着的事情吗?其实分析问题,就是如此,复杂问题简单化。这是也只是一个假设例子而已,所谓效率提升,无非就是开源节流嘛。下面这个思维导图,会很清楚的说明,需要提升哪些,哪些浪费需要截流。

   

  以上都是从开发的维度,去头脑风暴的。基本不涉及其他任何业务上的效率问题,只讨论团队开发中的效率问题。虽然影响团队效率的问题,远不止这些。产品,需求方,流程这些效率问题也都很重要,不过,最好不要混在一起谈,否则,问题就会越来越复杂。

对于代码审查的认识和理解

  代码审查应该成为任何重要的软件开发工作中一个基本制度。并不单指产品程序――而是所有东西。而且代码审查也不需要花费很多的时间和人力,但它却能发挥巨大的效果。

  从代码审查里能得到什么?

  对于代码审查的认识,在代码提交前,用其他人的眼睛检查一遍,防止bug混入。这是最常见的理解,也是对代码审查的好处的最广泛的认识。

  但是,在我看来,这并是它最不重要的。人们确实可以在代码审查中找到一些bug。可是,这些在代码审查中能发现的绝大部分bug,很显然,都是微不足道的bug,程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。

  代码审查的最大的好处在于,如果你是程序员,而且知道将会有其他同事来检查你的代码,你编程态度就完全不一样了。你写出的代码将更加整洁,有更好的注释,更好的程序结构。因为你很在意别人对你的程序的看法。没有代码审查,你可能会认为,你写的程序基本不会有人看到,除非有人用到了,它不会给你带来同等的紧迫感。除此之外,还有一个非常重要的好处。代码审查能传播知识,培养分享的氛围。在很多的开发团队里,经常每一个人负责一个核心模块,每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序,他们从不相互交流。这种情况的后果是,每个模块只有一个人熟悉里面的代码。如果这个人休假或辞职了,其他人则束手无策。通过代码审查,至少会有两个人熟悉这些程序。审查者虽然并不能像程序的作者一样对程序和业务十分了解,但他会熟悉程序的设计和架构还有业务的架构,这个极其重要的。

 

  刚开始,大家在代码审查时经常会犯一些错误,导致很多麻烦,特别是一些缺乏经验的审查者,他们在代码审查的时候会给了程序开发者的很不好的感觉,最终导致程序员抵触代码审查制度。

  针对所有人的审查
    * 首先必须承认:审查者都是根据自己的编程习惯来评判别人的代码。所以很多编程上的主张都是一种个人观点。所以应该讨论它们的利与弊,提出你倾向的观点,迅速的在团队达成一致。

    * 对与审查者和被审查者,大家觉得有压力,感觉非要说点什么,非得找出点什么问题出来才好,别人都提出了点什么,自己多少也得说点吧。(完全不需要。只说一句“这段程序写的真不错。”就可以了)

    * 尽量使用提问或是建议,而不是命令。(“把这个变量命名成:user_id,你觉得怎样?”)

    * 请求说明。(“我不明白。你能解释一下吗?”)

    * 避免代码的归属之争。(“我的”,“不是我的”,“你的”)

    * 不要讽刺,嘲笑别人的代码,避免使用一些会被认为或可能会被认为是有关人身特征的词语。(“笨蛋”,“愚蠢”,“傻逼”,“二”)要把所有人都看作是有魅力的、聪明的、善意的。

    * 要明确。要记着并不是每个人都能理解你的意图。

    * 要谦虚。(“我不能确定——我们来分析一下。”)

    * 不要用“总是”,“从不”,“永远”,“毫无…”这样的修辞语。

    * 如果对于某个代码,有太多的我不理解或大家都有不同的看法,可以组织一个讨论会,或是技术分享,然后把你们的交流形成共识,总结成文档

    * 代码审查,不能时间太短,这样没有太多的效果,但是时间也不能太长。毕竟大家还有其他的工作要做。

 

  让别人审查你的代码

    * 首先要达成共识,理解审查是对事不对人。审查的是你的代码,而不是你。

    * 对审查者的建议表示肯定和感激。(“对,你说的没错。”,“谢谢提醒。我会把它改正。”)

    * 解释为什么代码写成这样,可以说明这段代码的业务逻辑。

    * 整理所作的改动,不必当场改掉,复杂的程序,也可以在以后的迭代中重构它们。

    * 努力站在审查者的立场上理解,同样也要努力理解作者的立场。。

    * 针对你感觉非常好的地方以及不是很好的地方与开发者交流。

    * 找出既能解决问题又能简化代码的方法,让代码变得简单。

    * 提出你的实现方案,但要表现出作者也在考虑这种方案。(“你觉得这里用一个自定义校验如何?”)

    * 程序风格样式和注释,同样也是代码审查的范围,而不仅仅是程序。

 

项目管理知识框架PMBOK(文字版)

项目管理知识框架PMBOK

 
项目整体管理[I](Integration)
1. 制定项目章程(Develop Project Charter)
2. 制定项目初步范围说明书(Develop Preliminary Project Scope  Statement)
3. 制定项目管理计划书[P](Develop Project Management Plan)
4. 指导加管理项目执行[E](Direct and Manage Project Execution)
5. 监控项目工作[M](Monitor and Control Project Work)
6. 整体变更控制(M)(Integrated Change Control)
7. 项目收尾[C](Close Project)
 
项目依据(Input)
     项目发起人或赞助人(Project Initiator or Sponsor)
          工作说明书(Statement of Work)
          合同(Contract)
     企业环境因素(Enterprise Environment Factors)
          组织文化(Organization’s Culture)
          项目管理信息系统(Project  MIS)
          后备人力资源(Human Resource Pool)
     组织过程资产(Organization Process  Assets)
          方针,程序,标准,原则(Prolicies,Procedures,Standards,Guidelines)
          确定的过程(Defined Processes)
          历史信息(Historical Information)
          吸取的教训(Lessons Learnt)
 

1. 项目范围管理(Scope)
     1.1 范围计划[P](Scope Planning)
     1.2 范围定义[P](Scope Definition)
     1.3 制作工作分解结构[P](Create WBS)
          范围基准(Scope Baseline)
     1.4 范围验证[M](Scope Veritication)
     1.5 范围控制[M](Scope Control)
 
项目成果(Output)
     顾客(Customer)
          最终产品,服务,成果(Final Product , Service , Result)
     组织过程资产(Organization Process  Assets)
 
2. 项目进度管理(Time)
     2.1 活动定义[P](Activity Definition)
          里程碑清单(Milestone List)
     2.2 活动排序[P](Activety Sequencing)
          项目进度网络图(Project Schedule Network Diagrams)
     2.3 活动资源估算[P](Activity Resource Estimating)
          资源分解结构(Resource Breakdown Structure)
     2.4 活动需时估算[P](Activity Duration Estimating)
     2.5 制定进度表[P](Sechedule Development)
          进度基准(Sechedule Baseline)
     2.6 进度控制[P](Sechedule Control)
 
过程循环(The Cycle) 
     计划(Plan),
     执行(Do),
     检查(Check),
     行动(Action)
 
3. 项目成本管理(Cost)
     3.1 成本估算[P](Cost Estimating)
     3.2 成本预算[P](Cost Budgeting)
          成本基准(Cost Baseline)
     3.3 成本控制[M](Cost Control)
 
4. 项目质量管理(Quality)
     4.1 质量计划[P](Quality Planning)
          质量衡量指标(Quality Metrics)
          质量基准(Quality Baseline)
          质量改进计划(Quality Improvement Plan)
          质量核对表(Quality Checklist)
     4.2 实施质量保证(Perform Quality Assurance)
     4.3 实施质量控制(Perform Quality Control)
 
过程结果(Process Result)
     变更请求(Change Request)
          请求的变更(Requested Change)
          批准的变更请求(Approved Change Requests)
          否决的变更请求(Rejected Change Requests)
          实施的变更请求(Implemented Change Requests)
     纠正措施(Corrective Actional)
          推荐的救助措施(Recommended Corrective Actional)
          批准的救助措施(Approved Corrective Actional)
          实施的救助措施(Implemented Corrective Actional)
     预防措施(Preventive Actional)
          推荐的预防措施(Recommended Preventive  Actional)
          批准的预防措施(Approved  Preventive  Actional)
          实施的预防措施(Implemented Preventive  Actional)
     缺陷补救(Defect Repair)
          推荐的预防措施(Recommended Defect Repair)
          批准的预防措施(Approved  Defect Repair)
          实施的预防措施(Implemented Defect Repair)
          确认的预防措施(Validated Defect Repair)
     可交付成果(Deliverables)
          可交付成果(Deliverables)
          批准的可交付成果(Approved Deliverables)
     绩效信息(Performance Information)
          工作绩效信息(Work Performance Information)
          绩效报告(Performance Report)
 
5. 项目人力资源管理
     5.1 人力资源计划[P](Human Resource Plan)
               角色与职责(Roles and Responsibilities)
               人员组织图(Project Organization Charts)
     5.2 项目团队组建[E](Acquire Project Team)
     5.3 项目团队建设[E](Develop Project Team)
     5.4 项目团队管理[M](Manage  Project Team)
 
6. 项目沟通管理(Communications)
     6.1 沟通计划[P](Communications Planning)
     6.2 信息分享[M](Information Distribution)
     6.3 绩效报告[M](Performance Reporting)
     6.4 干系人管理[M](Manage Stakeholders)
 
项目管理过程组(PM Process Groups)
     启动过程组[I](Initialization)
     计划过程组[P](Planing)
     实施过程组[E](Execution)
     流控过程组[M](Monitoring)
     收尾过程组[C](Closing)
 
7. 项目风险管理(Risk)
     7.1 风险管理计划[P](Risk Management Planning)
     7.2 风险识别[P](Risk Identification)
     7.3 定性风险分析[P](Qualitative Risk Analysis)
     7.4 定量风险分析[P](Quantitative Risk Analysis)
     7.5 风险应对计划[P](Risk Response Planning)
     7.6 风险监控[M](Risk Monitoring and Control)  
8. 项目采购管理(Procurement)
     8.1 采购计划[P](Plan Purchase and Acquisition)         
          工作合同说明(Contract Statement of Work)
          自制或外购决定(Make-Buy Decisions)
     8.2 发包计划[P](Plan Contracting)
          采购文件(Procurement Documents)
          评估标准(Evaluation Criteria)
     8.3 询价[E](Request Seller Response)
          合格卖方清单(Qualified Seller List)
          采购文件包(Procurement Document Package)
          建议书(Proposals)
     8.4 卖方选择[E](Select Sellers)
          合同(Contract)
          合同管理计划(Contract Management Plan)
          资源可用性(Resource Avaliability)
     8.5 合同管理[M](Contract Administration)
     8.6 合同收尾[C](Contract Closes)
 
项目生命周期(Project Lift Cycle)
     开始阶段(Initial Phase)
     中间阶段(Intermediate Phase)
     最后阶段(Final Phase)
 
 

 

循序渐进的敏捷-每日例会

  通过一段时间的推行,每日例会也取得了不错的效果,大家也都明白各自需要做的

工作事项。

  敏捷开发中的每日例会,就是为了确定下一天所需执行的工作,以最大可能地履行其承诺。 团队的每个成员都应该描述自上次会议以来所做的工作。  他们计划在当天完成的工作,以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或碍。 为了确保会议准时开始并在  15  分钟或更短时间内结束。 在此会议中,每个团队成员都需要回答以下三个问题: 

  昨天我完成了哪些工作? 

  今天我将完成哪些工作? 

  哪些阻碍性问题或障碍可能影响我的工作? 

但是,在每日例会实行的过程中也遇到了各种各样的问题,所以现在总结一下。

1. 会议无法按时召开

问题:以前是在早上开,但是老有人迟到,也无法硬性规定不能迟到。即使是大家都按时上班了,也会由于各种拖拉,导致例会不能按时召开。

解决:后来我们就放到了下午,下班前20分钟,提前10分钟提醒。这么调整之后,效果确实不错。所以确定一个大家都合适的时间,形成习惯和规律,坚持执行。可以有奖励和惩罚的措施。

2. 互不关心

  问题:刚开始大家都在各自说着各自的事情,做的多少,准备做哪些。一个人讲话的时候,其他人都在想着自己的那点事情。各自讲完一遍之后,大家对其他人要做的东西和问题还是搞不清楚。 

  解决:为了解决这个问题,后来每日立会就采用了抽查提问的方式进行改善立会的问题,基本的形式就是,在每日立会上,当一个人讲完了之后,随机抽取一个人进行提问,问刚才讲了什么,有哪里不明白的。这个人要明明白白说出刚才那个人说了什么,如果说不出来,就让这个人去向刚才讲的人进行询问和了解。别人都在一旁看着这两个人进行对话,直到不明白的人能够清清楚楚的说出来为止,如果说不明白,就继续问。一段时间之后,发现效果不错,大家的情绪一下子提升起来了,气氛也热闹起来了。

3. 描述含糊

   问题:立会上大家所说的话中如果存在含糊的词汇,就需要引起注意,含糊的地方,其实有可能就是需要注意的地方。比如“已经差不多完成了”、“这个任务有些复杂”、“遇到了点小麻烦”、“昨天弄点别的耽误了”,“有个地方有问题,需要重写”等等。咋一听,感觉上合理的,因为一些原因,导致今天的任务有所延误,也是合情合理的,但是仔细一想,导致这些问题没有被及时发现。这些地方其实就是问题的地方。

  解决:如果出现模糊不清的词汇时,停顿下来,追问一下,差不多是多少,哪个地方有问题,为什么需要重写,什么小麻烦??这样把真正的问题追问出来,及时的纠正和提供帮助,模棱两可的地方得到确认,避免开发人员带着疑问去开发。立会上不应该有含糊的词汇。不过需要注意的是在追问的语气和态度上需要把握一下,追问的目的是知道模糊的原因是什么,是为了帮助员工,为了整个团队的效率,而不是仅仅的去追究责任,增加压力。

4. 任务过大

  问题:任务挪动不了,因为没有做完。连续两天可能都挪动不了。

  解决:拆分任务,如果每天都挪动不了,会增加心理压力,产生沮丧感。拆分任务可以解决这部分问题。

5. 返工太多

  问题:由于没有明确完成的定义,所以刚开发完,没有经过测试的任务,就直接说完成了。导致后期返工,又重新花时间去改之前的bug

  解决:明确完成的定义,团队所有人达成共识。我们对于人物的定义是:经过了开发人员自己的测试和另一位开发的交叉测试(具体在前面一片文章有讲)。这个任务才算完成,才可以挪到完成里面去。这样就促使开发人员,必须自己的测试全面,没有问题。也能够解决开发人员不愿测试的毛病。

 

循序渐进的敏捷-交叉测试

   由于各种原因,团队人员换了一些人,新到的团队成员,由于对业务不够了解,对系统的代码和架构,也不是很清楚,很多时候测试也不到位,导致了一系列问题和bug。很多问题在我们看来都是不应该发生,或是当时如果仔细测试,是完全可以避免的问题。

  针对于这样的情况。我们进行了总结和反思,决定尝试加入交叉测试,来提高系统的质量。

  交叉测试的时间和范围

   迭代的功能完成之后,开发人员互相检查别人的功能和代码,并进行足够的测试,测试和检查的范围包括系统数据库设计、业务需求、解决方案、代码(注释、代码风格)、数据表等。

  交叉测试的流程

  开发人员在完成一个功能之后,找到另一个人员,进行交叉测试

  1. 讲解业务需求。

  2. 讲解解决方案。

  3. 功能演示

  4. 代码交叉测试

  5. 功能测试

  期间,交叉测试人员,随时提出问题和看法,尽早发现开发者在业务和设计方面的问题。

  交叉测试的优点

  1. 对模块的了解不只局限在一个开发人员身上,分担了项目的维护风险;

  2. 规范代码,至少在注释和代码风格方面能保障;

  3. 避免一个人思考问题和对业务的理解存在的遗漏或盲点,多一个人查漏补缺会避免不必要的bug;

  4. 确保所有的功能至少核心功能,都有两个以上的人测试到;

  交叉测试的缺点

  1. 交叉测试会占用开发时间,熟悉别人的功能和代码都要花不少的时间,我估计测试时间是开发时间的1/4至1/3;

  2. 队员水平参差不齐,开发人员和交叉测试人员对业务和代码同样不了解,这样就无法保证交叉测试的质量;

  3. 尽管花了很多时间,有可能还是无法保证交叉测试做完之后,测试范围覆盖到全部模块的业务,无法确保需求或是业务的问题;

  4. 交叉测试会导致开发者会不关心bug的责任问题。

  交叉测试注意的问题

  1. 交叉测试者一定要理解开发人员的业务需求和解决方案,这样才能达到了业务讲解和理解的目的,才能提出问题;

  2. 避免不讲业务需求和解决方案就直接进行测试,这样无法保证交叉测试的质量;

  3. bug应该属于团队所有成员的,不应该由某个人来单独负责,bug也作为一项任务;

  4. 关键性模块才进行交叉测试,这样既避免了交叉测试占用太多的开发时间,又避免了核心业务的不稳定;

  5. 尽量避免不了解业务的人员去给其他开发人员做交叉测试;

 

对一次系统上线的思考-走出“舒适区”

  今天,本来计划是会对系统进行一次更新,将这上一周做的需求和修改的bug 发布出去,然后明天开始新的计划,本来团队已经对这个目标达成了一致,大家努力的测试,争取今天能够上线。后来有一位负责的同事说,今天要是上线更新不了,就明天吧,反正我们也没有对需求方承诺具体的上线时间,明天再测试一天,没问题在上线吧。大家一想也对,干嘛非得逼自己今天就上线呢。明天上线不也一样吗?反正我们也没承诺今天必须上线。于是乎大家就这么愉快的下班了。

 

  但是,在回家的路上,越想越不对劲,我们什么时候开始给自己找借口了?我们什么时候开始害怕失败了? 我们什么时候开始畏首畏尾了?我们以前的拼劲,闯劲,打不死的小强精神哪去了? 

 

  原来我们找到了舒适区,每个人,每个团队都有自己的“舒适区”。在这个区域里,你会感觉很舒服,但是一旦离开了这个区域就会感觉不舒服。因为舒适区是由你的习惯构成的。

 

  有一本书叫《谁动了我的奶酪》,里面有一个很有意思的故事,一只小老鼠,找到了一块很大的奶酪,于是它就呆在那个窝里,觉得很舒服,慢慢习惯之后,一旦出去了以后,它感到很彷徨,很无奈,很恐惧,所以它就不愿意出去。这个窝就构成了它的“舒适区”。团队亦是如此,习惯的思维,习惯的行为构成了团队的舒适区,离开了这个区域,大家就会觉得不舒服。久而久之,整个团队就会变得不再主动,不在进取。慢慢的就变成了羊圈里的羊,温水里的青蛙。

 

  改变自己,变得积极,变得主动,变得进取,明确目标,达成一致,确定的目标,就要抱着必定的决心去完成。不再为失败找借口,不再给自己找后路。走出自己的“舒适区”。

对一个同事项目的思考和总结

  这几天,跟旁边项目组的同事聊天,下班的时候也一起聊些项目上的事。通过他的描述和我看到的一些情况。确实发现不少问题的。首先就是上线成功率不高。很少有一次发布成功的情况。大部分都是发布之后,出现各种问题,又得改bug重发。开发和测试流程不规范,开发人员很随意。然后就是各种技术风险。

  发布质量不高每次发布都跟打仗一样,每次上线发布,都要一两个小时,作为一个公司内部的web系统,一次小版本的更新,发布时间都要在1个小时以上,就足以说明很多问题。

  发布质量不高

  1. 发布的质量不高,没有进行系统的集成测试,每次都是开发人员测试通过之后,就完事了。没有集成测试的过程,导致上线之后,本功能没问题,但是影响到其他的功能。导致上线不成功,重新修改bug ,然后上线。

  2. 发布人员没有进行必要的冒烟测试,由于没有专门的测试人员,发布和测试的人员都是开发人员进行的。所以,发布人员,没有获取完最新的代码之后,没有进行必要的冒烟测试之后,就直接发布。导致很多时候,发布之后,网站直接不可用。这类问题,应该上线之前的冒烟测试就要测试出来。

  流程不规范

  开发流程不规范。开发的时候,有很多随意性,有些数据库脚本,没有在测试环境测试,直接就在生产环境中执行。或者本身脚本没有问题,但是影响到其他功能。开发人员只关注自己的那一块,没注意到修改之后,对其他功能的影响。

  测试流程部规范。只测试自己的部分功能,没有经过集成测试,就直接发布,导致系统发布之后,出现各种未知的问题。

  有些时候竟然出现发布完之后,开发人员还有代码未迁入或是发布人员未获取到开发人员所提交的代码的情况。这类问题,必须要有规范的流程。

  团队分工不明确

  这个项目可以分为apiweb网站两部分。但是开发人员对其定义不明确,职责也不明确。出了问题,所有开发人员都去猜测问题可能会出现在那块,所有的人都从前端测试到后台,做了很多无用功。如果分工明确,那么api 的去检查api是否有问题,web网站的开发人员去检查网站前端。这样就能快速定位并解决问题。

  技术风险

  由于这个项目用到了mysqlEntityFramework这以前没用过的东西,导致存在很多技术风险。比如mysql 所有的开发人员都是只知道一般的使用,没有一个对mysql 了解比较深的人,EntityFramework 也是如此。出现了性能问题,很多时候不知道该如何优化。

 

  思考

  1. 明确分工和职责。项目分块,专人负责。

  2. 优化开发流程,倡导代码规范,修改代码之前,确保没有其他地方使用到,团队对于哪类文件该提交哪类文件不该提交要达成共识。

  3. 优化测试流程,所有的功能,开发人员测试没问题之后,才算完成,提交,一定要进行集成测试,发布之前开始要求提交代码,并进行集成测试。所有的功能要在测试环境测试通过才能发布。测试人员发布的最终发布版本,要进行必要的冒烟测试。

  4. 消除技术风险,技术问题,交由专门负责人员解决,mysqlEntityFramework 这类交由专人负责并掌握。消除这类技术风险。

 

 

关于福建出差的总结

  前段时间,由于公司要上一个ERP项目,虽然请了专业的实施公司,但还是有一些需要沟通和对接的地方。所以几年都不用出差的人,终于出去走了一回。体验了一把出差的感觉,虽然回来了这么久,今天终于有时间把自己这一个来月的感受写出来。

  生活
  刚下飞机,福州给我的第一个感觉就是闷热,没有风的时候,到哪里都是很闷,很热的。福州女生的身材也不错,不过可能由于气候的原因,皮肤都偏黑。福州的美食还是很多的,海鲜,推荐碳烤扇贝,味道真不错。至于其他的游玩的地方,就是三坊七巷了还算不错。也不收门票,吃的也便宜,是个不错的好去处。
  
  工作
  由于福州公司新上了一个erp 项目,所以要去和福州的开发团队和集团信息中心做对接,
刚到Oracle Erp 项目组,见到了实施团队,他们给我的第一感觉是专业,由于他们都是专业的Oracle 实施团队,有着丰富的项目实施经验,虽然他们是技术人员,但是他们对Erp里面相关业务的理解都很专业,很透彻。同样是开发人员,不得不说他们对ERP 的业务了解的很透彻,跟我们公司专业的供应链沟通,毫无障碍,能清楚的知道业务中存在的问题和风险。
  还有就是Oracle Erp这个产品确实不错,产品功能也很全,功能都是通过配置就能够实现,二次开发也非常容易。不过易用性和用户体验确实很差,用户操作太过复杂。
  然后开发过程很透明,项目的各个阶段也很专业。我们到福州之后,赶上他们集成测试,把集成环境准备好之后,会把所有的项目核心责任人召集到一起,按工作流程和职责把整个大部分功能都过一遍。
  但是同样也存在一些团队管理上的问题:比如沟通协作,实施团队分为实施顾问和开发人员,有些时候实施顾问和开发人员也存在扯皮,推责任的情况。还有任务分工不合理的情况,有些人很工作轻松,有些人的工作却很繁重,还得和业务负责人沟通。

  来福州还有一项重要的事情就是和集团信息中心的配合,由于集团信息中心的数据中心调整,各个分公司的业务对接也得做相应的调整。就有一个系统遇到一个问题,我们这边的系统,调用以前的地址是正常的,但是调用集团的新地址,出现了一些问题。但是集团的技术人员,一直坚称集团接口没有问题,是这边的系统的问题。邮件,电话沟通了半天,也没有任何效果。实在没办法了,只能带着笔记本上他们那,一起把问题解决掉。同样是集团的IT部门,他们或多或少也存在着跟我们一样的问题。

  除了和福州的工作之外,北京还有一些工作需要处理,所以,在福州工作之外,每天下班前,还得和北京的同事沟通开发进展。也遇到了一些问题。比如在电话沟通过的工作事项没有后续跟踪,到后期,一些之前已经沟通过的事项,后来发现却没有处理。

关于公司内部培训分享的思考

  前几天和同事讨论如何在公司内搞培训分享,提升大家的学习,分享的意愿和氛围。其实以前也搞过一些培训分享,也有一些效果好的分享,不过大多数效果都不行,分享的内容质量不高,大家的参与的意愿不够强烈。也有些分享,参与的人不多,听过之后也就那样了。没有后续继续了解的意愿。还有一些由于分享人的原因,没有做到一个很好的现场控制。导致活动混乱,草草结束。可是培训分享又很重要,怎么做好公司内部的分享活动呢? 这个问题也困扰了我们很久。所以基于以上,对公司内部的分享活动做了如下总结。

 

  活动的准备:

  - 要提前准备会场,提前向大家告知要分享的内容,时间和演讲人,以方便大家回去准备,思考,和安排时间。
  - 要有宣传推广,提前邮件通知还不够,还要有海报等。海报比邮件更能让人记住。同时调动演讲人和大家的积极性。
  - 事先检查好设备。投影是否正常,有没有激光笔等。

 

  内容的准备:

  - 多讲目标听众不知道/感兴趣的内容。听众投入最宝贵的时间来听分享,演讲人最起码责任是保证听众在这段时间的收获。
  - 避免常见错误或者明显缺陷,自己不明白的地方最好不要讲。
  - 最好是分享自己清楚的,听众愿意去学习的。最好不要分享各个系统自己的业务。
  - 平日的大量积累。没有切身体验的死记硬背和摸爬滚打后的娓娓道来,听众的收获和感觉是大不一样的。
  - 提前安排一个人熟悉你的流程和内容,制作气氛,提问题等。说白了就是托。

 

  幻灯片:

  - 有时间的话尝试用新软件去设计幻灯片。
  - 所有元素风格一致。包括但不限于字体,色调,标点,对齐方式,动画出现退出的方式。
  - 一图胜千文。比较推荐利用信息图/数据可视化作品。虽然信息图已经烂大街了,但还是人民群众喜闻乐见的元素。

 

  排练:

  - 最好主讲人要提前排练,精心准备自己要讲的内容。保证内容烂熟于心,各种笑话和梗会被适时、自然放出。
  - 录制排练视频。镜头下所有的弱点都会被暴露,这个阶段超级打击自信。要改进的时候多看看TED talk。
  - 请有经验的朋友对幻灯片内容和表达给意见。他们能反映听众的真实感受。
  - 善用软件的排练功能。PPT的Present view能看到下一屏的内容,可以让你更好地连接上下文。
  - 计时。保证对时间的分配有清晰的掌握。避免前面的讲得细致入微,后面压根讲不完。

 

  细节:

  - 控制时间。假如不只有你一个人演讲的话,时间太长可能会影响其它主讲的时间。
  - 适当与观众交流。问问题等。
  - 永远站着做演讲。听众大多是坐着的,站起来有利于建立自信,营造一种对场面的无形控制力。
  - 不要跳页。跳页会让人感到准备不足,或者你并不熟悉此页上的内容。即使时间有限,也要用一句话概括。

 

  其他: 

  - 要长期保持大家的积极性,还应该有相应的积分奖励制度。
  - 必须保证分享的质量,包括内容的质量。
  - 保证整个分享流程规范,专业,这样大家也会认真投入。
  - 一定要坚持定期、定长、严格执行时间。
  - 对演讲者进行培训,指导。提高演讲者的水平和积极性。

关于开发和测试沟通的一些问题

1.分工测试,
2.不是每次都要测试全部功能,主要测试那些常用的重点功能,
3.尽量不要用电话,qq,也不要发现问题就找开发人员,要用邮件报告发给项目负责人,由项目负责人统一判断,安排,
4.不是随时报告,而是下班的时候统一发给各个测试负责人汇总自己组内的测试,合并重复的问题,提交给项目负责人,
5.每个测试小组每天的测试报告要连在一起,要有连贯性,
6.每个问题要标好功能模块,要有测试人,测试版本号,测试时间,截图,输入数据等。
7.不要把需求和问题混在一起,
8.测试报告中各种描述要清楚,明确。不要出现不好用,无效,等描述,