这半年来，自我们接手这个中心的管理后，采取了若干措施：

在组织层面提倡敏捷模式/让所有的项目都应用系统进行过程管理/完成职级职等的评定，一部分人调整了职级职等，涨了薪酬/尝试改进绩效考核模式，每月自评，主管评，开发负责人评/要求各部门开展能力提升工作 等等

对于这些事情的效果，始终心存忐忑，是否起到了积极的作用？

与部门主管X的沟通：

他表达了一个核心意思：

——别太折腾了，大家觉得在这里没啥愿景，就等着看年终收成怎么样呢，年底收成要不行，大概率是一波离职。

（Y前两天要求大家背诵默写敏捷宣言，后面还要背诵默写12项原则。在这一点上我其实是不赞成的，但他坚持要做。让办公室的打印出来，每人工位上贴一张。）

——别搞这个了，现在是不停的在给主管和开发人员提更高的要求，但大家并不能从中得到什么实惠，大家为啥要按这么高要求去做？主管操那么多心，但在待遇上并没有什么体现（去年的年终奖给得不多，答应涨工资的也是拖了很久，等等，）

——我们就想做个开发人员，说让干啥就干啥，要让我们站在用户角度思考问题（这样多累啊）

——不停的对我们提越来越高的要求，我们提出的问题得不到落实（主要是工资的事情，迟迟不给涨。很多人3年每涨过工资）

（对于背诵敏捷宣言和原则这件事情，我也觉得可能是适得其反的一件事。大家在形式上不知道如何做，每天关注的是如何完成手上的任务，他们还不到关注宣言和原则这件事情的时候——因为他们缺乏愿景，缺乏内驱力，就不会对是否敏捷感兴趣。

反倒是作为领导，更需要理解敏捷的本质而不是形式，要在制定规则的时候，在自己的言行中，贯彻敏捷的理念，而不是念着敏捷的经，做着和敏捷理念违背的事。

成员沟通时，更多的在传递负面情绪与消息，传递正面的较少。大家都习惯吐糟事业部负责人，需求不清晰，需求反复，吐糟公司环境，等等。较少说自己的项目什么地方取得了成功，有哪些进步。

有两个典型的项目取得了很多明显的成绩，如质量上的进步，通过迭代模式在整体上保证了进度，避免了传统模式下那些风险，及早的发现了需求上的问题等等，项目组并没有感受到，只是感受到了需求方的反复变更。——这个现象也反映出在组织层面缺少对里程碑进展的传递，说明项目组的回顾会开得不够成功，没有起到充电的作用）

通过两个小时的交流，X似乎了解到了中心确实取得了进步，对于治愈消极情绪有了积极的作用。

试点项目核心成员Z：

——在你参与的这个项目中，用天气形容下你的心情，现在是什么心情？

——最近这个项目快收尾了，心情算得上阴转晴，由开始的混乱，到后来团队磨合，还比较顺。

——给项目整体能够打个8分。

——对于中心的印象是什么？用一个词形容的话

——外包。

——对比中心这几年的变化，有什么感觉？

——对于这半年中心的变化，总体感觉上是积极的，一些措施让中心变得更有规矩了。有些过程中的问题也可以理解，是在尝试中改进。

——上次在自评中提到的不搞”形式主义“，具体指什么呢？

——针对技术分享说的，不能为了分享而分享，项目中的代码审查、设计评审等有意义，在项目中实际的一些技术研究、突破拿来做技术分享有意义，但没有结合实际工作的一些内容，也没人愿意去参加，就没必要搞了。

——如果将代码审查变成强制措施呢？

——有必要。这次项目中好多新手写的代码，埋了很多坑。（上午例会，项目负责人提到，团队中有非新手写的代码，也有很愚蠢的坑，如年月日的计算方法，导致出现了2020年13月这样的日期）

——对中心的建议？

——多些人文关怀。

——具体点讲？

——如去年，大家还去别墅搞了活动，撕名牌，唱歌，等等，今年啥都没有组织。

（很多人在自评表的建议部分都提到了团建，但管理层却一直没有回应。我作为其中一员，有很大责任）

新员工W：

不了解敏捷。敏捷开发，似乎说的是开发人员，不知道测试和这个有什么关系。

在自动化测试脚本的编写过程中，产品有些字段上的变化，如果有文档能给到最好了，这个应该是需求评审中要说到的，但自己没参加过需求评审（实际上就缺了需求评审，或者有需求讨论但没叫上测试自动化的人员，没在团队里面）

自动化测试证明有一些效果，在2.0中跑一遍发现了10多个问题。

新员工Y：

整体感觉公司很不错，能给到10多天的时间预先学习平台，而不是如其他公司一样给两天时间熟悉，然后马上就给安排任务。

在团队里相处得也不错。

很好了，还没什么建议。

在宾馆的讨论：
晚上在宾馆，发生了激烈的讨论。回想起来，我没有能够控制自己的情绪，这是一个致力于“教练”角色的人所不应该的。

之所以情绪激烈，是因为这段时间来，我反复提到一些问题，似乎没有得到理解。

——组织缺少愿景，导致员工缺少精气神

——让员工们每个月提建议，但却没有公开的回应

——作为事实上的一把手，自己亲自安排编程规范的事情（恰好是非自己擅长的领域），自己编写项目的工作流程（也是非自己擅长的领域），没有去解决中心的定位、愿景的事情，没有去更多的找事业部和所本部，解决外部环境与项目来源的问题？工作的重心、边界应该是什么？

这两天断断续续的交流，把以上的意思都说出来了，似乎得到了理解。

所谓“敏捷”，不是穿件“开发模式”的花衣裳。敏捷最关键的是，作为领导层，要理解其核心价值观与原则，并在自己的言行中践行。

不能制定与敏捷原则相矛盾的规章制度，不能只要求别人敏捷而自己不敏捷。

以前段时间因为绩效考核，引起一位员工离职的实例举例说明了Scrum中的勇气与开放的价值观的例子，也顺便解释了我在前两天写的开发中心的“we have a dream”中关于“关于公司、工作上的事情都可以公开讨论”的意思。

因为某位员工bug率较高，将他评为了待改进——这个评价过程没有与主管商量——然后员工自己并不认可，因为他工作中做了较多的技术难点的任务，最后虽然进行挽留，他仍然离职了。他原本就有离职的心思。这个其实是绩效考核不应该用单一指标去判断一个员工的整体情况，绩效评定的过程也缺乏，没有在确定之前与当事人达成一致，尤其是主管、团队的人都认为这位同事干得还不错。

我说，假设我们每月有一次面对所有员工的中心的运行情况的通报，我们有没有勇气在这个时候向大家承认这件事情是管理层犯了错误？而不是大家在下面私下里讨论？ 这正好体现了勇气与开放的价值观。

经过反复的解释，最后他大概理解了我的意思，达成的一致意见是：可以在这个时候，总结下我们这段时间以来取得了哪些成果，有哪些不足，再持续改进。

工作的边界

管理层的不同角色应该有分工，有各自工作的侧重点。而不能想到什么就做什么。

工作的优先级问题：有些核心问题已经显露出来，但却被搁置一旁，反而去做了一些本该交给其他人完成的事——其实质是在“捡软柿子捏”，觉得这个自己能下手，所以就先干。

以编程规范得事情为例。上周例会上有人提出了编程规范的事情，提了一些大家在开发过程中代码写得不规范，应该规范（我不在会上，大意如此）。因此会上提出要编写开发中心的编程规范。

会后Y问ZW，能不能安排一个刚来的实习生，去拷贝拷贝别处的编程规范，并且Y自己在网上搜了份编程规范。

我的反应是，这件事情安排给一个小朋友，干不好。而且，编程规范本来就有，只是执行得不行。

——这个编程规范，已经有了，只是执行得不好。用的就是阿里的java开发规范。（问ZW）我们是有这个吧？

——（ZW）是的。我们现在要求额得不严格，只是说要求大家用阿里的插件扫下自己的代码，没有严格的问题就可以了。

——比如，这个编程规范的事情，可以让ZW负责就行了。我们可以考虑如何加强代码审查。

（会后）

——你看，编程规范这个，恰恰是你不擅长的领域，你交给别人就好了。

——我不知道以前的情况。

工作的重心

谈到这种区域组织负责人的工作模式问题。

——他们在北京见到我总说，你怎么又在这呢。

——能不能每周在这边呆个3天，4天？

——主要是周一有个例会

——对啊，周一的例会开了，就过来，例会也就是双周才一次。在北京的时候大部分时间应该不是在办公室坐着。去找事业部领导聊天去。就像事业部的人一样，现在就去找客户，找明年的项目了。

——是应该这样，但要做到还是挺难的。有些人天生具备这样的性格。

（理解。我自己就做不到）但你坐到这个位置了，就不得不走这条路。

关于形式主义

——如背诵敏捷宣言，可能起不到什么作用。

——不背诵肯定没有作用。

——我担心的是背诵会起反作用，他们现在并不关心这些价值观，原则的东西，需要的是在具体的事情中带着他们去践行。本来大家就在反对形式主义，再搞这个更甚。

——起反作用我也认了。

——你认有什么用呢？做这件事情的目的是什么？

关于以身作则

这次我给周例会定了一个模板，将会上提出来要协调的事项，放在会议纪要中，写明白负责落实跟踪的人。

宾馆里的对话：

——领导需要言传身教，以身作则，哪些该落实的事情也要放到跟踪表中。

——管理层不能置身其中。置身其中可能有问题（忘了说的啥问题了）。

（你那还是传统的模式。想起了OKR的例子，一把手的KR并不是简单的经过拆分，每个KR由不同的副手一抗就行了。一把手有自己的KR，这个KR是别人不能替代的。）

我在周例会上特意强调，“这个跟踪表要记录的是需要进行外部协调的事情，如需要管理层出面协调的，需要跨部门协调的。部门内部的事情不列在这上面”

会议上提出的有两项符合这个，于是将其放了进来。在负责人一栏，我问“这个是谁来负责”，Y说他负责，ZW可能觉得让领导亲自负责还不太习惯，把自己也写了进来。我要的就是要将领导写在这里。领导不能只是对别人提要求，自己要践行“承诺”的价值观。