大家好，我是孙冲。这次分享是我从技术转管理后，经历的一些项目管理和敏捷转型的实践和经验总结。希望能对一些初步转管理，刚涉及项目管理和正在尝试敏捷的团队提供一定借鉴的思路。
主要由以下五部分内容组成：
- 以现在的角度重新去看过往的一些项目
- 第一次真正实践敏捷
- 再一次尝试敏捷
- 经历敏捷的实践后对敏捷的一些思考
- 最后是概述总结
主线
在整个分享过程中，主要穿插着两条主线：时间线和能力线。
时间线分为三部分：
- 第一部分是2016年-2018年的一段项目经历。当时的背景是，没有转型管理，没有项目管理经验，没有敏捷常识知识。
- 第二部分是18年到19年的一段项目管理经验。当时的背景是，刚刚开始转型管理，项目管理经验较少，第一次尝试敏捷。
- 第三部分是19年到现在。自己已经完成初级管理转型，项目经验也有了一定的积累，开始第二次尝试敏捷。
第二条主线是一条能力主线，并且随着时间主线的延申，能力主线也在不断变化。
从管理能力(对下管理、对上管理、以及平级之间的竞合关系)，到项目管理能力，再到敏捷项目管理能力。
第一章：回顾以前的项目经验
好，我们开始第一章节，回顾以前的项目经验。站在当前这个位置，回望自己16年到18年的印象深刻的一个项目。
这是一个内部项目，CRM客户管理系统，级别很高。公司不是矩阵架构，各个职能部门之间进行协调配合，所以没有真正的项目经理。
再就是开发在青岛，但是测试、产品和前端都在北京，是典型的异地沟通。这个项目迭代两年多，自己一个人差不多维护了近两年。所以我被称为活文档，甚至说比产品更了解当时的这个系统。
那么在以上这些背景下大家能够预料到存在哪些问题?
第一个现象：估工时，砍工时
各种”O“大大们强调30天后必须上线，我作为开发估了50天，
主管看后砍到45天，经理看后砍到35天。最终”O“大大们接受了从50天压缩到35天的这个事实。我也间接为自己多争取了5天时间。
第二个现象：级别差距悬殊，没有话语权
上面提到了各种”O“直接提需求，好的方面是系统等级提高了，不好的是领导的需求提过来基本没有还手的余地，更别说是中途改需求，加需求这些事情了。
经常是我们非常不理解领导层这么快上线的初衷，也就是不能够明白这一次迭代的价值。
第三个现象，因为主要是我来维护，所以问题理解程度有的甚至比产品更深入
请假后，自己越想没事，往往时刻盯着群里。第二天去公司已经发现有很多问题需要回复和处理了。
第四个现象，会议多而长
因为是异地沟通，再加上需求的频繁变化和没有实质的项目经理，所以基本是面向产品开发，产品指哪儿我就打哪儿。
我们经常是临时拉起会议，然后讨论一个流程上的问题。有时也会组织一次会议，专门讨论需求，但是会议的效果不理想，经常超时，讨论进展缓慢，每一次会议产生的成果也少，很多时候我们就一个问题深入讨论很长时间都没有结论。
关键是我那时对会议超时反而觉得自豪，心里想：看呐，我们讨论的多激烈，这个项目多复杂，需要我们来回讨论好几轮。
大家经常参与会议的应该会深有体会，预定会议室，协调各个工种人的时间，会议上讨论，没有讨论完的继续预定下一轮讨论。再加上我们时异地沟通，其中的沟通成本可想而知。
其实这些现象对项目中的每个人而言都是一种煎熬。表面上我们看上去很忙，实际上我们的产出价值有待商榷。
期间我至少有两次机会可以转型管理，因为对这个项目太熟悉了，但我印象中的两次都失败了。
我一步一步越陷越深，直到我自己都有些迷茫了。我到底要不要转管理?转管理这个问题是充满诱惑的。转，是一种瓶颈突破。不转，可以全力投入技术。
越迷茫越纠结，越纠结越迷茫。我纠结着很多问题，比如：
现在的我再来看这些问题我已经有了答案。有几点总结吧，首先我认为转管理最好自己有转管理的意向，其次可以看一些管理认知方面的书籍，如果有人指导一下更好，最好的情况是有行政命令，逼迫你必须转变。
第二章：初始敏捷，小试牛刀
现在我们再回到时间线，进入第二段：18~19年 敏捷小试牛刀。
18年进入到轮子科技，自己开始了带人，也开始学习带项目。这个转型过程也是让我印象深刻，简单举出几个例子。
1)重构32个接口是怎么回事呢?
在我第一次成为项目经理时，内心是激动的，幻想短时间内打造一个优秀的项目。
这个项目叫”产品中心“，我在这个项目重构后的1个月后接手。没几天我就像领导提出要重构对外的着32个接口，领导应该当时很诧异，只是说一会要去开会，让我回去等等。这一等就把我再次重构的热情降了下来，因为业务系统开始慢慢对接了，后续的需求迭代也开始了。
2)中台会议连环发问
当时我们在讨论一个中台战略的项目会议，现在我称之为杰哥的人在会上强调了10条建议。我为了显摆自己，针对这10条建议，一一进行了反问、诉苦。
会议让我带跑偏了，成了我的抱怨会。因为刚刚成为项目经理嘛，遇到很多问题自己总是认为不是我的问题是其他人的问题。
3、瀑布模式的痛
第一次做项目经理，比较没有自信，也比较天真。难的任务给自己留下了，一些临时任务也没敢往下分积压在自己这里，例会也没有抹开面子去开。
这一次迭代，就迭代了2个月，第一个感觉就是项目快失控了。第二个想法就是测试别测了，赶紧上线吧，真的快被折磨疯了。
有时候会对自己很失望，啥也不会。有时候会对其他人很愤怒，怎么这么多事。
一个是漫长的瀑布模式，一个是欠缺的项目管理经验，都让我走得很难。在这个版本结束后，我第一次接触了敏捷相关的一些理论。
4)尝试敏捷
是的，我们开始尝试了敏捷。我们学站立会，学估点，学使用面板，学使用短周期迭代。这种方式我们尝试了2个版本，每个版本基本一个月。也算是积累了一些东西。
项目概况模板——算是阐述这次迭代的核心点和注意事项。
检查单——这个主要是弥补项目管理经验的不足。
打分模板——这个我们虽然打了分，但是每个人对打分的理解完全不一样。
总结模板——我们每次项目迭代后虽然开了项目总结会，但真也就总结一下就完事了，完全没有形成闭环。
所以我后来就想形成闭环，这一次迭代做了总结然后形成电子版记录，下一次迭代总结会上会再拿出来，对承诺的一个提升点进行盘点。
从上面这四个小案例，现在的我再去看那时的我。会发现当时我转变一下思路，很多问题其实就会迎刃而解。
关于项目管理，项目管理本质是管理好项目，让项目顺利上线。如果我当时拿着这条准则去做，那么很多事情我会安排下去而不是积压在我这。
1)这期间我也对向下管理有了一些新认识
如果我好好分配自己的时间，给新人一些压力和指导，那么他会成长快一些，反过来还能承担一些工作，我就可以有更多的时间去做其他更重要的事情，这是一个良性循环。
2)我也对同级管理有了新认知
以前我总是比谁的技术厉害，同级之间是攀比竞争。现在我觉得同级之间很多时候需要互相支持。竞争也算是一种学习，我觉得你项目中好的东西，我可以拿过来尝试一下。
3)那个时候对向上管理认知不够
以前总觉得领导就是必须主动关心我，如果不经常关心我我就觉得自己被抛弃了，被忽视了。
4)对于心态
如果我当时多站在业务系统的角度去看问题，就会发现很多的问题都是可以理解的。
比如：他们上线前几天才通知我加接口。如果我抱着服务的态度去解决这个问题，就不会那么消极。
为了避免后续再有这些问题，我会建群，提前关注业务系统的项目动态，经常群里问问他们的迭代计划。有问题解决问题，而不是抱怨。
经历了职能转型，项目管理转型，初步尝试了敏捷后，有收获也有惨痛的教训。当公司提出想做敏捷转型，我们开始做试点，于是我们又一次踏上了敏捷之路。
第三章：再次开启敏捷之路
在重新开始敏捷前，我自己看了很多资料很多书籍，对敏捷有了一个全局观的认识。
在看书期间也发现了我之前道听途说的一些敏捷是错误的。也发现我们第一次实践敏捷的时候没有准备就上路了，所以很多东西并不知道其中的价值。
我从书中总结，现实中再去实践后，又有了一些收获和思考。
1、物理面板
优势：
- 在物理面板前一战，确实显得正式有仪式感。
- 成员会主动贴、移任务，能够关注到自己在做的需求。
- 粗粒度看到项目整体概况。
不足：
- 用户故事、任务、便利条慢慢占满了物理面板。密密麻麻的信息，此时的物理面板反而不够全局了。
- 视觉上的冲击很容易让我们分散关注整体，需求，任务的注意力。
- 字体小的话很难平和的心态去关注这些具体的任务了。
- 依赖物理面板可能会丢失项目过程中的数据。
方案：
1)坚持物理面板：
- 需要空白地方：玻璃墙，白板
- 需要同步好信息：项目需要一些项目数据的，所以同步到电子版是有必要的，每天的站会物理板拖动后，有个人负责同时拖动电子板(为了统计项目信息)。
2)使用电子面板：需要投屏，需要培养移动电子面板任务的习惯。
3)两者结合：电子面板及时同步物理面板信息。
2、产品列表和用户故事长远规划，可以粗可以细
产品列表按照优先级排列，里面有产品需求也有技术债。以前的我被灌输使用敏捷，需求必须转成用户故事。
现在看来，这只是一种形式，一种成员都认可接受的描述需求价值的形式。所以只要是成员能够理解这个需求价值到底在哪，至于怎么描述就看大家的接受认可度。
“我是开发，我想重构队列服务，队列任务隔离，各自处理各自的，不互相影响，好扩展。”
“我是运维，我想最好有一个导出按钮，这样响应客户速度快，我就不用每次邮件申请等待DBA导出了。”
“我是用户，希望你们提供一个接口，我能知道某个时间的具体税率信息，这样才能保证我每月的月初订单对账。”
建议：
我觉得描述完全没什么不妥，就看大家怎么看，哪种接受度高，从语境中能够认可它的价值。大白话一点，直白一点，不需要那么死板官方。建议第一人称，代入感强，身临其境。
我认为这个用户故事或者说需求没有硬性要求。合适的就是最好的。
难点：
难点在于找到团队成员大部分认可的一种表达方式。对产品的要求较高，几句话能够抓住读这句话那个人的大脑，让他跟着你的语境思考这个需求到底做了什么事。然后这个需求实现后能够带来什么。
3、计划
- 每一次提前做计划，大家的时间充分利用。
- 提前参与需求的讨论，理解需求的源来。
4、估算
这里的估算我们使用的后面的一种方式，理想工时。当然还有估点，只是我们使用得不够熟练。后面会慢慢尝试，对比两种哪种更适合团队。
5、开会
以前开会，自认为会议就是用来讨论的，一次不行两次，两次不行三次。期间一个大家否感兴趣的话题一出，群口相声来了。讨论确实激烈，但是时间过得也快。
既然是讨论嘛，时间长点就长点，大不了转战另一个地方再战。搞到最后，大家争论不休，会议不止，都很疲惫。会议上没人记录，会后没人总结。一些细节点，一些结论不久的将来忙起来渐渐忘记。
建议：
- 前期将一些重要的点可以先找相关人讨论对对。
- 会议找个资深的作为主持人，控制会议节奏。
- 有问题没事，记下来会有再重点细致讨论。没有必要妨碍后面的进度。
- 会后趁热打铁，把会议的问题去确认对应的解决方案。
- 同一天，最多第二天。把会议上的问题处理方案，发到群里广而告之。
- 不能确人的问题，记录好接下来持续解决。
6、评审
关于评审，我觉得作用非常大。评审会议需要线下多花精力对接讨论。主流程和难点都浮出水面可以再拉起会议进行沟通。
7、代码走查
关于代码走查的好处不用多说，这里代码走查的可以融合部门规范，树立良好的代码风格。同时可以检测出相关的bug。这个功夫要花在平时，不太建议拉冗长的会议，大家再会议上去找茬。
8、验卡
验卡，其实可以看作里程碑的交接。就是开发发起，产品验收的同时测试也在旁边。对主流程走通即可。不需要冗长的会议。人少建议工位前花10分钟走一下即可。
9、技术债
我们的系统随着时间的推移，慢慢会积累技术债。到最后往往是我们不怕新增特性，而是怕在原来的基础上需求变更。主要原因是技术债导致我们系统的扩展性和可维护性大大降低。
所以在平时迭代我们会将一定比例的技术债进行迭代(比例：1/6)
10、项目总结
总结如同反省，有反省有思考才会有进步的可能。所以可以和戴明环类似，使项目和成员在迭代中螺旋上升。这一次的项目总结，提出下一次的精进目标。下一次迭代项目总结拿出上一次的总结进行盘点，形成闭环来精进。
第四章：敏捷路上的思考
很多时候我都会到技术微信群里抛出一句“大家有实践敏捷项目的吗?”接下来很多人回复，有的回复“不好用”、“累死”。
我就在想说得这些人是不是真正了解过敏捷，又是不是实践过敏捷?
敏捷有标准吗?
在我看来没有~，我们部门四个团队试点敏捷，但是大家对敏捷的这些方法实践各种各样，顺序和形式各种各样。组内的项目成员对敏捷的形式又是一种理解。所以有时候感觉敏捷确实难以实施推动。
敏捷不是银弹
我一开始比较迷信敏捷，觉得敏捷是一个能解决所有问题的方式。
敏捷的价值
我们劈里啪啦实施敏捷，到底是图什么?
有一个共同的目标引导，自己能力迭代提升(认知、技能、沟通、主动性、心态)。获得更好的收入，更高层次的职级，升职加薪何乐而不为呢?
其实这也反推项目的成长，相辅相成。
第五章：总结
成长往往伴随着痛苦，谁不想在舒适区待一辈子。面对着社会压力，面对着家庭压力，面对着自己的价值实现,应该走出舒适区，重新定义自己。
1、业务和技术互相促进
技术人学带项目，会发现平时项目经理处理的事情表面上自己都会。但是一旦自己成为项目经理后发现事情不是自己想象得那么简单。你要考虑客户的感受，你要考虑项目能不能可控，你要考虑组员的成长。
你会拥有大局观，你也不再认为技术就是一切。总之会在业务和技术之间学做平衡。
2、平级沟通
与优秀的人一起工作是一种幸福。
3、向下沟通
技术人转管理会发现带出一个人很难，但是一旦带出来又很有成就感。
4、向上沟通
理解了领导也是人，领导也会有情绪，我和领导不是站在对立面，而是站在同一战线，互相支持互相成就。
5、项目管理
我认为项目管理是技术人的一种基本能力了。
6、敏捷虽然不是银弹，但价值无限
7、坚持做下去，持续精进下去
