Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work in web development, that involves a lot of smaller custom projects rather than one large product. Requirements and specifications are always coming from outside the company.

We've setup a ticket tracking system (Active Collab, which is rubbish compared to redmine btw) and given access to clients so they can submit issues. The idea being that less time is taken up with long phone conversations and emails. I think it can work really well if done right.

However I'm not so sure it's always a good thing. Feature requests have gone up a lot on some projects. The system also needs to be friendly to non-developers while having the many features that developers use. Developers' tickets do not always map 1-to-1 with the tickets clients will create.

So the requirements and broader tickets need to be separated from the more specific developer (specification) related tickets. Perhaps we could use two systems, one for clients to submit their requirements or describe a bug, and one for developers to create tickets like implement method x in class y. Maybe this can be achieved by structuring tickets into more appropriate categories or creating sub-tickets under a feature request ticket. I've briefly looked into Pivotal Tracker and it has a fundamentally different workflow.

tl;dr How do you keep technical tickets (developer jargon) separate from client tickets (layperson language).

share|improve this question
1  
Electronic communications have a tendency to lose in translation the end customers desires I have found. The idea is great in theory but vocal communication, even face to face communication is much easier to elicit requirements from. –  Chris Jan 14 '11 at 21:22
add comment

2 Answers

The Two System Approach

I currently use the two system approach. We use

  • OTRS - Help desk so users can submit issues. Many of them aren't very technical, so there are issues coming in that could be a bug or could be user error that we can just tell them how to do what they can't seem to figure out. (There are much better ticket systems out there. Use what flavor suits you.)
  • Team Foundation Server 2010 - This is our bug tracking/task/feature request server. If an issue comes in via OTRS, then we create a new bug in TFS and note the associated OTRS ID (and copy the history into the bug description/notes). If the OTRS ticket is something that looks like a feature, then we pursue that in the ticket. Once we have enough information to properly create a bug, task, or feature request in TFS and understand how critical it is, due dates, and have enough requirements, then we create one.

We keep users up to date through the ticket system along the way as needed. Once we've completed a bug fix or feature and release it, then we update the ticket system as completed.

This works well for my team, as we only have a small handful of developers. However, this hides technical details from users that might get see it and mentally "check out", while at the same time allowing a technical filter so that "silly" requests don't make it into the true feature tasks (and so a developer doesn't accidentally work on something that hasn't been approved).

share|improve this answer
    
Won't individual reports get out of sync? –  TheLQ Jan 4 '11 at 14:05
    
They can, and that's one of the downsides. It's up to developers to keep them in sync (assuming an OTRS ticket and a TFS task NEED to be word for word...two or three OTRS issues may map to one TFS bug, for example). The reason we use this approach is we have a separate IT team that monitors OTRS for other issues and can assign issues to the dev team. If you're a shop that JUST writes/sells software, then I'd go with how Codeplex works. They integrate codeplex.com with TFS directly, so any issues submitted to the site automatically show up in TFS. –  Ryan Hayes Jan 4 '11 at 14:13
add comment

Tell them to use the tracker as their wishlist.

I have actually used Redmine and given access to clients so they can use it as their wishlist, it has worked with some, but not with all, and it generally depends on their enthusiasm/involvement with the project.

Another recommendation for a simpler and perhaps more engaging tracker is PivotalTracker. The interface is basically one dashboard with drag & drop for tasks. Very scrummy.

Finally, you could try looking for scrum based project management tools (scrum is an agile project development methodology that puts special attention on communication with the client), such as Agilo and have them create "user stories".

Use a simpler customer feedback application

Another apporach I've used is to put an UserVoice tab in the frontend and/or backend, and this generally works better since it is a simpler interface (seems that Redmine can be too complex for some). The good thing about UserVoice is that you can actually handle items as tasks/features, giving "planned", "under review", "started", etc.

share|improve this answer
    
+1 for Trac and Uservoice. I use them both. –  user2567 Jan 9 '11 at 0:05
1  
I found this redmine plugin called backlogs, which is similar to pivotal tracker. redminebacklogs.net –  Keyo Jan 9 '11 at 1:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.