上个月我司的产品老哥哥借了我一本王明兰的《敏捷转型》，读来颇有收益，故想在此记录一二。以下内容的例子是基于我个人真实经历过的事情，如有雷同，只能说大家都会经历这样的事情。
诚然我司也是那种天天嚷嚷着要走敏捷迭代，但事实上工作效率并没有如传说中那么高效。究竟我们做错哪一步了呢？
- 用旧的模式去经营新的东西
这本书中提到，大部分企业会在没有试点的情况下，将公司内部所有的小组都转化成敏捷小组，任命 SM，大部分 SM 对于敏捷迭代没有一个清晰的概念，在组织工作的时候，还按照原来项目管理的模式去经营一个敏捷小组，由产品定好什么时间内做完什么任务，然后 SM 再把任务拆分出来分配给开发人员。
- 完成一项任务需要多方配合
事实上，一个敏捷小组本身就应该具备独立完成故事点的能力。但事实上很多小组的成立都不具备这样的能力，比如做一个C端的优化，需要有能开发 APP 的人以及能够设计 UI 界面的人。我司将 APP 和 UI 作为公共资源来分配，一旦公共资源被多个任务同时抢占时，协同配合的效率会大大降低。团队与团队之间也需要花大量时间和精力去磨合。
- 不关心员工成长
没有设立良好的机制，能让实习生得到良性的成长，让经验老道的员工去发挥最大的能力。事实上，学习到更多的工作上的技能，渴望获得迅速地成长是每个实习生的心愿，如若在企业中得不到成长，很容易造成栽培了大半年的人才流失；而经验丰富的员工，由于在工作技能上就算已然达到熟能生巧的境界，亦很容易因为没有进一步的发展而成天得过且过。
- 管理层热衷给意见
敏捷小组在向上级汇报工作时做的风险评估，管理层喜好站在【权威】的角度上加以干涉，其结果不言而喻。
在敏捷迭代的工作中，令人反感的点还有很多很多。接下来我主要想针对我自身对于上述问题采取的措施。
- 不再让团队成员被动式接受任务
敏捷迭代最大的特点是每天早上都有一个晨会，一般我们会在晨会上对任务的进度进行汇报，以方便把控进度。后来我采取了晨会主持人轮流负责的方式，团队成员中，无论是开发还是测试，都有机会体验下在晨会中充当 SM 或产品的角色。此举优点有二，一是激发团队的主人翁意识。二是，主持晨会的同学会更容易将自身任务中遇到的难处拿出来和大家讨论，因为他必须向其他成员提出这样问题：
- 昨天做了什么
- 遇到了什么障碍
- 今天要做什么
- 有什么风险
-
条件限制导致一个敏捷团队无法独立完成任务时，更需要积极地与其他部门沟通，一起制定能够让工作更加顺畅的流程、规则、交接的文档等等。
-
SM 和团队中其他人的关系并不是上下级的关系，SM 是一个在团队中充当协调的角色。在我看来，就是把这群小伙伴看得比自己还要重要。既要关心他们的成长，也要关心他们在团队中是否感到愉悦。【存在感】这件事情，对于团队中的每个人来说都很重要。
-
在向上级汇报时，如果有风险点，要对风险的解决办法进行补充。如果不想被干涉，那就自己做好准备。
查理芒格曾经对年轻人在工作中应该追求什么进行了以下的回答：
好的工作应该满足以下三点原则
- 别兜售你自己不会购买的东西；
- 别为你不尊敬和钦佩的人工作；
- 只跟你喜欢的人同事。
看到这个答案时，我忍不住笑出了声。既是表达赞同，也是在嘲笑自己当前的现状。可是，工作是要与人交往的，难免会有磕磕碰碰，难以忍受之处。可是工作之于生活的意义重大，是我们不可割舍的。专注且开心快乐的工作，和自己喜欢的人一起，做自己喜欢的事情，还能赚到钱。这件事情是可以被努力且被成全的。只要你愿意。
网友评论