主要是针对管理经验的一些探讨，也是管理过程中经常遇到的问题的一些反思。
7.管理经验
7.1 项目的管理
7.1.1 项目是怎么来管理的？
答：项目是一个很大的概念，项目的管理的目的还是把这个项目处理好。
- 熟悉项目的人和事情
- 建立项目流程的规范，让其可以自动运转。也可以使其更加有效的处理。
- 项目的本质就是管理好，人，事情和自己。
7.1.2 项目是怎么来推进的？
答：项目的推进更多的是按目标和计划推进。
- 如果制定好了计划或者排期，就可以定期检查项目中的任务完成的情况，存在什么风险，需要解决的哪些问题等。对于影响推进的人和事情都尽可能的暴露，有一张计划执行表，这样每个人的目标都比较清晰，方便安排自己的事情。
- 如果目标很重要，但是还没有计划。甚至资源比较紧张的情况下，要推进这个目标尽早的制定计划和让项目的尽早落地。这时候需要更多的是，推进目标的拆分和目标的执行方案探讨，包括会议讨论的计划。
7.1.3 项目是怎么来暴露各种风险的？
答：怎么来暴露风险？这个问题也值得深思，我们经常看到事故产生很多都是一些风险没有提前暴露，或者说已经有风险的苗头了，但是重视不够，随着问题埋藏的越深,这样影响越大，甚至后面要解决的成本也就越高。 那怎么来暴露风险呢？ 风险的类别和应对的方法：
- 代码不规范引起的问题，代码逻辑的问题。这类风险主要是开发质量带来的风险。遇到这种情况需要加强的单元测试和代码的review，保证代码质量风险。还有就是开发人员培养和规范的完善。
- 紧急需求的插入的风险。这种风险，带来的问题，有些开发的进程已经执行，如果需要调制这样思路和要做的事情影响都比较大。一般遇到这种情况，采用异步事件机制。所有的需求都要进入需求池，并且需求池里面的需要需求的管理，如类别，优先级。最好有开发的预估时间等。产品的同学在要设计产品的时候，可以根据需求池里面的进行选取，来设计产品。也可以大概预估开发执行时间。这样开发的版本周期不是很大，也可以尽早的处理。
- 架构的风险，随着项目的复杂增加，改动的成本越来越高，并且改动带来的bug风险也是存在的。所以，从这个角度来看。需要尽早梳理架构的问题，并且要考虑需求的增长和非功能性需求的要求增加的处理。
- 商业价值的风险，这个是最难评估的，最好每次版本更新后,都追踪版本带来的效果。并且考虑版本的效果怎么样？以及定期跟产品，技术还有运营等团队沟通，反思问题的做的好的地方和做的不好的地方。尽早把风险解决。
7.1.4 项目是怎么来保证安全和目标达成的？
答：保证项目的安全，首先需要解决的就是前面提到的项目的推进，计划和风险。在建立日常的开发机制和项目架构的不断优化。这样就可以在一定程度上保证项目的安全。对于目标的达成也需要对目标的结果进行分析，看目标完成失败的原因是什么？是定的太大啦，不符合实际情况。还是市场不成熟，还是整个团队处理效率和质量上没有满足要求等。
7.2 团队管理
7.2.1 你是怎么来人员的招聘？
答：对技术的招聘其实还是直接的。主要是看技术功底还有就是非技术的了解。
- 技术功底主要看对技术的底层的理解，看对问题理解的深度，对问题的局限性在哪里。是否喜欢探索技术的底层机制和原理。重点还是极客这一块。
- 非技术的主要是对业务的理解经验，对沟通能力，对一些事物看问题的方式是否深刻。性格是否那种非常喜欢积极进取和乐观的处理事情的态度。还有就是之前的工作经历和工作的态度的思考。还有就是抗压能力，对于一些困难和紧急的事情，是怎么个态度来解决的。
7.2.2 你是怎么来人员的培养的？
答：人员的培养是润雨细无声的过程。更多还是师傅带徒弟的方式，让技术或者业务理解比较深的技术元老，来带他们，建立起来团队的文化。并且设置一定的事情的难度并进行考核，比如说。内部的串讲，技术的分享，主动推动一个方案的执行和落地等。在执行和做的过程更多的是鼓励和引导。 对于在各种培养都没法达到要求，则只能劝退。
7.2.3 你是怎么来人员的激励的？
答：人员的激励是比较深，也是比较难处理的。不同的人需求也都不一样的。所以在激励之前更多的是对激励的人当前的能力，当前满足的需求要有定的认识，然后站在他的需求进行考虑激励。根据马斯洛的理论整个我自己的想法，主要我会做如下的事情：
- 对于刚毕业不久的，对技术和业务都有自己能力的突破，更多的是让他们把一个事情不断的做深。激烈他的做技术的成就感，让牛人带他们，可以让他们走的更远。
- 对于版本开发和技术都比较厉害的。这一块更多是考虑，奖励机制，如项目季度评分或者年终奖都会打的比较高。
- 对于项目的老员工（金牛）并且做的非常不错，让他们带新来的人，灌输文化，还有就是让他们尝试思考底层的技术架构和技术规范等文档的输出，设置更高的挑战的问题一起去处理。
- 对于状态不太好的，做事情有一段低迷的同事。尽早沟通，了解困难，多鼓励，帮他们分析存在的问题，对于需要资源协调和帮助。
7.2.4 你是怎么来建立梯队的？
答：一般是建立管理的扁平化比较好，大家关注于项目的效率。但是事情需要分开，对于不同擅长的类别分为，版本开发和架构升级。但是都参与版本的开发。梯队可以根据项目的复杂度和业务的复杂度，进行水平拆分和垂直拆分。 水平拆分更多根据要做的业务拆分成不同的项目，而不同的项目有项目的负责人，并且对于底层架构和技术栈还是同意管理。这样就出现了，应用层项目有相关的负责人，底层架构有自己的负责人。而自己更多的是关注项目的价值，技术架构深度改造和人才的吸引。还有就是不断的非技术的思考，不同部门，产品等一些事情思考，还有对客户和用户的反馈的深入了解等。
7.3 资源整合，多项沟通
7.3.1 1号位机制你是怎么理解的？
答： 在公司跨部门沟通的成本是比较高的，并且对于事情的推动和作用是否承担这个责任和对推动的结果负责就特别的重要了，毕竟内部的大家都有自己的事情，资源都非常的紧张，怎么来保证项目能够正常的完成要求，这才是非常重要的。 1号机制就是要解决这类问题。1号位就是自己作为事情推动的负责人，并且把各项意向都跟相关成员确定，并确定大概的时间和规划，在不同的时间节点都要跟进大家完成的情况，最后就可以实现真正的价值了。 对于推动结束后，要总结经验和作出的成果。
7.3.2 跨团队/部门沟通你有遇到什么问题吗？
答：跨部门沟通主要是协调资源达到最好的效果。跨部门需要不同的部门都进行资源的协调，很容易跟当前团队的优先级产生冲突。甚至某个执行节点因为特殊的需求而产生中断了。比如说，之前公司有个目标，把所有的账号系统统一进行接入。 但是涉及的部门众多，甚至有些产品对其优先级还需要评估。这样制定的周期非常长，并且考虑到不同项目节点都有自己开发和上线的情况。这样带来的问题，时间上的冲突，资源上的冲突。
7.3.3 跨团队沟通你什么经验吗？
7.3.4 向上沟通有什么经验？
答：沟通包括全量沟通和增量沟通。
- 全量沟通主要是定期汇报下当前的情况，存在哪些问题以及解决的方案。希望给出的建议。
- 增量沟通主要是对于紧急和重要的事情，及时的同步；特别是一些需要资源和需要上级去协调和处理的事情，尽早抛出，来制定风险。 3
7.3.5 有遇到什么冲突？是怎么来解决的？
答：时间冲突，紧急需求和当前版本的冲突等。
