I had an idea today - it was triggered by the countless number of Emails flooding my (and my teammember's) Inbox. The problem as I see it is not that people send Emails - that is perfectly fine. The problem is that they often send me valuable information which I have a hard time backtracking when I need the information 3 months after I recieved the Email....
I tried figuring out how to avoid this scenario and came up with a few stories:
S1: A user should be able to save valuable information received by Email
S2: A user should be able to search through stored information
S3: No anonymous access to the information should be possible
S4: The cost in time of storing information should be very close to zero to assure that the shared container of information will be updated frequently.
I think we actually achieved all goals in a matter of 2 hours work... How did we do it? Well, Uncle Google to the rescue:
I had an idea that saving everything in a private blog could be the silver bullet for us and ensure that story S1 and S2 was easily solved so I created a GMail account which could serve as a shared login to ressources hidden behind the login. I quickly set up a blog and clicked around a bit to ensure the privacy of the blog (no search engine should index the content, no pingback to tracking sites etc.). Then I changed the blog from being open for anybody to only being open to the people I invited. Everything went fine - until I discovered that RSS is not possible for a private blogs... Oooops. That wasn't part of my master plan at all because I always had the idea that invited people should be able to subscribe to the RSS-feed of the blog.
I tried fiddling around Google to see if I could establish a workaround but I discovered that due to the nature of RSS it is not possible to validate the viewers... Bugger, bugger, bugger, bugger, bugger... I knew for sure that my idea required that viewers should be notified somehow whenever new content was added otherwise the Email-hell would continue.
I actually thought that my idea was going down the tubes until I discovered that Blogspot has this nice feature called Mail-To-Blogger. When you want to add something to the blog you could simply do it by Email to make it magically appear on the blog! Voila, problems solved...
I set everything up and now whenever somebody in our team has something they want to share with us ("I updated the server X with patches Y and Z - it shouldn't have any effect on process B but be aware anyway. Read about the patches here" (where the link is the valuable information nobody can find 3 months later) they send an Email to each of us as usual - but they also send a CC to a special Email-address to save the Email in our private blog. If I recieve something such as a new password to a service we use I send it to this Email to ensure that when I go on vacation nobody is stopped in their work because the Email is located in my Inbox only. Sweeeet.......
Security? Well I have made a lot of effort to turn off RSS, to explicitly tell Google to NOT index anything on the blog etc. The content of the blog is viewable only to the people I have sent invitations to - the Gmail-account which was used to create the blog has been shared between all members so everybody are able to administer the blog. Does anybody have any experience with private blogs and how private they really are? Please let me know if you do.
We will evaluate the blog in a few weeks time to see if we have had any value out of it. The Email-hell is still there but Emails are not bad just because they are Emails. They only become a living hell when you as a user are unable to find that single Email which contains information you need and that's the problem we are trying to solve right now. I will get back to you with an update when we have more experience on the subject.
This blog contains reflections and thoughts on my work as a software engineer
mandag den 18. februar 2008
How to share knowledge amongst teammembers
Indsendt af Kristian Erbou
Etiketter: agile team communication, best practise, knowledge exchange
Abonner på:
Kommentarer til indlægget (Atom)
Opslag
9 kommentarer:
That's what wiki was built for.
Well... I think that people tend to believe that as long as the right tools are available to you everybody will begin using (and loving) them... A wiki, I think, is a perfectly good example at how you can implement complicated solutions for trivial problems. We tried implementing the use of a wiki at my previous job but never made it work because people's habits are very hard to change if they feel they have to put an extra effort into publishing information on a wiki.
I think the wiki can be a good solution... But you need to be patient... You first need you critical mass / critical amount of information.
The originator(s) of the blog should know this beforehand and see it as their responsibility.
This means, they need to keep the wiki alive and keep on adding content (until the wiki is seen as an added value, because then people will use it).
Did you also think about the drawbacks of your blog ?
eg. what will you do with your password if someone leaves your company ? Will you change the password every time or can an ex-colleague still access your blog ?
At work we have a wiki (mediawiki) that is accessable through ldap (active directory). It took some time to get it working well, but now we see more and more value in it.
I forgot to mention: I work with 2 (soon to be 4 or 5) developers and the size of our IT-departement does not exceed 15 individuals. Due to the relatively small size of our IT departement (together with the arguments mentioned above and the fact that everybody is always working on the same project) the wiki-approach is not the right for us at this point in time.
If we were i.e. 20+ developers working on different projects all the time the Email-thingy would by it's very nature not be the right one for us.
We tried a wiki and it withered on the vine. As busy professionals, there was no time to learn/train 14 developers wiki syntax and structure. I created a simple Drupal site with CCK and Views, a couple of custom content types, and within a month had complete buy-in by development. Now Product Management has started using the site to manage Specs, and QA and DBAs want to use it to document processes and workflow. Best part is: it's all managed/maintained in-house, so it has the same insulation and security as everything else on our intranet.
You may took a look at this:
http://www.wrike.com/
I had pretty much the same experience. Wiki's are fine, but they are difficult to use as a chronological log of software changes with associated comments and code review information. That's more of a logging and commenting activity; blogs provide a viable solution.
I also wanted posting to be as painless as possible for my Web 1.0 team members, and relied upon the blog-by-email option. And I found out that I could not monitor the blog via RSS myself and keep it private at the same time.
I think that if Google provided private feeds for blogspot like they do for Google calendars, that would be good enough security for our purposes. I put in a request for that at their wishlist.
In the meantime, instead of having the team add the blog's email to their cc list, I created a private google group and added the blog's email to that, along with authorizing all my team members' email accounts there. Team email traffic now goes to the Google group address, and the blog gets updated as a bonus. Since the Google group does have a private feed I can keep up to date on new posts to the blog - but not new comments :(
@John:
Thanks for the advice - how long has your team used Google Groups and has your team adapted this way of gathering information in the way it was intended?
The important point I think is the Email receiving part. Most wikis that I know do not have a mailto feature, wouldn't make much sense too, because the information in a wiki should be structured somehow. We use a wiki here too (TWiki) too store stable and longlasting information.
To keep track of the Email hell we use an open source Ticket system (OTRS), that can receive emails too. Advantage: the system is under our control, and you can even put structure into the information. I am not sure you could do that with the blog based approach.
Send en kommentar