
Ask HN: Lessons learned from using JIRA/similar for an interdisciplinary team? - katsukare-
My company is a startup transitioning to 100 people. Most are hardware engineers.<p>Project 1, I set it up and had under 10 engineers:<p>1. hosted bitbucket.<p>2. google docs.<p>3. kept requirements to a minimum in google sheets<p>I joined project 2 halfway through (setup by others). About 40 engineers:<p>1. Enterprise bitbucket, JIRA, Confluence and Bamboo<p>2. Gitlab CE for system level issues<p>3. IBM Rational DOORS for requirements. Traceability required.<p>4. Windows fileserver hosted by us because its &quot;Not in the cloud&quot;. No more google docs.<p>Software guys are happy with JIRA, hardware guys happy with gitlab but there is not transparency in between. DOORS&#x27;s gotta go. The fileserver, with word_final_v2.doc&#x27;s causing issues. Often files are on personal volumes and shared by slack (in the cloud but nobody noticed).<p>I checked some options to replace DOORS and add some other tools for verification and change management. Along the way, JIRA emerged as the only option that was a single system. It seemed good to use the same tools as our software group and maybe Confluence can help our documentation. Reporting seems good.<p>Project 3&#x2F;standard tools:<p>1. Enterprise bitbucket, JIRA, Confluence and Bamboo<p>2. Requirements&#x2F;Test 4 JIRA. Maintained by only a few people (so I am confident it can be implemented well)<p>3. Begrudgingly keep using the windows fileserver for other files.<p>I wrote a script to migrate to JIRA. Red flag 1: there are many scripts to migrate from JIRA to gitlab, but none in the other direction. Red flag 2: any forum post about JIRA is full of complaints. The more I use it, the more the UI seems inconsistent. All of that said, JIRA still looks like the best option and the dashboards do what was a manual job in gitlab.<p>What I actually want to ask HN is, are there some lessons learned about trying use JIRA and Confluence (or similar tools) in interdisciplinary teams? Any tips to keep the 1-2 times per week users happy?
======
katsukare-
I wanted to add a comment specifically about documentation tools. We've always
had a lot of collaboration. On an earlier project (let's call it project 0),
at the same company, back when there was only a few people, we did all
documentation in latex with CVS. It was glorious but as soon as a couple of
non-technical people joined it was unmanageable and inevitably someone would
have to troubleshoot others' environments, usually eventually giving up and
manually merging on another's behalf.

Then we switched to google drive plus latex/CVS. It was not so glorious using
both at the same time for the same files. We quickly switched to google docs
only, which I came to love for realtime collaboration (a game changer for
remote meetings) and its commenting system. It seems very hard to break linked
content, like drawings or spreadsheet cells in a document. Keeping your
architecture diagrams in a presentation file and linking them to all of your
documents is also a game changer (they will automatically update).

Google drive also became much better when TeamDrive was added. I like that by
design its permissions are not complicated and hierarchical. It's not possible
to deny permissions to a subfolder in a TeamDrive. But old school IT people
think this is a requirement.

Besides Confluence, I tried Amazon WorkDocs (useless), Office's new
collaboration tools (broken) and Office 365 online (not bad but I predict
people will just download and work offline meaning 2+ versions in 2+ places).

I'm going to keep using google docs while I can but have Confluence ready for
whenever strict onsite requirements are enforced. Hopefully someday google
docs has an enterprise or more security options. So far there are only options
for HIPAA, and not other industry-specific options.

------
cimmanom
Jira is infinitely configurable. A lot of teams use that as an excuse to
introduce heavyweight processes and lots of cognitive overhead. The result is
that end users often find it some combination of confusing, frustrating, and
exhausting.

Your challenge when configuring Jira and designing a process to use with it is
to create the simplest workflow with the fewest restrictions and requirements
and roadblocks that still works for everyone.

Treat it as a communication tool rather than an enforcement tool. For your
infrequent users, make someone else responsible for the nitpicky bits of
process (probably a project manager) such as setting ticket priorities and
classification fields like “component”. The infrequent users should be
responsible only for things like creating new tickets with adequate
descriptions and for updating them when things change to indicate what
changed.

Confluence is unnavigable in my opinion. The opposite of what a wiki should
be. We ended up migrating our docs elsewhere.

~~~
katsukare-
Thanks for this, I’ll consider the roles of contributors including updating
tickets, rather than trying to force it with required fields.

