Every techie knows Google Groups (formerly DejaNews, and in paleolithic times - Usenet) is the magic beans of software development, by itself it's justification for getting Internet access for developers. It is the best, largest repository of esoteric information on the net.
You may have noticed that a couple weeks ago a new version of Groups came out of Beta. When Groups-Beta was released I pretty much ignored it; It was always the content that was important - the group was just a category inherited from Group's origins with and dependence on Usenet. So other than looking more '2.0' what could Groups-Beta offer?
Google Groups is actually useful for business
Well, it's a substantive improvement in terms of functionality, Groups now features full read/write access controls; file, document, and web hosting; as well as the revamped discussion groups. Now you can create private knowledge bases full of development resources and use Google's technology and servers to host and search it.
Groups is not your Grand-Daddy's Usenet. Use it to:
- Host private knowledge bases for you and your company, with resources for development technologies.
- Host a client facing homepage for products, where users/customers are encouraged to participate in the support forums and where product downloads and documentation are readily available.
- Create a resource site for your team's development projects, where team members discuss bugs & features and store project resources, QA builds, project plans, and documentation.
Knowledge workers need fast access to information
We sure as hell don't have email and 6Mb broadband to keep in touch with clients. We have tech forums and programming meetings to share development tips - it's what code reviews and pair programming is all about, your manager called it knowledge sharing. Most IT knowledge workers already use groups to search for information, so they're not learning any new behaviours
When we are keeping in touch with clients it's convenient (for you and them) to have a single point of contact rather than relying on interfaces with individual developers. Use groups to host your product downloads, support forums, and documentation.
Earlier I mentioned three things to store in a knowledge base:
- Company specific (personal) knowledge about a particular technology
- Development knowledge about a particular product
- Customer facing (and customer contributed) knowledge for a particular product
Let's look at each more closely.
Create your own private (or company-wide) knowledge base
Access controls let you create a knowledge base with access limited to yourself or your company. I've created a private Group for each technology I use (currently one for Google code and one for C# development). I've invited each of my staff to become part of the group and encourage them to post clever resources like code-snippets, and to ask (and answer) tech questions within the forums. I also make sure everyone forwards email chains with problems / solutions into the discussion forum.
Because access is limited to the people you invite, you can post sensitive company questions / answers / code snippets / binaries without fear of public disclosure. The centralised archive means all the members have access to the same information as soon as they've been given access -- no more archives and forwarding mailing list emails to new staff. And the information is available on any Internet connected computer.
File hosting gives you somewhere to store cool icons, useful toolkits or 3rd party resources. The 'Pages' (or 'wiki' or 'documentation') section gives you somewhere to put company doco, like coding guidelines, naming conventions, FAQs, etc. The documents are collaborative and revision controlled (think Wiki) so staff can update them as required and everyone can see what's changed and when.
You also get the Groups' discussion forums, with all the usual goodness like staring, sticky posts, closed discussions, ratings, and threading. Staff can choose how they read and contribute to the group using email, digests, RSS feeds, browsing, or searching.
If you're feeling adventurous, check this out. I've also created a secret private 'me access only' group, but rather than posting snippets, I post full source code. All my source code. A full text, universally accessible, fully searchable copy of my code base. I know some of you just threw up a little in your mouths, and yes, it has risks. You can minimise them by obfuscating the code a little (remember it's not a source backup, it's a knowledge backup), remove all the headers at the top of each source file and kill all project / solution / package references -- anything that gives the files structure.If I release a product I need to host it somewhere
At a minimum that site needs a descriptive homepage, support / discussion forums, access to the most recent downloads, and all the release notes, FAQs, and documentation.
Now I could build this myself, and it would be someone's job to update the info, monitor the server, and deal with the support emails. But me and my small staff don't have the skills or the inclination to do it properly, plus I'd rather the whole team participate in support to get a feel for what the users are saying. So rather than building from scratch I suggest creating a new Google group like this one for my Google Office Tools.
Write a 'welcome message' (effectively a homepage) with a description of your product with screenshots & PR material. You've got 100mb of file storage to host your downloads, and a built in support / feedback forum. Use the documentation tab to provide release notes, FAQs, how-to guides, etc.Customise the look and feel by changing the colour scheme and fonts to bring the site in line with your product or your other websites. Using the 'navigation' tab in the settings, hide the 'members' tab and rename 'Files' to 'Downloads' and 'Pages' to 'Documentation'.
You've got a clean, structured, and reliable homepage that you can build a user community around. You even shift the burden of server load or bandwidth to Google in the process.
Manage your projects internally with a project management site
I also want somewhere for my project team to host technical specs, store binaries, and ask project specific questions that customers shouldn't be reading but which are too project specific to store in the technology knowledge base (what's the address for the SQL server we're using for QA? What are the RGB values for the colours used on the splash screen?), so I invite the team members for each project to a private group.
I cross-post bugs and feature requests here, as well as a summary of when / how bugs were fixed (or why they weren't). The files section hosts the current QA and release binaries as well as the last QA source, plus things like project graphics or required release distributables. The documents section holds the project plan, specification, release schedule -- all version controlled Wikis.
If a new team member joins they've got a first place to look for answers to their questions, and an excellent place to ask questions they can't find the answers to.
General Tips for Professionals Using of Google Groups
- Structure your documents. By selecting 'Rearrange your documents' in the 'documents' section, you can structure your documents into a sensible hierarchy. 'Sub-documents' will be indented underneath their parent and will be shown when you view their parent. Hierarchies can go multiple levels. [Here's an example].
- Add your product or company logo. Each group lets you include a logo that will be displayed on the top left and in the listings.
- Discussion posts via email. If you have an email discussion with someone that covers technical details or any other useful information, bcc or forward the conversation to the appropriate knowledge bases. You can get the email address at the bottom of the full discussions list (next to the XML feed icon).
- If your knowledge base is going to feature a lot of code snippets, set the default view to proportional font in the appearance tab of the group settings.
But what's wrong with using Outlook?
The three most common technological solutions I've seen are: Mailing lists and/or Email folders, Wikis, Internal databases.
Email and mailing lists are difficult to search and a pain to distribute to new staff and Exchange is a dirty whore to search (especially server folders). Watch your mail server get pwned during a particularly heated discussion about a message with a 3Mb attachment.
People ignore email messages older than 5 days and will never go back to them while Wikis tend to be too formal, which can intimidate new users, and are seldom up-to-date. Plus you have to setup and host a Wiki somewhere.
Internal databases are generally an admission that using Outlook just isn't enough. Generally these systems have special data entry requirements (and a new UI) that staff need to learn, have specific access permission requirements, and that often can't get accessed away from your desk (or the office).
No comments:
Post a Comment