I?m starting this thread to really examine what our ideas of knowledge management in game development, and on a broader level, as professionals actually are.
This is actually a hot topic at uni amongst biz/information management students in masters. It is however broadly generalized and in a lot of instances sapped by profiteering consultants. Despite this I believe that I solid understanding by designers and developers of what Tacit and Explicit knowledge is, what knowledge buy in is, and what sort of systems exist for capturing or Tacit knowledge actually exists.
To start the hunt I?ve included a few links to start the ranting:
http://www.systems-thinking.org/kmgmt/kmgmt.htm (A brief overview)
http://www.kmworld.com/
http://www.systems-thinking.org/tkco/tkco.htm
http://www.amazon.com/gp/product/0684844745/002-3638931-8880044?v=glanc… (if you want a text)
And for a little knowledge before you start attacking your pointy haired boss:
quote:Originally posted by matt.davo
...I believe that I solid understanding by designers and developers of what Tacit and Explicit knowledge is, what knowledge buy in is, and what sort of systems exist for capturing or Tacit knowledge actually exists.
My entire understanding of these terms is pretty much based on [url="http://en.wikipedia.org/wiki/Knowledge_management"]this wikipedia entry[/url], so I'm probably talking way outside my station - but...
One of the most useful tools I've ever used was an integrated bug tracking, source code control and release management system. It wasn't specifically designed to track tacit knowledge, but as a side-effect it certainly managed to.
The way that worked was that to get anything into a release it could only be checked in against a bug* in the bug database. Each release was thus a collection of bugs*.
That meant that if you ever wanted to know what was done to fix a bug* you could immediately see it. The reverse was even more useful - if you wanted to know what a line of code was doing, or why it was there, you could see which bug* it was checked in against.
We hooked it up to CVSweb and using the 'annotate' feature and some custom hacks you could see literally see a bug* number against every single line of code, or a collection of changes across the entire project on a single summary page. And, of course, by looking at the bug* you could see the symptoms which caused the issue, with as much detail as you want (client reports, screenshots, etc) in the first place.
So hidden between the lines you could see how and more importantly why things were done.
The key reason that this worked was that it was made relatively easy, but also mandatory for the users of the system. Every time you made a checkin, you had to say which bug* it was against.
I've seen any number of knowledge-bases, wikis, documents etc in projects come and go - most of them seemed to just fall into disuse. The combination of simple and mandatory as part of workflow seemed to be the magic bullet.
...and congratulations Matt!
*a bug is used as shorthand for a defect, or feature request, or task
quote:Originally posted by mcdrewski
The way that worked was that to get anything into a release it could only be checked in against a bug* in the bug database. Each release was thus a collection of bugs*.
Somehow reminds me of a certain very large software company's products [;)]
edit: Sorry I couldn't be there btw Matt.
quote:Originally posted by matt.davo
This is actually a hot topic at uni amongst biz/information management students in masters.
Also in comp-sci. Would you/people like me to ask a research postgrad who's topic is in the area if she'd be interested in joining?
Management Info Systems (subject I've been head tutor of) is part of this area- it's about the software systems used to aquire, store and analyse data, information and knowledge for company management.
Version control systems and bug tracking databases are imho the most obvious for game dev studios explicit knowledge storage.
I suspect some huge publishers would be using some very fancy systems indeed for trying to predict what is going to sell based on past data. I would be in their position...
Good morning ladies and gents. I'll be back in Australia from the 8th of January. Looking forward to continuing this thread.
Really, I'm more interested in the way game developers as artists and programmers share knowledge with other co workers (say for an artist an interesting modelling technique) or for a shader coder different ways of passing state variables to a shader to make it run faster...
This is the sort of data that a successful game development project can live or die by...
I think knowledge hoarding *MAY* be prevalant in the Australian Industry because of the amount of turnover induced by the companies themselves. Keeping knowledge to oneself makes you indispensible.
Oh, and my grammar is all messed up because I have an engagement party tonight (yes, my own) and I've been drinking chimay all afternoon, and well, it's only when your this drunk do you actually have the balls to post this sort of stuff in an open forum)