团队快到40个人了，除了SOC被我叉的比较多一些之外，自认为打辅助还算可以。技术方面也已经总结过数据安全架构的玩法了，今天再来总结一下关于项目管理与团队相关的经验。
1. 团队
这里聊一聊在组织架构之外形成的一些虚拟团队（你可能已经组建了相应的部门，但还是有些东西需要去做）。虚拟团队一般是因为在HC有限，或者团队已经到达一定规模，但仍需要进一步建设安全团队时成立的。
- 安全BP
成为业务线的接口人，每条业务线通过安全BP输出安全能力。在技术-运营-管理的三角模型中工作内容更倾向于运营。BP可以是一个虚拟角色，并组成虚拟团队。其中大部分成员应该自应用安全Team。需要对外建立一定的技术信誉，实现背书。内部可以由安全架构师对BP进行培训，并整合安全平台的能力，使其既要明白应用安全和SDLC的事情，也要知道Cloud & NetSec以及Security Platform的能力。通过BP使Policy在Release之后可以有效的起到约束作用。 - 安全治理委员会或信息安全委员会
虚拟团队，最开始去促进成立安全治理委员会的时候，是因为感觉到架构组的安全架构师参与度不够。后来发现安全治理委员会还能够评估来自管理层的不合理需求并被有效的拒绝掉。安全治理委员会成员来自安全架构组的架构师和各组的Team Leader以及Head Of Security以及再高一层的人员构成。在这个过程，Head作为组长起到负责方向把控的作用，架构师评估方案的合理性或者给出设计的方案。由所有成员共同表态完成一次会议讨论。并在之后由各个Owner安排相关人员完成具体任务。最近在审查一些厂商（非安全业务）的安全及合规能力时，发现大部分的企业在PR中确实会在CISO下面设立信息安全委员会，来完成相应的工作。 - 红队蓝队
成立虚拟团队完成红蓝对抗，用来检测防御能力并以工促防。还能有效的发掘到业务盲点。或者说灯下黑的东西。比如密码中包含公司名称类的弱口令。通过实施常规化的钓鱼演练和安全考试促进员工的安全意识。针对每次攻击后进行事件复盘，形成整改项。设计新的解决方案，并制定长期目标。（管理上的话就是一套一套的）
一个凝聚的有能力的团队是做事的开始，个人从0-1的过程固然有成就感，但团队的方式更加高效并使得个人具备归属感，团队具备荣誉。我总结了可能会导致团队变得内耗和效率低下的几个点，是需要避免的：
- 挑能干活的压榨
- 表现的很忙
- 信息差很大
- 只看结果（看结果是好事，但不能只看结果，也要关注过程，责任人）
- 工作氛围不匹配（外企内去卷，卷逼企业里装外企人）
- 不许讲话
- 把下面的活揽给自己做（推荐每个leader阅读《别让猴子跳回背上》）
会议是一个简单快速的沟通形式，可以解决信息差。但是大部分时候开会变得臃肿了。除了早会，周会，还有对内的对外的，月度的，季度的。让我想到一个笑话，一个老板在分公司招了个经理，在每天开会之后结果反倒不如之前。当然，这可能只是一个笑话。开会依旧是最快速的沟通方式，或者说电话，面对面的沟通是快速的。但每次开会前一定是要明确好主题，议程（quick call除外）。沟通一方面可以降低信息差，一方面可以提高合作效率。如果能够在一次会议上拍板的事情，就不要分两次去解决冲突。我们team现在每周有两次快速早会，时间在10-30分钟。安全治理委员会每周有一个placeholder，有议题就开，没有不开。内部team leader周会，以及同外部业务方负责人之间的周会在1h以内。
其他几个不举例子了，记住就行了。
2. 项目
最近对于项目上只有一个三方依赖是个比较大的问题点。
立项需要通过安全治理委员会评估，如果是安全架构组之外团队设计的方案需要通过架构的review。在立项后需要PM进行追踪，在每周周会上同步进度。而针对采购的产品，很容易出现一种情况。就是一旦产品出现问题，绝大部分时候只能去开case/ticket。但像微软这种大型企业，针对你的小小需求，或者小小的bug。快则三五个月，慢则一年以上才能解决。等解决了的时候，人还在不在都不敢确定了。对于这种情况，需要在方案设计之初尽量的暴露问题，并评估采购的产品是否符合基础要求。避免买回来之后发现某些地方不符合。现在公司内的产品采购，就是需要通过安全评估的。当然这些还都是对内的，对外的话哪些项目能够体现安全团队的价值。为业务方带来了什么收益，客户的满意度是什么样的？这些都是运营部分，运营往往开始于项目结束的时候。
运营是一个严肃的话题，但往往被不严肃的对待。我个人曾经比较讨厌运营，认为充满了重复和无用劳动。以为做了架构师之后会减少运营的工作量，但实际上即便做了架构也是离不开运营的。例如安全咨询，架构评审，方案推广（营销自己的方案）也都是运营。怎么推广自己的方案，让别人能够理解。确保采购合适的产品之前一定是需要说服相关利益方的以及如何建立起相应的技术背书等等。除此之外还有很多细节，例如买的产品有被用起来吗？用户使用姿势正确吗？客户满意吗？是去培养用户习惯，还是符合用户使用习惯？最最重要的是，当你根本没有那么多预算和人力的时候，问问自己，你的运营能做到什么程度。有哪些指标可以衡量？
3. 总结
在最初的时候，感到架构师对安全内部的参与度不够高，所以和Head of Security建议并成立了安全治理委员会，当时也是秉着提高内部信息透明度，降低信息差的初衷。后来发现即便如此，也不能够使安全架构师有效输出，因为提高信息透明度只是参与的第一部分，参与了不一定意味着有输出（划会的同学可能深有体会）。因此一定是需要使架构师能够有效的输出，将方案通过安全治理委员会输出出来给到各个team leader，使其能够落地。之后进行demo或者其他形式进行验收，确认符合要求后关闭项目。
很多时候我们挑到了一个问题点，就洋洋自得，认为别人的项目做的不好。实际上别人可能已经做了80%，而你只是发现了1%的问题。当然不是说指出问题不好，而是说万万不应该产生这种心理，更不应该在不了解那80%的情况下因为自己的一点点小小发现得意忘形。但这好像又是某些人的乐趣所在。
不会，就去学习。根据吉德林法则，把难题清清楚楚地写出来，便已经解决了一半。学习是没有那么难的。
一个团队内，不会还不学，动不动就抱怨问题，总是话分两块，你聊需求，他说实现难点，你聊技术，他说用户体验。以前不知道，可能自己在刚开始工作的头两年也有这个坏习惯，当然也可能因为位置和视角不一样。现在才发现，这种行为在Manager内心可能会显得非常不专业，也明白了企业内为什么大家都是很容易被替代的。
我又看了几遍，还是要坚持做好自己，经常反省。后面有空再总结一下SOC的文章。