Tuesday, September 29, 2009

Sharing Feedback Systems

Pop quiz:

You have a client, on whose behalf you are building the next Twitter (or whatever). You're a nice, forward-thinking, modern software kind of guy, so you've agreed to take client feedback throughout the project and to put up interim builds frequently to show progress. In addition, you've got a tester who will work on this project as it gets built.

Do you let your client see your defect tracking system? The one your tester is using?

Let's think about this for a minute:

Pros of having the same defect tracking system for internal (your tester) and external (your customer) feedback:
  • No more copying and pasting from emails or one system into another. You've just bought someone hours of time!
  • Fewer duplicates. Your tester will confirm things your customer saw rather than double-reporting them, and (hopefully) vice versa.
  • More comfort. Your customer knows exactly what he's getting and gets some comfort that you're not just writing and waiting on him, but that you're actually using this and working out the kinks before it goes live.
Cons:
  • All your warts? Totally visible. This is really the big downside here.
  • You all have to watch your language a bit. No putting "the customer is always right, even if they're total idiots" in bugs.
  • Less comfort. You mean you're not perfect? If the developers didn't catch this, then what are they missing?

Notice that customer comfort appears on both lists; both of them are probably in play a bit, and which one dominates will depend on your customer. Most or all of the customers I've worked with, though, have fallen into the more comfort camp. They know software in general has problems, and not finding them means you're not looking. And if the customer doesn't see you finding them, then as far as he's concerned, you're not providing that comfort.

My preference is to err on the side of transparency. I think that showing the client you're not hiding anything is part of building a good relationship. I also think that you shouldn't be denigrating your client even in private (you never know what might slip out into public!). At least for the team I often work with, knowing that the client is going to see everything also incentivizes the developer to poke at it a bit harder before putting it out for public review (not true of everyone, I'm sure, but having an incentive to not slack off never hurts!).

If you want to not share with your customer, ask yourself what you're hiding, and what would happen if your customer knew. And then go out and fix those things. The things you hide, those are your problem areas. Being transparent will make you fix them.

There are probably situations where an internal-only system is needed, but I haven't run into one yet.
Posted by at 1:30 PM

5 comments:

  1. nope i wouldn't let the client see the defect tracking system. Life is about managing perceptions and managing the perception of project is always in the best interest of the PM. Having the customer see how the team interacts etc isn't necessary since at the end of the day it is the end result that matters i.e. software delivered. Periodic reporting of issues would be suffice

    my 2 cents
    ReplyDelete
  2. "There are probably situations where an internal-only system is needed, but I haven't run into one yet."

    I have -- clients who micromanage.

    That said, my preference is to make the user stories or requirements -- and their completeness (or lack thereof) -- visible, but keep the bugs/tickets/backlog invisible.
    ReplyDelete
  3. Hi Catherine,

    i think, it all depends upon the mode in which we are wrking with the client, as in some projects client is quite active in daily meetings (scrums etc),in that case i will agree with catherine that transparency, sharing status, sharing actual bug reports would help in building good relationship with the client.
    if we are hiding some information from client, then we have make sure what will be the results when client eventually know the real picture, i had a expereince where company loose project of worth about 6 million $ just after 6 months working, as they hide some information from the client, (not the sensitive one), but in the end cline loose their confidence and withdraw their offer.
    After sharing my expereince, i would say again it all depends upon the project mode.

    Nice discussion Catherine.
    ReplyDelete
  4. Hi Catherine,

    i think, it all depends upon the mode in which we are working with the client, as in some projects client is quite active in daily meetings (scrums etc).in such case i will agree with catherine that transparency, sharing status, sharing actual bug reports would help in building good relationship with the client.
    if we are hiding some information from client, then we have make sure what will be the results when client eventually know the real picture, i had a expereince where company loose project of worth about 6 million $ just after 6 months working, as they hide some information from the client, (not the sensitive one), but in the nd client loose their confidence.
    after sharing my expereince, i would say again it all depends upon the project mode.

    Nice discussion Catherine.
    ReplyDelete
  5. We use an in-house developed bug reporting system that allows customers to log on and raise faults directly. Faults that are raised internally are only made public to the customer after they are fixed. But, only the general details of the fault are made public, the specific details of the fault and any internal correspondence are still kept private.
    ReplyDelete

Subscribe to: Post Comments (Atom)