自我管理与持续交付

　　在两年前我首次在团队中提出向自我管理型组织转变的想法以后，日后的团队管理思路就潜移默化的受此影响了，只是并没有系统性的通过方法论来指导团队的发展，主要原因还是时机不成熟，无论是组织内部还是外部环境都无法全力支持这种管理思维模式的推进，但并不意味着这是失败的，也不意味着这事儿戛然而止了，一直以来我时时受此种组织愿景的鼓舞，无时无刻不在蓄势促成此事，通过不断拓宽自身的管理思路，下放团队的自我管理的范围，博观约取可以接触到的观点，并不忘反思总结，进而实践落地，现在我想应该是可以再发发力，努努劲，下下功夫了……

　　还有一个前提那就是对现有系统的改造，跟看牙医一个道理，拔牙总是比修补牙齿来的更高效。偿还技术债是必须要付出的代价，技术债务的产生我从不认为仅仅是技术的问题，主要应归因于管理不善，这首先是思路上的本末倒置，反映到具体工作中就是对管理工作的不重视，对管理角色的忽视，技术至上主义者总认为一切系统都可以通过技术解决，可以通过引进高层次的技术人员解决，殊不知这也恰恰是系统问题产生的根本原因。

　　因为唯技术主义者总是深陷技术的泥沼不能自拔，无法从更宽阔的视域俯瞰项目、系统和团队，很容易出现拆东墙补西墙，只看短期利益，只图一时之快而埋下无穷的隐患，这为未来的技术债播下了罪恶的种子。

　　自我管理型团队成员，尤其是经理和主管级别的成员，首先要转变的是思维习惯，同时还有角色，由原来的自上而下的发出指令，跟踪组员的经理或主管，转换成身正为师、学高为范的教练/教师，最后变成促成者/协调者和顾问，这种转变与技术无关，其实就是对自我的一种管理——广义上的“自我”可以是自己抑或是自己所辖的团队，如何把自己的小团队管理好，除了建立起自身的技术权威赢得队员的技术尊重，更重要的是如何促成组员的成长和用正确的心态面对这种转变，切入点可能是技术，但最终的本质却是一种价值观、方法论和思维方式。

　　持续交付背后是一套非常棒的方法论和工具集，更是一种文化的体现，亚马逊每天的交付次数达到了23000多次，谷歌也达到了5500多次，不断的实践也逐渐的暴露出这样一种与我们常规观念完全相悖的事实：更强的产品可靠性需要更高频率的变更！细想一下也不无道理，在以前瀑布式开发占主流的年代，发布意味着风险和对稳定性的破坏，所以都尽可能的减少发布的次数，而现在大家说的最多的一句话是当今时代是互联网的时代，而互联网时代唯快不破，产品的可靠性已经远远的被产品的更新快速甩在了后面，但二者也并非水火不容、不可调和，快速发布不意味着低可靠性，这二者之间的矛盾是有相对完美的解决方案可以弥补的，在解决了团队思维方式和文化转向之后，这是接下来要做的第二步……。