昨天和一个朋友聊天，说到SharePoint的事情。
朋友是一家中型软件公司的项目总监，技术基础很好（Java、.NET都会）又有一定的商务能力。但是，他很“讨厌”SharePoint，理由是：
- SharePoint 功能有限。相比自己开发来说，SharePoint很多功能都实现不了，尤其是客户比较个性化的需求。
- SharePoint 开发困难。要基于SharePoint开发个性化的解决方案，需要先了解SharePoint的架构和接口，学习难度大，开发和调试都难。
- SharePoint 人才难以留住。会SharePoint的技术人才，跳槽比例太高，外面诱惑大，留不住。
- 基于SharePoint 的应用，被微软捆绑住了，软件公司自己的市场受压榨，不如开发自己的应用框架更好把握。
各人所在的位置不同，看到的问题也不一样。
如果是站在技术人员的角度看问题，那么朋友所说的第3点根本就不是问题，相反，是个机会：） 如果做SharePoint的薪资更高，那么学习SharePoint不就对了吗，哈哈！
我不想反驳他的看法，因为站在他的位置这么想，是有道理的。不过，我也抛出我的观点，供他和其他人参考，这样可以增进对事物的了解。
- SharePoint 功能有限。我同意，的确如此。仅仅一个用户访问授权就搞得那么复杂而且还不完善。
所以，我们得让SharePoint做它能做的事情。销售人员可能会夸大SharePoint的效果，但我们不能去帮他们圆谎，而应该提出我们的更接近事实的看法。 - SharePoint 开发困难。这个要看你怎么个开发方法了。
你如果一个 6G 以下内存的电脑，要开发SharePoint，那真是困难！
如果你不去利用SharePoint自己的对象模型和存储机制，用Application Page另写一套，那真是困难！
如果你不利用事件、Feature等功能来帮助你实现自动部署和事件处理，那真是困难！
最重要的，你被销售忽悠，认为SharePoint是万能的，然后去开发它根本就没有的功能，那。。。 等着没日没夜的加班吧！ - SharePoint 人才难以留住。
刚才说了，这对SharePoint人才其实是个好事。
对软件公司呢？
可否这么去想：为什么SharePoint的人才薪资较高？我的看法是从供求来考虑：SharePoint项目的利润高、人才少。用SharePoint的，都是规模较大的客户，项目金额肯定不会低，而SharePoint是一个产品，很多开箱即用的功能降低了项目实施成本，所以利润一般较高；另一方面则是人才较少，因为要搞清楚SharePoint需要知道的东西太多，什么AD域、DNS、SSO、IIS、SQL Server、.NET、HTML、CSS、Web Service，而且，它需要你跳出程序员的视角，从IT架构、运维和业务人员的角度去想问题（比如，Application、Site Collection、Web Site、Managed Path、Authentication 如何规划等等）。
既然如此，软件公司是否可以考虑，转身投入SharePoint的市场，而不是去抵制它？ 这个当然不容易，但是，是一个思路，可供参考。想想，如果部署和配置SharePoint就能赚钱，何必一定要去自己开发呢？ - 开发自己的应用框架，当然好，技术框架是软件公司的吃饭家伙，能自己把控当然放心啦。
可是，框架之间是有竞争的。在SharePoint技术人员薪资较高的情况下，如何留住人才守在自己的框架上面，是个值得考虑的问题。
而且，SharePoint不仅仅是个框架，它是能直接用的。这和 Spring、Ruby On Rails、Django、ASP.NET MVC 是不一样的，公司自己要把框架做到SharePoint这个水平且保证其安全与稳定性，挺不容易。
而且，把核心框架研发技术人员留住的难度，不比把SharePoint技术人员留住的难度低。 - 替客户想想。
假设你去买车，有2个厂商向你推荐他们的车。其中一个仓库里全是零件，然后拿着几张设计图向你推销，并保证说一旦你选择他们，他们可以很快的用这些零件给你组装好一辆车；另一个厂商，给你看的则是他们已经完成的几款车型，你甚至可以试驾一下，只不过，内饰和音响等没有、座椅高度也不合适，不过，他们保证你可以稍后再加装进去，但整车改动的余地就不大了。你会如何选择呢？可能不同的人在不同的阶段，会有不同的选择。但我认为，后者是趋势。
前一个就是搞自己的技术组件的软件公司，后一个就是基于已有产品平台（比如SharePoint）的软件公司。
我可不是在这里做SharePoint的广告喔！我的意思是，软件行业发展到现在，如果你没有几个拿得出手的平台，全部自己CRUD的搞开发，恐怕是再很难混下去的了。不管这个平台是SharePoint也好或者是别的什么也好，你真的得有一个才行。这才是我的本意。而SharePoint的出现，给我们提供了研究学习的机会，对吧？ 要拒绝可以，但是，先研究一下吧：）
看到大家的评论，我再补充几点内容：
2、先对业务进行分析。客户说什么就做什么，无论你用什么技术都是“死路一条”。 虽然我也不一定能够做到，但是，尽量争取吧。
3、好像外企对SharePoint接受程度更高，你让他们自己手动的管理用户组、配置简单的审批流程，他们都能接受。 国内项目么，呵呵~
看到评论，再补充：
1、这个是我认为的“终极”学习资料，用SharePoint，如果能搞透这几张图，就差不多了：
让做应用开发的同时也做应用咨询，是我看到的很多软件公司的做法，这有点儿难为搞开发的人了；以SharePoint（或者SAP、自行研发的平台等）就相当于做应用咨询这个环节，离用户更近，附加值更高。
继续补充：
IT项目其实对组织架构和管理职能是否到位是有要求的。如同飞机一样，航空公司不是把飞机从制造商那里买回来就可以了，还要配备机组人员、安排航班计划、准备维修人员和零部件等等的。不能让制造飞机的个人来帮你做维修吧？
这方面，BizTalk的文档给我很大启发，它开篇就告诉你：要玩BizTalk，先得有哪些角色到位。参考：
