The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
For non-source-code files, I have to admit that SP works well -- as long as you switch to "classic sharepoint view" every time you open it (otherwise you have to deal with all the time-consuming and energy-draining recent "improvements").
I wanna be a eunuchs developer! Pass me a bread knife!
SharePoint is most often used for the storing of version-controlled documents, such as Word documents and Excel worksheets. In many environments, email is used for passing documents back and forth between users. The potential for mixing up different versions of the same document is considerable. Also, storing multiple copies of the same document takes up a lot of disk space. Because SharePoint provides a single source for storing, viewing, and updating documents, many of these issues are eliminated.
Yes and No.
GIT works quite well, I do still prefer the older SVN/CVS though, but personal preference and all that jazz, I use it most days and you get used to it.
Sharepoint, meh, marmite, you either love it or hate it, people use it for storage but I believe it was designed originally for document collaboration, I wouldn't go around replacing all of my NAS shares with it but for documents I guess it does what it says on the tin, as for organising I guess that depends how the people running the show are organising the folders, it *can* be made to be more intuitive than not, but you need someone who understands folder structures well enough to do it for you.
Having most things cloud based means you can work from home more efficiently (unless you need access to specialist equipment / hardware), though i'd have no problem working over a VPN to an actual NFS, again, if you have a network department that knows what they are doing. Most i've come across, small or large corps do not, someone's cousins son set it up etc or someone is still trying to figure out where they can plug their 10baseT coax into.
Sharepoint has changed much over the years. We hosted Sharepoint Server back in the 3.0 days or whatever it was (some 10 years ago). It turned out to be a solution to a problem we didn't have. When we tried to use it for collaboration on Word documents, people would check stuff out and not check it back in, put it in the wrong place, etc. We trashed it. A couple of years ago, we shut down the Exchange server and moved to O365. Sharepoint now has solutions we can use, again collaboration on sales quotes and other documents. Also hosts price lists and calendars and other corporate documents. The users files sync to the users computer, similar to One Drive. It does have decent search capabilities.
I think you have to be prepared to do some development to enhance it. I have created some stuff.
Created an Excel Add-in that allows users to use a Template for their quotes and publish to their folder in a Sharepoint quotes library. It syncs to the folder on Sharepoint. Perhaps some this can be better done with content types. All people who handle quotes have a folder and have access to the library (some read only).
Created a console program that downloads any new or changed quotes (including 5 layers of history) to the file server every night.
Created a desktop program that allows searching through the quotes stored on the file server, and creating reports ( ran too slow going up to Sharepoint).
Created a LookOut add-in to allow linking to a quote template from an email contact (still a work in progress).
To me, Sharepoint is somewhat like a database server. After you set your first one up, you realize where you screwed up and are ready to start over. For those of us in the slow group, it seems to be recursive.
I would suggest that you jump in with both feet, create some applications/add-ins and make yourself indispensable.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
The use of GIT caused people to ask 'why!' to which I had to give the lamest answer: 'I'm only obeying orders' GoogleDrive was rejected as not secure enough, OneDrive as too secure and to easy to delete & Dropbox was not as far as I am aware discussed. It's just with 365 Sharepoint is being used to store everything! I did as as 'it might be good if these thing' (images, png's which were derived from some PDF Documentation) 'could be stored in a directory' to which the reply was 'Meh!' using teams has not improved people skills.
I was asked the same sort of question on my last contract - It would have been nice to be able to suggest Sharepoint - but the company wernt anywhere near where they needed to be skills-wise given we were just beginning to get them set up on O365
The top two thoughts I had, and I stipulate this very carefully, 'based on their requirements', were
GIT, with GIT LFS and SparkleShare
Umbraco CMS (or similar)
Since they had a lot of Azure going on, if I could have found a 'file manager' view suitable for management to use, over Azure File Storage, that would also have been a hot contender (I'm sure there are such products around, but being a start up $$ come into play)
Ah welcome to the MS family, with 365, SQL Server, VS, Teams and now sharepoint your organisation is truly part of the clan. Not a bad thing but you are now susceptible to all the different servers that they can foist on you. Once you get past the tipping point (and that was probably 365) there is n going back.
When the sales person says they all integrate and work together laugh in his face.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
It might depend. I'm not a fan of Sharepoint in the least, but I could see where it might be useful for storing documentation. More specifically, general docs like process documentation (here's how we branch & merge), HR docs, etc.
If by 'stuff', you mean 'technical stuff' like source code, then, no, that doesn't seem like a very good solution. Even project docs like requirements and design (to me) need to go in a change control system like jira or whatever.
Look at me, advocating using jira/whatever when (as my current employer already knows), email is a perfectly valid change control system.
Thanks not easy at this time, get some agents phoning me to find out if I have any roles available (?), buy 'Stuff' I meant AVI video files, configuration data, docs & diagrams of how to connect widget A to Widget B with letting the magic smoke loose! The test are being converted by myself and another to JIRA via Zephyr (or whatever!) the Chief is a big 'Jira Ninija' and got upset by people trying to use Jira like a relational Database...
Also late to the party...long-winded too And, good luck on your job search!
TL;DR - The single act of purchasing new tool is not going to solve an organization's problems. One must set up conventions and workflows for the tool to optimize team collaboration for the organization.
I have found in my "travels" that there is a misconception typically at the decision-making-level in organizations, that these types of tools (GIT, SVN, VisualSourceSafe, Sharepoint/Confluence, JIRA, Wikis, and bunches of others) and the features they provide, once purchased, make all your problems go away without any additional work. The flawed assumption is that the tool forces a specific workflow and thus forces team members to use the tool in just one way and by doing so, creates a single organizational structure for the data to be stored, which we all know is not correct - instead of the desired/assumed "file cabinet" for data (project docs, source, etc.), these tools become "junk drawers" (often referred to as the "wild west") where teams don't know what data is where, what is the latest version, identical doc's are stored in different locations/folders causing data coherency issues, nobody knows what is in the master/trunk branch (or tags or any of the other branches) - and it gets worse and worse as time goes by.
The key to team success is, once the tool is purchased, one or a few people build up a moderate level of expertise so they know best how to use the tool then create (and document) a structure (branch definition for source tools, folder structure for doc tools) and workflow that works best for all the organization's requirements, then get buy-in/agreement, and put in the constructs (like varying access rights per group) prior to its use, and police it's use (which can be time-consuming) during its use.
Mind you, for those that do contracting, you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not.
In agreement with others on the post, using a source control tool like git/GitLAB/BitBucket/Subversion for documentation control is not a good idea - Subversion/Confluence tools are more appropriate. I find source control tools deal best with text-based files (like code), but not well with binaries (like MS docs, etc.) wrt version control.
Since I work for a small company, we have shied away from those complete solutions from Atlassian that are costly (JIRA/Confluence/BitBucket). We do use Atlassian JIRA for tasking/bug tracking, cloud-based Sharepoint for documentation, and internal GitLAB for source control. There is some use of Subversion, but find git more intuitive/logical although I have found the git paradigm is confusing when you first get started
I think they were referring to TFS Team Foundation not Teams, Microsoft's source control offering rather than the chat app, built into Visual Studio, the old VB6 used to have one called Source Safe or something like that.