减少沟通成本，提高团队成员的自我管理能力，明确目标，充分授权，允许犯错但负分要上帐，合适的人，合适的时间，合适的行为，做合适的工作；人是首要，原则团队至上，一定要能合作的人，当然遇到天才我们可以选择跟随。
代码的归属权，一系列支持维护性代码不断的在多个开发或者多个团队中转移，质量和风格得不到保证，最后大家都讨厌它，脆弱的稳定性给团队带来更多额外的成本。团队的合并与分拆，我们总在思考怎样才是更合适的！没有一成不变的组织，但其过程必然惊心动魄。一个新产品从矩阵型组织开始，到敏捷型组织推进，可能在矩阵型组织中就结束了，又或者持续在矩阵型组织中，无法走向可能的成功，最终还是团队决定了结果。
以身作则，以人为本，使命为先；赋予个人和团队权力，团队利益至上，团队愿景，每个人都被利益驱动，但利益永远无法填满，我们的内心需要有值得骄傲与自豪的事物存在，就如骄傲的宣称自己在哪里或是哪个团队工作一样；每个人都有自己的责任和义务，无论身处何处，我们当尽力而为，也是维护着自己的品牌，同时也是一个团队的品牌。我们容易高估自己，无知者无畏。
架构和设计的可扩展性决定了需求变更，业务增加时我们要付出的成本；标准化，规范化，可传承有利于提升整个团队的效率；“播种，施肥，除草”，播种时的付出会影响除草的成本，而这个成本可能是数倍甚至数十倍的，把初始做的更好后面才能更省心，这几个事情我们一直在进行，但需要不断的复盘，归纳，整理。
关注过程，好的过程产生好的结果，经历过一些案例，开发把需求都做了，按时上线，看起来都满足了要求，直到有一天这个开发离职了，代码交接给下一位同事，我们发现这些代码大部分毫无设计可言，大量的重复拷贝，硬编码，我们不得不花更多的时间去重构，改善这些代码，也许好的过程可以让我们尽早发现这个问题，纵然不能纠正这个开发，我们也可以选择换一个更合适的人来做这份工作，过程是规范，是约束，要让一个开发团队完全的执行，需要时间，协商以及过程的可实施性，这方面我们还有很多改进空间；我们不断推进基础类库在各团队的使用，常用开源框架的选型和使用封装，推进统一基础架构框架在不同业务方向上的使用，标准化的方案可以减少试错的成本，统一的升级和优化不断可以改善性能，也可以让团队更加专注于业务开发。
定义角色：经历过短时间内团队大动荡，大量业务找不到负责人，找不到代码，又或者代码跟线上不一致的情况，乱！大量需求方寻求支持，给出时间和负责人！这时，我们强力把业务分给某些人，角色不明，而无缘故增加的任务需求及紧迫和未知掺杂着，很可能会导致开发人员的不满意，甚至愤怒和离职；重新分析业务属性，归类整理，评估开发工作量，定义好个人角色和方向，暂时的还是长期的，合理性是分配的根本。我们需要强大的内心和绝对的可掌控。
故障管理和问题管理。关于故障管理，当我们在线上遇到一些故障的时候，我们常规是优先恢复业务，然后记录并查找问题，如果是在恢复故障的同时确认了问题根源，则一次性在系统记录完整过程；如果并没有当时确认问题根源，则可能要等故障复现或持续分析找到真实缘故，这个也会在系统中记录并跟踪；但是关于问题管理，我们并没有在后续做出更多跟进，归类和整理，可以考虑一下，分业务方向的问题归类，分来源的问题归类，分故障类型的问题归类[响应延时，CPU飙升，内存过耗·等等];到系统更细微层面的监控，监控到接口的响应耗时，响应结果统计等。
扫一扫
709
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
