从软件到 SaaS，变的很多，但不变的，也很多。
更新历史
- 2022.06.14：完成初稿
读后感
这是每一个想做技术管理的工程师都应该仔细读几遍的书，虽然是博客文章合集，但是思路清晰讲解到位态度诚恳。更重要的是，不拘泥于具体的概念和套路，而专注于以最小的代价解决问题，这才是最最重要的能力和思考方式。
想的要远，但做的要小。要有鹰的眼睛，也要有狮的胸怀，也有要猴的灵活，也要有骆驼的坚韧，也要有豹的敏锐与果敢，也要有猫的细致，也要有熊猫的低调温和。
读书笔记
三五个人十来条枪 如何成为开发正规军（一）
- 就我们目前能拥有的权力和资源，我们如何一点点改进。我们需要的是从游击队到兄弟连，从兄弟连到正规军的方法。我们现在还处于游击队，一个队长领了一帮游兵散勇，有的人甚至没有枪还背着大刀，有的人还没杀过鬼子。
- 主要矛盾就是在：操作说明、培训机制、稳定性。如何保证这三点。而且从以上来分析，稳定性是最重要的。不稳定，你即使有操作说明和培训机制，其他部门人都躲着实施，谁想去客户那里尴尬丢脸挨骂呀。所以，其他部门人会找各种理由向老板告开发部的状，以躲避实施，说软件太烂，根本无法拿出去。这也就是开发部往往和其他部门关系都不好，开发人员老抱怨自己就闷头辛苦开发解决问题，没有人说好，却被奸人陷害。天长日久，积怨颇深。其实说起来，根源还在开发部自己这里。
- 每个人的技术水平都参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，他作为公共代码开发员。每个产品或项目的修改需求，必须首先经过他的思考，能做成公共代码，能封装成函数，就他来做。其他的程序员只管调用函数，实现客户UI操作和辅助功能。
- 公共代码开发员的标准：
- 参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合的把握。如果队伍中没有这样的人，只有开发经理一个人有这样的经理，那么接到客户需求，分析客户需求，分解析辨是公共代码员来做还是其他开发人员来做。
- 公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位内存创建释放有头有尾，代码优美，代码可阅读，代码重构，代码性能和稳定都高
- 公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上最好应该说，找一个技术能力好的，工作认真负责的人，应该是不难找到的。而且专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。
- 那我们就鼓足勇气，走出来，从我们的设计模式、OO、软件工程、虚拟接口、反射、持久化、框架中走出来。开发经理来承担起客户行业研究来：
- 客户行业这个群体有多大？大中小规模各有多少家，各分布在什么省？我们面对的最佳客户是什么规模什么信息化程度的？我们的次佳客户是什么规模什么信息化程度的？
- 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？他们各自的优点是什么？他们各自的缺点是什么？我们应该突出的优点是什么？我们的缺点是什么？
- 客户行业的过去5年，现在2年，未来3年的发展历史和趋势是什么？他们面临哪些挑战和机遇？
- 我们现在所做的典型客户，他们的组织结构，人员规模，每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程，每个岗位每日每周每月季每年的输入表格，每个岗位每日每周每月季每年的常用数据查询，每个岗位每日每周每月季每年的统计报表
- 针对以上的了解，客户面对未来挑战和机遇，未来应该如何变更他们的岗位和职责和流程，尽量流程少，效率高，运转快？
- 其实，开发经理就相当于业务架构师（因为我们还是游击队，不可能有专职的业务架构师），公共代码开发员就相当于技术架构师。
- 有了夯实的业务+技术，功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求，就都能满足了。这时候再招测试人员，就能把质量再夯实了。
- 而且，测试人员由于熟知产品，他们还能做技术支持呢，这样可以有更多的开发人员来专职开发，开发的专业性就能越来越提高了。
- 好的产品，还需要有好的文档和培训，否则其他部门还是不会接开发部的产品的。
- 那就招一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试（这个很重要，否则文案人员不熟知产品，无法写出有质量的文案）。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于他自己写文案自己用自己的文案做培训，在培训中会有各种提问，会更加增进他对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。
- 记住：业务架构、技术架构、测试兼技术支持、文案兼培训，四套马车。我们一直用它，效果很好，搭建团队容易，循序渐进不革命。
- 有了这么好的团队，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。其他部门也愿意接软件了，软件的实施和培训和技术支持都被其他部门接过去了。开发部门也终于专职专业起来了，整个公司都很协调了，部门间也不互相陷害抱怨了。公司发展速度蹭蹭的。
三五个人十来条枪 如何成为开发正规军（二）
- 软件修改，尤其项目型软件，不修改是不太可能的。我不赞成在客户处修改软件。因为不仅仅你只会以事论事的修改，容易陷入到这家客户具体的需求中，而不会考虑其他客户的需求兼容，所以你修改的软件有很大局限性，最后形成只能一家维护一套代码，最后客户越多越累成本越高越不赚钱，被客户多而拖累死。而且你在现场那么多事情，那么多人打扰，你根本无心踏实下来修改软件，只想着赶快改完上线回家，你急躁，潦草，应付，软件质量就没法保证了。你想改变这种现状，你必须把需求整理好，交给在家里专门编写代码的程序员。你在现场，你也很懂业务，你和你本公司的程序员沟通肯定比客户沟通要顺畅的多。
- 这样，你在现场，你的任务就是当好一个项目经理，专门协调，控制，理顺，制定流程、规范、目标、时间，保证执行到位。现场还有培训专员分担你的培训工作，可以帮助你校验数据，测试功能。公司里还有专门coding的程序员分担你的开发测试工作，而且人家写的代码更加多家客户兼容使用，而且质量稳定性比你高。
- 只有专业分工合作，才能转成正规军。否则，你只能把自己熬倒了，心力交瘁，最后心灰意冷，跳槽而走。从民兵，到武工队，到土八路，到正规军。这条路有好几个阶段。不能想着一步到位。现实情况也不容许我们一步到位。我们只能是能改进什么就改进什么，天天进步一点，我们就会大变样。
第三章 项目经理的工具箱
- 我一直在商业软件公司工作，也深深的明白自己的责任就是帮助公司最大限度的利润最大化。而利润最大化的实现手段就是最小的成本、最少的人、最少的时间、最简单的方法达到老板的目的，拿出合适质量和功能的产品，包装好，卖上尽可能高的价格。只要能赚到老板想赚到的钱，达到老板的目的，只要不影响这个目标，不影响大目标，小磕磕碰碰自然难免，有问题解决问题，没问题继续前进。哪个企业没个矛盾没个利益集团，哪个企业没个问题没个埋怨，有人爱自然有人恨。就是这样，这样是常态，不是异常。所以，我使用工具，一般都是在各种手段我都使用的差不多的情况下自然使用的，而非为了正规而正规，而是为了解决问题，而且是很有效的解决问题，而且是最简单的解决方法。我从来不为面子工程付出成本。
- 一个BUG管理工具，能把计划、进度、质量、需求、BUG都能管理起来，而且能追溯，能考核，能统计工作量和工作质量。真是必备。
第四章 人,是人,真的是人
- 计划不计划一件事情，执行不执行一件事情。一定要以老板利益为目的。老板不赚钱，一切好事一切好想法都会被老板推翻，老板就是老板。老板赚钱赚的眉开眼笑，其他的事情就好办的多。这是很多职业经理人居然都认识不到的，他们总抱怨老板限制太死，什么资源也不给，干活还贼累。根源就出在这里了。想实现你的想法，必须在实现了老板想法和目的的前提下才能做。所以我的方法能实现，多靠此。
- 而且我的方法不是为了我自己有什么好处，我的每一个方法也都不是为了正规化装修门面图好看。我的方法都是为了解决实际问题，为了老板赚钱更快更省成本更容易，员工更省力，客户更满意，而且每个方法都是在本企业能力和成本范围内能执行落地的解决方案。这样的解决方案，哪个老板会不支持呢。但很奇怪的是，很多研发部主管都忽略这个重点，老板在想利益，他在想技术。两人说不到一个目的去，互相不理解互相不支持互相埋怨，久而久之互相猜疑互相提防互相留一手。其实技术就是个手段，赚钱是目的，双方一起绑定去赚钱，怎么合法的赚更多钱怎么来。如果研发主管能脚踏实地的从本企业的能力和困境和现状去思考改进方法执行落地，而不是抱怨这样的环境没法实现想法消极怠工或心想跳槽，我想很多心结就都打开了。
- 人与制度
- 好的氛围，才会引入、留住好的人（乱世强盗多就是这个理）。
- 好的人，才会有好的制度，并且保持好这个制度（制度是人定的）。
- 好的人和好的制度，才会遇到好的客户（有句老话，夜路走多了总会遇见鬼。有些人老想着邪门事，最后也被邪人玩。近朱者赤近墨者黑，什么人总遇到什么人，就这个道理）。好客户就会产生好的结果。
- 所以，好的人才，好的客户都不是运气来的，而是来自你自己。你就是控制源头的人。
- 如何制造好的氛围，我讲讲我的职业经理人管理人的一些心得：
- 师傅制。这里没有总监，没有经理，只有师傅，老师。总监，经理，会让员工产生隔阂，距离，权力争斗。每一个人总有一个师傅。每一个新人进来，都要指定一位合适的师傅。尤其是新人，更要短期内注意看时候合适，不合适就要更换合适的师傅。什么问题都可以问师傅，从技术到公司制度到公司新闻公司历史到职业发展规划到个人生活问题。团队的凝聚力，配合性，归属感，责任感，很多问题都被人的感情消化了。
- 朝九晚五，禁止加班。其实大部分程序员也是不喜欢加班的（不过有些程序员是光棍，也是漂在北京，反正也是一个人，于是就喜欢呆在公司上网玩游戏看小说看电影吹空调，美其名曰加班。还有一类老板喜欢看表面功夫，谁加班就喜欢谁，于是大家都装做很忙都要加班）。因为加班不给钱。不给钱，还加班，天长日久就觉得自己很亏，心里不平衡，各种心思就都有了。其实也没有多大的事。我的老板一开始对我的不加班也是心存戒心，但是每次交给他的结果比加班的部门做的都好都快，他也就默许了。
- 良好的办公环境和良好的个人形象。我们看到美女就兴奋的口吐莲花，我们看到阳光溪水草地我们就心情舒畅。当然，我们看自己，别人看我们，都是一个道理。心情好，工作才能好。一个满桌狼藉充满烟味饭味脚丫子味有人在冥思苦想解决问题有人在打游戏有人在放朋克音乐有人在骂有人在打闹嬉笑有人把脚放到桌子上的办公环境，我看谁都会逃离。
- 以更快更省成本更容易完成任务为目标，以赚更多钱为目标，以提高产品质量产品价值产品售价为目标，鼓励员工进行自我岗位上的改进创新，我经常给与交流和指导，一旦有效，进行精神或物质的奖励或职位提拔或工资晋级。
- 以下是我引入好的人才的几个心得：
- 人的年龄和工作经验拉开距离。年年招，时时招。不断看人，试人，滤人，培养人，形成层次感有阶梯有接力的员工组织，绵绵不断前赴后继，不会出现人才地震、集体疲劳、小团伙争斗。避免不同高低职位上全是80-84年的人。下属还在窝里斗互相不服（很多员工不看对方能力，就看对方的工资和年龄。凭啥你就是我师傅？），那么客户逼你，老板压你，其他部门利益冲突你，下属还闹你，你这个孤独人算是失道者寡助也。
- 人的技术能力高低先放一边。首先要过EQ关。有些中小型企业没有HR经理，一般考察EQ，都是老板把关。如果你现在招人没有老板把关，那么必须先考察人的EQ，再考察他的技术能力。我最怕有些羡慕科学管理的管理者照搬什么EQ测试问卷或什么团队游戏来评测。我的评测方法仍然是不讲道理，要讲经历。没有工作经历，至少有学习经历和生活经历吧。一个人的情感、压力、正义感、真诚感、领悟力、心细观察力、思路整理总结能力、关注全面平衡能力、执着力，都能看的出来。
- 专业发展，流程协作。如果不专业化，老板有什么活就分配什么活，时间短了还认为自己是在学习更多知识在锻炼。时间长了就会觉得自己就像个混子，干什么都干过，但什么都拿不起来。出去应聘啥职位，是应聘开发呢，项目经理呢，实施呢，支持呢，销售呢。啥都做过，但啥都没做专，都了解个皮毛，真要让上手还真给人家拿不下来。心就慌了，觉得自己是个被老板困在手心的小鸟，无法飞出本企业的樊笼，一旦飞出就要饿死没有能力存活。好可怕。难道只能在这家公司耗死了？赶快能逃逃吧，逃到一个正规的专业的公司去。
- 下一阶段目标交流制定。交流，我想每个CTO或技术总监或研发经理都会做。交流可以了解员工的困难和心中的疑惑、个人期望、个人专业兴趣的变化、人生观世界观技术观管理观生活观（以调整自己以后和该员工如何交流、如何讲解工作、如何鼓励、如何布置任务、如何考察等等）。交流也可以让员工多了解自己是怎么想的。双方在日常很多事情的分歧和误解就会消除，心会往一处想，劲会往一处使。但是，交流也不仅仅实现这些目标。更重要的是，交流，主要为了能给该员工制定一个切实可行的、某段时间段内可达到的、他也喜欢也愿意努力的、也会他未来职业发展很有好处的职业目标。没有目标的工作，虽然他很努力，但是他容易迷失方向。如果他又是一个不能很有悟性很有规划的人，他的工作就会形成做一天和尚撞一天钟。撞钟撞的不错，但没什么更高层次的提高。天长日久，就会木然，倦怠，不思进取，思想守旧，遇到新问题无法突破。所以，我会根据双方的交流，和员工一些协商一个下一阶段的职业发展目标，并且时常指导调整他的做事方法和思考方法，给他讲解一些我过去的工作经验和我的感受，鼓励指导他们有计划有目标的走的更高更专业。这是很多研发部门主管没有做的一点。
第五章 实施经理的工具箱
- 我这个人就有个习惯，能改进我就不在原地踏步。这个改进方法不行，我就继续想其他改进方法，不断尝试不断推进，哪怕一点改进我都要去实现它。量多了就会引起质变。许多人就等着大机会大改变，对小改进懒的动，我不赞同。
- 你自己得过且过不正规，别人更就不把你当回事。你举止文雅谈吐内涵，别人也不好意思在你面前大放厥词。
第六章 客服顾问的工具箱
- 这个重量级的工具就是客服工单系统。没有这个系统，客服部就不能称之为客服部。
- 所谓客服工单系统，就是客户的每个支持，都记录进这个系统。哪个客户的哪个部门的哪个人提的问题，提的是哪类的问题，这个客户是谁实施的，谁过去做过他的现场支持服务，问题的严重级别多高，解决的流程是什么，提出时间是多少，解决时间是多长，回访确认解决了没。谁解决的，谁回访的，客户满意度如何，哪个工单还没有结束，哪类工单最多，哪类工单耗时最多，哪些工单拖的时间最长也没有结束，哪类工单未结束的最多，哪类工单耗时最短，哪些客户工单最多，哪些客户工单最少。
- 我们每个月，每个季度，每年都要统计对比这些指标。根据指标，确定下一阶段重点支持的问题，重点支持的客户。耗时多的工单，集中各部门把解决方案提出。拖的时间最长的就尽快结束掉。耗时短的都总结出FAQ，发布到BBS中。问题最多的那类，就和研发部一起合作，确定下一版本的修改事宜。
- 谁接待的工单谁负责工单的关闭，现在解决到哪个流程，停留在哪个人的手上，就要追查。一个工单多次解决都未能关闭，每次解决的过程都要记录下来。高级别的工单要优先解决。高级别的客户要优先解决。而且每次解决的电话录音都和这个工单关联在一起。想听录音直接播放即可。
- 工单系统还和呼叫中心绑定在一起。
- 客户的每个人的档案都记录在内。客户的姓名，部门，职务，电话，客户等级。我们不断跟踪更新，保持这里面的客户档案为最新，谁离职了，离职到哪里了，我们都有记录。因为客户行业是一个行业，客户的员工离职跳槽，一般都是跳槽到这个行业的某个企业，这会给我们带来新的潜在销售机会。因为我们有这个熟悉的联系人。
- 工单系统有各种统计工作量和工作能力的报表。每天每个客服人员的接待客户量，接待时间量，解决工单数量，解决不同级别的工单数量，未解决的工单数据，拖延超期未解决的工单数量，自己能力不行解决不了转给其他人的工单数量，收集的销售机会数量，收集的销售机会金额，更新客户档案的数量
- 有了量化的工作考核指标，客服人员就有了高级客服顾问，中级客服顾问，客服顾问三个等级。工资不同。而且不同等级的客户，不同严重级别的工单，也开始分配给不同级别的客服顾问。
第七章 你这该死的销售
- 想、做、写、说，对于一个成功的人来说都是必不可少的。
第八章 水清则无鱼
- 我过去遇到的问题是：我一直在琢磨如何提高销售收入。否则，这么老路子做软件，费死劲也挣不了几个钱。所以，我在研发过程管理上引入了一些方法，引入专职的项目经理、公共代码开发、测试员，来收集需求、控制需求、安排进度、把控质量。在产品制造上我引入了美工来美化界面，引入了文案编写了精美的帮助文档、产品白皮书、演示版和视频教学。让销售拿出去给客户打单，一看PPT一看产品演示就感觉这是个专业的产品。另外，我在实施和咨询和技术支持也下了大功夫，让这种专业性一直连贯的保持下来，否则就会让客户感觉签单前很专业，一签了单子就糊弄人，这样生意就没得做了。
第十一章 物以类聚,人以群分
- 我说，一个团队的好与坏，就在于团队的创建者和第一任运营者。就好像我们老听的一句话：什么是企业文化？企业文化就是老板的性格。一个公司尚且如此，一个团队也是如此。
- 如果你的团队的创建人就是小农经济、投机、疑心猜忌、不择手段，当然能在团队中待住的人也会是这样的人。物以类聚，人以群分。那么团队的继任者也会是这样的人，因为上一任要提拔人，也是提拔和自己思路一样的人。处处和领导冲突的人，也不会被领导提拔。能跳出这个圈子的几乎看不到，所以我们总是凡夫俗子，而无法成为史玉柱或陈天桥或马云之类
- 我不是一个喜欢控制的人，我喜欢抓大放小。往往大部分事务的成败，也就有那么两三个关键点。你抓住了关键点，事务就不可能偏的太远。如果一个管理者处处事必躬身，那么只有像诸葛亮一样呕血而死，死后还蜀中无大将。这就不是一个管理者了。有了问题，我就在远处静静看着，也不干涉，我看看我的团队会如何。这样很锻炼一个团队，我会在合适的时机插手，否则老板就对我要开火了
- 许多管理者喜欢把下属揉捏有余，雷厉风行，显得自己很有手腕。我更喜欢给大家提供舞台，引导目标，提供经验指导，让他们互相搭配表演一场好戏。我类似导演而不是管理者也不是教练的角色。我喜欢这个群体中能制造出明星，也有踏实的群众演员，也有幕后的剧务。我希望这场好戏能够卖一个好价格，于是路演和推广是必不可少。我需要拍一部好戏的资金，于是我要去给老板讲故事获得资源支持。也许，这就是商业和软件艺术和软件工程的结合。
- 所以如何描述一个我，可能是商业+产品+管理+技术。我总是在这四者间不断揉和。所以大家看到我的文章也是各方面的内容都有。
- 我看人，引导人，锻炼人，提拔人。首先就是责任心。这个责任心，好像现在都成了中国IT业非常稀缺的资源。有企业投机滥做的因素，也有社会投机滥做的因素，也有中国“小皇帝”一代的特征。结婚有老妈出钱，买房有老妈出钱，生了孩子有老妈带老妈养。工作的意义是什么？个人的事业目标是什么？是生存糊口么？我想很多现在80后没有糊口危机。而有事业目标的甚少。所以工作，就是个毕业了顺坡下驴的事情，没有啥目标性。
- 在责任心之后，才能说到才能。否则这个才能就根本体现不出价值。有才，但做起来掉里浪当，最后的结果是很平庸。这样的高才自己很自傲，觉得自己应该有更高的薪水，但是他就不看他最后的产出，就看自己满身的才。这有什么用，我们看结果。
- 对于下属，我主要是给机会给项目锻炼人。我会经常和他聊天交流，什么都聊。在聊天中，大家就互相知道互相的性格了。做事就懂得谅解和理解了。我不喜欢新人一进来，就为期一个星期的培训，从公司文化到公司制度到公司产品，一个星期把人给洗脑了。这种方式不好。我喜欢那种润物细无声的方法。我会给每一个进来的新人根据他过去的工作经历和能力，给他指派一位合适性格的师傅。公司的文化不是口头说的，那是假的。公司的文化是你在日常细节工作中潜规则感受到的。我经常会和新人说：有什么问题，都问师傅。从怎么休假到公司怎么给出差补助到中午怎么吃饭到公司发展历史都可以问。师傅解答不了，可以直接ＭＳＮ问我。
- 我经常用高于他能力一倍的项目锻炼人。我会给他分配任务卡定任务时间。我会去追究他的任务时间，从试用期我就一直这么用。我不会给他看书学习的时间。我相信实战锻炼人。现代企业又不是战争，他又死不了。我也不会把项目成败的关键点任务给他。如果他顶不住压力，自觉放弃跳槽，那么他就不适合我的团队。我会鼓励他，我会指导他，我会问他遇到什么问题了，我会问他进度提醒他任务时限。许多人刚一进来，觉得工作很忙压力很大。但留下来的，最后回顾自己的第一个任务，都觉得成长太快了，是以往都没有那么快成长的。现在的工作能力，感觉很充实。
- 我招人的时候，也只要能力差不多，说话理解能力还可以，能抓住重点，能重复表述，能细心反复的改进工作任务质量的，勤勤恳恳做好本职工作的人就可以。最怕没多少经验就乱谈老板乱谈公司乱讲战略，有一点工作成长就要求长薪水的。
- 我一般会找合适的时机向老板说明我的思路。而且我的思路的出发点和目的点一定为老板利益最大化考虑的（如果你的思路从一开始不是为老板着想的，那估计什么时候都得不到老板的认可）。所以，我有这个基点，所以我会找时机进言（时机很重要。老板正固执的时候你即使对的也不能接受。老板也是人，老板也有面子。）。如果老板仍然不接受，我会职业化公事公办的执行，安排人，推动，检查进度，监督质量，消除异常，调度资源，指导方法。我的意见，一般老板会听30%。而且，我当多年后回顾老板当年的想法的时候，我发现，老板大部分是对的。我想的确实不够更远更利益平衡。老板是比我掌握信息和资源多的人，老板也知道内外矛盾和困境，他就像在下围棋统揽全局，他想的步数可能会影响大局或影响未来的第三步第四步第五步。而我只能看到前三步。如果我也能看到比老板更多的步数，可能我就是他的老板的。所以老板自有当老板的资本。经过这么多年职业经理人生涯，我还自认自己有一点能力，但老板仍然是老板，我仍然服务这么多年。可见，老板不是混饭吃的。所以，我总是告诫自己，低调低调再低调，再考虑远一些，不要乱讲。我尚且如此，我手下的员工更是如此。
第十三章 敢问路在何方
- 大家看我的经历，就会发现，我研究技术，是为了解决软件制造和实施和服务中的问题，而不是纯粹因为感兴趣而学习技术，为了显示自己是公司技术最厉害的人而学习技术的。这在商业软件公司根本吃不开。商业软件公司，赚钱为主。如果你的技术无法给公司赚钱带来帮助，就根本没有用。
- 不过有些技术很牛的人现在也很困惑，工资就是不涨。我建议他从帮助产品提高销售额的角度去把自己的技术应用到产品中。我过去有个手下，做行业信息化管理软件，却不愿意深入了解这个行业。自认自己要成为技术专家，要做最好的软件架构，于是拼命学习了N多框架，对比分析，做源代码阅读，做实验尝试新技术，整天熬夜。做出来的架构却是并不能减轻业务功能开发人员的工作量。老需要注意N个地方，配置多个选项。配置错误就运行错误。这类架构还不如没有。我们是在开发行业信息化管理软件，不是在做变型金刚。我们不希望一个能制造汽车，也能制造轮船的东西。我们就需要制造小轿车的平台架构，连制造卡车的平台架构都不需要。但你制造的却是一个个的螺丝和钢管。
- 如果有的技术牛人，技术也能很有效的帮助产品提升。但工资还是不涨。可能跟公司抠门有关。可以建议去发表一些博客来提高江湖的知名度，这样请你去做技术咨询方案的人也有可能找到你。
- 如果你善于组织和调度人，善于推动项目和控制项目，善于和客户沟通理解客户，那么你可以往项目经理职位转变。实施经理、服务经理、开发项目经理，都可以选择。开发经理，未必是技术最好的那个人。
- 如果你不善于和人打交道，技术也不行。那么做一个踏实稳定勤恳的客户化定制人员或技术服务支持人员。并且在工作中不断小改进，让自己的工作更有效率更有效果。
- 如果你不善于和人打交道，技术也不行，但对客户业务比较熟悉，那么建议你踏实工作，做好实施（做好实施的人未必会与人打交道。我发现很多性格内向的人，提升自己的职业化工作细节，公事公办也达到了很好的实施效果）。从实施，可以转向咨询、售前。但咨询、售前都是很需要结构性思考和细致观察的工作。
- 如果你技术无望、不善于和人打交道，也不善于组织控制，也不善于细致观察思考，也不想踏实勤恳，却想到处跳槽涨工资。我想你恰恰什么都得不到。你是最容易被裁掉的那个人。选一样，你必须选一样。即使你一无是处踏实努力干活保证质量和进度也好啊，现在，踏实努力干活的员工在每个IT公司都是宝。
第十四章 懈寄生
- 想去深入了解一门技术，阅读源代码是最好最快的方法，虽然有些艰难，但不断阅读不断研究思考不断做笔记，突破后就能发生质变。如果你从入门到精通，这个时间将非常长，可能你在前进的过程中已经失去兴趣再也不想到达精通了。
- 想去深入理解什么产品，就去找制造这个产品的人写的书。这样的书没有歧义，能看出创造者的思路和创造的来龙去脉和他的眼光。不是亲自做的产品，不是亲自写的书。很多就有理解歧义，容易误导人，而且还不深刻，无法一步到位。
- 企业由各种各样的人组成。每个人或者每个利益团伙都有各自的目的和利益，而企业也有自己的每年每月的盈利目标和任务。这是一条大船，在大海上，会遇到各种各样的情况，所以每个人的位置，每个人的际遇也在不断变化。可能你会成为船长，也可能突然被大副扔下海。我常常感觉管理像是小时候玩的挑木棍的游戏。每个动作都必须轻，都必须看细节看仔细，不能动其他的任何一个小木棍，你要小心观察哪个小木棍可以挑起来。你要小心翼翼的挑起来。
- 雍正皇帝给我的感觉就是这样。所以我常常阅读，常常思考企业现状，平衡每个人，包括各个部门的经理，包括客户，包括老板，包括手下。
- 第一，我经常梳理自己的知识体系，技术的，管理的，业务的。不断梳理，所以心中的主线、重点、未来趋势、空白弱点，都一清二楚。所以我读书都是由针对性的，我从不走马观花。我知道自己的所需，我也知道自己的拥有。而且每看自己需要的内容，就很容易和自己现有的知识体系对接在一起。
- 第二，我读书就和猕猴吃食一样，先看书的目录，然后发现自己感兴趣的章节，直接找自己关注的问题答案。如果发现这本书有不少自己想看的，就会买回去，细看，并且做笔记。先把自己想看的看完，做完笔记。然后再思考目录，看看自己遗漏什么没有。然后再根据筛选再读一遍遗漏的地方。然后就把书从头到尾都看个遍。对于自己已经明白的就很快翻过去。
- 第三，从小到大，我都保持着读书的爱好，一本好书在手，经常饭不吃觉不睡。在大学如此，上班后单身也是如此，现在结了婚也是如此。所以家人也理解我这个爱好，给我提供了很多的条件帮助，让我能安心读书。在大学的时候，也是每天睡3-4个小时，打工编程赚钱（有时编程太累就把键盘推到一边，头上盖好西服就趴那里睡着了），并且还把财务管理和计算机两个学位拿下来，还阅读深度技术书籍。即使工作后单身，也常常周六日通宵达旦的看书。现在做了高层经理人，负责的事情多了许多，出差也多了不少。但每次都是上洗手间的时候也拿本书，飞机上也带本书。每当《财富》和《程序员》来了的时候，晚上拿回家，吃晚饭收拾完家把孩子打发睡觉后，自己起来偷偷阅读直到全部读完才睡觉。这么多年，睡眠时间短都这么多年过来了，好像我一直是这样，也就习惯了。
第十五章 那根胡罗卜
- 大部分老板开公司的出发点和目的点都是钱和权（有其他梦想的除外，一般以实现梦想为主要目标的，大多企业要么大成，要么就是失败。不过还是失败的多。企业存活，还是很现实的），所以我们也不难理解老板的行为。
第十六章 七里香
- 我也曾经做过几次新人培训，但一工作开，发现也是全白费。所以我现在就不培训新人了。采取行动中开火，实战中成长，师傅带领指导监督管理。
- 当然，我也被指派了一位师傅带我。我的师傅，并不是我的领导。我的领导是研发部经理。我的任务是研发部经理分配的，而师傅是指导监督我的新人期工作的。师傅只是一个非正式传帮带，不是职位或职务。每个新人进来公司，都有师傅。即使一位在其他公司工作多年的老员工跳槽进来，也会由研发部经理适当的安排一位师傅。
- 每个企业和组织都有其内部的制度和规则。这些规则和方法可能不是被白纸黑字的写下来的，但由于长期部门内协作和经理的个人管理风格和部门间的利益力量博弈，所以形成了部门内说不清道不明的规则。它存在，它不是明面上写的，它存在于人们日常的工作流程和人际关系中。
- 做过企业管理软件信息化的人都知道。最难的不是编程开发录入数据的窗口，而是做报表，并且报表数据做平了，几张关联的报表的数据还能对平了，而且钩稽关系都正确。
- 这是很不容易的。因为表结构已经定死了，设计的时候，可能设计者多考虑了数据录入，却轻视了数据统计，所以很可能这个表结构出报表非常难，甚至你不拿存储过程+临时表来做就想不出更好的办法。更糟糕的是，数据库不知道是谁调试程序时发生了问题，侵入了异常的数据，你怎么都想不明白怎么数据平不了。更为严峻的是，我面临的是22个子系统，1000多张表的一个大数据库结构。更让我着急的是，我的经理还给我设置了时间期限，不是让我学习试验的，而且我做的东西要给客户用，这是要卖钱的，做不好，客户就不给钱。
- 我现在引导新员工，也是通过做报表。我不会安排任务时间让他们专门学习业务系统，让他们阅读系统设计说明书或帮助文档。这没有用，因为这样做没有目的性，他们不知道该看什么才有用。直到真正遇到任务，带着问题去找相关的答案，他们才会去真正用心了解这些。
- 我一向的管理风格都是以问题找答案。没有问题，就不乱动。即使有问题，问题不影响最终的大局和目标，也能不动就不动，能不做就不做，不急不躁一切都在预料之中。我不喜欢大革命大运动大学习大整风（可能是我家在60-70年代历史原因影响）。平时不润物细无声的管理、指导、引导，到了发怒的时候才去大动手，对于一个组织来说太伤筋动骨。
- 在研发部，还有每周五不强制的下午学习。大家如果觉得有必要，就早就计划好让研发部内某人讲一次业务系统难点，或设计难点，或难点技术最新技术共享。这种学习型的组织一直让我很推崇。看似大家在浪费时间闲聊，但大家的团队凝聚力，团队学习力，团队配合力，真是空前的高。
- 这次我是娴熟的老员工。
- 公司所有人的联系方式要到
- 每个部门的头都短期内认识了。认识方法就是吃饭
- 现有产品深刻使用操作了一遍，发现了问题，也知道了现状，也知道了未来如何改进
- 现有客户，现有正在跟单的项目情况
- 离老板最亲近的几个人，和他们玩，聊天，吃饭，深刻观察了解他们的做事方法，观察他们为什么能离老板这么近。近朱者赤近墨者黑。这样也能看出老板是个什么样的人
- 每个部门的事实领导人，有些人不是头，但是很有影响，是事实上的内部头目，和他们玩，请他们吃饭，把部门的利益团伙和公司历史，公司的真正收入来源和真实收入数额和盈利模式都了解清楚
- 瞅机会，创造一切机会，和每个老板聊，了解每个老板的想法
- 改进现有产品最大的几个难点问题，寻求短期内出彩的活让公司所有人立刻刮目相看
- 华为公司是一个以高技术为起点，着眼于大市场、大系统、大结构的高科技企业。以它的历史使命，它需要所有的员工必需坚持合作，走集体奋斗的道路。没有这一种平台，你的聪明才智是很难发挥，并有所成就的。因此，没有责任心，不善于合作，不能集体奋斗的人，等于丧失了在华为进步的机会。
- 如果您是一个开放系统，善于吸取别人的经验，善于与人合作，借助别人提供的基础，可能进步就会很快。如果封闭自己，怕工分不好算，就需要较长时间，也许到那时，你的工作成果已没有什么意义了。实践是您水平提高的基础，它充分的检验了您的不足，只有暴露出来，您才会有进步。实践再实践，尤其对青年学生十分重要。唯有实践后善于用理论去归纳总结，才会有飞跃的提高。有一句名言，没有记录的公司，迟早要跨掉的，多么尖锐。一个不善于总结的公司会有什么前途，个人也不是如此吗？
- 您有时会感到公司没有真正的公平与公正。真正绝对的公平是没有的，您不能对这方面的期望值太高。但在努力者面前，机会总是均等的，只要您努力，您的主管会了解您的。要承受得起做好事反受委屈。没有一定的承受能力，今后如何能做大梁。其实一个人的命运，就掌握在自己手上。生活的评价，是会有误差的，但决不至于黑白颠倒，差之千里。您有可能不理解公司而暂时的离开，我们欢迎您回来。您更要增加心理的承受能力，连续工龄没有了，与同期的伙伴的位置拉大了。我们相信，您会加步赶上，但时间对任何人都是一样长的。
- 公司永远不会提拔一个没有基层经验的人做高级领导工作。遵循循序渐进的原则，每一个环节对您的人生都有巨大的意义。您要十分认真地去对待现在手中的任何一件工作，积累您的记录。要尊重您的现行领导，尽管您也有能力，甚至更强。否则将来您的部下也不会尊重您。要有系统、有分析地提出您的建议，您是一个有文化者，草率的提议，对您是不负责任，也浪费了别人的时间。特别是新来，不要下车依始，哇啦哇啦。要深入地分析，找出一个环节的问题，找到解决的办法，踏踏实实地一点一点地去做。不要哗众取宠。
第十七章 走钢索的人
- 李维先生曾经有过一次演讲，讲到了一个架构师应该具备的特性：
- 核心软件技术。要攻克数据库设计问题，必须深入了解数据库的工作原理，而不是会写复杂的SQL会管理个备份会设计个表结构就算精通数据库。有人甚至把会用hibernate\structs\spring当作自己会核心软件技术
- 产品特性。你学了那么多核心技术，到底要干吗？我一直在商业软件公司工作，没有在研究所工作过。我各种技术要做到的就是帮助企业软件生产，如何更快更省力气质量更好市场竞争力更强。我总是以这个原则来验证一项技术是否对于我的工作来说而实用。现在技术多如牛毛，在各个层次各个领域解决着各个环节的问题。如果不以解决自己工作中的问题为圆心，很容易陷于到大量学习却越来越茫然找不到出路的境地。
- 软件趋势。在企业管理软件开发领域，往往会见到这样的现象：不少开发人员精通客户业务需求，深入第一线做客户实施。他们学习技术也是为了解决现有手头的问题。尤其企业管理软件开发领域，技术要求并不高，而如果不了解客户需求，开发的软件实用性就不强，即使你的功能开发的又性能好又安全性好也没实用意义。所以，不少在企业管理软件开发领域工作多年的开发人员，形成了技术轻视观，甚至有种核心技术学习无用论的思想。
- 创新技巧。我们往往会遇到这样的情况：要解决手头的问题，摆在面前的有N种技术方案。选择哪个都有缺点，综合来用又感觉牛刀杀鸡了。有时候，我们还会遇到另一种技术选择，未来的软件趋势一定是那样那样的，但现在还没有达到，现在的技术方案都是过渡期的，所以我们还要等。否则利用现在的过渡期技术，开发出来就被淘汰了。如果是这种以现状看技术的思路，不管技术发展到什么阶段，都有遗憾，都在向未来过渡。所以，作为一个架构师，比别人厉害就厉害在，总是能把手里这些技术巧妙的利用，以解决自己的问题。当然，你想把你手中的技术能用活，你必然是理解这项技术的来龙去脉和这项技术的适用领域，还要深入理解这项技术的工作原理，还要清楚的认识到你要解决的问题领域，否则，你无法把你的技术和你要解决的问题结合在一起。
- 架构师总是游走在技术和业务之间，既要兼容软件历史不能割裂又要面向未来发展，所以我老把架构师称为走钢索的人。
- 我一般都是把我们这个产业的竞争格局现状了解清楚，我们的过去现在，竞争对手的过去现在都了解清楚。然后我去研究我们的客户行业的竞争格局、层次现状。看看这个客户行业盘子，三教九流到底多大多复杂，我们现在是占了多大，我们还能占领哪些客户群。然后我就研究客户行业目前的挑战、机遇、困境。能解决其中一两个问题，就是咱们的竞争亮点。如果作为软件一点都解决不了这些业务困境，我就思考如何让产品做的更易用。微软不就靠着易用发家的么？最后我会去研究我们公司现有的研发优势和弱势、实施服务销售的优势和弱势，找到适合我们突破的地方，具体归研发能承担能起作用的事情，我就会去动员做。脱离现实资源现实矛盾现实包袱的改良，是无法做到改良的。
第十八章 焦油坑
- 我主张的是：普通人通过使用一定的方法和规则，做事情虽然无法做到优秀，但也至少能保持一定水准，不会把事情做烂。如果任由普通人自己去想自己去做，这要管理者何用？作为管理软件开发公司，其管理思想，竞争不过管理咨询公司，其技术实力，又没有技术门槛，属于那种规模化生产实施服务的类型。所以，管理软件开发公司要想成长，必须走规模化路线。而规模化路线就需要依靠大量的普通人才，而非个别的英雄。英雄是很难找到大量人才的，而且优秀的人才其成本也高，更约束的无法规模扩张。这和规模化路线有悖。
- 所以，他带出来的兵都是单兵作战能力很高，都属于那种能救火队员型，有问题冲上去嘁哩喀喳就搞定。领导是很喜欢这样的人才的，因为这样的人是多面手，是特种战士，把一个人随便往哪一扔都能把项目完成的很好，很省成本。但是这样的人才有个特点，没有一年半载，这样的人培养不出来。而且这样的人往往都游兵散勇似的，一遇到必须合作的事情就变扭，老觉得其他人办事都不放心，都觉得别人做的没他预想的那么好，还不如自己一个人都包办了快速且省事。
- 我并没有想过这件事该管理咨询公司做，那件事情该软件公司做。我只想解决我的问题，我的方法也是由此而来的。
第十九章 一个人的战斗
- 维护老系统，也要象经营企业一样，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，才能渐渐从恶性循环走向良性循环，才能把一套烂代码扭转成可持续维护的代码。
- 一、重点把控输入数据的校验。你看见很多横插进来的代码，就是由于输入的漏洞进入，最后引起后续数据处理出错，所以以前的程序员他不截源头，他在最后爆发的地方堵漏洞。
- 二、以后的需求再往上加，都写成函数。遇到比较大的IF..ELSE判断，就把其中的代码段再分出一个函数。
- 三、以后再加功能，尽量不要做成联动触发的。
- 四、你以后写代码，把特殊处理业务和正常处理业务的功能代码分离。就好像你走路，老有人给你下绊子，你就感觉不爽。
- 五、现有的功能，把不常用的功能做一些隐藏处理，放到一个不起眼的位置。使用的人就会越来越少。到时候就适机真正藏掉，不让它触发了。
- 六、真正的根源在于此，老系统无法维护只是借口而已，可能希望老板认为自己的工作很辛苦很复杂而加薪）。真正危害大的是全局变量和大流水代码。所以写代码，要严格避免这两个坏因素。
- 七、修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。
- 八、我曾经和很多做维护的开发人员都做过交流。他们都觉得一个软件没有文档，没有注释，简直就没法维护。但确实是很多软件没有任何设计文档，连帮助说明都没有，代码也没有注释。而这些软件又出自他们自己之手。也就是说他们一边抱怨没有文档没有注释，一边自己也不做文档不写代码注释，不知道在等谁来专门做。我问他们到底需要什么文档才可以将一个软件维护的越来越好，从一套烂代码扭转到一套良好渐进的代码？他们说要要表结构说明、要详细功能设计书。表结构还好说，可以整理出来，详细设计说明书就不容易出了。
第二十章 累斗累
- 人和人的信任，都是在做事中不断看人试人品人，才能取得信任，才能放权
- 如何比实施人员更了解客户需求？如何让老板相信我比实施人员更了解客户需求？这也是摆在我面前的一个问题。
- 我是把产品放在一个产业中看。看竞争对手，看业界标杆，看业内管理专家，所以我对产品的升级完善，是基于产品战略的，是基于盈利模式和竞争力构建的。如何引出更多的盈利增值产品，如何保证产品更有竞争力，是我思考的重点。
第二十一章 我要飞的更高
- 这个已经定了型的公司形象就容易阻碍公司新业务开展。公司没有鲜明形象吧，客户不清楚你到底是个干嘛的公司，到底能干嘛，到底什么做的专业。真正通过多年做产品做客户，让客户有了定位，反而客户认为你就是干这个擅长，其他你就不行
- 不同意这种观点。很多人的思维是守阵地型，觉得自己有多大能量就考虑多大的事。但是做企业，守阵地是守不住的，你不攻打别人，别人就要主动来吃掉你的份额。我一贯的思维都是，先放大眼光，放眼整个IT行业，整个客户行业，甚至是和客户行业相关联的上下游行业。能不能做到还没论证呢就否认说不能，这种人无法引领公司产品成长。先研究，说不定还能做到。一旦成功，就可以获利颇丰。当然，我也会考虑风险，不会让公司要么赔死要么赚死，我是职业经理人，我要保持平衡发展。老板可以大刀阔斧进行革命，但我只能曲线救国。
- 公司现在的人的技术素质是否能达到，如果想做的事情确实挺好，公司愿不愿去提供更高的薪水来招聘人。是自己独立研究开发，还是通过合作先代理别人的产品进行销售维护在别人的基础上进行扩展，还是请外脑顾问进行指导。合作者是否理解深刻意图，能否在利益上达成一致，未来分道扬镳的时候是否能好聚好散，都有很多沟坎，都需要拿捏到位。
- 公司现在的资金如何，公司现在的业务销售是否具有可持续性。这也是需要考虑的事情。一项新产品的研发，是需要花费很多时间来跟踪收集研究，做尝试，做推广，逐渐在客户群众树立影响力逐渐扎根逐渐认可，是相当长的时间。在新产品还无法代替现有产品的盈利地位之前，必须能保证现有产品销售稳定性。否则大家都要喝西北风了。
- 在研发当中，更要验证对未来综合竞争力的提升。不能是单独的产品，而无法成为一条产品线或产品体系，就不容易利用现有的销售、客户、实施网络进行落地。必须与现有产品形成互补。就好像我们下跳棋：既要给自己留下路，而且同时这颗棋子还能成为对手的绊脚石。如果我们既不是行业中的第一或第二，还要防止行业领头羊打击新兴模式，在你还没有成气候的时候就灭掉你这个新模式，让你失去新产品发展的土壤和环境。
- 我们更要考虑的是我们传统模式和流行模式结合在一起的新产品新模式，到底面对什么样的客户，市场容量多大，可能会有什么样的竞争对手进入，我们会有什么危险，我们如何应对，会吃掉多少市场容量，未来我们最大可能占多大容量，这样的容量值不值得我们做。我们做需要多少资金投入，需要多少钱来推广，需要多少时间达到我们的盈利点，在达到我们盈利点之前我们如何防御性发展。
- 摸清了我们自己的优势、困境、竞争地位、未来目标、未来业界位置，摸清了行业业界现状、未来影响，摸清了竞争对手，摸清了现在流行的盈利模式，摸清了未来更加敏捷的技术，我们才能给我们的产品定一个位置。新产品必须与公司的实力和战略相结合。老板的想法你不了解，你自己一个人瞎琢磨新产品的研发，很可能想法很好也未来很可能成功，但不符合老板的观点，没走出第一步就壮士未捷身先死了。
- 我先剖析行业标杆老大的产品。所以，我常常跟踪分析SAP、用友、金蝶这些标杆企业的产品，学习他们的架构、产品气质、实施模式、咨询模式、服务模式、销售模式、市场模式。
- 虽然他们都是做通用企业管理软件的，但是每个细分的行业管理软件领域发展有快慢不同。所以借鉴他们，就能在自己这个所定位的行业领域取得先机。有句话：我不期望比刘翔跑的快，但我只要比你跑的快就OK。
- 只比客户前进半步。这是做产品的很重要的指导原则。你可以想的远，很好的前景和盈利模式使你心情荡漾，但真正做起事一定要只比客户前进半步。你可以想的功能策划的功能很多，但一开始推出第一版的时候，一定要突出特色功能，而不要把你的想法全盘托出。
- 只有自己能讲通了，并且自己能说服自己，才能给研发内部扩散你的产品规划体系，从行业客户发展过去、现在、未来变化，现在竞争对手、咱们的竞争地位，讲到现在的新兴赢利模式、新兴敏捷技术、咱们的战略发展思路，说的头头是道，才能让你自己的研发手下相信你的判断正确，思路深远，才能形成目标一致。
- 获得公司内部最多人支持是一件非常重要的事情。尤其一件新的产品。到底行不行，大家首先就有疑问。抱着怀疑的态度看事情，没有问题也有了问题。
- 首先要获得自己下属的认同，这是最容易认同的人。这是你的群众基础，在你势单力薄的时候，他们就是你的拥护者和同声者。
- 然后是获得老板的赞同。没有老板的赞同，你和你的手下想做都不能做。老板不会给你任何时间和资源做的。想让老板赞同，你必须所有的思考都要按照老板的思考方法去给他讲，不能你按你自己的思路讲，那样行不通。另外，你的想法一定是以可以帮助老板赚取更多的钱为唯一目标，而不是其他和老板切身利益无关的目标。那样的事情，老板不感兴趣。很多人说我遇到慧眼识人的老板，其实没有，我只是能帮助他赚取更多的钱而已。这样的人，谁不想要啊。（有人想拿着老板的工资，敷衍老板的做事，干自己的事或者积累自己的客户、技术、朋友等等，这样的人，老板自然不喜欢）
- 然后是获得客户的支持。我走访客户时候，和客户老板经常会谈到现在的行业发展、行业挑战、新兴行业机会、互联网新型模式。和客户中层经理谈的就是管理监督、流程、评价模型。
- 客户是给老板钱的人，老板是给我们钱的人，而营销部门在乎的是好不好卖，能不能大卖，能不能赚更多的提成，而且卖完后没有后遗症（小心自己多年维护的客户关系被毁了）。而实施部门在乎的是东西好不好让客户接受，能不能很快培训完上线走人。而支持服务部门只在乎以后别出问题就行，工作越少越好，但也不能没有BUG，否则他们就没有多大用处了。
第二十二章 波,波,波
- 我们都知道，做新软件研发，是很消耗资金的。所以，我们都尽量使每一个产品都能生命周期尽可能的长。
- 在过去的几年中，我把软件分离为简化版、标准版、高级版，分别对应那些IT信息化水平和信息化理念层次不同的客户。
- 对于高端客户，就需要给软件注入管理方法。如何更有效的管理生产，如何更有效的管理销售，如何更有效的管理服务。而这种管理方法，是普通员工所无法理解并传递的。所以这类客户，就需要咨询式销售，与之跟随的产品市场宣传、实施、服务都不一样。
- 我们的软件产品也需要客户细分。否则低端客户觉得产品复杂，高端客户觉得小儿科，我们两头客户都得罪了。
- 公司管理团队做了很多交流，对未来产品发展和盈利模式和销售模式和现有员工素质都做了综合讨论。要不要开发新产品，什么时间开发，市场目标客户群多大，潜在竞争对手是哪些，我们如何防御，我们的盈利模式怎样，他们会占有多大的市场份额，我们最终可能会占多大，值不值得我们做，我们现有的资金和人才是否匹配我们去开发新产品，我们的困境和发展是否是新产品能解决的，在我们投入人力和资金研发的时候，哪些业务和人员来支撑发展，竞争对手如果发动进攻我们如何防御。我们一定不能一边忍着挨打一边研发，那样很可能我们没有尝到新产品的好处就自己先死了。
- 新的产品而且要与现有产品形成增强的核心竞争力。就像微软，虽然是世界软件帝国霸主，虽然微软的产品线有上百条，但微软主要营收也仅仅是在于四个产品：Windows、SQLSERVER、Office、VisualStudio。四个产品有机结合，互相增强，使微软整个产品战略整体推进。别的公司也生产微软类似的产品，但整合性不好，或者只是生产某一类产品，就无法形成整合竞争力。我们经常会说一句话：用了微软的东西，就得什么技术都得用微软的，否则就配合不力。可见微软的产品整合竞争力多强。我们做产品也需要这种产品体系。像金山词霸、毒霸、影霸，虽然都是消费类软件，通用性强，受众广泛，但几个产品并没有形成整合的竞争力，全是单点，在翻译、杀毒、多媒体播放各个领域都面临着强大的竞争对手，无法形成自己的整合竞争力，所以一直前进的很辛苦。我们做企业管理软件，就是不断产生主打产品，几个主打产品互相结合，并且这几个主打产品还能扩展形成相关的小的子系统，这样每个主打产品其实都是一个产品群，几个产品群互相结合，这种解决方案就很威力强大了。所以我们做产品规划的时候，都要思考新产品与老产品的关系，最好形成整合互补关系，而不是代替的关系，更不能形成互相不关系的关系。
- 我们不赞成跳跃式产品规划，看什么有前途就去做。因为一个公司在行业中有固有的形象和影响力，客户认为你就是IBM而非DELL而非迪斯尼，当然苹果转变不成通用。这就是企业气质，和人的性格一样，有些人永远无法成为管理者，有人永远无法成为软件开发高手。有网友提到蓝海战略。第一，蓝海不是那么容易寻找的，但公司需要每天开张销售。第二，寻找到的蓝海往往与现在无法结合，看着好却无法去做，做企业不能乱做，有可为有不可为，今天看搜索不错就去做搜索，明天看地图不错就去做地图，后天看网游不错就做网游，这类企业活不长。你如果在这样的企业工作，你能适应不断转变的要求么，你是一个搞搜索开发的，你能很快转去做网游吗？所以，产品战略规划，最难的就是继承过去，结合过去，还要面向未来。很多程序员有个毛病就是老喜欢推翻别人的代码自己重写一次，这种程序员能力是很低的，高的程序员都是如庖丁解牛一般，在看似复杂关联的环境下还能游刃有余。
- 产品规划，我们尽量促使产品成为消费类软件或基础类软件。所谓消费类软件，就是每个人都需要，每个人都得装一套。所谓基础类软件，如中间件、数据库、阿里巴巴平台等等都是基础类软件，上面可以插入或扩展许多合作伙伴的产品，形成了强大的产业链。这种产业链就类似整合产品核心竞争力，互相结合整体推进，就强大的很。大家研发产品的时候一定要记得这两个关键点：整合产品竞争力、基础类软件与合作伙伴。
- 第一年开始提上日程，解决要不要研发的事情。要不要研发就涉及到我上述提到的那么多问题，不商量定，新研发或许刚开个头就被下马了。而且要不要研发，需要全体人的支持和老板的坚决决定，否则有些利益团体给老板吹风，本来研发就是需要大量的人和资金，需要长时间研发、推广、销售才能看到效果，如果目前一面临点小困难，就很容易让老板动摇，就把新研发砍掉了，大家都去忙于应付目前的困难。所以，很多公司没有新研发，都是随着客户的项目来完成产品的实现。这样必然留下这个项目的缺陷和局限。所以，大家也总是忙于应付困难，而且困难总是一个接一个，怎么也解决不完，而无暇顾及未来发展研发。
- 把人布局好，才能规划产品。所以一个产品的研发，往往是立项、筹备就花费一年，设计、开发、测试、文案，为新产品而匹配的市场、销售、咨询、实施、支持团队的打造这些都需要花费1-2年的时间。
- 在销售好的时候，大家都觉得产品肯定还能火好几年，反对下一代产品研发的人很多。而真正的下一代研发，其实最好在产品第七年就开始启动研究立项。这样，老的产品在推出8-10后，慢慢进入衰落期，下一代产品就能成为新的现金牛，继续带领公司营收创新高。
- 研发的早了，推出来市场接受不了，不仅花费大量市场费用而无起色，就连员工和公司高层都觉得没有希望。本来好好的一个产品，就这样被停掉了。研发的晚了呢，人家竞争对手已经推出，我们才匆忙跟随，很容易新产品不优秀，老产品在衰老，几个回合就全军覆没。所以做公司，真是每日如履薄冰，随时都有覆没的危险。
- 关于新产品的研发，一定要有这个产品生命周期的视野。要从产业、竞争环境、国家环境、客户行业、技术发展多个角度去思考产品规划。在产品8-10年的生命周期内，每一年的产品完善重点，每一年的市场、销售、定价、实施、服务策略都需要不断调整，而且要针对不同产品层次不同客户层次调整所有策略。
- 很多人问我是怎么研发一套可扩展的架构。我说，你不了解这个架构最后的演化未来，不了解这个架构的生命周期，那么你就无法研发可扩展的架构。我们是做企业管理软件，不是做一个百变金刚的企业业务开发平台。架构所应用的产品，它的生命周期是3年，5年，还是10年，还是20年，决定了架构的要求。而且客户行业未来的8-10年的变化会如何。而客户行业往往受中国政策和发展变化影响很大。所以我也喜欢看《经济新闻联播》之类的节目，也阅读《中国经营报》这样的报纸。我一般也就能看到3年，5年都看不到。这样的素质，把握一个8-10年生命周期的产品，确实需要不断的升级自己的知识面和眼光层次，以保证自己能不断调整，不断滚动这3年的步长眼光。
- 这就是一个CTO需要做的产品生命周期规划。大局规划，细处入手，客户最关键的需求实现。大规划、大研发，既耗资金又不容易掌控这么庞大的团队又不容易控制这么长的研发周期。而技术总监，可能重点关注于这个产品的实现执行组织。而CTO，就需要在客户、产业、技术、盈利模式方面能有长远并且综合的产品战略。CTO和技术总监的关系类似于国家主席与国家总理之间的拍档关系，一个负责产品战略，一个负责产品实现执行。
第二十三章 八部众
- 这几天在规划新产品，新产品要做什么，两个来源：
- 看看业界最新的产品，先来个海阔天空的头脑风暴。从ipod模式谈到金山与google的合作，从android谈到百度的电子商务，从孙正义的投资校内网到汽车GPS、车载充电、车载MP3。但这些只是引新思路，真正还要落回到自己所在的行业所在的客户。正规的干，和现在业界的标杆比，我们水平差，和他们用正规的方法交锋，只有输的份儿。所以，历来以少胜多，都是以奇取胜。我们作为中小企业，把金庸+古龙，或者王朔+鲁迅这样来个改良菜，把其他行业或领域的新产品新模式引进来，或许才能突破现有大佬制定的游戏规则。
- 踏踏实实，还是要去检索我们的需求库。历年来，全国客户提出来的数以几千条的需求都记录在其中。小说，就是来源于生活而高于生活。所以，需求就是现实生活，我们的新产品必须从现实需求中提炼出来。否则就是空谈新产品，而根本无法落实。
- 我经常看到不少内地程序员拿Google的开发和国内的开发比。在Google，软件是艺术，大家阅读源代码也阅读的赏心悦目，大骂国内软件业毫无创新。我个人以为，我们的积累还是太短，从业者年龄和经验结构偏低，还无法从现状而创新。另外我们面临的资金、客户的限制，我们更是没有多少发挥空地。所以我认同软件工厂做法，大批量高质量低价格快速度的生产。但是，现状是，连能把这种生产模式做的好的软件企业都寥寥无几。大量的软件企业无法实现高质量大批量快速度，低价格也是降低质量克扣员工得来，势必引起客户和员工的反抗而终结低价格。所以，我们做新产品，也不能抱着科学家研究的思路，而更应该是在资金、时间、人的素质、人的数量、竞争压力、客户现状的框架下的量化可控的研发，有阶段，有目的，有重点的研发。
- 要有控制的研发，就要有需求管理工具来管理需求库，可以分类查询、检索、统计。就需要老老实实去回顾需求库。如果需要调研，就需要有方法的调研，从组织结构、过程、考核、优化这几方面来梳理需求，而不是开讨论会。
- 一个软件，对于不同的人来说有不同的要求。如果你把这些需求归类，你往往会得到这些要求特征。
- 对于销售来说，演示的时候稳定、易用、好看、速度快就是关键。
- 就如同我们遇到一个女孩，很漂亮，到底心灵如何，还没有那么多时间和机会去了解，但首先感觉就不错，愿意去接近。如果遇到一个女孩很普通，从心里一开始就有坎，不是抱着主动去了解的心态，而是怀疑和旁观的心态，就不容易了解一个女孩子。软件，和女孩一样，都同样的道理。
- 对于实施来说，最重要的就是软件稳定。软件不稳定，客户怕软件使用过程中出现问题，就不敢放实施人员走。而实施人员上面还有实施总监在管，有项目进度和经费的控制，所以实施总监老催实施人员为什么还不回来。实施人员也急呀，今天查报表，明天改数据，总是按下葫芦起了瓢。
- 软件稳定的基础上，最令实施人员头疼的就是客户需求的事情。如果每遇到一个需求都需要让程序员搞定，而程序员又少，就把实施人员晾到现场了。实施人员本来就想和客户搞好关系，以希望能够把项目顺利进行下去。这下，长时间解决不了客户需求，实施人员就交待不下去，当然要给程序员施加压力。这就是开发部往往是软件公司最受攻击的一个部门，销售、实施、支持都攻击开发部。所以，为了能让实施人员现场满足客户需求，开发人员往往想了很多办法。最常想到的就是开发平台。但我见到许多开发平台，简直就是面向开发人员的（什么XML、SQL、流程编辑）。实施人员只懂业务，对计算机软件操作并不娴熟。所以，开发人员必须要给实施人员提供实施人员能用的起来的实施工具。很多软件系统没有实施工具，只有一个光杆软件，孤立无援。
- 对于支持来说，软件稳定是第一位的。否则自己的支持电话非打爆不可，那样，支持的工作又累、钱又少还整天郁闷解决不了，还不如不干支持。软件如果不稳定，那么软件必须可跟踪。最怕软件出了问题，客户打来电话就说：软件不好用。这个不好用怎么查问题啊。到底怎么个不好用，报错的界面截图是什么样的，在哪个模块，怎么操作的，录入了什么数据，报的内部英文错误是什么，版本号是多少，软件打了多少补丁，操作系统是什么版本，操作系统打补丁没，数据库打补丁没，防火墙是怎么设置的，年月日和货币符号设置对不对，打印机设置对不对，自己的IP网络设置对不对。这些内容，最好像WINDOWS一样，出了错，把所有需要跟踪的信息都自动收集起来，然后报出一个提示框，可以发送报告给微软。所以，我们做了一个日志模块，可以自动截图，自动发送日志，自动记录当时操作的SQL语句，自动记录当时的客户输入数据和点击操作流程。给软件跟踪解决问题加快了许多效率。如果一个个去问用户，用户都不知道这些信息到哪里去收集，再一顿反复解释寻找，解决问题就很慢了。有很多时候，用户由于时间太长有其他事在身，就放弃了解决这个问题，久而久之，由于问题越积累越多，就渐渐不用这个软件了。
- 对于支持来说，软件自动升级也非常重要。我们往往遇到很多问题都是软件没有打某个漏洞补丁造成的。而且还有很多问题是由于客户端版本不统一造成的。如何能自动的、全部客户端一起升级，一发布补丁就自动全国升级，很多问题客户还没来得及发现就被解决了，满意度就上来了。
- 对于数据量大性能要求高的应用，性能是很关键的持续改进方面。
- 对于安全性要求强的应用，设计安全的方案，编写安全的代码，安全的测试覆盖是很重要的工作。
- 业界有个笑话，就是说微软的软件，从第三个版本才能使用。这说明，一个好软件，应该具备好软件的标准，但一个好软件，不是在一个版本就把这些标准全部实现。而是有步骤有重点的实现，逐步达到一个好软件。
- 到了软件第二版，客户签单量就上来了。实施工具就要提上开发日程，否则多个项目并行提出来的需求能把程序员的工作排到明年。
- 到了软件第三版，这是很关键的阶段。很多软件，生或死就在这个阶段，就看能不能过去这个槛。这个槛正值有部分客户和影响力，但还需要大规模高速扩展的时期，把握不住产品发展策略重点，很可能就渐渐的无声无息了。所以这一阶段主要是在增强现有功能和稳定性的基础上，尽量使软件易用、易维护。软件必须可跟踪可自动升级，这样才能支持日益扩张的客户群，才能使问题迅速解决，而不是大规模扩散。在这一阶段，不主张多增加功能，这样会使软件复杂性加大，阻碍了大量客户的理解，而大部分客户都是一般客户，而非理念先进的灯塔客户，能让大量的一般客户快速理解到软件的好处和应用操作上手，是很重要的阶段任务。
- 到了软件第四版，软件越来越复杂，如何兼容，如何容错，如何容易阅读，如何容易修改就成了首要问题。这个版本，重点就是内部代码重构优化。
- 到了软件第五版，性能是个问题。过去3-4年积累的数据使系统越来越慢。优化性能成为第五版的重点。
- 到了软件第六版，由于这么多版本的升级，功能很是复杂了，使原本易用的软件现在变的越来越难懂了，到底是特殊处理的业务。把常用功能和非常用功能分开，把正常业务处理和异常业务处理分开，做到组合裁减，一部份不常用的功能就渐渐萎缩掉，一部份常用的功能做增强。在这一版本，重构易用性成为重点。
- 软件到了第七版，就几乎在打补丁了，不再投入大量人去维护了。软件进入大销售大实施大维护的收割阶段，维护本版本的开发团队在萎缩，下一代产品在酝酿。
- 这就是一个软件生命周期中，不同时期的不同开发重点。把握好节奏，合适的时机做合适的事情，一点都不浪费投入人力。
第二十四章 葵花点穴手 定
- 我想到了曾经看过的微软的一种方法：对于什么目标市场的客户（一定要精确描述好你的目标市场，千万别用什么中小型企业之类的词语）而言，你的什么产品或服务（针对这类目标客户，你提供了相应的什么产品或服务，这个产品或服务一定要与你的目标客户匹配），提供了什么主要价值（要精确，千万不要说提高了管理水平。管理这个东西很模糊，就类似这个企业管理水平低，到底指的是什么），因为你的这个产品或服务提供了什么独到之处（一定要独到，否则人家为什么买你们，而不是买别人的）。这是微软的一个产品定位方法。
第二十五章 文档知多少
- 我们并不是为了正规才编写文档，我们写的每一个文档都有作用。我们也在力求能少写就少写，根据团队的、客户的磨合理解共识程度，哪个文档或哪个环节不需要写，我们就砍掉。
- 我们并不在乎正规不正规，我们也并不在乎我们看上去很美，那没有用。我们只是商业开发，我们要的是可控，在有限的人力资源、合同额、合同周期内交付出客户认可的质量产品（不是高质量，是客户能接受的质量，我们从来不为没有利益回报的东西多付出）。
第二十六章 狮面人
- 公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。
- 一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。
- 对于项目进度的保证，还必须有一个条件，就是：我们不允许开发人员在客户现场开发，我们更不允许开发人员和业务开发组长不在一起。
- 开发人员在客户现场，往往开发进度和功能需求变更容易受客户控制，致使开发团队做的计划和设计都被客户视为扯淡的东西。开发人员不满客户的做法，但在现场又没有办法，只好敷衍答应开发权且应付。本来一个理性的设计，被客户自己自以为是的好做法而推翻。软件什么扩展性啊，兼容性啊，都被扔在了一边。来客户现场，就要听这个特定客户的，你必须口对口服务这个特定客户，你如果和他讲其他客户怎么办，他才不管呢，反正他付了你的钱，在你眼中他必须是你唯一的客户。
- 我也同样不允许团队出现多种技术。多个技术，会让团队成本升高，每个人都得会多种技术。而我们做企业管理软件，要想上升赚钱，必须大规模一般员工团队低成本开发，这是我和老板都认同的一种思路。所以，我们必须使用最常用最普通的技术。除非没有办法。
- 我们曾经有一个客户，嫌10万块钱买了一张光盘，觉得贵死了。说地摊上一张才5块，你卖我10万。我们于是就把所有的帮助文档都打印了出来，600多页，装订成3本书，印刷好封面交给他。然后把软件装在一个很精美的木制盒子里，客户笑的很开心，把盒子和手册都郑重其事的放在了IT部门的柜子最上面。我想，软件是由代码组成的，确实不容易让客户理解其中的艰辛和付出，所以客户并不认可我们的付出。能拿客户可以理解的方式去讲明白就是解决方法。我一贯遵守的原则就是：要么解决问题，要么闭嘴。如果你想不出解决方法还抱怨影响团队情绪，那么滚蛋，这种人就是团队的毒药。
第二十七章 沙场秋点兵
- 我刚出道的时候，加入了一个新成立的研发中心，才成立四个月，我是第六人。产品还在规划当中，团队还在建设当中，技术还在学习摸索当中。
- 当时的技术总监做了两件我现在也认为很对的事情：一、他让所有人阅读上一代产品的源代码，整理上一代产品的功能，并且得出上一代产品的功能所映射的客户业务流程。并且要求指出上一代产品业务流程中的漏洞和矛盾。二、他让大家通过改造源代码来学习新技术。
- 他不仅仅让大家整理业务，还要画出来详细的流程图，整理出详细的数据结构。然后安排集中会议让大家讲，讲的时候，以流程图为主，走到哪一步，就进入软件界面讲解，并且讲明背后的数据存取到底是处理了哪些字段标志， 表之间是怎么关联的，到底从哪些表中取出来，表结构设计的有什么不合理的。
- 这次没讲明的，这次提问没有确切答案的，下次继续讲，而不仅仅是讲一回。我发现，很多团队缺乏这种不断追根到底的魄力。总是虎头蛇尾，第一次讲的很起劲，讲的期间出现了自己也没有理解透的东西，领导只是安排下去再去研究一下，但就没有了下文。自己下去了看了一下，认为找到了答案，但就没有再次校验的机会了，于是最应该细究的地方被这样放过了。我们知道，编写程序，往往是最细节差异的地方最容易出现问题，而且很少能被测试到，而且维护代码的程序员往往不清楚这块是干什么的，一旦出现问题很难阅读懂。
- 技术总监还让我们改造源代码。但这个也是有目标的，就是把控件都修改成一个统一的体验风格，没有DB的控件，就去寻找。寻找到了，就把这部分代码摘出来，然后形成我们自己的控件包，力求不要为了一个小小的控件，就安装整个的控件套件包。实在寻找不到，就自己开发控件。
- 我们是新团队、新产品、新技术，很多我们尚未了解清楚的，我们却把我们学习新技术后得到的控件应用到了我们以后的正式产品中，并且作为基础应用。这给以后的发展带来了几乎是灾难性的打击，我最后费了好大的劲才算把基础重构并且稳定住，否则基础崩盘了，上面的应用就不可收拾了。所以，我现在都是尽量限制使用新技术。也就是说，不会让新产品、新团队、新技术这三个新都同时出现，风险太大了。而且坚决不使用新技术作为基础技术。
- 我先安排团队开发了系统管理工具。这是个没有具体业务的，而且通用的，而且也是基础框架的一部份的开发工作。但是，由于系统管理工具，涉及到了新的组织结构模式，新的权限控制模式，这是大家不太熟悉的。而且编码架构风格和他们以往的开发不太一样。所以开发起来也是疑问不断，需要实时复查代码，实时解答问题。
- 终于开发完毕，我们开了一个总结会。大家都总结了对这次开发的体会，并且讨论出来以后再遇到这样的问题要如何解决，每个人的分工和人员配合流程再次确定，功能和功能的用意再次给大家讲了一次，对于新的编码架构风格再次讲了一次好处和用意。大家都说：如果在开发前就把这些讲清楚了，那么开发就不会遇到这么多问题了。我说：开发前我就是这么讲的，但是大家都不理解。这次经历过来了，就明白了。
第二十八章 代码那些事儿
- 我告诉他：做事不能走极端。要么全写注释，要么不写注释，都是不对的。我只在我认为要小心的地方，或者我自己都觉得很难理解懂的地方我才写注释。否则，我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂，我就不写注释了。咱们做企业管理软件，深入技术又没有，只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽然说理解能力不同，我能快速理解了的未必有新手能够理解，但是你看看我的代码你就明白了。
- 我的代码居然能看出业务流程。函数数量均衡，不像他的代码函数太多，跟踪跳转的很累，也乱了头绪。函数长度也正好在可理解阅读范围内。而且有一个流程控制函数，把流程处理环节串了起来。细深入跟踪某一环节，又发现了更细的流程。每个函数都看起来简单，但整体来看，却实现了复杂的功能。他问我是怎么做到的？我说，我的心中只有业务，业务和代码，我认为只是英语和汉语的区别，表达的是同一个思路。而在你心中，业务是DOC上的文字，代码是你的技术表现，你老需要把业务和代码映射拧在一起，我则不需要。业务流程如何，我的代码流程就是如何。
- 我还经常进行代码复查工作。发现有人的代码出现坏迹象，我就让他整改重构自己的代码。否则，定了规范，光喊口号让大家遵守规范又不检查又不惩罚，谁爱遵守规范？
- 很多网友都问到如何培养开发人员、培训开发人员、提高开发人员技术。我过去所在的公司是每个周五都不定期召开技术培训会。但是慢慢的也流于形式了。我个人感觉，技术培训会是个好事，但最终达到的效果可能是加强了团队的凝聚力和和谐力，有利于团队建设，但是技术提高，并没有给开发人员在实际工作中有应用。因为大家听了也就听了，会一散实际工作中仍然照旧自己的思维习惯，很难落实下来。
- 通过代码复查，这就是真真实实的代码，这就是大家最实在的工作成果和天天接触的东西，很有真实性，不脱离，有针对性。通过这种方法，达到了大家对自己日常写代码的技术技能的提高。这就是我对程序员的培训方法。
第三十章 蛋白质女孩
- 我发现这样一个现象：不管是实施部门、服务部门、销售部门，对产品的了解还只是停留在产品最初的几个版本认知基础上。现在软件已经升级了很多版本，加入了很多细节功能，也修补了很多Bug，但大家都不知道。仍然在按照自己过去的理解讲。虽然每次发布新版本，都有更新变动说明，都有最新的操作说明，也有操作视频，但没有人看。这和我们在网上遇到的很多开发人员一样，网上大喊：冰天雪地360度空翻裸体在线跪求，非得让人明确告诉他去看微软某个文档的第几页第几行才算了结。或许，人都大多如此。
- 我交给文案的任务就是：每当新版本发布，你对照你写的更新变动说明，你的操作说明书，你的操作视频，你的演示版，你搞个集中培训。并且你出题，给他们考试，给他们打分。但你给他们做培训的时候，必须有正规的签到表，正规的培训教材，正规的培训PPT，掌握好一节课的时间，掌握好一节课的重点，掌握好一节课的快慢与难易程度的节奏。下了课还必须让他们填写本课的培训反馈。你整天在这里写呀写呀，并不是我的目的。这样的状况，你写个十年又会如何呢？人需要成长。我希望你能成为优秀的咨询顾问或者培训老师，如果有可能，你也会成为优秀的市场人员或销售人员。这是我对文案这个岗位的职业发展期许。但是，机会是需要你去铺垫创造，你去抢机会（你自己铺垫的机会也有可能被别人抢走），你去有能力抓住机会，机会并不是我送给你的，机会是转瞬即逝的，你懂吗？
第三十一章 像咨询师一样思考
- 在软件产品方面，分了高级版、标准版、简化版。并且引入了测试，提高产品质量。引入了文案，制作了产品白皮书、操作帮助说明、安装说明、配置说明、维护说明、新版本更新说明、操作视频、演示版。在软件UI方面，引入了美工。在实施方面，引入了金牌实施顾问、银牌实施顾问、铜牌实施顾问。在服务支持方面也亦然。一切的一切，都旨在一个产品，面对不同层次的客户进行裁减组合，销售不同的价格，提供不同的服务项目与质量，与客户所期望的目标和所付出的金额成正比。
- 拼软件，这个竞争价值已经不高了。价格在持续走低。你报十万，人家两个人的草台班子，人家报2万。大家都有客户关系，你这个报价怎么能和人家两个人的草台班子血拼成本呢？
- 而管理方法，却是许多做管理软件的弱项。管理软件公司没有管理，这是业界很久的一个自嘲笑话。
- 很多人跟我要讨论管理，抱怨他们公司管理水平低。但管理水平低，表现在什么方面？优秀的、能比现在的管理方法优秀一步的管理方法是什么？与现有管理方法能改良契合的管理方法是什么？我反问过很多人，很多人都说不清楚。
- 很多人也做着企业管理软件，我每逢问他们：你们这套管理方法比你们客户的管理方法有何先进之处？你能为我讲讲你们这套管理方法吗？
- 很多人听到我的问题懵了。他们虽然做了多年的企业管理软件，但是从来没有这样想过这个问题。管理方法？
- 注: 也就是说，我们如果是做数字化营销，我们要比客户更懂数字化营销才可以，不然我们的工具，就是没有意义的，也没有竞争力的
- 说了半天，好像软件就是软件，管理就是管理，而这个管理软件，这个名词，太奇怪了，本来要把管理+软件捏在一起，现在却无法捏合在一起。
- 所以说，管理软件，要有竞争力，必然是在管理方法上竞争。这是目前能提高软件售价的唯一出路。
- 所以，我主张筹建咨询部门。不为别的，只为能提高软件售价、软件竞争力。当然，在适当时机，还能有独立的咨询单子可以做。但这种咨询项目的机会，是必定依附于我们的软件产品。毕竟我们不是正宗的咨询公司，我们给客户释放的形象一直是行业软件提供商。就如同IBM很难变成迪斯尼一样。
- 咨询部门要做的第一步就是提炼软件中的管理方法。
- 企业的管理方法，很多做管理软件开发的心中却没有这个概念，因为他们大多是开发出身，而且思维老跳不出开发这个圈子，做行业软件开发，就是用心深入的到客户一线去了解客户现状了解客户需求，他们没有方法，只有经验。
- 其实，企业的管理是有方法的。在咨询行业，要梳理提炼企业管理方法也是有其自己的咨询方法。
- 一、把你现在怎么做的写下来，然后照着做。如果写的和做的不相符，就改进写的内容，直到相符了。执行一段周期，重新审视你写的内容，需要整改或详细的部分，就让它完善起来。然后继续按照你写的去严格执行去做。这个思路就是ISO的思路。也是CMM可重复级的思路。现状好与坏，先放在一边不要争论。反正现在已经形成这样的现状，必然是符合现在的情况和历史的发展情况。每件事情的形成都不是无理由的。存在就必定合理。所以，先能让你写的和你做的吻合了，是最紧要的事情。先固化，后优化。
- 二、计划、执行、检查、修正、再计划、再执行、再检查。这也是一种方法。很多网友问我用什么测试工具、版本工具、设计工具等等没有，如何提升管理水平。我说，你先什么工具都不要用。用EXCEL就可以。这是大家最熟悉的工具。如果大家连EXCEL都不熟悉，那么总该熟悉记事本吧。用什么工具无所谓，重要的是，要把大家每个人每天要干什么任务要记录下来。作为软件开发，任务不外乎来自需求和BUG。所以，先做一个需求EXCEL和BUG EXCEL。有了任务的根源，再去计划任务。否则，任务就会是开发主管拍脑门自己想的。很多事情没有明确目标，做的半路被自己推翻了，更改了，或者废弃了，让手下人非常不爽，一来而去就显得管理水平很低了。
- 三、组织、岗位、流程、考核。这个方法也是企业一般管理方法，对于软件公司也通用。软件公司也是公司，也要生产销售，和自己面对的企业客户是一样的，都脱离不了这个方法论。公司的组织结构、每个人的岗位职责描述、每个岗位的每个职责的工作流程、每个职责的工作流程之后的考核。按照这种方法梳理下来，管理流程、方法都跃然纸上了。
- 四、问卷评分法。管理水平有没有提升，怎么知道？所以需要调查，而且需要周期性的调查，才能不断对比管理水平是上升了还是下降了，上升的幅度大不大，下降的大不大？上升，主要是由于哪些原因，下降是由于哪些原因？问卷评分模型能达到这个目的。
- 五、标杆法。问卷评分法是自己和自己的评，自己环比或同比，自己来看自己。但竞争，不是自己觉得自己提升了就觉得很好了。你觉得你提升了30%，但这种提升，一放到自己的行业内，自己还处于业界中下游，这就不愉快了。所以，还需要有标杆法，拿自己和行业领头羊比，看看差距多大，看看差距在哪里。
- 需要的咨询人才，一般具备以下能力：
- 能够根据企业现状，绘制出企业现在的组织结构、岗位职责、流程、考核
- 能够找到空白的、多重管理的、压力大的、不优化的业务流程节点
- 能够找到关键流程节点，制定KPI考核指标
- 能够根据KPI指标设计问卷回访评分模型
- 自从我们建立了咨询部以后，给我们贡献了正规的有体系的详细的咨询方法，在我们打单的时候，其他的IT开发商只成了编码商，和企业对于管理提升的期望根本无法匹配，而我们却让客户企业感觉到这是一家很独特很有实力的真正的管理软件公司。我们的管理软件也不再是企业现有流程的素描照片，而是有清晰的体系和重点和功能目标，也能明确的给客户企业评价投入产出效果。我们的咨询项目去年也有了开端。我们的软件售价提升目标达到。我们的另一个业务收入来源正变得越来越重要，即将成为我们继产品开发销售、服务外包销售的第三个主要业务收入支柱。
第三十二章 一分钟先生
- 每日接受开发组长报告给我的进度报告、功能需求设计报告，我来提出调整建议和指导。对于报告的问题，我会给出建议的处理方法。如果需要我出面动手解决，那我就出面。这是每日的例行事务，占了主要的时间。
- 处理手下员工间的流程配合问题，处理部门间的流程配合问题。一般都是根据现在出现的问题重申和强调过去的流程、职责。如果需要调整流程和职责，就把新的流程和职责重新定义清楚，并且观察几天的执行情况，直到每个人都按照新的流程走。
- 定期重新回顾这段时间公司业务的开展情况和面临的困难和未来的动态发展，以重新审视自己过去定义的产品战略，不断调整，以适合公司发展变化。根据产品发展战略的调整，然后调整内部每个人的职责和分工。
- 定期和每个员工在MSN中沟通或面对面沟通，了解他们现在的心理变化、薪水、公司发展看法、职业发展看法，以自己掌握的信息和自己的经验，对每个员工提出指导建议和方向建议。对于没有个人目标的员工，和他一起交流制定一个可见时间内他可以达到的目标。如程序员，我会提出，在6个月内，让你的代码变的比现在稳定，至少要达到你自己心中的满意的稳定程度。然后，我会针对这个目标，时常提醒他，不要让他忘记这个目标，鼓励他一定能达到这个目标。不提醒，人就会渐渐忘记了自己上个月才确定好的目标，甚至由于当前的诱惑和问题，对自己定的目标发生了怀疑或不感兴趣，就失去了目标。
- 对于每个员工所干的工作，我也会根据他最近出现的问题，及时进行能力方法、技巧的指导。如你应该这样做会更好。对于如何写稳定的代码、高性能的代码等等，对于如何测试找到更深层次的问题等等，都有技巧的指导，而且都是结合他现在所遇到的问题和手头的工作。我不会专门拿出一段时间来专门培训。我都是在日常工作中不断指导，把培训都化在了每日的工作中，尽量做到润物细无声。对于一些新手程序员，我拒绝回答他们的技术问题，我通常会说：把你们报错的那个信息原模原样输入到百度中，你就会找到答案。你也可以查询微软、SUN的联机手册，或者你到CSDN上问、搜索。
- 我还会平时看IT技术网站、行业网站，思考客户行业发展、IT技术发展。我来研究软件中的管理思想、管理模型、管理业务流程优化、考核评价模型。管理软件、数据分析咨询业务、市场推广，很需要这些模型和文章。每当我研究出一个管理模型，我就会写文章在内部发邮件，给公司老板、高层、员工推广
- 偶尔我会跟着实施、咨询团队到客户现场，体会真实的客户应用，和客户面对面交流，交流现在的问题，交流目前的困境和焦虑，交流未来的发展看法，体会客户真实的想法、思考思路，体会客户的真实应用水平。
- 由于我经常性思考产品发展战略、盈利模式、管理模型、工作职责、流程制度，所以公司的发展一般都是按照计划和既定流程走的。很多公司也不知道自己做什么才能赚钱，就东一头西一头拉项目，所以也不会有产品发展战略，而一般老板也是销售出身，想不透软件产品如何发展，而技术总监呢，又不懂这些，可能就是个技术牛人而已，甚至连技术牛人都算不上，只能算个一帮人的头儿。我们过去也是没有产品发展战略，但我是职业经理人，我不能让公司东一头西一头的随波逐流，所以我常常思考公司现状，从公司的现在的资源和优势和困境来找一条产品发展路线。就这样不断思考不断尝试不断执行，渐渐的，在我空降公司3年后才找到了现在的清晰的切实可行的产品发展战略。有了切实可行的产品发展战略，随之就有稳定的工作流程与职责，每个人就有了稳定的计划和工作任务。变化少了，自然也就不会老救火了。很多人说忙，就是老出异常，老救火，公司没有稳定清晰的盈利模式，一直处于抓项目的状态，每个项目都没有连贯性，当然也就不需要流程，也不需要职责，有了项目大家一窝蜂加班，没有项目大家闲的要死，这样的状态，即使有流程和职责也是被废掉，根本没有用，执行不了，项目一来就废掉了。
- 我不会去处理事情。我总是授人以渔。我一直强调方法和流程。如果一发现新异常，没有流程和职责和明确的人负责，我就会立即把这些都补齐，让明确的人去处理，而且有明确的处理流程。如果明确的人没有方法和头绪，我会指导他。但我从不会亲自做。
- 就是因为有稳定的模式和流程和员工岗位，我就从细节中抽了出来。需求调研、功能设计，有项目经理。开发有开发组长和程序员，测试有测试员、文档有文案人员，实施有实施人员，支持有支持人员，每个事都有专门的处理人员，而且有明确的流程协作。由于我的平时不断的指导，还有他们每日都处理自己专门的事情，所以他们对自己负责的事情越来越经验多，处理起来很快，质量也高。我看到很多公司业务不固定不稳定，人经常被抽调来抽调去，当然经验积累就不深入不专业，工作就不胜任，干活质量和效率都不高。
- 我这个人很专。我清楚的知道自己的优点和缺点，自己想要走的路。所以我十年，一直在开发岗位，而不是去做项目经理，去做实施，去做售前，去做市场，去做销售等等。很多人尝试了不少工作，但我没有。我知道自己，所以我总是把自己很优秀的方面练的更加优秀，这样我的缺点就非常明显，因为我没有去想着补齐我的缺点，我根本就没有为我的缺点投入任何精力。所以我这个人看起来很简单，同事们都能很容易看出我的优点和缺点，而且我的优点和突出。所以对于老板、对于其它同级同事，某件事需要不需要我的参与，需要不需要我做，大家都很明白。所以，我不擅长的事情从来不找我。这样，我也省去了很多乱七八糟的事情，就有了很多的时间。不少人这个也能干那个也能干，但都干不精，这样的人最容易被别人抽调来抽调去，当然就没有时间了。我只能干很窄的一个领域，所以我在这个领域精进的很快很高很专业，所以我总是能当这个领域的管理者。
- 我是个公司赚钱导向的人。我研发产品，率领研发团队，我一直贯彻这样的思路，所以整个研发团队全是这个想法。所以，很多事，一拿这个准则来衡量，这个事到底值不值得做就很清楚了。所以，省掉了不少事。许多人不知道自己要做一个什么产品，只要别人说的有道理没有办法回绝就做，到头来这个软件就成了一个四不像，看着什么功能都有，但这个软件的竞争力在哪里，它的核心模型是什么，很多人回答不出来了。我对产品目标，每个阶段的目标，产品的核心竞争力，我因为有清晰的产品发展战略，所以我都能把这些要素控制的很好。到底做不做，看是否符合利益和当前阶段的目标。
- 我这个人不是一个追求完美的人。只要不影响我的任务目标，即使出点小问题小异常，我也不爱管不爱问，就这样过去了。世界上很多事情，其实要成功，只有那么关键的几个点，我深刻的理解是哪几个点。于是我就把控这几个点。只要不是这几个点出现的问题，我都大事化小，小事化了。所以在我手下做事，干的比较轻松，还能达到目标。虽然在有些追求完美的人的眼里看来，每件事情都做的不好。但钱也赚到了，事也按客户要求的进度和质量完成了，而且后续的客户单子也来了，又没有影响未来的客户合同延续。一切关键因素都不影响，我何必花成本和代价去追求完美，让我的人累的半死呢？
- 我有个我自己的每日任务列表。我每天要做什么事情，我都随时记录下来，然后一条条的做，一条条的消。我看着不断有任务变灰，就很开心。我清楚的知道我每天要做什么事。
- 我要求手下在每天下班前一个小时把今天的工作进展发过来。然后我一一审阅，给些建议。这样，他们明天该怎么做，该做什么，今天遇到的问题该怎么解决，在他们下班前就知道了。这样，他们明天一来了就立即动手，根本不耽误时间，所以工作效率很好。
- 有的员工跟我絮絮叨叨讲了很多，反映他所遇到的问题。我听完后往往第一个校验的就是，你到底要达到什么目的。很多员工被反问后，是啊，我到底要达到什么目的。最后一重新审视自己的问题，很快就把问题简化了，问题的症结就找到了，当然解决也就很快了。甚至，弄清楚了目的，发现问题根本不是问题，根本无须解决。省了不少功夫。
- 我不喜欢员工像讲故事一样来龙去脉的报告。我总是强调，要1、2、3，这样来。而且你一次报告，不要报告太多的问题，人不应该关注那么多问题。关注多了，就根本理不清，所以也就解决不了问题。先要把自己的头脑清醒了，就焦点关注在前三个问题。等前三个问题解决了，再思考以后的。有些员工向我报告问题，总是拔起萝卜带出泥，一个问题的描述往往会引入另外的问题，然后问题串问题，跟糖葫芦一样。我总是让他打住，就说那是另外一个问题，咱们现在先别管它，咱们先把你现在说的这个问题说清楚解决完，再处理另外一个问题。
- 咨询有个方法，就是四象限。在时间管理中也有这个方法，重要且紧急，重要不紧急，紧急不重要，紧急重要。很多人其实是分不清楚这个事情是重要不重要的。我就拿我的目标和赚钱为导向来校验，不赚钱，也不影响未来赚钱，也不影响我当前核心目标，这个事情就不重要。既然事情不重要，那它怎么会紧急呢。不重要，就认为它是紧急的。就让大事化小、小事化了。很多事情，随着时间的消磨，也就那样了。你不去处理它，也就过去了，根本对未来没啥影响。
- 有时我指导训练手下员工，但员工听不懂，当然也不会按照我的方法来做。不少管理者见到这种情况，非常生气，还不如自己亲自动手做，本来简单的事情被员工搞了两天搞不定，如果是自己，两个小时就能搞定。但作为管理者，千万不要自己这么做。越这样，越是欲速则不达。每次都是自己亲为亲力，员工闲死，自己累死。我不怕员工做事做不好，关键点出了异常我可能会亲自处理，其他我都能过则过，而一件事情的关键点往往就是两三个。所以，一次做不好，咱们其他的事情我继续指导、重复指导。一次听不懂，我继续在下一件事情方法上指导，直到员工自己也能做的很好。时间，真是一个很奇妙的东西。它能自然改变很多东西。有时候你讲了许多员工也听不懂，时间长了，他也就明白了。不是不到，是时候未到。就是这个道理。
- 我希望记笔记，不管看书，还是做事，想到一个很好的点就立即记下来。而且我还经常回顾自己的这些记录，把它们尽量整理成体系和方法，让彼此关联起来。所以我解决问题思考问题的时候，总是有很多参考。而不是从头想起，也不是一遇到什么事情还得重复寻找资料。我这个人由于太专，所以关注的东西也不多。就看自己关注的东西，所以范围窄。许多人没有重点，什么热就看什么，而且积累了一大堆资料，反而后来自己都不看。而我，由于关注的少，所以看的东西自然比别人范围小，看的少也就看的精，而且还定期整理自己的笔记和资料，发现过时了就删除掉，保留下自己持续关注的资料。我发现，不少人有移动硬盘，里面放了很多资料，但真要做事反而一点资料都找不到，跟没有资料一样。
- 我喜欢看书和思考问题。过去坐地铁上下班，我都拿本书拿支笔，随时读书和记笔记。一天不读书不总结就觉得空空的，即使上个厕所也要带本书。很多工作中的管理方法很问题解决思路都是这样想出来的，在工作时间就赶快去，节省了不少工作时间。有的人记忆力还不好，还没有做笔记的习惯，还想问我有什么阅读理解的好方法？我的父亲常说：好记忆不如有个烂笔头。其实做笔记不仅仅是个做笔记这么简单的过程，而是在你写字的时候你就会思考揣摩思考，本来你认为很不错的一段文字准备记录下来，在记的过程中你就会想到自己的问题是否能有所借鉴，在记的过程中你就会联想其他同类的信息对比，总结出共性和差异点，在记的过程中你就会发现这段话说的比较片面不像你刚看的那么激动。很多人做不好自己时间管理，就是想做，但只是一个想法，真正做，就觉得这样做太累了，就放弃了。
- 我常笑说我是个生活不能自理的人。许多平时工作中的例行事情，我都交给我的团队中的文案女孩处理了。她就相当于我的一个兼职文秘助理一样，帮我处理了许多行政事务。我要去给客户讲某个产品，我给她讲好思路和客户爱听的重点，她就能把方案处理的符合我明天的讲解。比如我要出差，订票订宾馆只要和她讲一下，她就处理了。而且她还会告诉我怎么去那家宾馆，地址、路线图、联系电话都有。我很多事情，都是能不用我处理就不要我处理，我都分配给下属了。
- 我从小爱看书，但是家里也没有多少钱买书。我的一个亲戚家里有许多书，但我不能经常去。但只要去了，我就赶快看书。为了看的多，就渐渐养成了能很快把握书中的重点和思路的方法，也养成了如何快速鉴别手中的这本书对自己到底有没有用的方法。所以，现在工作也是，能很快读书，也能很快总结理出思路。对于员工报告的问题，也能很快找到重点和关键。这个性格也是我能留出时间的原因之一。但这个性格很少人有，这个是从小的影响，无法复制，所以我也就放到了最后。
第三十三章 灯塔客户
- 一个好产品，研发阶段其实是非常简单的，也是非常短的时间的，设计、编码、测试都不是具有挑战性的工作。而一个好产品，要获得营销人员认同、老板认同、实施部门认同、支持部门认同，更要获得客户的认同，是需要非常多的运营和各环节的人员的支持。不少新做开发主管的网友也曾经和我反应过他们的郁闷，我说这些都是很普通的事情，完成产品研发，只占产品成功的10%而已。一个产品死在公司里无人知晓，很普遍。想让大家都支持你，凭什么？就凭你是研发他是营销，他必须配合？
- 电话是打完了，演示版、说明书都给了客户。老销售的三把斧也玩完了。但谁也没做过产品销售，不知道怎么推新产品。问我接下来该怎么办？
- 我说，做灯塔客户。他们客户之间都互相走动，消息特灵通。先让他们中的有影响的客户先用起来，咱们给其他客户宣传推广的时候就容易的多。而且灯塔客户用的好，咱们的影响力就大的多。如果一开始怕失败怕困难，先做些小客户，反而费了半天努力起不了多大的水花。还不如咬咬牙顶一顶，成了也就成了。我想起了我9年前在其他公司做灯塔客户时的情景，那时候就是寻找了一家小客户，上线倒是挺快，也没修改多少，但也没有给软件的成熟带来啥提升，在业界的影响力也没有多大，金额单子也签的少，但最后的支持服务没少打电话，而且客户的IT能力有限有时还需要去出现场。唉，一切都归结于是第一个客户。客户处处拿这个拿捏我们，说我们拿他们做的实验小白鼠，就得送佛送到西。而且签的时候就故意找的当地的客户，就是为了做实施的时候成本低。但从此也形成了一种坏的实施毛病，就是程序员去实施，当场改程序的实施模式。这种模式的形成就在于做灯塔客户是程序员亲自去的，谁写的代码就谁去做灯塔客户实施，客户有什么需求就当场立即改掉，希望能很快把软件完善起来。但这样做就形成了惯性了，实施第二家灯塔客户仍然照旧如此，最后灯塔客户都做了好几家还无法交付给实施部门去做。差点把开发部变成开发、实施、支持全功能的部门。费了好大的劲做过渡转换，如今后遗症还不小。
- 他问我怎么选择灯塔客户？我说，首先找喜欢创新的客户。产品，也是有生命周期的。一开始，不能找大的客户，也不能找小的客户。咱们的系统还算初出茅庐，大的客户会控制咱们，影响咱们未来的发展。而小的客户，做完了影响力也不大。所以，我们要从中不溜的客户中间挑选喜欢创新的客户。不喜欢尝鲜的客户是没有应用的积极性的，反而对新事物天生产生怀疑和拒绝。
- 这个创新的客户还需要系统建设方面有影响力。有些客户很喜欢业务创新，但天马行空的，不去想系统能不能实现，最后反而想的多说的多，系统方面却无法落实。这类客户也经常会看见。所以，我们要找的就是喜欢创新、系统建设重视的客户，而且这个客户需要规模在中等。这就是典型的灯塔客户。
- 只有灯塔客户做起了标杆，有影响力的有分量的大客户在推广的时候才能关注起来。这就好比江湖，江湖老大并不关注那些小喽啰，而他最关注的人恰恰是第二第三名，因为一不小心这些人就会超过。
- 灯塔客户为生命周期的第一拨，大客户为第二拨，第三拨就是看着创新激进派和大客户们都应用的不错，那些抱着怀疑的客户才会蜂拥而至。这类客户就如同企鹅一样，谁也不下水，怕水中有海豹。等其他的企鹅下水了没有事了才纷纷下水。
- 这位销售老手果然重点关注了几个喜欢创新又系统建设的不错的客户。啥也别说了，肯定能搞定，能不能借我一个星期开发人员，我要领到现场去给他们修改开发，肯定签单回来。
- 走出第一步，千万要把型塑好，千万不要特殊事情特殊处理，否则特殊处理很容易变成习惯处理，最后再也无法回到正常的流程上来了。想让开发部不变成实施部，第一步很重要。
第三十四章 黑衣人
- 我告诫他们在演讲过程中注意以下几点：
- 不要把全部的功能都展示给客户。每家客户的问题重点不一样，每个人的听课重点也不一样。展示太全面，不仅听众听的糊涂，而且问的问题也多，还容易把客户最关注的问题迷失掉。我们只讲客户感兴趣的，宁少不多。
- 不了解行业，不要打比喻，否则比喻不恰当，很容易漏底。
- 不要和管理层谈行业，在行业上，不管你走了多少客户，你那点经验都是表面功夫，都是蜻蜓点水道听途说而以，真正的本质和内涵你根本不了解。
- 不要和IT层谈IT。你的技术可能连他都不如。人家估计从硬件到软件到安全到网络到数据库都搞过，而你虽然计算机系毕业，但连这些东西的技术参数都没有详细了解过，并且应用过。我们经常会碰到市场推广会上、白皮书上宣传的都不错，什么稳定性，安全性，用的时间长了发现不是那么回事。
- 我们最了解的就是我们的软件，我们软件中含有的独特的管理模型。而对于软件，对于管理模型，都是客户管理层和IT层都不了解的，这才是我们谈论的核心，这样看起来你才比别人知识更专业。
第三十五章 矛与盾
- 唐骏最后去了盛大，有了下面一段：陈天桥一开始说要跟我分工，我说不用，我是辅佐你的，不是来跟你分江山的，你不做的事情，我做。这是我的简单哲学。我相信他一定有不想做、不能做、做不了的事情，这些事情就是我的权力。
- 我会建议开发团队以老板可以理解的角度去展现自己的工作。我们引入了需求管理系统、BUG管理系统、任务管理系统，不仅仅是有利于我们自己的工作，也给展示我们自己带来了很大的好处。老板不清楚开发人员到底在干吗，是在偷懒还是在糊弄，所以心中从一开始就有防范之心。人都是这样，对自己不了解的事物总是抱怀疑态度。所以，作为开发团队，要证明自己，要让老板放心。否则，老板不放心，就会限制资源，就会疑神疑鬼。许多开发主管受不了这一点，相互之间互相防备互相捉迷藏，合作最终分道扬镳。其实，作为开发主管，是老板的下属，应该有义务去向老板证明自己开发团队的工作
- 开发团队的人，往往是做多说少，人都太老实，这就容易吃亏。老板也不是明君，就算是乾隆康熙这样的千古人精，也是被众多大臣搞的云里雾里。所以老板误解误会看错人看错事情是很正常的事。让老板误解你也是很正常的事情。我们就需要让老板正确认识自己。所以，首先，我要求我们的开发团队首先会做，假把式我不要，哑把式就太吃亏。首先要会做，然后要会写。写这个东西就太难为开发团队了，就如同让开发人员写文档一样的难。所以，我就需要帮助他们了。每做完一个项目，需求收集了多少，BUG测试出了多少，写了多少测试计划，写了多少测试报告，安排了多少任务，每个人的项目总结，厚厚的项目文档，有条理有根据，主动给老板报告，让老板不由得心服口服。所以几次项目下来，项目的质量也不错，项目的进展和问题也透明，项目最终落实下来的软件是老板看的见的，客户口碑是看的见的，项目总结是老板看的见的，老板也就放心了。于是给与的资源也就越来越多，干涉越来越少。放权，一定是建立在放心的基础上。有些网友甚至跟我问到如何向老板要钱要权，看来他让老板连信任都没有，这样的开发主管估计当不长了。
- 平时各个部门都有自己专门的事情，互相之间的事情了解不是太多，尤其对于整天钻在屋子里开发的开发人员，许多人不了解，但是开发人员开发的产品却是其他部门的人都在用。这很容易存在误解。互相之间不了解，产品有点什么问题就被放大。中国人就是这样，是哥们关系，就大事化小小事化了，不是哥们，就不太容易做到公事公办，往往带有个人感情色彩。往往其他部门的人对开发部门有怨言：“这帮家伙，拿着高薪，不用出差，不用打单，开发的东西还这么烂，还让我们销售、实施、支持，给我们的公司带来的多少麻烦”。所以，开发团队必须和其他部门成为朋友哥们，否则害了的就是自己。你在那里调试问题，别人在老板面前报告你的不是，你那个屁股是坐不长久的。
- 我们现在也没有对团队协作、忠诚度、执行力、沟通能力、文案能力、演讲能力这些方面进行考核。这些都是公说公有理婆说婆有理的，不同性格的主管喜欢不同类型的员工，就容易给考核造成虚假。条条大路通罗马，只要达到我们的本质目标就可以。谁说会沟通会演讲的人才是好的实施人员呢？我见过不少销售总监都是戴着眼镜温文儒雅，说话低声，虚心学习、记录、思考、交流探讨，和大家在文章杂志中看到的销售人员形象是反差很大的，但是他们却是销售总监，他们的销售业绩也是很好的。
第三十六章 地主家也没有余粮了
- 能把其他行业的成功模式恰当的改良引入到你所在的行业客户，这本身就是一种创新。如果这种创新一旦确实适合该行业，并且能成功的运作，那么这就是一种新的模式。
第三十八章 我就是一个香港导演
- 咨询业有一个很好的分析企业管理方法的模型，就是：组织结构、职责、流程、考核。
- 网友们想看的，最近关注的，我没有写，我还按部就班的按自己的思路写，最终，当然的结果就是写了没人看，点击量日益下滑。最后不得已，立即根据网友评论反馈奉献出网友们关注的问题文章，点击量才回升。
- 这就和我们写软件一样，必须要以客户为中心，按照客户的需求来设计软件，要有一种途径和方法与客户做第一手的互动。你越是自己闭门造车，越就远离客户，客户最终就会抛弃你，你只能自己自言自语。我这次写作，就采用了博客发表草稿，然后读者评论的需求交互形式，给自己文章内容的充实、问题重心调整、叙述风格、需求落实上都带来质的影响。
- 网友们喜欢看哪一章，我就提前把哪一张先写出来。这就颇似拍电影，今天到了哪些大腕演员，今天的哪些景已经准备好，今年就拍哪个镜头。所以我们常常看到电影这样拍摄：拍摄前有场记，记录下这是第几场第几次。大量的电影都是这样被拍摄完成的，并不是从第一场戏开始拍，直到拍完最后一场戏才算杀青。如果这样拍，早就浪费了大量的时间和成本了。比如说《闯关东》，故事历经好多年，重复过了多少春夏秋冬。如果真要一场场连着拍，这就没法拍了，只能集中把冬季的戏集中拍，然后在后期剪辑的时候，把这些戏按照剧本再串联在一起，就形成了我们现在看到的连贯的剧情。
- 我设计开发软件的时候也是这样，先把第一优先级的，互相关联的功能先设计出来，然后边开发边进行第二优先级的功能设计，这样就保证了设计、开发、测试、文案在同时工作，将串行变成了并行。
- 我写的时候，实际心中只有这么一个框架思路，里面每个章节的内容也只是有个那么个大概1、2、3点，细节也没有多想，觉得讲的是一个独立的主题，就应该独立出来成一章。所幸，过去这么多年，我爱做笔记，看到什么想到什么都随手记下来，有的记在了纸上，有的记在了手机上，最后我还得把它们誊到笔记本电脑上。我平时也喜欢润物细无声的培训、指导、影响，所以经常给员工给老板写不少邮件，这次写作，很多内容都来自这些平时的邮件和积累的笔记。如果没有这些平时的积累，我想要从第一个字写起，一年都写不完。
- 我在写这个系列的时候也是这样，细节没有，看着一个主题，想想应该要讲到1、2、3、4这几个点。但是讲完了，这个主题就太单薄了，也很突兀，让人看着也很枯燥，就想着怎么把这几个点串起来。好不容易想了些串词，一写，发现这个主题的描述需要事情的背景、基础、前提，否则大家不知道为什么要提出这个问题，这个问题有什么意义，到底要解决什么问题，这个问题能不能被这些点解决掉。于是我就回过头来把这些背景再加上。写完后，又发现结尾结的干脆，1、2、3、4点讲完，就完了。到底效果如何，有没有后遗症，该注意什么常见的执行问题，都没有说到。于是把结尾后果又写了出来。终于写完发布了博客，网友一评论，发现还是少东西了，于是又修改完善。有时候网友提出来的问题非常准确，没法见缝插针的修改，所以有的网友看见我的博文上有后续记，来专门针对网友的某个具体问题进行回答。这样看起来整篇文章就不连贯，因为往往是博文发布了两三天，我都在不断完善这篇博文，致使我第一次一气合成写就的文字，和后来的补遗，从心态到笔锋都不一致。所以，我在后来成书的时候，为了能使所有段落一致，花了大力气进行的改稿，经常把某段话搬来搬去，最后实在无奈，单独拿出来，看有机会再塞到哪篇文章中，或者干脆再另起一章。
- 我在设计软件的时候也出现这样的问题，尤其对于一个新的产品，而非一个新的项目。新产品，谁也看不好说不好，具体要什么具体要做什么层次什么地步，客户也说不好。大家都是抱着探索的心态去思考。但是总得要有一个开始呀，不能老在那里调研交流思考啊。怎么开始，做的多深合适。于是，我设计软件的时候，也是先把1、2、3、4功能点设计出来，然后围绕这几个点进行周边的完善，第一版出来后，对需求就比较准确把握了，但是看看开发出来的第一版，觉得过去写的确实不满意，真要真正做以后的产品，要作为公司未来现金牛的主力产品，肯定不能这么干。所以，我研发新产品的时候，不会在许多方面要求这个那个。第一版往往是按照粗框设计，实现的时候是为了快速实现看效果，只能算一个原型版本。正式做软件的时候就需要重新写一版。这并浪费时间，由于需求准确了，大家过去写第一版的时候也只是当作练手代码而已，并没有下多大功夫，利用价值也不大，所以重写很快，也没有包袱。大家都知道，白纸上画画最好做，最难做的就是维护已有代码，大刀阔斧改还不让，不改又不爽。为了让大家没这种后顾之忧，所以我还是建议重写的好，能利用过去就利用过去，利用不上也无所谓。
- 我在设计规划软件的时候也是这样，功能之间环环相扣。我的实施人员就差些，尤其是一些新手，喜欢把菜单打开，一个功能一个功能的讲。我曾经说过他们多次，不要给客户展示所有的功能，客户不需要所有的功能，客户只关心自己所关心的那一点。所以，我会从这一点切入，然后讲到它的前置条件，然后讲到它的后续分析，这样，一个单薄的点就被讲丰满了，而且客户也知道了我所讲的每个功能都很重要，都有存在的理由。这样讲就生动了许多。
第三十九章 方法为什么
- 这就是责任，这就是长子。长子就意味着你没有任何依靠，而且还有许多人要依靠着你。
- 你把你的工作岗位有了这种责任，你会发现什么压力、什么艰难，都没有了，你要做的，就是把心踏实下来，不急躁不茫然不失措不逃跑不灰心，然后把身子踏实下来，打好长久战的准备，打好艰苦战的准备，一步步，一丝丝的解决问题。
- 人和人之间，由于陌生而自然不信任，这是人的本性。如何建立信任关系，不是口头说说签个协议什么的。为什么有一句老话：“一起同过窗，一起扛过枪”。只有共同的经历，艰难的经历，才能让彼此建立起深刻的信任。自己和手下，自己和老板，自己和同等级部门经理间的信任，都是这样一日一事磨出来的，“日久见人心”。非要走极端，“要么别让我坐这个位置，要么就把这个位置的权给我”，这种思维是肯定不对的。谁会把自己辛苦打下来的江山全盘信任托付给一个素不相识的人呢？所以，我能做的就是尽量展现自己的工作效果，让老板看到我的全面价值。
- 我曾经说过一句话：企业的文化就是老板的文化。针对研发团队，我个人的气质性格和成长经历就决定了我的管理方法和风格，我的管理方法和风格就决定了我的团队的文化。物以类聚，人以群分。不符合我的风格的人自然就无法在我的团队中生存。
- 我的父亲经常跟我说一句话：“想做事，要胸怀大，要踏实，要低调”。我时时记得他的话，并由此受益良多。话虽简单，每个人都似曾听过，但能做到者甚少。在低潮时堕落茫然，在高峰时狂躁不可一时，都是不成熟的表现。人要想做事，看的是目标，不要在乎一城一池的得失。
- 责任感，就能产生领导力，就不畏挑战。态度、胸怀就能决定是否有团队能让你领导，是否有人追随你自然形成团队。
- 我是不赞同频繁跳槽的。家家有本难念的经。你看到许多外表光鲜的公司，你真正进入了都会发现金玉其外败絮其内。即使在我所在公司也都一样，对薪水不满意，对公司前途不满意，对老板朝令夕改不满意，对部门间斗争不满意，等等很多原因。这些常见的管理问题我们也都存在。
- 但是，每个公司都有机会。机会需要你去创造铺垫，需要你去敏锐的观察是否出现，需要你去快速果断的抓住，甚至有时机会需要你去抢才能抢到。机会，不是给你掉下来落到你的手上砸到你的头的。
- 我跟他说，其实作为中层管理，有五个点你一定要把握好：“需求、进度、质量、报告、平衡”。
- 你先什么也不要改变，先做三个EXCEL，一个是收集需求的，一个是收集BUG的，一个是用于任务分配管理的。你能把这三个EXCEL执行顺畅，我的方法自然也就用起来了。这就是我老强调的“从手头做起”。
- 想的要远，但做的要小。要有鹰的眼睛，也要有狮的胸怀，也有要猴的灵活，也要有骆驼的坚韧，也要有豹的敏锐与果敢，也要有猫的细致，也要有熊猫的低调温和。