I guess I am in the minority of devs - I am a fan of project management tools, particularly confluence and jira.
I switched into tech from finance, where your projects management tools are multiple email threads on the same topic and an excel spreadsheet that gets emailed around for people to update.
Yes, it could be better, but I am happy that it is not a lot worse.
Confluence squarely falls into the intranet trap. The only intranet/wiki/etc that anyone likes it the new one, no matter the product/technology. Old document stores gather cruft, aren't maintained, and become full of incorrect information over time.
Eventually, you start over (MediaWiki -> SharePoint -> Confluence -> something else) and the new one is great (Confluence is awesome) and the old one is passe (Sharepoint sucks!). Nobody has solved the fundemental problems around intranets.
It allows you to easily search everything! At my last company, someone pointed out to me that I could find almost anything I wanted to know about existing systems in our confluence.
It is excellent for collaborative editing.
It is excellent for writing and formatting documentation that must be shared.
It has a wide variety macros and plugins that let you effortlessly embed charts and diagrams. Admittedly, some macros (ie gliffy) are vastly superior to others (lucidchart).
You can write good documentation with minimal effort. But it also provides a comprehensive set of tools to format the crap out of your documents if you want to.
At this point, I'm really struggling to figure out what someone actually wants out of a "perfect" product. A lot of the things the author complains about would require draconian solutions from a systems standpoint that would just set off another round of complaints that the system is to restrictive.
Same. They absolutely fall into the category of "worst tools available except for all the others". It takes work to configure a JIRA workflow and set of dashboards that works for your org, but every other product I've tried just doesn't even try. I was really shocked the first I tried Notion and Asana since they were so hyped, but they felt way to simple to be useful. Even with a small team we found them way too confining.
You know, I don't hate most aspects of Confluence, except I find the editor to be terrible (at least in the way it's configured in my workplace). I find that I inadvertently change fonts all the time, I can never really get code formatting to work, the I find the controls to be counter-intuitive. Granted, a lot of these are sort of inherent to WYSIWYG editors, but I guess I just really want them to add a true "write in markdown instead of a WYSIWYG".
Because of this, I do all my notes in Obsidian, which I like a lot, but there's something sort of inherently problematic with this: a lot of the notes I take about how things work (e.g. build steps, relevant links, code snippets, code "gotchas") should probably be shared with the team, but it's such a pain in the ass for me to put onto Confluence that I don't bother.
I'm in the same boat. Most of my notes transfer over just fine because it's Markdown, but Confluence handles in-lining LaTeX significantly worse than pretty much any other CMS I've ever used.
> neither are you ever going to use Confluence as a filesystem storage to replace Google Drive. This means that your knowledge’s single-source of truth needs to accept external tools content as possible documentation. This interfacing, though, can’t simply be about linking files and urls in one place, it has to be deeply integrated so that it feels natural, native even. We should be able to put a Google Sheet file in a folder, attribute tags for example.
What's wrong with using just links?
(reads to the end)
Oh, it's lowkey a promotion for his product it must obviously have this native interfacing that he's hyping up about. I honestly don't see what the problem is with keeping a collection of links to Gdocs/Gdrive/Figma in the knowledge base. That's pretty much the only guaranteed way to use these tools, because all of them want to silo you into their website.
Except you can open them in an iframe. Which is what Dokkument (the product being promoted by the author) is doing. Not sure how much more useful that is than simply opening it in another tab which would work 100 times better since you won't have to jump a ton of hoops to make sure everything works fine.
I really don't have the hatred for these Confluence products that most around here seem to have. Sure, there's some quirkiness in writing in the Confluence WIKI, especially now that there's also no behind the scenes confluence-based markdown mode, like we used to have.
And regarding JIRA, I'm guessing it's because more people around here are working on small single focused teams, or early stage startups, and don't really appreciate the power of JIRA to orchestrate delivering complex features that span multiple different groups at an org. At a base level, creating simple JIRA task tickets for a single teams scrum is just so damn easy, and devs looking at their assigned work for the sprint, is pretty easy. And it basically integrates with all the tools devs use, from Emacs to Slack, etc....
I'm really not sure what alternatives people are into? Also, these current tools are such a huge step forward from what we used to use a decade ago...
The world really needs "one ring to rule them all". (e.g. something that sucks in content from all those places and makes them organizable if not findable)
I worked at a startup where, every two weeks, we had a retrospective meeting and the complaint went around that we had too many places to store documents and that we couldn't find them.
Often the same people who were complaining would tout that we add a (N+1)th place to the N places we already had (N>20 by this point.) I'd be the only one to point out the irony in this, people wouldn't get that it was ironic, management would approve, and it would happen again two weeks later.
It might have been funny except for this: it got us in trouble when we were collaborating with customers and customers would get mad that we were sharing documents in ways they thought were insecure. When it happened more than once with the same customer, we lost some very good customers.
> The world really needs "one ring to rule them all". (e.g. something that sucks in content from all those places and makes them organizable if not findable)
We have those, we call it filesystem or fileserver.
A previous company I worked for had a team who’s whole job was keeping the kb up to date.
If you wrote an article/page they would schedule a recurring 6 month meeting with you to go over it and confirm it was still accurate and relevant. If you missed the meeting more than once in a row they would archive your doc until it could be reviewed. You also had to identify a secondary domain expert for that article who could step in if you left the company. The process worked pretty well.
As others pointed out here, it’s a process issue that is hard to solve with tech.
The people at the top need to buy into the idea that a good kb makes everything run smoother and be willing to pay for it (ie hire more heads just for kb maintenance).
The hatred for atlassian products, IMO, has a root cause in a few facts:
1) it's an enterprise product, so the typical enterprise issue of: it's not being sold to the users, the people who it's being sold to don't have to feel the pain, and checking off features is more important than UX.
2) that said, it's not the worst enterprise. It is possible to configure atlassian products to have a really smooth UX (can't say the same about speed, the last I used atlassian, it was really, really, slow though that may have changed). However, wrangling the product (and its users) is almost a full-time job, and atlassian is known to have breaking transitions that mess up your workflow with no recourse to go back to classic. Change management is hard.
3) a lot of higher ups who make the choice of using atlassian even if they are technical and once were a user of atlassian products, used it in an era where it was simpler or worked in an environment where they were privileged enough to have a full-time wrangler from 2)
You don't understand the hatred for Atlassian until you've been around long enough to notice there's a cycle: 1. We hate X. 2. "Here's a lightweight replacement Y for it!" 3. Lightweight replacement Y is forced by the problem space to become as big as what replaced it. 4. We hate Y.
I'd guesstimate the hatred for Atlassian productions is about 75% simply the fact that anything that checks all the boxes necessary to become the enterprise standard will be something that is big and bloated and hated by the users, because Atlassian is merely the latest in a long line of systems hated by people.
Which is not to say anyone should change their mind about the product. Just bear in mind, there isn't anything better that, if it did somehow unseat Atlassian, wouldn't have exactly the same problems in 3-5 years. The problem is the problem space, not the solutions. I mean, sure, I'd like Atlassian to be faster and I suspect there's some room for improvement there, but even if they put a lot of work into it the problems would remain. The problem is that everyone thinks they mean the same thing by issue management, but when you sit down to actually see what that means, it turns out to be the leading bug tracker or wiki means you actually have to be a meta-bug tracker or a meta-wiki, and that's never going to be a great product.
As addendum to 1, this also means it's often seen as the technological hammer with which to get rid of organizational problems, without having to put management effort into solving them first. That can't not end in tears, no matter which particular hammer is directed at your thumbs.
My main complaint against Jira is that it seems to poke the wrong parts of the brain for the wrong type of project manager. It's... fine... on its own, but something about it seems to call out to the hyper-detail-oriented micromanager that makes them want to make 23-step story status workflows. I've come to appreciate opinionated tools that want you to use them a certain way. Even if they prevent me from using them exactly like I'd want to, they also prevent the nightmare PM from using them exactly like they want to.
I can't articulate what I find deal breaking in these tools. I would love to see more contenders to jira. From my understanding people generally hate jira for its ocean of configuration and slowness. Would love to learn more what problem jira is not solving, and would love to try more alternative. I have used github issues, basecamp, trello, among others for project management. They are all okay. At the same time definitely not miles better than jira. In my case, project management is something has to be there, doesn't matter which tool to use (given that most of okay).
Given these points (and point #2 in particular), I'm certain that project management using Google Drive + Google Sheets + Google Docs (or whatever cloud based office tooling you prefer) would be far more productive and cost effective than what Atlassian is selling.
This post makes some salient points about the challenges of team knowledge sharing:
- Tree structure is too strict for cross departmental content ex sales to customer success handoff - should that be under sales or customer success?
- The right answer can be found in multiple tools - companies are not going to ditch Google Sheets / Excel for Notion tables
- A common source of truth needs to take into account the variability in skill - some users are going to be heavier users or more technical than others
- Collaboration needs to be as good as Google Docs or else people will just use Google Docs
It looks like the author is envisioning a new solution with Dokkument but if you want an existing one, take a look at https://slab.com. It’s designed to focus on team knowledge sharing while recognizing that it will be part of the productivity stack. For example, there is have a Content Map feature that shows a bird’s eye view of the entire information topology (with filters and drill down possible) and even mass reorganize from there. Integrations are first class with search retrieving results from other tools and rich linking that will preview external content. Knowledge sharing used to be an afterthought for a lot of teams but with the world going remote it’s exciting to see the innovation and prioritization pick up in this space.
Some friendly criticism. I was curious how slab topics work but could not find the details after a minute of trying to click and scroll around. The marketing bit about topics does not link anywhere. I finally made some progress by scrolling to the bottom, going to the support section, and searching for "topic". I had to scroll past results that described how to reorganize topics, assign permissions, until I arrived at the basics of topic usage. Even that did not provide an insight about how topics are different from regular tags, and I still am not sure what the difference is. So a "features" or "concepts" page would be nice, and even better if it was the main page. (I am an engineer.)
The depressing irony of all this is that despite the massive advances in technology in software and hardware, this kind of tooling, specifically document/content/knowledge/issue management has remained stuck in its containing medium, be that word documents on a shared drive, or textareas on a web page (as I am typing in right now!)
It seems that smalltalk-like systems, and derivatives such as the lively kernel contain clues as to what a unified meta-interface to an individual's or organisation's content might look like (and how it might behave). Integration and user adoption is a difficult problem (in general) though -- probably the best example of this is the poor (and in some circles, pretty vile) criticism that Google Wave received, though this type of feedback is probably due in part to a lack of understanding of the problem being solved.
"The content revolution hasn't happened yet!" [1] :-)
I should add Mathematica (obligatory emphasis), Sage, Jupyter, and other notebook-centric tools to the group of systems which tease the promise of a more "alive" computing model.
Over the decades, I've set up many engineering and organizational document processes, and I've also been a developer on doc tools. The culmination of all of this is that I've ended up gravitating to very-low-friction, tracked, centralized doc -- code-embedded API docs and Markdown files in the/a repo -- and sometimes also a Wiki (preferably a Wiki of the same platform that hosts the repo, unless you've made it hard for non-developers to access the repo platform).
But, if I absolutely have to, I'll endure Confluence. Only if people agree to stop throwing away important information into a dozen different other SaaSes and tools that are effectively write-only, as far as the organization is concerned. Don't just turn those 12 memory holes into 13.
I have come to believe that tools will never solve philosophy-of-use problems. This solution may not scale, but I am confident that a team of 5-10 technical writer/archivists/internal consultants under the command of an extremely rigorous leader could handle widespread documentation for a company of 100-200 people just by using a LaTeX/Git/Wiki stack.
This is related to problematic changes in the field of requirements management. A few decades ago, various companies invented technical requirement databases for large-scale engineering projects, and moved their document-based teams onto these new databases (DOORS, etc.)
Engineering managers think it's like this: Databases (good) > Documents (bad), and they get paid by the metric. And that's the good managers. The bad managers hate changing anything and want to stay with documents.
This, unfortunately, is a reduction of the problem. Most requirements teams didn't have a robust architecture for writing and storing requirements even in their document-based method. The actual hierarchy goes like this: Database with excellent plan (best) > Documents with excellent plan (good) > Database with no plan (bad) > Documents with no plan (worst). Most legacy requirements engineering teams have no idea just how bad the situation is, and have no desire to improve their consistency or internal organization.
This attempt to replace documents with databases seems to be analogous for the modern software company attempt to shift from hard docs to widely-accessible wiki-style docs, or at least it certainly is at the pure software company I work for now (I came from more tangible engineering). Rules for storing documentation are almost more important than the documentation itself. My current team generates documentation at a very large rate; it's completely unsynchronized, the articles vary stylistically and structurally, the linking is inconsistent, and labelling is nonexistent across divisions. We need a hierarchical documentation structure imposed on us tyrants, consulted by the company-specific subject-matter experts. It's like comedy--much easier to write a sketch about broccoli than it is to write a sketch about anything.
I generally find these sort of diatribes against the market leading project management tools a little pointless. Another popular topic that also has numerous "we deserve better" articles is email.
The fact of the matter is solving those problems, while solving all the incredible long tail of corner cases, is incredibly difficult. You can theorize how things should be done and try to "rationalize" your way into some sort of ideal product, but as we've seen plenty of times, they eventually end up with a product that looks like an existing product (see Asana's evolution for example). It doesn't mean you shouldn't try, because my hunch is there's probably some sort of thing that just hasn't "clicked" yet, and the moment a product is able to do that, suddenly it'll become the most obvious way to do things. Until then companies will keep trying because it's an incredibly lucrative space, and there'll always be a new trendy system out there (Monday.com for example). But most of them end up being inferior in most ways, and superior in just 1 or 2 ways which forces the hand of larger companies to just to choose the larger one anyway.
Good luck to Dokkument in trying to get there. In this space you either die a hero or live long enough to become the villain.
>I generally find these sort of diatribes against the market leading project management tools a little pointless.
Confluence and Notion are not project management software. But if you replace with knowledge base I agree with you.
At the end of the day the only things that matter is not the idea, it's the execution, and that's also the reason why we often end up with shitty tools.
We are trying something, if it clicks as you said, it clicks, if it doesn't it will be just another among the other ones
Any confluence like tool (wiki/sharepoint) is only as good as the people who populate, edit, and curate it. The tool itself (confluence) is generally not a problem, the problem is that documents go stale and/or are badly organized. You can't really automate yourself out of that problem. Just because any given document hasn't been touched in months or years doesn't mean it's actually out of date.
I remember for about 5 seconds in late 90s early naughts there was talk of this role of 'information architect', a sort of a digital corporate librarian. I imagine such a role should still exist, but who has the headcount?
I wonder if part of the issue (on top of the software itself being poor, and obvious point that human problems are hard), is that nobody ever seems to hire a design team for internal stuff until far too late in the game (if ever).
Many of the problems with internal knowledge bases could be lessened if there was an IA, whose job it was to iterate on improving the organisation of internal knowledge. They wouldn’t do it alone, they’d need company-wide buy-in, but what I typically see is that it’s a complete free-for-all or it’s owned by HR/People (also bad in my opinion).
I’d like to just open JIRA or Confluence and not have a dozen call-to-action notifications strewn about the UI about (new feature no one asked for or cares about) I have to manually close.
* built in document aging and asset maintenance strategies - ideally including a time estimate for billing. A document not worth maintaining is not worth having.
* similarly some sort of automated / well-designed change management component - I changed this codebase / design component / business offering / org chart, what knowledge bases are affected
* and similarly a much more intelligent (and harsh) judger of documentation, Wiki content etc - the human curator today comes back to the room and says, "everything we have is old or sh!t," the KB comes back with "31 pages of results!" Infuriatingly shallow experience.
* graph and Venn diagram representations of viewer/authors and tags/topics, metadata, etc with killer app search and browse capabilities. Eliminate hierarchies, embrace dependencies
Never ceases to amaze me how people are so quick to slap a "made for tech teams" onto their landing page — in an attempt to say they're for the entire company.
Exactly what is made for tech teams? All I see is generic features in there.
Confluence, Notion and Dokkument and all the tools are not made for tech teams. They are just generic editors and organizers. Notion stands out in the fact they are trying to cross boundaries from the docs space, into the project management space, and into the data management space.
Again, do we see API docs in any of these tools? Do we see integrations to GitHub, OpenAPI/Swagger, GraphQL, software architecture diagrams, changelogs, great markdown support? Do we see great care in keeping the software fast as required by tech people?
It didn't seem that way to me when I started building archbee.io — it's truly made for tech people.
[+] [-] game_the0ry|4 years ago|reply
I switched into tech from finance, where your projects management tools are multiple email threads on the same topic and an excel spreadsheet that gets emailed around for people to update.
Yes, it could be better, but I am happy that it is not a lot worse.
[+] [-] pseudosavant|4 years ago|reply
Eventually, you start over (MediaWiki -> SharePoint -> Confluence -> something else) and the new one is great (Confluence is awesome) and the old one is passe (Sharepoint sucks!). Nobody has solved the fundemental problems around intranets.
[+] [-] tynpeddler|4 years ago|reply
It's web based so no installation hassle.
It allows the raw storage of documentation.
It allows you to search uploaded documentation.
It allows you to easily search everything! At my last company, someone pointed out to me that I could find almost anything I wanted to know about existing systems in our confluence.
It is excellent for collaborative editing.
It is excellent for writing and formatting documentation that must be shared.
It has a wide variety macros and plugins that let you effortlessly embed charts and diagrams. Admittedly, some macros (ie gliffy) are vastly superior to others (lucidchart).
You can write good documentation with minimal effort. But it also provides a comprehensive set of tools to format the crap out of your documents if you want to.
At this point, I'm really struggling to figure out what someone actually wants out of a "perfect" product. A lot of the things the author complains about would require draconian solutions from a systems standpoint that would just set off another round of complaints that the system is to restrictive.
[+] [-] tootie|4 years ago|reply
[+] [-] billconan|4 years ago|reply
I think the real problem is "writing is difficult." I used to write blogs, now I don't do it anymore. it's too involved.
could there be another form of content that's easy to create? like audio and video (with searchability ).
[+] [-] tombert|4 years ago|reply
Because of this, I do all my notes in Obsidian, which I like a lot, but there's something sort of inherently problematic with this: a lot of the notes I take about how things work (e.g. build steps, relevant links, code snippets, code "gotchas") should probably be shared with the team, but it's such a pain in the ass for me to put onto Confluence that I don't bother.
[+] [-] arksingrad|4 years ago|reply
[+] [-] spacehunt|4 years ago|reply
[+] [-] SPBS|4 years ago|reply
What's wrong with using just links?
(reads to the end)
Oh, it's lowkey a promotion for his product it must obviously have this native interfacing that he's hyping up about. I honestly don't see what the problem is with keeping a collection of links to Gdocs/Gdrive/Figma in the knowledge base. That's pretty much the only guaranteed way to use these tools, because all of them want to silo you into their website.
[+] [-] thecodrr|4 years ago|reply
[+] [-] taude|4 years ago|reply
And regarding JIRA, I'm guessing it's because more people around here are working on small single focused teams, or early stage startups, and don't really appreciate the power of JIRA to orchestrate delivering complex features that span multiple different groups at an org. At a base level, creating simple JIRA task tickets for a single teams scrum is just so damn easy, and devs looking at their assigned work for the sprint, is pretty easy. And it basically integrates with all the tools devs use, from Emacs to Slack, etc....
I'm really not sure what alternatives people are into? Also, these current tools are such a huge step forward from what we used to use a decade ago...
[+] [-] PaulHoule|4 years ago|reply
I worked at a startup where, every two weeks, we had a retrospective meeting and the complaint went around that we had too many places to store documents and that we couldn't find them.
Often the same people who were complaining would tout that we add a (N+1)th place to the N places we already had (N>20 by this point.) I'd be the only one to point out the irony in this, people wouldn't get that it was ironic, management would approve, and it would happen again two weeks later.
It might have been funny except for this: it got us in trouble when we were collaborating with customers and customers would get mad that we were sharing documents in ways they thought were insecure. When it happened more than once with the same customer, we lost some very good customers.
[+] [-] ojkelly|4 years ago|reply
But yep you’ve gotta have just one, more and the network effects break down rapidly - at which point it’s no longer a useful tool.
[+] [-] slightwinder|4 years ago|reply
We have those, we call it filesystem or fileserver.
[+] [-] madiator|4 years ago|reply
[+] [-] vxNsr|4 years ago|reply
If you wrote an article/page they would schedule a recurring 6 month meeting with you to go over it and confirm it was still accurate and relevant. If you missed the meeting more than once in a row they would archive your doc until it could be reviewed. You also had to identify a secondary domain expert for that article who could step in if you left the company. The process worked pretty well.
As others pointed out here, it’s a process issue that is hard to solve with tech.
The people at the top need to buy into the idea that a good kb makes everything run smoother and be willing to pay for it (ie hire more heads just for kb maintenance).
[+] [-] dnautics|4 years ago|reply
1) it's an enterprise product, so the typical enterprise issue of: it's not being sold to the users, the people who it's being sold to don't have to feel the pain, and checking off features is more important than UX.
2) that said, it's not the worst enterprise. It is possible to configure atlassian products to have a really smooth UX (can't say the same about speed, the last I used atlassian, it was really, really, slow though that may have changed). However, wrangling the product (and its users) is almost a full-time job, and atlassian is known to have breaking transitions that mess up your workflow with no recourse to go back to classic. Change management is hard.
3) a lot of higher ups who make the choice of using atlassian even if they are technical and once were a user of atlassian products, used it in an era where it was simpler or worked in an environment where they were privileged enough to have a full-time wrangler from 2)
[+] [-] jerf|4 years ago|reply
I'd guesstimate the hatred for Atlassian productions is about 75% simply the fact that anything that checks all the boxes necessary to become the enterprise standard will be something that is big and bloated and hated by the users, because Atlassian is merely the latest in a long line of systems hated by people.
Which is not to say anyone should change their mind about the product. Just bear in mind, there isn't anything better that, if it did somehow unseat Atlassian, wouldn't have exactly the same problems in 3-5 years. The problem is the problem space, not the solutions. I mean, sure, I'd like Atlassian to be faster and I suspect there's some room for improvement there, but even if they put a lot of work into it the problems would remain. The problem is that everyone thinks they mean the same thing by issue management, but when you sit down to actually see what that means, it turns out to be the leading bug tracker or wiki means you actually have to be a meta-bug tracker or a meta-wiki, and that's never going to be a great product.
[+] [-] wly_cdgr|4 years ago|reply
[+] [-] creshal|4 years ago|reply
[+] [-] kstrauser|4 years ago|reply
[+] [-] a_c|4 years ago|reply
[+] [-] jtdev|4 years ago|reply
[+] [-] jhchen|4 years ago|reply
- Tree structure is too strict for cross departmental content ex sales to customer success handoff - should that be under sales or customer success?
- The right answer can be found in multiple tools - companies are not going to ditch Google Sheets / Excel for Notion tables
- A common source of truth needs to take into account the variability in skill - some users are going to be heavier users or more technical than others
- Collaboration needs to be as good as Google Docs or else people will just use Google Docs
It looks like the author is envisioning a new solution with Dokkument but if you want an existing one, take a look at https://slab.com. It’s designed to focus on team knowledge sharing while recognizing that it will be part of the productivity stack. For example, there is have a Content Map feature that shows a bird’s eye view of the entire information topology (with filters and drill down possible) and even mass reorganize from there. Integrations are first class with search retrieving results from other tools and rich linking that will preview external content. Knowledge sharing used to be an afterthought for a lot of teams but with the world going remote it’s exciting to see the innovation and prioritization pick up in this space.
Disclosure: I am a co-founder of Slab
[+] [-] bad_username|4 years ago|reply
[+] [-] gjvc|4 years ago|reply
It seems that smalltalk-like systems, and derivatives such as the lively kernel contain clues as to what a unified meta-interface to an individual's or organisation's content might look like (and how it might behave). Integration and user adoption is a difficult problem (in general) though -- probably the best example of this is the poor (and in some circles, pretty vile) criticism that Google Wave received, though this type of feedback is probably due in part to a lack of understanding of the problem being solved.
"The content revolution hasn't happened yet!" [1] :-)
[1] with apologies to Alan Kay, https://www.youtube.com/watch?v=aYT2se94eU0
[+] [-] gjvc|4 years ago|reply
[+] [-] neilv|4 years ago|reply
But, if I absolutely have to, I'll endure Confluence. Only if people agree to stop throwing away important information into a dozen different other SaaSes and tools that are effectively write-only, as far as the organization is concerned. Don't just turn those 12 memory holes into 13.
[+] [-] quacked|4 years ago|reply
This is related to problematic changes in the field of requirements management. A few decades ago, various companies invented technical requirement databases for large-scale engineering projects, and moved their document-based teams onto these new databases (DOORS, etc.)
Engineering managers think it's like this: Databases (good) > Documents (bad), and they get paid by the metric. And that's the good managers. The bad managers hate changing anything and want to stay with documents.
This, unfortunately, is a reduction of the problem. Most requirements teams didn't have a robust architecture for writing and storing requirements even in their document-based method. The actual hierarchy goes like this: Database with excellent plan (best) > Documents with excellent plan (good) > Database with no plan (bad) > Documents with no plan (worst). Most legacy requirements engineering teams have no idea just how bad the situation is, and have no desire to improve their consistency or internal organization.
This attempt to replace documents with databases seems to be analogous for the modern software company attempt to shift from hard docs to widely-accessible wiki-style docs, or at least it certainly is at the pure software company I work for now (I came from more tangible engineering). Rules for storing documentation are almost more important than the documentation itself. My current team generates documentation at a very large rate; it's completely unsynchronized, the articles vary stylistically and structurally, the linking is inconsistent, and labelling is nonexistent across divisions. We need a hierarchical documentation structure imposed on us tyrants, consulted by the company-specific subject-matter experts. It's like comedy--much easier to write a sketch about broccoli than it is to write a sketch about anything.
[+] [-] RealityVoid|4 years ago|reply
[+] [-] intev|4 years ago|reply
The fact of the matter is solving those problems, while solving all the incredible long tail of corner cases, is incredibly difficult. You can theorize how things should be done and try to "rationalize" your way into some sort of ideal product, but as we've seen plenty of times, they eventually end up with a product that looks like an existing product (see Asana's evolution for example). It doesn't mean you shouldn't try, because my hunch is there's probably some sort of thing that just hasn't "clicked" yet, and the moment a product is able to do that, suddenly it'll become the most obvious way to do things. Until then companies will keep trying because it's an incredibly lucrative space, and there'll always be a new trendy system out there (Monday.com for example). But most of them end up being inferior in most ways, and superior in just 1 or 2 ways which forces the hand of larger companies to just to choose the larger one anyway.
Good luck to Dokkument in trying to get there. In this space you either die a hero or live long enough to become the villain.
[+] [-] polote|4 years ago|reply
>I generally find these sort of diatribes against the market leading project management tools a little pointless.
Confluence and Notion are not project management software. But if you replace with knowledge base I agree with you.
At the end of the day the only things that matter is not the idea, it's the execution, and that's also the reason why we often end up with shitty tools.
We are trying something, if it clicks as you said, it clicks, if it doesn't it will be just another among the other ones
[+] [-] sleepybrett|4 years ago|reply
I remember for about 5 seconds in late 90s early naughts there was talk of this role of 'information architect', a sort of a digital corporate librarian. I imagine such a role should still exist, but who has the headcount?
[+] [-] andrewingram|4 years ago|reply
Many of the problems with internal knowledge bases could be lessened if there was an IA, whose job it was to iterate on improving the organisation of internal knowledge. They wouldn’t do it alone, they’d need company-wide buy-in, but what I typically see is that it’s a complete free-for-all or it’s owned by HR/People (also bad in my opinion).
[+] [-] pram|4 years ago|reply
[+] [-] dcchambers|4 years ago|reply
Jira...I can definitely see why people have issues. But confluence has always been rock solid for me and easy to use.
[+] [-] jdgoesmarching|4 years ago|reply
[+] [-] dabedee|4 years ago|reply
[+] [-] remram|4 years ago|reply
[+] [-] kthejoker2|4 years ago|reply
* built in document aging and asset maintenance strategies - ideally including a time estimate for billing. A document not worth maintaining is not worth having.
* similarly some sort of automated / well-designed change management component - I changed this codebase / design component / business offering / org chart, what knowledge bases are affected
* and similarly a much more intelligent (and harsh) judger of documentation, Wiki content etc - the human curator today comes back to the room and says, "everything we have is old or sh!t," the KB comes back with "31 pages of results!" Infuriatingly shallow experience.
* graph and Venn diagram representations of viewer/authors and tags/topics, metadata, etc with killer app search and browse capabilities. Eliminate hierarchies, embrace dependencies
[+] [-] dragosbulugean|4 years ago|reply
Exactly what is made for tech teams? All I see is generic features in there.
Confluence, Notion and Dokkument and all the tools are not made for tech teams. They are just generic editors and organizers. Notion stands out in the fact they are trying to cross boundaries from the docs space, into the project management space, and into the data management space.
Again, do we see API docs in any of these tools? Do we see integrations to GitHub, OpenAPI/Swagger, GraphQL, software architecture diagrams, changelogs, great markdown support? Do we see great care in keeping the software fast as required by tech people?
It didn't seem that way to me when I started building archbee.io — it's truly made for tech people.