杨长春的个人空间

软件实施012：小白如何走上实施岗

Thu, 18 Nov 2021 15:43:08 +0800

职场如战场，走上职场，要有竞争意识，弱肉强食，你争我夺，要想出人头地，就得建立自己的核心竞争力，找个实施岗位的工作起步很容易，而要有计划地打造自己的核心竞争力就不容易了。

其它行业改行过来的实施

原来是干其他工作的，例如干财务的，干生产计划的，干车间管理的，干建筑的，等等，然后改行做软件实施。

这种路子出来的实施，最大的优势就是精通业务知识。

当你熟练掌握了某个复杂行业的业务知识，然后做这个行业的信息化工作，你在职场上就有了一种不可多得的核心竞争力。

要想走这种路子的话，可以先到某甲方工作，当然，这个甲方的业务必须是那种够复杂的，业务性强的，值得你花三年五载去学习的。学成之后，再转到这种行业相关的信息化实施工作。

不过说实话，对于小白来说，走出校门就这么搞职业规划可不容易，简直不太现实。我所接触的，都是原来干某行业干了一段时间，然后一朝顿悟，或者一失足成千古恨，或者遇到了某种机缘，才改了行做软件实施。

从开发转实施

开始做研发，后来因为种种原因就转到实施岗位了，或者从设计转的，或者从产品经理转的，等等，大概都属于这种类型吧。例如，

嫌研发需要天天呆在公司，实在太沉闷，希望能经常跑客户换换气，于是，换到实施岗位；

或者，到了一定的年龄段，然后就换到实施岗位；

或者，对公司做实施的家伙严重瞧不上，水平太差，对不起自己辛辛苦苦开发的软件，决定自己亲自上阵；

或者，单纯就是发现自己喜欢跟客户打交道，对用软件解决业务问题有强烈兴趣，于是转到实施岗位，等等。

这种路子出来的实施，最大的优势是，精通软件技术。

做实施的重要工作是建立甲方业务跟乙方技术相结合的桥梁，用技术解决甲方的业务问题。因此，要做好这件事，当然需要两边都懂。

精通软件技术，至少已经解决一半的问题了。在帮甲方处理问题的时候，相对于对技术不精通的实施，自然更有优势。

要想走这种路子的话，自然先找个程序员的岗位干干，如果目的确实是为了将来做好实施，就不需要做那种技术要求太精深的研发岗位，尽量做那种技术很杂的岗位。

专攻某些软件产品的实施

有些大型的管理软件产品，例如SAP啥的，非常复杂，要想完全掌握需要付出很大的功夫，有时候，难度简直不下于再读一个文凭。

很多做实施的兄弟就靠熟悉这些软件产品获得了核心竞争力，想想如果需要实施这种复杂的软件产品，你一个完全不懂的人，想去干这事简直是癞蛤蟆想吃天鹅肉啊，这个门槛就是核心竞争力。

要走这种路子，可以先到某些管理软件产品做得不错的公司工作，不管干什么，先学会、学精通。

还是随缘吧

最后想说的是，其实对于大部分没有任何工作经验的小白来说，如果想做软件实施，如果能按照前面介绍的几种方法给自己进行职业规划，固然很好，但也不需要过于纠结，完全可以先找个实施助理之类的工作先干起来再说。

实施是个对工作经验要求很高的岗位，需要大量项目的实践经验才能做好，这些经验只有亲身经历才会拥有。因此，先干起来再说，好实施是项目砸出来的。

软件实施012：小白如何走上实施岗.pptx

软件实施011：售前之如何编写解决方案

Sat, 13 Nov 2021 14:35:25 +0800

解决方案的形式

乙方的售前人员在经过售前调研之后，了解到甲方的一些基本状况，然后就需要编写解决方案了，所谓编写解决方案，就是针对甲方的要求，论述自己将如何满足他。

解决方案根据项目售前工作的需要，一般有两种最典型的方式，一是PPT形式的，一是Word形式的。

PPT嘛，一般用于给甲方做演示，图片多，文字少，讲究视觉冲击力，而主要的内容需要售前人员配合着讲解。

Word嘛，就可以展开描写，可以阐述非常细节性的问题，讲究专业性。

根据不同的场景，售前人员可能需要编写不同形式的解决方案，例如，让甲方领导被吸引产生进一步沟通的兴趣，就需要PPT形式的；让甲方选型人员综合评估，对乙方有个良好的认知，就需要Word形式的。

我们懂你

不管用什么形式，如何才能写好一份售前解决方案呢？

首先，你要在方案中证明，你对甲方是了解的，对甲方的想法是了解的，对甲方的困境是了解的，对甲方的希望是了解的，甚至，对甲方不切实际的痴心妄想也是了解的。总之，我们懂你。

因此，解决方案需要阐述你对甲方的理解，例如，

项目的背景，

项目的起因，

当前面临的管理问题，

甲方希望达到目标，

对软件有什么想法，等等。

如果是一个非常复杂的项目，要把这些问题阐述清楚并不容易，特别是那些行业特殊性很强的，或者规则很复杂的项目，如果你是个纯外行，要完成这个任务简直是“蜀道难，难于上青天”啊。隔行如隔山嘛。

我们可以满足你

为什么要写“我们懂你”，潜台词就是，我既然那么了解你，那么，就容易帮助你们解决问题，毕竟，我们已经知道了症结所在，了解问题是解决问题的基础嘛。因此，接下来，方案中要写的内容就是，我们满足你。

也就是，针对甲方的要求，甲方的问题，阐述你们将如何满足这些要求，如何解决这些问题。既然是个管理软件项目，当然一般会强调如何围绕甲方的业务要求建立信息化管理体系，例如，

怎么设计个可人的系统来；

如何保证系统是个好系统；

系统会提供哪些有用的功能；

系统会解决哪些问题；

如何使用系统处理工作；

未来有哪些使用本系统的主要工作场景；

本系统使用后，如何改进管理方式；

如何将复杂的业务规则信息化，等等。

在实际工作中，千万不要死搬教条啊，需要阐述哪些内容，因人、因项目而已，看你如何取舍了。

我们人很牛

我们既懂甲方，又能满足甲方，是不是就完事了？并没有。

站在甲方的立场上想想这个问题吧，你说你能满足我，我又不能亲自体验，你得证明你能做得到啊，证明你不是个大忽悠啊，不是在百度找了个文档就来耍我们啊。

考虑到这些，乙方就要证明自己能做到、能做好这些事情。

怎么证明呢？

首先，我们有人才。

独行侠的时代一去不复返了，单兵作战能力再强也抵不上好团队。因此，可以先介绍团队的构成，有什么人才，每个人的简介、证书、经验、成就等。

要将事情做好，离不开好团队。要甲方相信你们能把事情做好，做漂亮，就要他们信任你们的能力，要他先信任你们的团队。

如果团队确实人才济济，会大大增强客户的信任感。甚至，如果有一两个特别厉害的领军人物，简直会让甲方一下子刮目相看。

不过呢，说实话，大拿毕竟是稀缺资源，大部分人都是普通人，每个项目都配上绝世高手显然是不现实的。

有些售前人员为了提高甲方对团队的信任感，会把公司最顶级的一两个厉害人才做成资料，在每个解决方案中都贴一贴，其实大家心知肚明，他们是绝对不可能到每一个项目中的。这样，确实可以增加甲方的信任感，但是也带来了风险，万一遇到较真的甲方，签了合同后非要方案中出现的某某某来负责工作，那么麻烦了。

我们技术很牛

有了可以信任的团队就完事了吗？显然还没有。管理软件项目，虽然算不上什么高科技，但也是个专业性非常强的事情，牛人未必有牛技术，未必有跟这个项目相称的牛技术。团队是否拥有相应的技术能力，对项目能否成功有决定性的作用。

因此，需要在方案中介绍团队使用什么技术。例如：

怎么架构系统，

怎么开发服务端程序，

怎么开发网页程序，

怎么开发安卓手机端，

怎么开发苹果手机端，

怎么管理服务器，

怎么管理数据库，

怎么保证质量，

怎么保证系统安全，

怎么保证系统性能；

有什么技术优势，

有什么独创技术，

有什么软著、专利，等等。

大家一定要记住，写文档有一个重要的原则，就是要站在受众的角度写文档，你写文档又不是写日记，读者不是你自己，你要考虑读你这个文档的人，尽量让读者容易理解。但介绍团队技术时是可以适当违背这个原则的，不需要每句话都让读者理解：

一者，隔行如隔山，读者不是内行，要让他们都懂，恐怕要把解决方案写成科普读物了，这个太难了，太难了；

二者，介绍技术的目的，不是让甲方学会技术，而是让他们觉得你们专业、厉害——这个目的才是最重要的，让读者看得云里雾罩，可能真的会认为你们高深莫测呢，写得过于浅显直白，可能反而会认为你们技术不咋滴。

我们管理很牛

有了人才，有了技术，难道就完事了？并没有，还需要优秀的管理。没有好管理，什么人才、技术都是浮云，不可能做好项目。

因此，接下来，要介绍公司是如何管理项目的。

介绍公司跟项目相关的一些管理措施，例如，

项目开发流程，

需求变更处理流程，

新需求处理流程，

客户提交问题后的处理流程，

项目组考核方法，

项目组人员流动的应对措施，

项目知识管理机制，等等。

这些管理措施貌似跟这个项目没有太大的关系，但通过这些介绍，可以让甲方觉得你们公司专业，可靠，安全，不是乌合之众，是正规团队，不是小作坊，从而建立信任感。

当然说实话，解决方案中这么写，未必你们公司就真的是这么管理的，这个我就不能说得太多了，万一给杨老师的甲方知道了就麻烦了。咱们心照不宣吧。

我们实施很牛

管理很到位，下面，就要看具体的项目了，看如何实施这个项目了，没有好的实施，项目怎么能做得好呢，实施不重要，杨老师干嘛要花这么多功夫成年累月地讲呢？闲的蛋疼么？

因此，需要介绍团队将会如何实施这个项目，例如，

按照什么方法论实施，

如何制订项目计划，

实施流程是什么，

每个步骤如何进行，

项目团队成员如何分工，

如何确保项目按期交付，

如何保证实施效果，

如何培训，

如何配合验收，等等。

我们服务很牛

甲方做项目，是需要长期运营的，希望能够持续不断地带来收益。因此，为了让甲方放心跟自己合作，打消后顾之忧，不能不介绍自己在未来会提供什么样的服务，如何服务，例如，

售后服务团队的构成，

服务的内容，

问题处理流程，

客户投诉机制，

客户建议机制，

系统如何升级，等等。

我们公司很牛

最后，还要介绍自己的公司，如公司简介、高管团队、成功案例、资质证书、奖项、辉煌历史、高光时刻等。目的还是增强甲方的信任感，打消后顾之忧。

由于管理软件服务内容的不确定性，甲方可能到签合同时都没有搞明白自己究竟会买个什么东西回来，如果签约的公司是个实力雄厚的大公司，在心理上确实让人更有安全感，这跟我们平时购物喜欢买名牌是一个道理。对于那种大型的、行业性强的项目，如果乙方有类似行业的成功案例，会在甲方的决策天平上，丢下一个异常沉重的胜利砝码。

PPT课件下载：

软件实施011：售前的主要工作（下）.pptx

产品方向应该由产品经理主导，还是研发主导？

Thu, 03 Dec 2020 13:57:58 +0800

作者：杨长春 2020.12.2首发于微信公众号“IT改变管理”

兄弟A，拙著《软件需求分析实战》的读者，今天问了我一个问题：杨老师，你说做产品，确定产品的方向，究竟应该是产品经理主导，还是研发主导？

说实话，刚听到这个问题，心里感觉是有怪怪的，谁会跑过来问这么暴露智商的问题呢？

一个不主导产品方向的产品经理还能叫产品经理么？

作为产品经理，注意力集中在产品市场、客户群、用户群，解决什么问题，抓住用户什么痛点，如何处理事情，如何使用等等。

作为研发，注意力集中在如何实现设计要求，如何架构，如何部署，如何利用资源，如何优化性能，如何提高安全性等等。

简而言之，关于软件产品这点儿事，产品经理的重点是“WHAT”，研发的重点是“HOW”。《人月神话》说得好，他们各有各的学问，都不容易，没有高低贵贱之分。

所谓“术业有专攻”，产品方向本来就是产品经理的研究重点，属于分内之事，怎么能让研发主导呢。

当然，世事无绝对，并不是扔一个“产品经理”的头衔就可以主导产品的。不同的产品经理之间，差了一个珠穆朗玛峰，乔布斯是产品经理，张小龙是产品经理，我们公司刚来的实习生小王，只能帮着画画原型，也叫个产品经理。

作为产品经理，能力不行，威望不能服众，只会逐渐失去话语权，最后只能做个帮研发画原型的助理，别说主导产品方向了，工作还不知道能不能保得住呢。

话说回来，条件反射似的说产品经理主导产品，这只是理论上的，现实中千奇百怪的事情多着呢。

想到以前的一件旧事了。

那一年本人也在某个公司做产品经理，经常做好各种设计后给研发人员开发，结果研发出来的产品跟原来的设计思路差别巨大，跟研发交涉，他们总是有一大堆说起来振振有辞的理由。用户如何使用产品，产品如何解决用户的问题，面向的客户群……这种种问题，他们并不考虑，能抛出来的理由往往是微信怎么怎么弄的，QQ怎么怎么弄的，微博怎么怎么弄的，就是不去想我们做的是管理软件产品，跟这种社交产品的使用场景天差地别。管研发的很倔，说不通，我们就去找老板，老板也说不通他们。无语了。

唉，这样子能搞出什么好产品来呢？

没有人主导的产品团队属于乌合之众，乌合之众活跃气氛可以，开联欢会可以，做产品不行。

看来产品的方向由谁主导并不重要，重要的是，谁能主导个正确的方向。很多小公司，不都是老板在主导产品方向么？腾讯都上市了，马化腾不是还在主导产品方向么？

或许，我们应该从另外一个角度看待“产品经理”这几个字，谁主导产品方向，谁就是产品经理。研发主导，研发负责人就是产品经理；需求主导，需求工程师就是产品经理；项目经理主导，项目经理就是产品经理；老板主导，老板就是产品经理。

不主导产品方向的，不管叫什么头衔，产品经理也好，产品总监也好，都不是产品经理。世尊曰，实非产品经理，是名产品经理。

产品经理，毋宁说是一种岗位，不如说是一种职责。

产品方向由谁主导？当然是产品经理。因为不主导产品方向的就不是产品经理。

循环论证，完美收工。

写作吧，闺女

Tue, 01 Jan 2019 14:04:05 +0800

女儿跑到成都去上大学了，离家一千八百公里，从此由水乡妹子变成了川妹子，所谓天高皇帝远，管不了了。但还是希望她能够在学习、生活中养成勤于思考的习惯，于是给她写了这篇文章——

老爸真的忘了什么时候养成这个习惯的，每天必须写点东西（虽然没有什么文学细胞），不写点东西就觉得空落落的，以前没有电脑、互联网的年代，用日记本写，前前后后写了好几十本，后来也不知道丢到哪里去了，沦落在民间。来到互联网时代，自然就在电脑上敲敲打打了，听着键盘噼噼啪啪，看着自己的思想在屏幕上闪出，有一种说不出的快乐。

写着写着，就觉得写作这件事是每个人都应该尝试的，先吓唬下你：不写作的人生是不完整的人生。

老爸不是麒麟公子，也不奢望大雪天蹲在门口啃几口芹菜就变成曹雪芹，这辈子怕是成不了大文学家了。然而，我这里说的写作并一定是文学创作，这个世界上写作的多了去了，文学创作只占一小部分。写作，不一定非要写出红楼梦、水浒传那种伟大作品，完全可以随性而为，写出自己的所思、所想、所见、所闻，读一本书，写几行读后感，看一部电影，写几行影评，学习有所得，写几行心得，只要让你的笔听从你内心的呼唤，写出来就不是什么难事。

我曾经写过的内容包罗万象，家中的事情，时事评论，读书笔记，教育，工作经验等等，反正有什么想法就写几行，想得多就写篇长文，想得少就写篇短文。当然，自我感觉写得最好的还是工作总结，前前后后写了很多文章分享自己的工作经验，前年还出了本技术书总结自己的心得（《实战需求分析》），这都是因为习惯了写作，才会认真思考自己的工作，才会让这些经验汇成了体系。

一旦成了习惯，不让你写出来你会难受，正如哪一天有人禁止你说话一样——是不是憋得慌？

每个人都不想成为哑巴，因为我们需要通过语言表达自己的想法。然而，想过没有，用文字表达自己的想法是另外一种能力，缺少这种能力是不幸的，这是另外一种残疾——文残。能够用通顺的文字把自己的思想表达出来是一种幸事，正如能用流畅的言语把自己的想法说出来一样。会说话，那叫“口才”，会写文，那叫“文才”。

要通过口舌把你的想法说出来，说得好，需要练习；要把你的想法通过文字写出来，写得好，当然也需要练习。首先要把句子写通顺吧，要把主谓宾搞清楚吧，然后，要去思考如何扣住主题吧，如何设置主线吧，如何过渡吧，等等。当然，说实话，老爸也非专业选手，说不清如何能把文章写好，就知道一点，得练，持久地练，很多事情可以速成，写作不能。

先不管好丑，写起来吧，写着写着自然就来了感觉，写着写着你就会领悟到写作对一个人的巨大影响。子曰，写作促人思考。

举个例子吧。你不是刚学了《管理学》吗，如果你想写一篇文章给人介绍下这门课，你会怎么做？你坐到电脑前面，摸着键盘，盯着屏幕，然后——干什么？对，你会思考！也许你会打开本书目录，然后一边浏览一边琢磨，这门课包括那些内容啊，管理的N大职能啊，M大因素啊，计划、组织、领导、控制啊，泰勒啊，德鲁克啊，等等一系列的事情你都会想一想，对吧？否则你没法子写下去——这就是思考。因为写这篇文章，你必须对这门知识融会贯通，不管你的这篇文章写得如何，哪怕是最垃圾的，但你对这门功课的理解绝对会发生质的飞跃。这就是写作的魅力！

面对每天的工作，有人可能把同样一件事做了几千几万遍，但你要他说出如何才能把这件事做好，他可能一下就语塞了，因为他从来没有思考过，因为他从来没有试着写篇文章总结过，他哪怕只是偶尔在某个夜深人静的夜晚，拿着手机备忘录输入几行字做个小小的总结，他的整个人都会变的，因为思考。

老爸的一位前同事说过一句话，我经常引用：牛人与庸人之间的最大区别就在于会不会总结。是的，总结使人提高，写作促人总结，写出的文章是你思想的载体。

软件设计：原型上的数据

Sat, 07 Jul 2018 13:53:41 +0800

一般来说，在绘制软件原型时，都要在原型上写一些事例数据，如表格中的，label上的。新手很容易犯这种错误：不注意原型数据的展示。例如：

明明某个字段有唯一性控制，在原型上却出现相同的数据（如出现了两个“LK0292”工号，姓名却不同）。

明明某个字段应该是其它字段运算的结果，在原型上却不是这样。

明明某个字段需要排序，但在原型上出现的数据却是杂乱的。

一个叫“张三”的，明明在第一行的职务是“总经理”，到第三行又变成了“操作工”。

……

随随便便敲点字母数字文字，看上去像节省时间，其实未必。

要知道，原型上的数据是用来表达需求的，符合软件逻辑的数据可以把你的设计思想表达得更清楚明了，不符合软件逻辑的数据会把别人引入歧途。

例如，一个表格包括三个字段，单价、数量、金额。你分别敲2、3、6，别人一眼就知道怎么回事了，金额=单价*数量；你要是敲了2、3、6.00，别人一眼就知道金额后面要保留两位小数；如果你敲了2、3、4，恐怕会让看这个原型的人多揉几次眼睛了，因为不放心需要多查几次数据字典。

我们对原型上的数据的基本要求是，同一功能点上各个页面的数据，必须符合软件的逻辑要求，不同功能点的页面就不强求了。

一些常用的PPT图标

Sun, 11 Mar 2018 16:13:03 +0800

由于工作关系，这大半年做了无数个ppt文档，经常为找一些图标头痛。

今天将最近所用过的一些图标整了下。有兴趣的可以下载。

PPT图标.pptx

博主简介

Sat, 03 Feb 2018 13:58:54 +0800

姓名：杨长春

笔名：浦飞云

性别：男

出生年月：1971.11

邮箱：wuxiycc@qq.com

微博：@无锡杨长春

工作单位：无锡智尧信息科技有限公司

职务：监事，项目总监

简历：

大学学的是工业会计专业，毕业后做过几年财务工作，后改行做IT。

在IT行业沉浮十多年了，做过软件行业中的各种岗位，ERP实施，软件开发，需求分析，测试，销售，售前，软件团队管理等。

2009年离职创业，创办南通市飞云软件有限公司，从事中小企业生产型ERP的开发与实施服务，惨淡经营两年后忍痛放弃。

2011年加盟无锡朗奇软件科技有限公司，曾任高级项目经理、企业应用部经理、ICT业务部经理、人力资源部经理、行政总监等职。

2017年与几个朋友合作，再次走上创业之路，创办无锡智尧信息科技有限公司，任公司项目总监，主管项目、产品、售前支持等工作。

主要作品：

《ERP选型九步》——《AMT前沿论丛》

《ERP上线之后》——《信息系统工程》

《ERP试用之一单实施》 ——《电子商务世界》

《ERP成本差异分析》 ——中国管理会计网

《ERP实施两难：换人不换人》——IT168

《纺织企业信息的特点》——《2009中国制造业管理信息化大会论文集》

《中国式企业文化》——获2009畅享网中国式管理征文优秀博文奖

《实战需求分析》——清华大学出版社出版，2016.10面市

《实战需求分析》专属网站上线

Sat, 03 Feb 2018 11:20:57 +0800

《实战需求分析》由清华大学出版社出版，作者杨长春。本书是一本系统讲解软件需求分析及设计的书，面向管理软件，以实战为主。书中包括大量案例以及来自作者工作实践中的经验心得，主要讲述了需求分析的工作步骤、需求分析的工作内容、如何进行需求调研、如何进行系统规划、如何设计软件、如何设计出好软件、快速原型开发模型、需求文档的撰写、如何应对需求变更、如何成为需求分析高手。

适合从事需求分析工作的专业人士、希望从事需求分析工作的IT人、希望了解需求分析工作的IT人、计算机相关专业的大学生、管理相关专业的大学生、企事业单位从事管理工作的各级管理者，以及企业信息化管理体系中的关键用户等。

本书专属网站正式上线，链接：http://ra.yangcc.net 欢迎访问。

软件设计：表达组织中的上下级关系

Wed, 08 Mar 2017 14:10:07 +0800

正在策划一个产品，其中要用到企业中人员的上下级关系。

上下级关系，直觉上只是个简单的树状结构，如果不深入思考，容易将之简单化，其实，这里面还是有很多麻烦事的。例如，有些企业，某些人的上级不止一个，属于多领导，虽然有些口头上的分工，但分工并没有非常明确，还有的时候，一个人可能会有兼职，如某车间主任兼职工会主席，他就属于两个不同的管理条线下，还有些企业，对排名，特别是领导的排名很重视，可在兼职的情况下，在不同的岗位下，排名是不一样的，等等。

怎么表达企业里面员工上下级的关系，兄弟们主要分成了两大阵营，相互之间都说得有道理。

方案A：就直接用人表达上下级关系，至于这个人的岗位是什么，只当成一个不重要的辅助信息。这样做的优点，一，可以清楚地表达出谁是谁的领导，谁领导谁，一目了然；二，符合我们在工作中的认知，我知道我的领导是谁，至于他的岗位是什么，我并不太关心；三，如果用岗位表达上下级，对于那种事业部的组织架构，可能几乎需要对每个员工设置一个岗位。

方案B：用岗位来表达上下级的关系，岗位A的上级是B岗位，如果某个员工属于A岗位，那么他的上级就是B岗位的员工，谁在B岗位，谁就是他的领导，如果B岗位有多人，意味着，他的上级有多个。这样做的优点，一，如果有多个员工属于同一岗位，在实施的时候就不需要为每个人都设置他的上级；二，如果某员工离职（特别是管理者），对组织架构没有任何影响，只要将个别员工设成这个岗位就行了。

争论了很久，最后方案B获胜，产品经理决定采用。因为方案B方又抛出了两项优势，一，用岗位表示上下级更符合HR的思维，在实施项目的时候，跟HR讨论更容易，也就更顺畅；二，透过现象看本质，现在社会并不是养家臣的年代，人跟人之间的上下级关系，并不是人的关系，而是岗位的关系，你是我的领导，因为你在这个岗位，软件要表达现实业务才能提高灵活性。

最后，做个总结吧。为了让软件具有更好的可扩展行、可维护性、灵活性，要尽量表达出业务的本质，因为业务的本质变化的概率小，而表象变化的可能性大，也更可能遭遇难以处理的异常情况。

上例中，岗位的上下级关系是本质，人跟人的上下级关系其实是表象。

企业中上下级的岗位关系是相对固定的，只要没有组织架构的变更，一般不会变化，可人跟人的上下级关系变化的可能性大得多（如离职、升职、调动等）。

如果软件表达的不是业务的本质，而是表象，那么很有可能在使用中会遇到某些你现在无法预见的、无法表达的特殊情况。例如，假设某人兼职两个领导岗位，车间主任（上级是制造总监）与工会主席（上级是行政总监），车间组长的上级是车间主任，所属高管是制造总监，而工会会计的上级是工会主席，所属高管是行政总监，这时候，方案A是无法表达这种关系的。方案B很容易表达出这种关系：

如果采用方案A，如图，李会计与钱总，孙组长与赵总的关系无法表达出来。

认识售前工作的重要性

Sun, 09 Oct 2016 11:10:50 +0800

一个兄弟，以前做研发，最近刚做项目经理。根据要求，公司的项目经理经常要做些售前支持工作。可是他做售前工作总是马马虎虎，没有大错却经常有不少瑕疵，文案的字体不对了，格式不对了，标题不对了，等等，让人一看就显得非常不专业。

找他好好聊了一下售前工作——

对于一个售前支持人员来说，一定要尽量避免犯低级错误。程序员开发软件，出了bug有测试人员找出来修改，即使测试人员找不出来，给客户发现了，一般只要服务可以客户也不会过于计较。可售前工作完全不一样，你需要避免任何错误。因为一旦出了差错，会让客户对你立即失去信任，要让客户失去信任，在售后可能需要一百个错误，但在售前阶段，一个就足够了。

在售前阶段，客户对我们的了解很少，特别是那种全新的客户，对我们公司形成的印象很淡薄，你需要通过各种方式增加客户对我们的好评，不断给公司加分，但这种印象是非常脆弱的，一个低级错误很可能会让你前功尽弃，你很可能没有任何机会弥补你的错误。客户看了你的方案，你的文档，你的演示，你的报价等，只要稍有不满意，你就失去了再次跟他沟通的机会，因为你已经在一次竞争中被淘汰出局了——你再也见不到他了，怎么弥补曾经的错误呢？

所以，请仔细再仔细，售前工作容不得半点差错。销售打单不容易，约一次客户也不容易，因为你的一次不该犯的错误丢失了一个不容易有商机，不觉得可惜吗？