Category Archives: 管理杂思

技术人员思维 – 造车轮、设计汽车

大部分人的思维都是差不多的。希望别人做的更好一点。认为自己能比别人做得更好。技术人员尤甚。 软件开发当中有两大误区。一是自己能造比别人更好的车轮。造车轮比打磨车轮更有成就感。 当我们做一个功能的时候,外面往往有许多几经存在的模块可供使用。但是开发人员选型时总有各种各样的理由,功能不够、不适合使用、性能达不到。因为这些模块都达不到开发人员心目中的标准。理由各种各样,不一而足。但是目的一样,想自己做,我能比别人做的更好。但结果往往差强人意。做的总是没有想的好。以前我一直也是这么自信,甚至动手自己写一个Java虚拟机。但最后结果除了跑一个没有任何外部依赖的简单程序之外一无用处。 在做一个功能的时候,选择一个差不多的开源3PP,再把她调教调教是比较好的方法。任何一个功能有太多太多的东西需要考虑了。像配置文件怎么读取啊! 二是集成汽车很容易。设计汽车比改装汽车更有成就感。 有一位名人曾经说过,“汽车吗!不就是沙发下面加四个轮子吗!”。沙发也有,车轮也有,把他们放到一起不就行了吗。 我们做软件系统的时候也有这样的问题。很多模块都现成有,把他们集成在一起不就行了。但到做的时候发现,事情往往要复杂很多。如相同功能有n多模块可供选择,那选那个呢?每次都有选型问题。每个模块之间如何通信?每次模块升级了之后根着升不? 在做一个系统的时候,选择一个差不多的开源系统。将中间少部分能显示系统核心价值的模块替换掉。大部分软件,系统架构不是核心价值。何必要把大部分时间花在不是核心价值的地方呢! 上面的描述适用于大部分像我这样做的没有想的好的人。把想的理想的东西打个三折再和已有的东西比较。把估计的精力乘三倍看是否能接受。如果还是很确定,那么可以勇往直前。 就像某些执着的牛人,做的总比想的好,而且一做就是一辈子。要不成功都难。让中 国再多一些强人,把大众也买了,就像买沃尔沃一样。

双赢培训第二天后对自己的总结

今天完成了第二天双赢培训。把培训中的内容做一个记录。 工作技能分三种,专业技能-Professional Skill、交流技能-People Skill和概念化技能-Conceptional Skill。这三种技能在职业生涯中都需要,只不过偏重不一样。交流技能在每个阶段都一样重要。专业技能在职业开始阶段最重要,层次提高之后就慢慢弱化。概念化技能职位越高越重要。对专业人士来说,最看重专业技能。所以经常导致看不起老板,觉得怎么这么简单的东西都不懂。应该反省啊,老板之所以为老板,必有他们超人的地方。一般就是人家人际技能和概念化技能比较强。 有研究结果表明,大部分的大方明、大创造都是咖啡馆达成的。这就是著名的世界咖啡馆。所以有时候应该营造轻松的氛围。 分析问题有Mind Mapping和三段分析法。所谓三段分析法,先确定问题,再找出出现问题原因,然后再找如何解决问题。而描述这个图就用Mind Mapping比较好。中间放问题,然后再从中间引出原因,再从原因找方案。Mind Mapping的好处有二,一是比较好画;二是大脑比较容易接受,因为大脑细胞就是这个结构的。 双赢沟通有六个方面,未来导向-Fast/Future Orientation、喜欢改变-Comfort with Change、双赢导向-Win-Win Orientation、相互依赖-Comfort with Interdependence、信任-Ability to Trust和反馈-Self-Discloser and Feadback。一切要向前看,不要老盯着过去不放。当然信任也是一种能力。有同事问我借100,我可以毫无考虑就借了,借10万就的好好想想了。在不太确定该不该信任时,做好最坏的打算,做好计划以减少风险。 人最信任谁,自己。其次信任谁,和自己像的人。所以想要做成一件事最好先和对方像。先从外表像,行为像,再从兴趣像,再到内在像。交流时先要营造一种放松的环境,做最好的倾听者,这方面神父做的最好。我去科隆大教堂的时候就打算用方言去忏悔。为啥呢,放心啊!瑞典有个著名的心理学家,Milton Ericsson。刚出道时分到疯人院去,有人就整他,要他去和有精神错乱的人打交道。以前所有的人进去都没有完整的出来过。那人幻想自己是一只猩猩,老做猩猩的样子、。Milton进去后就把自己也搞成和猩猩一样。一个小时就一直和病人一直转,后来那个病人受不了了,说:“别闹了,我们做下吧”。 Karl G.Jung研究搞出了个DISC。又是一个瑞典人,我就呐了闷了,瑞典咋出了这么些人。在瑞典呆了这么久实在是没有看出来,下次再去该好好研究了。DISC是将人分成四种类型。D-Dominance or Driver;I-Influence or Interaction;S-Stesdiness or Support;C-Compliance or Correct。D型人比较喜欢结果、直接,做决定,需要加强部分的是听。I型人比较喜欢气氛、梦想,应该需要加强细节部分。S型的人喜欢安全感、团体,应该加强主动性。C型的人喜欢细节和数据,应该加强做决定。如果一个组织D型的人多了容易引起纷争;多I型的人容易少善后的人;多S型容易保守;多C型的人容易无趣。最好是什么人都有,保持多样性。我感觉我们公司C型人也不多,咋就变得有些无趣呢?不同类型的人在压力要求下有不同的表现,D型人在压力下容易变成暴君;I型人容易攻击;S型人容易投降;I型人容易逃避。如果压力更大些,类型就会转化。SI,CD。所以有时候新闻说一个一直很平和的人,忍耐(S型)的人做了什么过激的事,那是已经几乎压弯了。

双赢培训第一天后对自己的总结

工作摸爬滚打这么些年,一直不是很成功。以前也经常反省,但总是不是很到位。今天参加了了双赢培训,感触颇多,对培训的内容以及适用我的地方作一个总结。 成功需要有IQ和EQ,这些在以前听到过很多。今天还听到了AQ、TQ和PQ。AQ-Adverse Quitient,逆境商数,这方面刘备可以说是典范啊,屡败屡战,无论到何时都对自己充满信心。我在这发面就不是很好,顺境时做的好一些,逆境时容易对环境失去信心,总想不适应啊!该换个环境怎么的。TQ-Team Quitient,团队商数。这发面我做的还可以,和团队合作还是比较融洽。PQ-Partner Quitient,伙伴关系商数,主要指沟通方面。这方面我做的也不是很好。这次培训主要就是针对这方面的,后面有各个部分的反省。 有研究结果表明,沟通中信息可分为3个部分。第一部分为内容Content(Verbal),而这部分只占信息的7%。第二部分为语气Emotion(Vobal),这部分占38%。第三部分也是最重要的部分,肢体语言Body Language(Visual)。通常三种形式组合起来才能达到最好的效果。而组合时一致性最重要。如果想表达仇恨,如果文字是仇恨的,语气是温柔的,脸部是微笑的。那么对方根本搞不清楚你要表达什么意思。对一致性上我做的还可以。但是三种方式结合,就做的差一些。譬如说发完邮件应该再打个电话确认一下。如果重要的事,还应该跑过去当面再沟通。主要还是主动性上欠缺。 沟通时可以分为3个部分,听(Listen)、问(Question)和反馈(Feedback)。 而听是公认最为困难的。听可以分为多个层次。不理不睬,边听边做事就属于这一类;假装的听,虽然耳朵在听,但是思维已经跑到其它地方去了;选择的听,只听自己想听的部分;带着答案的听-Listening with Answer,在刚开始听就带着答案了,后面的话没有任何意义了;同理性的听-Listening with Understanding,听的目的是想理解对方的想法。不同场合下还有,第三者立场-Dissociation和对方立场-Association。这方面我犯的错误就比较严重,特别是对不想交流的人,经常会不理不睬。以后应该尽量避免,应该多用同理性的听,并在不同场合站在第三者或对方立场上思考问题。 问分为三种形式,开放式问题、封闭式问题和引导式问题。开放式问题和封闭式问题有不同的应用场合。引导式问题显得不是那么光明正大。我的问题主要在于人多的会上问的比较少。 反馈分为要求别人给自己反馈和给别人反馈。给别人反馈需要注意方式;给自己反馈需要心态。这方面我做的很少,无论是给别人反馈还是要求反馈。 有一个著名的潜能之窗(Johari Window)。分为4个部分,我知你知-暴露在公共场所的部分;你知我不知-盲点,如果第一次照镜子,第一次听自己录音都会觉得怪;我知你不知-私人部分,大部分名人倒下都是由于这个原因,有不可告人的地方。要求他人反馈可以减少盲点,和他人分享可以减少私人区域。 任何事物都有一个周期-Life Cycle,无论动物、植物、人、公司。动物植物很难在一个生命周期之内达到几个高峰。一个公司通过不断寻找增长点达到多个高峰。一个人可以寻求不同的职务、公司、行业来达到多个高峰。需要不断的寻找自己的第二曲线-2nd Curve。寻找第二曲线可以在上升期、顶峰、下降期和濒临死亡期。最好的点是顶峰。很多公司倒闭的原因就是在濒临死亡期才想到去寻找第二曲线。我的问题主要在于在上升期的前期就忍不住寂寞开始寻找第二曲线。 明天还有一天培训。到时候继续反省。

如何提高软件可用性

大家都知道软件可用性是一个软件成功的关键。微软成功的关键是可用性,苹果成功的关键是可用性,狗狗成功的关键还是可用性。 那么如何提高软件的可用性呢?用户根据什么来使用一个软件呢?那当然是软件使用文档了。一个软件如果软件文档很难编写,一个功能说明如果连设计人员都看不明白,那么软件的可用性就不咋的。所以应该边编写软件文档,边考虑可用性,再反过头来修改软件设计。 很多公司都有专门的文档编写人员。但是经常存在的问题是文档编写人员根本就不明白软件是怎么回事。更别说提出软件可用性的建议了。如果文档编写人员也能对系统相当熟悉当然最好了。但是术业有专攻,一般很难达到。即使能有这样的人,成本也不一样了。 所以我觉的软件文档应该由文档编写人员提供文档结构参考。设计软件设计人员负责编写。编写过程中如果发现难写一般会比较自然的考虑修改设计。文档初步编写完成之后再由文档编写人员润色。润色完了之后再由客户代表和系统测试人员测试文档是否描述清晰。

敏捷之我见

现在到处可以听到敏捷,似乎谁不敏捷谁就OUT了一样。我听过周围不少同事朋友都在讲,他们公司使用敏捷了,应用了哪些敏捷的最佳实践。感觉好像使用了那些最佳实践就实现的敏捷一样。 敏捷的目的在于响应快速的需求变化。所有的最佳实践都是为了实现这一目标。这些实践当中最重要的有三项。 最重要的一项为缩短和客户之间的距离,减少中间层次,尽量扁平化。这一实践在很多地方都没有提及。如果客户可以直接面对团队,那么客户就应该直接作为Product Owner。但是这种情况对客户端要求很高,一般不太现实。最合适的是三层设置,三是一个神奇的数字。一层为团队,第二层为客户代表,第三层为客户。客户代表需要理解并分析客户的详细需求,并将需求转达给团队。团队完成后,客户代表检查是否完成需求,再由客户代表给客户做演示。如果这个设置超过三层,往往很多需求在交流过程中会严重失真,最后的成品和客户的需求差别会很大,有时候甚至完全不一样。管理以及交流好一些,那么失真会相对小一些。如果一个产品经常有功能做了之后没有真正使用,一般都是由中间层次太多引起的。其实这也不是敏捷特有的,瀑布和螺旋开发方法都有。只是敏捷更提倡频繁的和客户交流,如每月一次,甚至一两周一次。 第二重要我认为是缩短发现问题的周期。发现问题的方法无非就是测试,包括单元测试、功能测试、界面测试、集成测试和系统测试。以前这些测试也都有,只是没有那么受到重视,有很多还是非自动化测试。而敏捷要求将这些测试有机的结合起来,每种测试覆盖一定的范围,像摞金字塔一样。如果没有多少测试,或者测试不是自动化的。那么发现问题的周期就会比较长,短则需要几天才会发现问题,长则需要几个月。问题发现的越晚,那么改正问题的成本就越大。能记住上上个月1一号干了什么事的人毕竟很少,更何况还不知道这事是谁干的。如果能有完备的测试,80%行覆盖率左右的单元测试,每个功能至少一正一反两个用例,每个边界一个测试用例,界面常用操作流程测试,系统打包生成、安装、启动和运行测试。问题在每种测试都会被拦一道,最后泄漏出去的问题就会很少。很多问题在单元测试就能发现,而这一般只需要几分钟的反馈时间,几分钟之前干了什么事谁又能记不住。其它的很多问题也可以在每晚集成中发现。 第三重要的我认为是缩短任务检查周期,每日晨会。每日晨会应该可以说主要是从心理学得来的。我总不能说昨天我啥也没干,今天我啥也没干,明天我还是啥都不会干。每日晨会还可以把项目当中哪些事做完了,哪些事没做完放到桌面上来,而不是一直只在某个人的箱子底下。啥事儿放到桌面上都是比较好解决的。 敏捷当中还有很多最佳实践,那些最佳实践主要是为了减少问题的引入,像结对编程,绝不加班。 敏捷只是一个名词,真要用好敏捷要从缩短反馈周期出发把各个最佳实践有机的组合起来。

新人培训反思 该谁先培训谁?

前两天,去给一拨新人做培训。在培训中前的对话中,发现有很多人很有想法,以前的工作经验也很有参考价值。它山之石,可以攻玉。 我就在想,这个新人培训,到底该谁培训谁?招来新人的其中最重要的一个目的就是为团队添加一些新鲜血液,加入一些不一样的东西。而我们却在新人一进来之后,先来个培训,把新人先同化一下,把棱角先磨掉。这是不是没有最大限度地用好新人呢! 公司新人中很大一部分是从竞争对手中过来的。对竞争对手的做事方式,管理架构,技术特点,产品结构等应该非常熟悉。而这些信息是我们想方设法想要的。我们是不是应该在新人进来之后,先让新人来给我们作一轮培训,然后才是做新员工培训!

几种软件开发的模式

模式一: 先收集尽量多客户的需求; 对收集到的需求进行分析; 根据分析的结果进行建模以及架构设计; 将软件交付给客户,如果客户有什么特殊的需求那么再进行产品定制。 模式二: 拿到一个特定客户的需求; 针对这个客户进行需求分析; 为这个客户进行建模以及架构设计; 对该反案作一些泛化工作然后提供给下一个客户。 模式三: 提供一个建模的框架; 设计一些不易变的一些模块及服务; 根据对客户的理解提供一系列的参考集成反案给客户; 客户拿到这些方案后进行一些简单的定制; 客户设计一些自己的集成方案; 有了对客户更深入的了解后修改参考集成方案,设计一些新的集成方案。 这几种模式各有优缺点,没有哪一种比另一种更适合,各有不同的应用场合。 模式一在能够分析好客户的需求情况下非常适合。模式二在快速响应方面很有优势。模式三在客户之间方案集成差异很大的时候非常适合。