对于软件行业的从业人员，不论是管理者还是工程师，对于软件设计的重要性都应当有允分的认识，只有这样才有可能在团队中构建真正有意义的愿景。是的，具备出色软件设计能力的工程师少之又少，但这并不表明它不重要。相反，这种人的工作效能很有可能是普通工程师的百倍。
除了认识软件设计的重要性，整个团队还应当至力于打造适合的质量保证方法论。再次提醒一下，这里的“合适”是指“易用和够用”。项目组不论资源多充足、人多聪明，都比不过质量保证方法论来得实在和有效。一个拥有自已质量保证方法论的团队，可以预测，团队的个人生活质量以及团队的集体声誉和精神面貌都将与众不同。。
“通过技术方法解决技术问题而不是管理方法”是作者想强调的另一个重点，作者将这一思想命名为李云技术管理第一法则。项目开发是一个复杂的系统工程，但是其中很多问题其根源并不是来自于管理领域，而是技术领域。技术根本问题解决了，表面看起来是管理方面的问题都将迎刃而解。请不要相信管理是万能的，合理地运用团队的技术技能和管理技能才有可能打造出出色的团队，以及最终创造出高质的产品。
过份地强调风险是软件开发活动中阻碍团队提高的可怕障碍，请记住“李云技术管理第二法则：过分地强调风险其实是间接地承认自己无能，”这一点无论你是管理者还是工程师都一样。
从管理者的角度
作为管理者应当明白，如果将风险最小化、服从上级指示作为优先考虑的工作内容，那很难带出一支出色的工程师队伍。通常管理者的薪资也相对的高，站在管理者的角度，为了保证稳定的高收入，小心谨慎是应该的，但是别望了现任雇主提供高薪的同时，还希望管理者承担另外的责任和义务 —— 培养团队。只有团队培养好了，产品的质量才能随之“水涨船高”。
团队的培养，一定要给工程师们合适的“土壤”、一种允许工程师们适当犯错的环境，当然，总是犯相同的错就另当别论了。软件行业如果想做到什么事都百分百的正确和没有风险，那只能是什么都不做。一个敢想、敢做和敢当的团队，只会让管理者的工作更加的轻松，这样的团队每一个管理者都有机会获得，但必须由管理者自己去培养。
花时间培养对团队的信任是重中之重，请不要将“我信任我的团队”只作为口号，而内心却总是想着“这样让他们干可能会给我捅出篓子来哦”。对团队的信任其培养方式只能是让团队在一定范围内放手去干，一旦团队的能力强了对之的信任也就慢慢地有了，且很有可能形成一种良性循环。
管理者很有可能想培养自己的技术专家，技术专家的培养不是选中一个或几个人，然后给之机会去成长。对于技术专家的培养，应为更多的人乃至整个团队提供平台去发挥，而不用专门选择人选，具备技术专家潜力的工程师一定会在这种环境中自发地出现。另外，技术专家的培养需要长时间的观察。存在一类工程师，在管理者面前表现得很有想法，但真正做起技术来时却一般，且缺乏追求完美的精神。这种人能博得管理者对他的好印象，乃至让管理者认为他能被培养成技术专家，但一个对技术工作没有追求完美精神且付之于行动的工程师很难成为技术专家。为此，管理者在培养技术专家时，不防将“网”撒得大一点，给大家的时间也长一点。一个真正的技术专家不是管理者认命和培养出来的，而是团队自然而然集体选择出来的。“自然而然”体现在，当出现问题时大家都会主动去找他（潜在的技术专家）以获取有价值的帮助。
一个健康的团队需要有争论，管理者千万不要将消除争论作为自己的一个管理目标，从而追求一种表面的“平和”。软件行业中的科学成份有不少，如果对于技术的争论都不敢（很少工程师会就个人问题而放到台面上争执），那很难想象团队做的技术到底是什么层次。积极的争论有利于诱发团队思考以及帮助找到更好的技术解决方案。
另外，团队的能力应当是有梯度的，请不要指望每一个人都在同一个方面很强。如果真的是那样，那一定不是你想要带的团队！理论上每一个工程师都有自己的强项，如何合理地运用各人的强项以保证项目不断推进，需要管理者不断地学习和探索。
除了工作质量，关心工程师的生活质量也应当是管理者的工作内容之一。经常加班加点并不是工程师们应该的，也不是这个行业的固有特质。出现经常性的加班加点，往往意味着团队技术能力不足，或者团队的管理存在问题，但无论如何这都是管理者需要致力于解决的问题。一个只关心自己利益的管理者注定是会被团队给 “抛弃的”，也同样得不到团队的鼎立支持，想想你的薪资！
光培养团队也不行，管理者自身也应具备一定的素质。一个出色的管理者应当曾经是一名出色的工程师。这里所说的出色工程师，不只是指别人交给他的任务都能完成（甚至出色完成），因为这只是出色工程师的必要条件。一名出色的工程师还应当具有良好的技术敏感度，这种敏感度是扎根于长期对技术的钻研（学出来的）和丰富经验的积累（干出来的）而获得的。只有对技术有良好的敏感度，管理者才能真正地把握住软件项目管理中的风险，从而在风险和团队发挥余地之间保持良好的平衡。请不要迷信“管理者可以不懂技术”，当然，如果你是一名大公司的CEO那就另当别论了。
如果管理者的技术积累并不足（即没有足够的技术敏感度），那还有一种方法可以加以弥补，可以考虑在团队中找一个技术能力强的人作为自己的左、右手，而且应当信任他能帮助你做好与技术相关的决策。当然，这里的前提假设是技术积累不足的管理者，他的管理能力却较突出。就作者的经历来看，的确存在技术能力不足的管理者，但却在很大程度上能将团队管理好。对于这类管理者，很关键的一点是他能很好地运用技术骨干的技术专长，且通过激励和鼓励让大家去做更多的尝试，从而使得团队的工作气氛很是活跃，一个气氛活跃的团队才有可能更具创造力。与之相比，也存在不少管理者，他的技术能力还不错，也能带领团队按步就班地工作，但却缺乏激励大家的那种意愿和能力。管理者如能运用好激励，将发现团队的精神面貌完全不同。
总而言之，管理者对于团队文化具有至关重要的作用，这也是为什么管理者的薪水在多数情形下更高的原因。一个作风正派的管理者，他的团队也将更具正气和更有活力，这种团队在绩效方面的表现也将更好。一个不大愿意承认他人的管理者，他所带出来的团队通常会显得死气沉沉，在这种团队中大家也不愿更多地发表自己的观点，其绩效也可想而知。请记住，管理不只是计划和时间表，更应当包含创造！
从工程师的角度
培养良好的工作习惯是工程师职业发展很重要的一个内容，好习惯对于软件质量也起着关键作用。就工作而言，习惯有好有坏，好的能让个人终生受益，而差的则能让整个团队痛苦。软件产品的代码是需要工程师一行一行的“码”出来，但是，如果“码”代码的工程师没有良好的编程习惯，一定不能获得高质量的软件产品。除了与编码直接相关的编程习惯外，工程师还应当培养其它的好习惯，比如：笔记习惯，将工作中花了较时间去解决的问题通过笔记的方式记录下来，这样下次要用就能更高效，笔记不一定要记在本子上，记在计算机中是一个更为有效的方式；思考习惯，对于问题积极的思考以磨练自己的洞察力，在他人提出见解时与自己的想法进行对比，看一看从中能学到什么；阅读习惯，一个希望在技术上有所成就或做到一定高层次的工程师，其知识和经验的积累一定不能只来源于个人的工作与生活，阅读是获取这些知识很重要的一种方式，多读一读行业相关的好书、简报（newsletters），除了能积累知识和经验，对于了解行业的发展趋势也大有裨益。养成各种好习惯的目的说到底还是为了提高自己的技能。
工程师应当意识到，软件开发已经不象以前那样，拿到需求文档后就根据自己的理解完全从标准库函数开始构建自己的软件模块，如果仍采用这种开发方式，那可以说是非常的落伍了。平台和框架这类技术的运用是打造高质量软件很有效的方法，也是个人和团队积累经验非常好的一种手段。对于一个项目组，现成的平台和框架实现可能一开始并不存在，但项目组应当在每一次的开发活动中努力寻找打造自己的平台和框架的机会，并积极地加以实践。平台和框架的设计并没有想象的那么容易，但无论如何只有通过实践才能进步。工程师要做到具备平台和框架开发的意识和能力，是一种比较难的事，但一旦达到了则意味着水平上了一个台阶。平台和框架这一开发方法，给软件产品所带来的收益是高质，给项目组所带来的收益是高效，而给工程师个人带来更高质量的生活。
软件行业中的很多问题其根源是技术问题，为了解决这类问题只能通过工程师的努力。项目的困难也不是一天或一个月造成的，而是由于工作没有做到位加上长时间的积累所形成的。为了保证一个更好的将来，我们只能是现在将事情做到最好。“现在将事情做到最好”是一种态度，也是一种提升自己技能的关键途径，一个做到六分的工作与一个做到九分的工作相比，其中所收获和知识和经验将截然不同。（以上言论仅代表作者的个人观点，不代表51Testing观点）
