Hacker News new | past | comments | ask | show | jobs | submit login

> We are dying under the burden of tracking and correlating engineering decisions across product lines and customers through presentations (you can't have a meeting without PowerPoint!) and spreadsheets -- scattered all over internal shared drives -- email, and Skype chats (which the company won't allow history for).

Sadly, a tool isn't going to get you out of this. You will end up with all the files uploaded to a wiki or repository. One would hope that seeing all the chaos in one place would make everyone say, "Oh, maybe we need to change how we do this," but that is unlikely. What will probably happen is, "This new knowledge management system is a chaotic mess. Let's abandon it."

I would completely ignore tools when you start on your plan. This is going to be a slog about setting expectations for how things will be decided, documented, and referenced, about getting managers and tech leads onboard to discipline their groups, and about having the whole thing not collapse into a bureaucratic nightmare.

Since you're shipping software, I might start with articulating the kinds of documents groups are expected to produce and keep up to date such as design documents that include why particular decisions were made, reference docs and docstrings to let users of a system find what they need, and tutorials/introductions to get users up to speed. Then expectations about how things should be recorded (in an expected class of document, not buried in a PowerPoint, and non-trivial examples).

Then you need buy in from management that engineers should put cycles towards this, and technical writing support to keep the whole think functioning. But think about behavior, not tools. User stories, if you will, of what kind of information people look for and when, and what kind of information people produce.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: