问题
UPDATE An interesting time to revisit this question. Is perception still the same now that SharePoint 2010 is beginning to take hold? Certainly implementing 2010 is not without its own challenges, but is business perception one of them?
UPDATE: Our implementation is now kicking into high gear with some high profile projets going live in the coming weeks, so I am quite interested to see if the environment has changed out there.
Original Question
We have an issue within our working environment where the perception of SharePoint is either:
a) The golden bullet, the answer to all our problems.
b) An application which either does or does not solve a specific problem.
c) A frustrating tool which does not deliver their exacting requirements.
Now in my opinion SharePoint (or more specifically in our case Microsoft Office SharePoint Server 2007) is a framework on top of various lower level Microsoft technologies (IIS, ASP.Net, WSS 3.0, .Net Framework, Windows Workflow Foundation amongst others) and as such can be developed to do most anything (given time and resources).
The attitudes that have been formed in my organisation (and others I'm sure) is a combination of the Microsoft Marketing Machine and an organisaton's desire to get the 'golden bullet' in front of as many people as possible wihtout saying 'What for?' or 'Why?' or in some cases even 'How?'
Is this an attitude and perception shared by other SharePoint devs?
回答1:
In the organization that I work for, it completely depends on the level of technical understanding that a person has. The business staff look at it as an opportunity to take a pre-built platform and slap on some minor changes with relative ease. The reality of it, however, is that for the technical staff, it's a nightmare to work with. The trade offs are often from one extreme to another, meaning that if we do something using the built in functionality, it's relatively easy, but the end user experience is far from satisfying. On the other end of the spectrum, we can usually come up with a better user experience, but at the cost of an extreme amount of intensive labor.
Personally, as an individual on the technical side, I wouldn't recommend SharePoint for any environment because when you factor in the cost of licensing, in addition to the development time to make anything worthwhile (which, in my experience, always takes more time than a custom ASP.NET application) you end up with a ridiculous net loss. Most intranet sites are able to get by with the free version (WSS) with relative ease; however, they typically aren't doing a lot of customization and just use it as a document repository.
For whatever reason, the business staff have a completely warped opinion of the product. They believe that SharePoint ultimately saves them money. I say that this is a warped opinion because every single project that I have ever seen that used SharePoint has far exceeded my estimates for a custom ASP.NET application (both long and short term). In one particular case, I have been involved with a project that would have literally taken one month at the very most (including development time, QA, etc.) in a custom ASP.NET application. The same application in SharePoint, however, has been under development for almost a year. The bottom line is that the project simply did not belong in SharePoint, yet the business staff refused to accept this until they had no choice to.
If you are considering SharePoint for your organization, I would strongly advise you to do your homework, first. Expect a very large learning curve and a lot of frustration. Most of your technical staff will immediately recognize the flaws of the product and point them out with extreme frustration. This is normal in a SharePoint development environment. If, in the end, you're willing to make these sacrifices with little or nothing to gain, SharePoint is the right solution for you.
回答2:
My current company is of the opinion we should empower the intranet user by giving them SharePoint.. this way, they can manage/add/remove users, sites, pages at will. And IT can use its time more productively like Googling for lol cats.
We do use SharePoint well and extensively..plenty of SharePoint lists all over the place..
What doesn't happen is that self service idea that actually sells the product internally..and 99% of the departments that should be "doing it themselves .. or simply just use it.." have never even touched it!!
-- The only Software most people here know about is Excel
People here send screenshots images for troubleshooting and make manuals with just pasted images inside Excel files!
(I used to work with an old Solaris machine, without Open Office, so even though I use XP now.. it still hurts to see this happen)
The internet to them is Yahoo homepage and email.
They (the evils) want these people to solve their business needs via SharePoint use.
Reality check: Self service or not, that just doesn't happen..they don't use SharePoint to solve any problems by themselves, but noone notices anyway...
..well thats a lie, people notice it but mentioning the disparity between how management thinks SharePoint is used and the reality, is a sure way of becoming the redheaded step child in the company.
This empowering of the "normal user" is a ghost feature, we in IT always end up doing the work..any work..that should have been solved by having the super tool SharePoint.. we end up creating the sites, the lists, the workflows, and usually we are the only ones who use them.
None of this is meant to be humorous..
(the only workflow used outside the IT Department with SharePoint is the monthly company lunch announcement, which comes from GA or HR on an automatic email after they add a new list item to a sharepoint list made by IT)
SharePoint is seen as this golden bullet to make IT more productive by releasing IT from the said smaller tasks but those smaller tasks remain PLUS we have the added cost of trying to make the other departments do it themselves
I think that after years of internally hammering the product down people's throats, there is now some minimal understanding of what SharePoint is, and its used quite a bit.. Problem being that the way people use it is as promised by Microsoft, but not upper management:
SharePoint List based document storage and Workflows --Great!
But the powers that be should understand that this will never be something with its own legs which can be free from IT nursing and nurturing.
It brings up a point I hate about the whole "let them do it themselves thought process", let non IT users develop stuff themselves is counter productive at all points
(Enter InfoPath forms....)
We in IT spend our lives learning how to make software and how to maintain it (and still do it wrong), and now have someone who just wants to do Marketing [or whatever] manage their own data and internal work process UI+logic!!
It is an unnecessary learning curve (for everyone) that will drive us all to go look for work elsewhere and leave IT with the impossible task of debugging insane unmanageable half cooked business objects.
Enter buzzword galore: MOSS does CMS...
Result: We are now moving from Interwoven as a CMS (was being used as a glorified automated FTP client server tool) to MOSS.
I have over a year of experience on SharePoint and now MOSS, but the whole idea again from upper management, is:
"have the marketing department do it themselves, because MOSS is SharePoint++.. self manageable"
I think MOSS is a really cool tool, but here is my comment in a recent meeting:
"Well, I think Marketing should have a quick look at SharePoint Designer so they know whats coming to them"
answer received: "That's too technical.." <<<< They are really expecting to perform full branding by using the out of the box functionaliy of click click on the sites' options..
They are planning to outsource development of branding initially and wing it from then on..and there is absolutely no point in trying to explain to them otherwise..
Me?.. I think of job search whenever we have a meeting on this project and thank the gods I'm not the project manager on this one.
Bottom line: I do not blame the tool SharePoint, but I can see how people are probably using it with the wrong frame of mind in offices everywhere..its hugely misused and misunderstood in my company at least, and will remain championed for the wrong reasons by the powers that be for years to come.
回答3:
Never figured out what to do with it. Just left us dazed and confused and we ended up moving on to other things.
回答4:
Our experience of SharePoint at my previous company, an FMCG group in South Africa, was positive in many ways (mainly WSS, though we did also implement MOSS).
We held back on customising too much and determined to use as much of the boxed functionality as possible, customising only when really needed.
Several groups of business users adopted it quite well for collaboration and knowledge management purposes around projects or departmental issues, and in some cases extranet sites dedicated to particular customer partnerships. By far the most effective sites were those where the CIOs of the various business units were directly involved - they seem to be positioned well to both understand the tech and help the business folk see the light. I think an important factor was also the fact that one of the CIO's had been pushing the general vision of an all-encompassing perspective-based portal as part of the information strategy for years before we actually had any product in place. I believe strongly in spreading SharePoint organically from a few points of high value rather than a heavy top down drive. But as SharePoint was implemented, the spread was well supported by our change management function which was housed in I.T. but well entrenched around the business.
For one of the businesses, we set up a general extranet collaboration site and trained up a person in SharePoint. It was a big win for a business user to be able to create, in minutes, subsites for collaboration with any business partner of theirs (apart from the account creation, which I.T. still did). These types of need were previously laboured over by website design folk and developers for months.
For my team (the dev team), we used WSS extensively for collaboration, KM, etc. but it also impacted our solution delivery meaningfully. For one thing, we'd been tied up many times in developing small niche apps which departments desparately wanted but which, quite frankly, cost way more than they should and took too long. By being very familiar with the WSS offerings, we increasingly found we could help them set up an adequate solution, using just WSS, in a fraction of the time. While some were simple enough for them to then run with themsleves (some progressive secretary types are adopting SharePoint sites like they once adopted Outlook) others required our ongoing assistance - but the maintainability was vastly more lightweight than that of a custom-written C#/ASP.NET app. Bottom line - we could deliver value faster and use code only where it really made a difference, lowering TCO.
I think SharePoint is helping us into a class of solutions where we compose rather than code everthing. In one case, for example, a company wanted to place orders by having humans send them in an Excel spreadsheet. The purist in us resists and wants to go for something more watertight - but we were not in a position to dictate and needed to deliver within those constraints and with agility. So we created a WSS site (by simply creating a subsite off the root extranet collab site we'd previously set up) and had the folk attach their spreadsheets into a list. We set up BizTalk to pick those up, extract the data, push orders to the ERP system and come back and flag the WSS list items with a status. So we still wrote code, but used WSS out-the-box functionality for the whole user-end experience.
I still have high hopes for SharePoint as a general web application development platform too (ie. here's a whole lot of plumbing, now leverage and extend as you need). We haven't gone deep there yet as there's a learning barrier and also the slippery slope of a whole lot of code in a place that might be difficult/messy to maintain. I do plan to keep exploring whether that's true, but in the meantime I reckon there's tons of value to exploit out of the box in a solution composition mindset.
回答5:
I meet a lot of people and Organisations where there has been some "silver/gold/magic bullet" sales going on.
I see people wanting to unify the information stored in thier business, usually with large shared drives and documents scattered everywhere, disparate applications some web based.
The organisations want everything to be available to their employees easily (findability) and they want it to appear as if it is all part of one huge application so users across the organisation have a consistent place they can go for everything they need to do.
The confusion that sets in is that people think that it has to be done "in" SharePoint, instead of using SharePoint to pull all the bits together and give it context within the orgnisation (e.g. the large "find a flower" application sits in the gardening section section of the site).
The problem is that a good Information Architecture requires a hell of a lot of work and planning on where stuff has to go. Too often, SharePoint is used like a new shared drive and stuff is just dumped wherever.
For developers, this just is not important for their day to day job, but it is important for the pm or the manager. Developement can spawn a lot of documents and a well created development site can make it easy to find that "design doc for that project we never got around to doing, but we need yesterday".
SharePoint is not really for developers core work (i.e. it is not the developement environment or the source control).
回答6:
We have SP here (non-MOSS just vanilla).
Most people are not sure what to do with it. It's not used to its potential but nobody (including myself) want to invest that kind of time.
The way its used here could easily be replaced with a remote share and a predefined folder/directory structure.
回答7:
As long as you or someone in the company is tech savvy your company will benefit from the free version of Sharepoint. Ensure you purchase Sharepoint Designer 2007.
My company isn't really aware of what sharepoint is and does. It is actually the "backend" to our simple production scheduling and part tracking system. The users see basic aspx pages created in sharepoint designer.
Sharepoint allows me to quickly create Lists for managing information. I see sharepoint as an extension of Excel to a web environment. Most people use Excel to create lists of information. Sharepoint enables web functionality to that list information.
I use the free version of Sharepoint and have customized it extensively using Sharepoint Designer. I am an engineer with some programming skills. I know enough that I have been able to create simple but useful data collection web pages.
I first used WSS 2.0 to create a software bug tracker. At the time(2003) I just discovered Fogbugz and we actually used the trial version of Fogbugz. Everyone loved Fogbugz mainly because you could assign issues and emails were automatically sent. A standard Sharepoint issue tracking list achieves this as well. Fogbugz clearly had lots more features but management decided that we would use sharepoint.....
In the end sharepoint was used extensively to manage project information and communicate with customers. This was done with little customization. Just created some site templates and every time a new project was created a new site was created with appropriate document libraries, issue tracking lists, calendars,etc.
I am a sharepoint FAN!!! Oh and yes it has many limitations and its top level items violate Database best practices but Sharepoint WORKS!
回答8:
From what I’ve observed across a range of organisations and third party commentary it comes down to one word: Expectation. There are those that have the expectation that SharePoint is the panacea to all problems. This school of thought is that it’s the best of all worlds; a rich, out of the box product offering a broad set of collaboration tools which you can also code against to extend aforementioned features. And because SharePoint is a .NET product you can grab your average Microsoft developer and start getting all that RAD goodness immediately.
Starting out with this expectation is setting the bar at a level which a) Microsoft never really intended and b) is very unlikely to be achieved without knowledgeable SharePoint developers and a suitable environment. It doesn’t take too long to realise that it’s a little more complex than that. Yes, you can code against SharePoint but you can’t jump in expecting it be analogous to building a .NET app. Everything from the development environment requirements to the release process to the ongoing maintenance is more complex than simply building an ASP.NET app. This also needs to be contextualised with the fact that in many organisations SharePoint is a centralised, shared environment which often brings with it a level of governance which isn’t going to allow you to simply deploy solutions at will.
Back to expectation; when you proceed with the assumption that this is a great tool for collaboration activities, portals or document management it’s a fantastic product. Even proceed with developing on the platform with the expectation that it will require some specialised skills and the deployment and management process will differ to the traditional .NET stack but do so with eyes wide open as to the implications.
So in summary, it’s a great product and can be perceived very positively within an organisation so long as the expectations are set appropriately. However, if you get caught up in the hype without fully understanding the implications there’s a good chance you may be setting an expectation you will not be able to deliver on.
回答9:
tl;dr: Sharepoint doesn't give the impression of being focused on helping me get my job done.
Not very well.
In our work, we find that Fogbugz provides the capability that we really want (and do) use in a fashion that is distinctly more intuitive, quicker and, therefore, more useful. Sure, you can create a Sharepoint workflow for many of these things but why would we? We get sensible workflow and features directly from a system that seems to be much more focused on helping us do our work.
- Development workflow: we really like the case-focused structure.
- Informal discussions: the Fogbugz discussions parallel the old time Usenet groups and are great for talking through an issue before we turn it into a case that needs to be worked on.
- Persistent discussions / documents: the wikis are a great place for us to build material that we need, particularly documentation.
- SVN integration: this is becoming more important for us.
- Project reporting / evidence-based scheduling: this is rapidly becoming critical to our planning and reporting process.
The final damning fact: we have had Sharepoint here for quite a long time with no real interest from the developers. We introduced Fogbugz and nearly immediately the development team embraced it and made it a part of their everyday routine.
NOTE: this reads like a Fogbugz ad but there are other tools that seem to want to help much more the Sharepoint.
回答10:
I would say sharepoint is not bad! The way it manages information is awesome! However,one thing that bother me is it is a little bit too complicated to end-users, our organization spent two months educating them but the result is far behind our expectation. Sometimes it looks like we got a supersonic plane in 50s last century----we can not put it in full use!
回答11:
Regarding your update of "if the environment has changed out there"... In my experience things have got a little worse. This is mainly because of the user interface.
As a dev, I often hear the "it looks like SharePoint" comment showing that the product is increasingly looking dated. (I've been disappointed with the look since release.) This means a lot of CSS and graphics work which is painful since there's so many tables in use and flat-out crap HTML.
Aside from the look, a lot of people find the interface unintuitive and frustrating. Particularly for less knowledgeable users just uploading a document is many clicks and different pages.
Also because of the deficient UI, I'm getting asked to do a lot of Web-2.0/AJAX/jQuery stuff to spruce up the interface and give better feedback to users. The product wasn't designed for this. It's time consuming when jQuery needs web services which are very disappointing in the 2007 release. (Fortunately someone has finally started a jQuery Library for SharePoint Web Services.)
As often happens when the next version of a product is close on the horizon, I'm desparately hoping SharePoint 2010 is rock-solid so there is little reason to start new projects on the 2007 platform when we reach RTM for 2010.
回答12:
So I notice that nobody has really had a truly positive experience of SharePoint to date, and yet everyone is buying it. It confuses me how MS have managed this?
There are many simple projects that we have in the pipelines that will greatly benefit from an injection of SP. But I imagine that in most cases we will be looking to 'blend' SharePoint into our mix of products and technologies. What it does well it does really well, but for specific scenarios it is almost always going to need some elements of customisation (be that CSS, JScript, or server side code), and it might not always be the appopriate solution.
I recently heard a MS analyst refer to SharePoint as modelling clay and that summed it up for me!
回答13:
I know this question was for devs (and a bit old) but I'd like to share an opinion from the perspective of a business user. Our company (75,000+ employees world wide) deployed the "Team Site" template of MOSS 2007, retired our existing documentum e-Rooms and set us loose with ZERO training, ZERO information.
Users across the company use their team sites as document repositories, period. There are a few pockets of users that have a bit more understanding and have begun setting up and using the collaboration functionality of MOSS 2007.
I should also mention - that our company is still using IE6 and MS office 2003. (Pity all the things we can't do with SharePoint on that fact alone.)
Our company doesn't reward the end user who finds ways to take the tools provided to create better collaboration and our IS/IT departments refuse to assist in providing learning materials, opportunities or assisting end users in any way. In the current dog eat dog mentality -- lay-off after lay-off with 1 person now doing the work of what 5 or more did in the past, people just don't have time, if it's not a part of the core focus of their job.
It scares the hell out of me that I've learned and implemented for several groups some colaborative functionality -- even though I learned it on my own time -- does that mean I'll be perceived as not having enough work to keep me busy and therefore - expendable?
As far as how I feel about SharePoint: I love sharepoint. It does put quite a bit of capability at an end users hand... it may take me a bit for the ah-ha moment, but eventually, I get it. Sometimes I get a bit frustrated in building pages -- I wish it was CSS and HMTL -- but, of course, we are locked out the use of sharepoint designer.
It would have been a better deployment if 1. Training was included in the roll out. 2. Solid change management was implemented during the roll out.
来源：https://stackoverflow.com/questions/493312/how-is-sharepoint-perceived-in-your-company