一次失败的商务谈判

我从小就是个胆子不大的人,有想法也往往都放在心里。每每无法反驳别人,事后内心却冒出看是有理有据的n多言词,但在交流争论的那一刻是无论如何也想不出来,说不出来的。总之,我不是一个擅于交际的人,不擅于说一些奉承的话。都说言多必失,但在这种商务谈判场合,言少更是将自己立于困难的境地,失去了气势,损失也就更难挽回了。

满心欢喜的去出差,看似胸有成竹。想着销售已经打点了一切,而做技术的我只要说些工作的内容即可,那些价格与客套的言语也不必我去过多的操心。但事与愿违,最终的价格也没有谈拢,工作没有得到肯定,我们也无法拿出一个领导都无法接受的价格去苟且,只能悻悻而回,留下了失望的背影。基于这个合同的特殊性,我们也不是完全的失败,公司之间只要有关系维系,总是有得有失吧。但对于我而言,还是有几个方面值得注意与借鉴的。

首先,最重要的一点,我们的合同没有得到主管领导的支持。这也是我们这次工作最大的失误。对方公司经历了人事的变动,原先合同签报的经理去了别的部门,而我们在商务谈判之前没有对这个领导进行很好的沟通。他甚至都没有参加我们这次商务谈判。在没有主管领导的工作肯定下,与他们的商务代表的会谈就完全失去了支撑。而他们的员工在这个合同上也缺少相应的话语权。价格得不到支持,谈判也就无疾而终了。这点也说明我们准备不足。

其次,从自身的谈判技巧上看,还是显现的非常稚嫩。从困难上的估计不足到谈判中的拉锯。我们都没有很好很完整的体现出我们的立场,我们的语气不够强硬,我们的态度不够坚决,我们的例证不够充分,我们的想法不够灵活,我们的立场也不坚定了。但是,领导的底线我们又不能破,谈判也就无法最终的完成了。我们没有谈到这个软件给他们带来的收益,没有深入去谈这个受益的人群,没有反复的重复,表明立场。而我们自身也没有很好的协调一致,观点相呼应。

第三,失败的根源另一根源是准备不足。我们的报价单还可以写的更加详细与专业;我们对之前的合同内容与金额的不了解;对签报内容的不了解;对对方谈判人员,工作人员的不了解。我自身没有充分的准备与意识。虽然根源是我们接触这个项目的时间很短,前辈也根本没有相关的资料给我们。而没有这些准备,在面对突发状况时自然就像无头苍蝇一样不知所措了。

实在是经验不足。内部单位之间的合作与独立企业之间的合作有着完全不同的特性。本来企业之间是签订合同,再开工。而这里就变成了先完工再谈价格,内部立项。这样我们it部门完全就被动了。除了靠信任,很可能落得个竹篮打水一场空。但内部单位之间又有不同的性质在里面,也不便再述了。通过这次谈判,我想可以从以下几个方面去吸收经验,为下次谈判做好准备。其一,搞好人的关系,确定主管领导同意的价格,得到他们的工作肯定和价格支持后,再来做价格的谈判。其二,面子工作要做的更好更细致,材料要充分,论证要充分。其三,靠经验积累,在谈判的过程中更有气势,更有力度,据理力争。

这次的失败对我们而言是挺突然的,但事后回顾上面的三点,说明我们的工作还是没有到位,没有做好。希望总结好这次的经验,在下次的谈判中将自己立于更好的局面。

如期提前转正

半个月前,一直在翻看自己的OA看自己的转正流程走到哪里。每次都是看到人事专员审批中就没有了下文。一来自己的行政制度考试第一次没有过,需要等到这个月初的补考才能知道是否通过。二来部门人事,领导都没有对我进行面谈,相应的流程也没有走。这个月初才进行的面谈,再加上相继出来的行政考试成绩,然后昨天才去OA上去看转正流程,惊喜发现流程审批结束,员工信息的状态已是转正,而且转正日期并不是昨天,是我之前设定的2个月转正的日期。当时考虑提前转正很简单的原因就是8折的薪水,不想自己的辛苦被打了个折扣。

当然,转正也只是意味着自己的工作初步得到了领导的认可,但其实自己还是有很多工作可以继续努力的。至少要从思想上更加重视起来,要绝对转变当初那种责任心不强的局面,摆正自己的心态。增加自己的团队意思,把过客思想转变成主人翁思想;把随便学学转变成认真求知,求真的思想;把短期战役转变成长期斗争的思想。努力充实过好在这里的每一天。

环境改变自己,改变人生。如今已从之前的安逸,平淡的工作中脱离出来,一头扎进激情,活跃的工作空间。身上的任务变了,担子重了,自己的角色也就相应的转变了。做事要更加的积极主动,要更懂得互相分享,更懂得沟通与协作,更懂得付出,淡看名与利,把事情做好。在这个与年轻人共同奋斗的环境里,更加更多的去激励他们进步,帮助他们成长,用过来人的经历与体验和他们一起进步。

提前转正,我还是有很多要去学习的。不懂的,未掌握的知识还要尽快的去学习和熟悉。领导分配的任务要努力的担当下来,还要积极与领导进行沟通与协作。在一岗,做好一天的工作。全方面的提升自己,我也把这样的机会当做自己的一次升华的机会。相信自己,相信信念,相信自己一定可以。

试着去写测试案例

工作近十年了,也就是说快写了近十年的代码了。我承认之前的九年没有为自己的代码写过任何的测试脚本,或者是任何形式的测试案例。每次穿梭于书店或是网上博客等,我对单元测试,或是诸如自动化测试都十分的不屑。“代码要紧”,“完成工作要紧”这是我当年的信条。虽然我认同自己的开发习惯还是不错,编码风格也挺赞的,但自从阅读了一本名为《测试驱动开发》的书后,才发现以测试为驱动的开发过程的确是对人们自认为的开发过程的一种颠覆。无法完全的说明哪种方式的好与坏,但编写测试案例,写单元测试确实给我带来了不同的思考,并认为这是非常有必要,也会为之努力而实践的。

编写测试案例,让我们更细致的去分析问题。计算机对代码的执行不会欺骗任何人,我们开发代码的过程中总是力争将所有的点和面都考虑到,将所有可能的情况都涉及到。所以有必要模拟各种可能的场景去测试每一个细小的环节。而这个细小的环节就是我们程序中的小小单元,对一个个小小单元的全方位测试,才能力促整个程序逻辑的完整测试。所以单元测试是整个程序测试的根基,是实际业务的问题点,逻辑点。将复杂的问题分析到点,测试到点,会有助于我们在编写代码的时候理清关系,将点组成线,从而组装成整个程序。

编写测试案例,让我们更好的去重构程序。测试案例能为整个程序的正确性奠定了一个基调,任何可能的修改都不能违背单元测试的正确通过。而同样的有了测试案例,相关开发人员,可以快速方便的通过测试案例理解程序和代码的运行过程。同样的,对完美代码的无限追求下所做的改动,也能保证所做的代码重构没有改变原有程序的正确性。也不用过分的担忧代码结构的调整会造成严重的逻辑的错误,而这些错误的改动却没有被发现。当然,这里有一个前提条件,就是我们要适时的去维护我们的测试案例,并要保证我们的测试案例本身就是经得起验证并且是正确的,否则,上面所说的一切将都是不成立的。

测试案例的编写,能帮助我们快速熟悉业务,甚至可以帮助我们提炼出程序的运行过程,制定合理的程序框架。让我们在修改代码的时候,不易更改原有的逻辑,不会去污染原有的代码。可以提高我们写代码的正确率。能更好的服务系统维护,二次开发等等。说了这么多的测试案例的好处,但只有尝试和运用,你才会有这样的体会。也许一开时你会觉得写测试案例是如何的无聊和重复。但当你看一段没有测试案例的代码时,你又会感到无奈无助,更会为在这段代码上进行的修改或二次开发而感到不安。但肯定会为有相应的测试案例而暗暗叫好,并会为一段代码补上测试案例而开心不已。测试案例就好比前人栽树,后人乘凉。

那么问题来了,测试案例怎么写?

测试案例应该全面但不重复的,我们应该尽可能覆盖所有的程序代码,但我们不必为代码写重复的测试案例。测试案例应该简单明了,让人一眼就能看明白。你不必纠结英文怎么翻译,你甚至可以简单的就用中文的类和中文的方法名称来表示这个测试案例的含义,甚至可能是测试的目标名称(但我反对在生产代码里用中文,甚至包括中文拼音)。测试案例往往是并列的,列表状的,所以你能一眼看到测试的结果和未通过的测试内容,方便查找和定位。当然,你还要有好的测试工具,测试包之类的。最后也往往是最重要的是保证你的测试案例是最新最完整的。

测试案例看起来像是开发过程中的一个负担,但这只是你没有从根本上去发现测试的魅力和益处。只有你潜心下来去做,去完善你的单元测试,久而久之,你会发现,测试真的很美。

挑大梁的试用期

试用期还没有结束,还没有转正,我就已经快速的进入了工作角色。虽然很多项目的业务没有具体去熟悉,我都想好了,等碰到具体问题再详细去了解,这期间也陆陆续续的完成了一些开发任务,更新了一批bug及各种新的需求。看着任务单里一个个删除完成了的任务,那种试用期对业务和工作的懵懂和迷茫慢慢的消逝了。

是很忙,至少比我之前做的许多工作都忙,也许除了我的头两年工作,那些最初入行的日子,工作肯定是不轻松的。后来到了太古,更谈不上忙,除了短暂的两三个月由于数据库架构的调整所对应的项目重新纠正和开发忙之外,我认为自己都是那个略微显得空闲的人,同样的也就没有了值得去称赞的事迹。也正是在那样的日子里,我会经常的去更新博客,写写体会。而现在,从早上进入办公室起,到不得不加班的七点后,我都没有一整段的时间来静静的写点东西,思考思考。也许,这样的忙日子是对我之前工作十年的空日子的补充吧。也许我的时间并不值钱,真正加点班又有什么呢。

刚来就出差,而且也出色的完成了任务,这从多个领导对我的谈话里都透露了出来。领导也建议我看看能不能提前转正,我也报着试试看提交了转正申请的流程。也多少从领导那里得知月奖和年中加薪的各种激励政策,我也热切的期待那个时候的到来。旧同事也要离职,领导也把所有的活都让我试着接下来。没有怨言,也许这些都是我能做的。慢慢的我也会去评估工作量,也会向领导申请新的资源和后备力量,这么多项目总是有多个人知道会好些。团队稳定是我们项目组是否完成目标的关键所在吧。尽力的保证当前各个项目的维护稳定与反馈及时,是我现在努力去完成和实现的。

我当然希望自己能去参与一些新的项目,外围项目,比如电子政务,智慧城市,和大数据沾上边的都可以。也许到最终的开发工作和当前做的可能没什么很大的不同,但这种经历毕竟还是有很大区别的,这种项目经验会与现在的小范围的项目有很大的不同。统筹的,多角度的,决策范围的业务会让你更广大的视野,对自己的帮助和提升相信也应该是巨大的。希望能如领导所说,会有这个参与的机会,但这也只能等到现有的项目都能很好的服务,或者我们已从当前的业务转身,那就是另一种情景了。期待那一天的早日到来。

又有同事离职了,还未转正,又交接了很多的工作给我,自我感觉算得上是一个大梁。经验往往在胜任工作的过程中扮演着非常重要的角色,无论是具体的开发实践,还是客户沟通,同事间的相互协作等等。而这些也只有经过时间的洗礼,才会慢慢的成长。而我期待这种成长,能让自己完成质的跨越。

新工作一月记录

时间过的很快,在新的单位也足有一个月之久了。从当初的种种不适应到现在的勉强去适应,随着工作的深入,接触的东西与人也越来越多,所有的一切都迫使你沉下心来去做一些事情,完成一些任务了。现在记录下这一个月来的主要内容吧。

出差台州将近有十天之久。出差本身就不太适应,再加上一来这个单位就出差,心还没有静下来,又要人飞的感觉,一切都没什么底,但也要硬着头皮上的感觉。还好吧,工作也算顺利,也不是什么大的项目,功能也没有太复杂,也都陆陆续续的完成。只是后端数据这块变动太多,所以还未能将项目完结。接下来的任务也会慢慢的变少,但也要抽出不少时间去完善各种功能的。

顺着项目算是学会运用了些Struts,myBatis框架吧。只是我还不会搭,或是说从头搭吧。在原有框架基础上增加删除新功能对我来说并不太难。难点是那些未曾触碰的知识,比如大数据量下载的处理啦,tomcat调优啦,还有就是自己想去学习的这些框架的原理。Java基础不扎实,看这些源代码也是很吃力的事情,再加上各种设计模式,肯定会花很多时间的。能接触更多的知识无疑对我有很大的帮助,这能完善我在Java开发上的知识体系。

不习惯加班,不习惯打卡,不习惯写日志,不写周报。在这里都要统统说NO了。所有的这些都会被以罚款论处,所以无论如何也不能和钱说不去。每天总是时刻提醒自己有没有忘记打卡,有没有忘记写日志。甚至加班的时长也作为小组考核的依据,压力山大啊。有的时候,我会想趁加班的时候看看书,或写写日志,做个小结,把这个时间用起来是再好不过了。

都快一个月没写日志了,好害怕自己不再爱上写文章,不再喜欢思考。也许是没什么时间,再说真心不想成天盯着电脑啦。每次打开记事本的时候却发现想写的东西并不感觉到有什么价值。但又不想这么消沉下去。总要努力让自己在博客上发出更多的声音。

新的环境 新的起点

还没有来得及适应新的工作环境,就被领导安排着出差来到台州。我的心是忐忑的,因为我的java开发经验真正意义上不足两年,我没有系统的学习过SSH,用我之前写的博客里说的那样,我的java是自学的。但给了我这个机会,我想我会努力去抓住的。我想着尽快的学好SSH,然后有机会学习点分布式或是大数据方面的知识。我目前没有后悔放弃我的.net而转到java开发。这并不奇怪,我曾经也迷迷糊糊的学习了一点php知识。语言对我来说就是个工具,但语言背后的那些高深的技术的确是需要有人引领的。

纵使旧人如何说公司的不好,还有不断的员工离去,甚至项目组现在人缺的连我这个新人就被推上出差的前线。但我在这里短暂的几天,就发现了自己曾经想找的那些东西。这里还是挺崇尚技术,崇尚分享。只要有你兴趣,周周都有技术的分享交流邀请等你去接受。这里有你的导师,还里有不段上马的新项目,这里同样有很多你没学到和可以学到的知识。这里有年轻的新人,有新鲜的血液,大都90后啦。这里还可以毛遂自荐。我是新人中的旧人,我没有理由不开始努力一把,做的更多,做的更好。

所以我没想到领导会直接安排我出差的时候,我同样也没想到拒绝。之后也想到过各种困难,想到过各种不易,但想到曾经的自己也独立完成过很多项目。信心也不会少很多了。再加上有现有的程序可供参考,加加减减功能也变得不那么难了,再不会的困难,到网上找找也总是有答案的,或者就变个法子去解决吧。也许等回过头来再看,当初的那些疑虑是多么的微不足道,甚至是可笑的。有些事情就是怕你去做,只要勇敢的走下去,就真能闯出一片天地。

我迫不及待地想去发现另一份美好了。

为了这个改变

五年算一个轮回,我已经跨五年来到了六年的关口。想想生活,想到可能的压力和梦想中的未来,就开始默默地下了决心去做一些改变。但不能否认这个决心下的是有些艰难的。毕竟这里安逸,稳定,一切都能按部就班,如果工作不犯什么大的错误,也许真的能在这里待一辈子,想想也会很害怕。但往往优点里面也透着显著的缺点,工作缺少激情,谈不上创造,晋升和加薪幅度缓慢。也许,我有我性格上的缺陷,我不擅于交际,我甚至怀疑大的领导根本就不认识我。我没有百分百的努力,因为努力可能也带不来回报,这里有很多的人情事故,先后之别。

人生有多少个六年。六年前,我以比原单位高一倍的工资作为外包员工来到了这个单位。我之前的单位薪水太低了。虽说是外包员工,但工作的内容也并不繁重,公司内部的管理系统对我来讲很多也是轻车熟路,只是从Windows程序跳到Web开发一时有些不适应罢了。随着工作的陆续展开,一切都不再那么忙碌,除了偶尔的上线和出差外,闲暇的时间也多。在最初的那段日子,我试着去读去啃一些英文的原版书,去读英语的网页,让自己的专业英语阅读理解水平有了一定的提高。到11年未,我开通了博客,前期翻译了一些英语的文章。这都是那个阶段英文学习的具体措施。

之后在外包的一段稳定时期,领导的抬爱,每年都能给我增加一些工资,也让我对自身所处的环境有些满足。转变也来的很快,14年上半年,随着公司组织架构的调整,我被安排在开发小组,由另一个人当了我的领导。领导的做事风格不一,一来可能领导自身的压力影响到我们,二来也可能是自己未能马上习惯新的领导,那段时间的工作都是相当充实的,做了很多,开发进度很快。后来我们都做完了,才发现并没有完全根据我们的设想的去做,之前全当是投石问路,当然接下来的工作就更加的轻松了些。无非就是小的修修补补。有问题要开发,也要绕到各部分经理,再到开发转测试到发布,一个来回很多时候没有一个月根本无法走完。战线拉长了,事情也同样被稀释了,工作量相应的也减少了。大多问题都是小的改进和小的Bug修改。15年初的时候,我被借调三分之二的时间去另一个项目做开发。几轮的开发平台工具培训下来,都未掌握多少,这只能到后续的项目实际中去学习了。后来到六月份左右,项目的开发才算真正启动,我也开始了我的Java学习之路。其实谈不上Java学习,除了一个Api接口站点用通用的SpringMVC框架外,其余基本都是在Sites平台上做一些jsp页面和Template的修改。外加在平台后台中类似数据建模的概念。我做的工作自己算起来真不算多,但还是有几个算是需要独立去研究的吧。比如:资产的定期同步功能,产品修改后的流程自动发起功能等。对于碰到的新的功能与要求,我总会试着努力去解决的。

忘了说我在14年7月转到了甲方,这当然也是领导的抬爱,只是这次转正加工资的幅度是大大落后于之前的,但想到福利公积金,想到归属与认同感 ,其实还是挺好的,这当中更能体现领导对我的认可吧。从不敢说天不无不散之宴席,生活的压力和自己的未来时不时的再提醒自己是不是落后了,能不能再进步一些。15年的后面几个月我延长了自己的下班时间,就是为了能多一点时间给自己再充充电,为了自己未来的工作讨活多一点点吆喝的本钱。其实生活也并没有想象中的困难,但现实就是相当的残酷,如要改变,自己得先变。于是,我就这样慢慢的准备着。

家是最后最强的堡垒。在很多内心苦闷的时候,总是家人在后面开导我,激励我。虽然有些时候会感受到来自他们的压力,但终归是他们给我勇气和前进的动力。想到他们为家付出的努力与心血,我也应该奋力为他们开创更好的明天。

你的spring是自学的吧?

当我第一次参加java面试的时候,在一堆spring相关问题之后,面试官直接来了一句:你的spring是自学的吧。我没好意思说啥,甚至有些不太好意思,因为我自学的很不好。事实就是我没有很多的spring开发经验。唯一一个用spring的项目,框架也是别人搭好的。地基搭好了,我只是在上面添砖加瓦,所以spring的核心思想,及各种使用的办法都没有清晰明了的概念。又反过来回到面试官的问题,试问谁的spring不是自学的?工作好多年,新技术,新语言也基本上都是自己在学习,要是没有自学,也真不知道自己能不能应付当下的工作,和新的挑战了。

回到spring,这些天总在反复理解spring的概念,什么IOC,什么DI啦。我觉得这要从spring是用来做什么事情的来理解。spring是一个框架,它的代码本身与任何的业务系统没有直接的联系。通常我们的业务系统就不得不定义和声明一些类和接口,代码中完成类与类,对象与对象的关联与操作。代码之间存在类与类,类与接口之间的关系可称之为耦合。以前我们在实现业务代码的时候,各种new操作,set方法等等这些都造成了我们的业务代码不容易修改和重用。系统运行过程中,就往往过多的创建实例,造成资源的浪费,同时也增加了垃圾回收的压力,降低了服务器的真实性能。

而spring就是这样一种轻量级的框架,我们可以将业务系统中定义的各种类的实例化交由spring来管理,这样spring就相当于一个容器,存放各种相互依赖的对象实例。当我们的业务系统代码中需要用到某个对象时,就可以到容器中去查找是否有,如果容器中有就可以直接拿来使用,而不必在使用的时候在业务代码中进行实例化。spring会根据上下文的配置或是成员变量在代码中的注解,将对象进行注入(依赖注入)。通过依赖注入,业务代码中的各类之间降低了代码的耦合。而spring本身不关注业务系统的逻辑,它运用的是IOC和DI思想,并在此思想上构成了这样一个通用的框架。

spring的IOC可认看成是工厂模式的升华,可以把IOC看成一个大工厂,只不过这个大工厂里生成的对象都是XML或者是注解的代码中给出的,然后利用Java的“反射”机制,给合类名生成相应的对象。spring的这种机制,可以很方便的将其它的类引入到我们的业务系统中,在代码中自动注入并使用它的某些方法等。

IOC是一种设计模式,这种新式的模式并没有在GOF中。之前我也没有好好的读过《设计模式》,近日来的阅读,让面象对象的接口设计给我来的各种惊奇。工作中的碰到的不同场景其实都可以往设计模式上去思考一番,是否可以运用这样的方法来改善我们的代码结构,或者是重构等等。过往的开发,我们往往太注重业务实现,而没有在代码的结构,重构和可扩展上面考虑的很详细。自学spring让我在这些方面领会到了很多。

Btw:上速的依赖注入及spring的思想等,是自己翻阅各种资料理解的结果,未必完全正确。而这里说的spring指的是spring的核心框架,没有包括spring的aop,web,mvc框架等。

理解编译时与运行时

在面象对象的开发过程中,经常会用到面象对象的多个特性,比如:继承和多态。继承通俗的讲就是可以用子类去扩展父类的方法和属性,可以直接用父类的引用指向子类的对象。而在运行的过程中,程序会根据引用对象的根本类型判断应该调用的方法,有的可能就是重载子类的方法,这就是多态。那么要如何判定程序的编译正确与否,以及运行时是否正确的执行,这里我们需要理解两个概念,编译时和运行时。

编译时:指的是编译器将你的程序代码编译成机器能识别代码的过程。在这个过程中,编译器会根据各个语言的规范,指出哪些代码会编译出错,无法通过。无法通过编译的代码当然无法执行。看下面这个例子。

class Base{
public void func1(){ System.out.println("B-func1"); }
}

class Sub extends Base {
public void func1() { System.out.println("S-func1"); }
public void func2() { System.out.println("S-func2"); }
}

public class Test{
public static void main(String arg[]){
Base s = new Sub();
s.func2();//编译出错,func2没有在类Base中定义
}
}

如上代码所示,标准行出现了编译错误,func2没有在类Base中定义。s是由Sub类创建,但被基类Base引用所指向,所以s只能调用Base的方法和成员属性。无法调用Sub类的成员方法。这时要调用就要加上强制转换再调用:


((Sub)s).func2();

编译时,不仅会检查各种定义,调用的规范,有的编译器还会对代码进行编译优化,比如:那些不变的静态变量的计算过程及赋值,可能直接就被计算结果所替换。还有一些泛型类或是C#中的语法糖都会编译成原始的代码处理方法等等。

运行时:有些基类的方法在子类实现了继承,而在代码中往往用的是基类的调用。这种情形下,只有在运行的时候根据调用对象的根本类型来判定调用的是基类方法还是重载方法。比如下例代码:


public class Test{
public static void main(String arg[]){
Base s = new Sub();
s.func1();
}
}

s调用了func1()函数。因为Base中定义了func1()成员函数,所以编译通过不会报错,但此时s调用的是Base类中的func1()方法,还是Sub类中的func2方法呢?s本质是Sub类对象,这可以通过s.getClass().getName()方法来得到。Sub类重写了Base类的func1()方法,因此这里在运行时,s会调用其根本类的即Sub类的func1()方法,而不是Base类中的func1()方法。这也是面象对象多态的特性之一。

编译时往往检测的是代码编写是否违反语言规范,而运行时指的是对象的动态执行过程。理解编译时与运行时有助于对我们对继承与多态的理解。

使用Xmind思维导图工具

最早知道这个工具是在公司的ITIL培训上。培训导师在讲课的同时特意引入了这个工具,说得非常简单和方便,一个tab加enter键就是基本完成所有的操作了,一定让我们在课下或是工作中好好的用用。但最重要的不是工具简单,而是这个工具能将你的思维扩大,能够激发你的大脑视野。最直观的是从你原先线性条带的要点,转换成图形,表格,鱼骨,甘特图的样式。让你记忆深刻,同时在观察分析图表的过程中,能找到问题的重要点,划清主次,找到问题的解决办法。

这个工具有免费的,也有收费的。大部分的免费功能还是能满足日常基本的要求,比如思维导图,组织结构图,树状图,鱼骨图等等。在没有使用这个工具之前,在学习或是看书的过程中,我往往都是流水的形式将重要的概念以多文本的方式记录下来,而简单重要的词汇概念在单行的记录中是看不出明确的意义的。而在Xmind思维导图中,一个概念,一个重点词汇在这个图中,它所代表的含义反而得到了鲜活的体现。任何在导图中出现的词语都可能是非常重要的,有明确的含义,都有其上下文关系,好似时空中的一个点,与其它各个点关联在一起,深深嵌入你的脑海,就像一个立体的空间那样令人深刻。一旦你的思维存活在这个立体空间里,便可以游刃有余了。

最早下载使用这个工具是在我的一个旅行计划里面。从旅行计划的时间,地点,人物,交通工具,住宿,景点,用餐等等计划安排上计算了旅行的大概费用。虽然这个计划最终没有实施,但仍让我对这个工具的有了一个直观的认识,并能让自己在分析一件事情上如何考虑的更加全面。第二次用这个工具分析了下一个PHP工程师应该知道的哪些技术,并以此来判断自己应该在哪些方面下工夫学习。这对制定目标与计划有很好的帮助,也为我后来制定2016年度计划提供了参考:如何分门别类,如何分析工作量与可行性。用Xmind制定工作计划的时候,可以加入各种图标,比如完成进度,优先级,表情,月份,可以标识结点间的关联关系,让图表更加的鲜活和有价值。以往在学习看书的时候,往往如之前所述的那样逐行逐句记录本文,或是拷倍作为读书笔记。如今,我在思维导图上以大纲的形式将之记录,将各个要点串边起来,从而书本的纲要都呈现出来。在回顾的时候,只要根据纲要分别各个击破,书本的知识就能全盘掌握了。这种纲要也更易于选择性的学习,将那些熟悉的知识快速略去,再深入那些未完全掌握的知识,从而让学习变得更有效率。

除非你认为你需要更强大的功能,那么收费版本可能更适合你。习惯免费的我一时不会去花这个钱,也许有一天真正需要的时候,我也可能成为一个付费的用户。有的时候,我们很执着的用着自己熟悉的方法去学习,而对他人的建议不管不问。但真的有时候,一个好的工具能让你变得更有效率。只是,能提醒告诉你的人可能很少,而当有人真正告诉你的时候,千万值得去尝试一番,也许他真能给你带来翻天覆地的变化。