Loading ...
Sorry, an error occurred while loading the content.

my dev team has too much support

Expand Messages
  • eliga_repoleved
    My dev team has way too much support load. We currently change support rotation every week. That is -- one person handles production support for a whole
    Message 1 of 13 , Feb 1, 2007
    • 0 Attachment
      My dev team has way too much support load. We currently change
      support rotation every week. That is -- one person handles production
      support for a whole week, then it is shifted to the next developer.
      Support calls can come any time of the day or night. And there is an
      expectation to answer all of these calls.

      I get annoyed with the support interuptions, because it distracts my
      current release work.

      I don't buy in the concept in any way shape or form, that being
      bombarded with support requests in the middle of the developer bull
      pen is some how supposed to make the product better. Whoever came up
      with this idea should be shot.

      There is a first level support group, but these are the people who are
      often coming to the on-call support person on my dev team.

      Anyone know how to handle this problem? Is there a way to get out of
      this support load interuption trap?

      All people involved work for the same company in one office. The
      software is created, supported, and mainained by people who work in
      the same company in one office.
    • Brian Spears
      At some point, customer issues that cannot be solved by front line support end up handled by the development team. We have a second line of support between the
      Message 2 of 13 , Feb 1, 2007
      • 0 Attachment
        At some point, customer issues that cannot be solved by
        front line support end up handled by the development team.

        We have a second line of support between the front-line
        support and the development team. They are more technical,
        more experienced, and more expensive.

        And issues still come to the team when the second line of
        support cannot solve them. When there are too many coming
        to us, that means either we've made the product too
        difficult to use/too buggy, or we don't have enough
        well-trained second line support people and need to invest
        in more. Either way we have a problem.

        Good luck!

        Brian

        --- eliga_repoleved <eliga_repoleved@...> wrote:

        > My dev team has way too much support load. We currently
        > change
        > support rotation every week. That is -- one person
        > handles production
        > support for a whole week, then it is shifted to the next
        > developer.
        > Support calls can come any time of the day or night. And
        > there is an
        > expectation to answer all of these calls.
        >
        > I get annoyed with the support interuptions, because it
        > distracts my
        > current release work.
        >
        > I don't buy in the concept in any way shape or form, that
        > being
        > bombarded with support requests in the middle of the
        > developer bull
        > pen is some how supposed to make the product better.
        > Whoever came up
        > with this idea should be shot.
        >
        > There is a first level support group, but these are the
        > people who are
        > often coming to the on-call support person on my dev
        > team.
        >
        > Anyone know how to handle this problem? Is there a way
        > to get out of
        > this support load interuption trap?
        >
        > All people involved work for the same company in one
        > office. The
        > software is created, supported, and mainained by people
        > who work in
        > the same company in one office.
        >
        >




        ____________________________________________________________________________________
        Have a burning question?
        Go to www.Answers.yahoo.com and get answers from real people who know.
      • William Pietri
        ... I agree. On the one hand, I like to stay focused while working. On the other hand, feedback is one of the fundamental XP values, and support is where the
        Message 3 of 13 , Feb 1, 2007
        • 0 Attachment
          Brian Spears wrote:
          > At some point, customer issues that cannot be solved by
          > front line support end up handled by the development team.
          >

          I agree.

          On the one hand, I like to stay focused while working. On the other
          hand, feedback is one of the fundamental XP values, and support is where
          the user feedback comes in.

          I think rotating a developer can be a good way to handle that,
          especially if many of the support requests are urgent. If not, then
          perhaps a queue would help, so that the lucky developer can handle
          things in batches.

          Is the problem perhaps that the developer assigned to support doesn't
          have a sufficiently light workload to do it well? Maybe the problem
          isn't the sort of work, but that there's too much.

          William
        • Chris Wheeler
          ... If by bombarded you mean that the support calls are frequent, and if by support calls you mean that the software is buggy or unusable enough that it
          Message 4 of 13 , Feb 1, 2007
          • 0 Attachment
            >
            > I don't buy in the concept in any way shape or form, that being
            > bombarded with support requests in the middle of the developer bull
            > pen is some how supposed to make the product better. Whoever came up
            > with this idea should be shot.
            >
            > Anyone know how to handle this problem? Is there a way to get out of
            > this support load interuption trap?
            >



            If by 'bombarded' you mean that the support calls are frequent, and if by
            support calls you mean that the software is buggy or unusable enough that it
            causes frequent interruptions, then here's a thought:

            Stop building new software and fix the stuff that people are complaining
            about. That, or go out of business as people get frustrated with your
            product. BTW, I worked for a company like that, and they chose to go out of
            business.

            Chris.


            [Non-text portions of this message have been removed]
          • Steven Gordon
            What percentage of the support issues that reach your team a repeat of an issue that was previously seen and resolved? If the percentage is high, somebody from
            Message 5 of 13 , Feb 1, 2007
            • 0 Attachment
              What percentage of the support issues that reach your team a repeat of
              an issue that was previously seen and resolved?

              If the percentage is high, somebody from your team has to take the
              time to properly train the prior levels of support staff and/or
              create/improve the FAQ.

              If the percentage of repeat problems is low (and yet still
              overwhelming in numbers), then the quality or usability of the
              software is the problem. Continuing to just play wack-a-mole with
              these problems won't work for long. Unless your team figures out what
              the root cause of a steady stream of new problems is and fix it,
              support demands will eventually prevent any new features from being
              delivered.

              Steve

              On 2/1/07, eliga_repoleved <eliga_repoleved@...> wrote:
              >
              >
              >
              >
              >
              >
              > My dev team has way too much support load. We currently change
              > support rotation every week. That is -- one person handles production
              > support for a whole week, then it is shifted to the next developer.
              > Support calls can come any time of the day or night. And there is an
              > expectation to answer all of these calls.
              >
              > I get annoyed with the support interuptions, because it distracts my
              > current release work.
              >
              > I don't buy in the concept in any way shape or form, that being
              > bombarded with support requests in the middle of the developer bull
              > pen is some how supposed to make the product better. Whoever came up
              > with this idea should be shot.
              >
              > There is a first level support group, but these are the people who are
              > often coming to the on-call support person on my dev team.
              >
              > Anyone know how to handle this problem? Is there a way to get out of
              > this support load interuption trap?
              >
              > All people involved work for the same company in one office. The
              > software is created, supported, and mainained by people who work in
              > the same company in one office.
              >
            • Slava Imeshev
              ... I know what Eliga is talking about. There are really big names (you likely used them once or twice) that put burden of support on software engineers. It
              Message 6 of 13 , Feb 1, 2007
              • 0 Attachment
                ----- Original Message -----
                > > I don't buy in the concept in any way shape or form, that being
                > > bombarded with support requests in the middle of the developer bull
                > > pen is some how supposed to make the product better. Whoever came up
                > > with this idea should be shot.
                > >
                > > Anyone know how to handle this problem? Is there a way to get out of
                > > this support load interuption trap?
                > >
                >
                >
                >
                > If by 'bombarded' you mean that the support calls are frequent, and if by
                > support calls you mean that the software is buggy or unusable enough that it
                > causes frequent interruptions, then here's a thought:

                I know what Eliga is talking about. There are really big names (you likely
                used them once or twice) that put burden of support on software engineers.
                It really means *everything*: operations, customer calls, network problems,
                air conditioning, restrooms, e.t.c. It is worth mentioning that no one gets any
                training.

                An aquaintance of mine recently told me the story about how he had to deal
                with a failure of a cluster of ~200 nodes. And that was the first time he dealt
                with this kind of stuff.

                The official idea behind it is that if you are really into company's business,
                you have to know how to deal with any problem. My gut feeling tells me
                that this is dead wrong because it denies efficiency of specialization.

                > Stop building new software and fix the stuff that people are complaining
                > about. That, or go out of business as people get frustrated with your
                > product. BTW, I worked for a company like that, and they chose to go out of
                > business.

                Well, I think the original poster comes from a place that proves again that
                success of a technology company does not depend on quality of software
                but rather on marketing and sales.

                The only way to fix this is to move on.

                Just my 2c.

                Regards,

                Slava Imeshev
                www.viewtier.com
              • David Carlton
                ... I would probably get really annoyed by that, too. The one thing that comes to mind: you complain twice about the interruptions. Am I correct in assuming
                Message 7 of 13 , Feb 1, 2007
                • 0 Attachment
                  On Fri, 02 Feb 2007 03:15:35 -0000, "eliga_repoleved" <eliga_repoleved@...> said:

                  > My dev team has way too much support load. We currently change
                  > support rotation every week. That is -- one person handles production
                  > support for a whole week, then it is shifted to the next developer.
                  ...
                  > I get annoyed with the support interuptions, because it distracts my
                  > current release work.
                  ...
                  > Anyone know how to handle this problem? Is there a way to get out of
                  > this support load interuption trap?

                  I would probably get really annoyed by that, too. The one thing that
                  comes to mind: you complain twice about the interruptions. Am I
                  correct in assuming that, when not on the phone, the support person is
                  supposed to act like a normal developer?

                  If that's the case, can your team come up with things for the support
                  person to do that wouldn't suffer as much from interruptions? Treat
                  the support person's non-phone time as a sort of slack; that person
                  can read about interesting ideas, do cleanups of things that are
                  annoying you that can safely be done a bit at a time, investigate bugs
                  that you haven't gotten around to digging into, talk to the front-line
                  support and figure out how to help them become more effective, or
                  something.

                  Heck, giving the support person no other responsibilities at all
                  doesn't sound like a bad idea to me, as long as there are at least 5
                  or so people or your team. A bit of slack is good.

                  David Carlton
                  carlton@...
                • Laurent Bossavit
                  Eliga, ... You seem to be implying that whoever has the support role deals with every issue immediately, as it comes in. It may be the case that some issues
                  Message 8 of 13 , Feb 1, 2007
                  • 0 Attachment
                    Eliga,

                    > Anyone know how to handle this problem? Is there a way to get out of
                    > this support load interuption trap?

                    You seem to be implying that whoever has the "support" role deals
                    with every issue immediately, as it comes in.

                    It may be the case that some issues can afford to be deferred for a
                    while, as long as the person raising it gets a response within a
                    reasonable time. If instead of being constantly interrupted one can
                    defer work on issues and do that in "batch", maybe set aside one day
                    of the week to do that and only that, often that is more effective.
                    Instead of calling, have people submit issues asynchronously.

                    That's the reasoning behind "trouble ticketing" or "issue tracking"
                    systems; have you looked into using one of those ? (And when I say
                    system, I don't necessarily mean dedicated software; anything might
                    do from Post-It notes on a separate board, to a shared email inbox,
                    to a full featured issue tracker.)

                    Laurent Bossavit
                    laurent@...
                  • Chris Wheeler
                    ... Or demand of the market - my first job was like this one - the company was successful in spite of itself, and couldn t not be successful , financially.
                    Message 9 of 13 , Feb 2, 2007
                    • 0 Attachment
                      >
                      > Well, I think the original poster comes from a place that proves again
                      > that
                      > success of a technology company does not depend on quality of software
                      > but rather on marketing and sales.



                      Or demand of the market - my first job was like this one - the company was
                      successful in spite of itself, and couldn't 'not be successful',
                      financially. The attitude of those who were closest to the money was 'Why
                      bother changing when we are raking in the cash?'.

                      I left the company, that's how I changed it. I couldn't see a better
                      solution - it's very difficult to change a company that insists it needs no
                      changing. In those cases, I just change my own situation.

                      Chris.


                      [Non-text portions of this message have been removed]
                    • David Carlton
                      ... I don t buy that, at least not with that sort of delay. You ve inserted a large delay into the response, a delay that is pure waste from the bug filer s
                      Message 10 of 13 , Feb 2, 2007
                      • 0 Attachment
                        On Fri, 2 Feb 2007 08:03:30 +0100, Laurent Bossavit <laurent@...> said:
                        > Eliga,

                        >> Anyone know how to handle this problem? Is there a way to get out of
                        >> this support load interuption trap?

                        > You seem to be implying that whoever has the "support" role deals
                        > with every issue immediately, as it comes in.

                        > It may be the case that some issues can afford to be deferred for a
                        > while, as long as the person raising it gets a response within a
                        > reasonable time. If instead of being constantly interrupted one can
                        > defer work on issues and do that in "batch", maybe set aside one day
                        > of the week to do that and only that, often that is more effective.

                        I don't buy that, at least not with that sort of delay. You've
                        inserted a large delay into the response, a delay that is pure waste
                        from the bug filer's point of view.

                        I'm not saying that you should always drop everything and respond
                        immediately (though I think it's worth considering inserting enough
                        slack into your system to allow you to do just that), but we should
                        already be trying to break our work up into small, self-contained
                        chunks. Even ignoring the support load, I think it's always a good
                        idea to be able to come to a reasonable pause in your work within the
                        next couple of hours; if you can do that, why not do the support tasks
                        at the next pause?

                        (Assuming, of course, that they can wait that long; that may not be
                        possible.)

                        David Carlton
                        carlton@...
                      • Laurent Bossavit
                        David, I suggest thinking about how you read your mail.
                        Message 11 of 13 , Feb 2, 2007
                        • 0 Attachment
                          David,

                          I suggest thinking about how you read your mail.
                        • David Carlton
                          ... Right. When I m productive, I don t constantly read my e-mail. But I read it a lot more often than once a week. Which what I was trying to get at in my
                          Message 12 of 13 , Feb 2, 2007
                          • 0 Attachment
                            On Fri, 2 Feb 2007 21:47:20 +0100, Laurent Bossavit <laurent@...> said:

                            > David,
                            > I suggest thinking about how you read your mail.

                            Right. When I'm productive, I don't constantly read my e-mail. But I
                            read it a lot more often than once a week. Which what I was trying to
                            get at in my response: I agree that batching is frequently good, but I
                            also think that small batches are better than large batches.

                            If an important part of my job involved responding quickly to e-mail,
                            though, I would find a way to constantly read my e-mail, and structure
                            my other activities to accept that level of interruptions.

                            David Carlton
                            carlton@...
                          • Dave Churchville
                            I personally had this experience as a the manager of a team with lots of production support issues. We instituted a triage approach where emergencies that
                            Message 13 of 13 , Feb 2, 2007
                            • 0 Attachment
                              I personally had this experience as a the manager of a team with lots
                              of production support issues. We instituted a triage approach where
                              emergencies that were not stopping all work would be addressed in 24
                              hours, and important problems that impacted productivity were
                              addressed within a week. Only truly critical "stop the line" type
                              issues could cause immediate interruption of work.

                              This not only gave the team time to actually get something
                              accomplished other than fire-fighting, but it sometimes prevented
                              solving the wrong problem in the rush to turnaround a solution in a
                              few hours.

                              It also allowed time for more information to be received from the
                              customer, and for true root cause analysis. We started fixing the
                              right problems with a little more time to think, and the support
                              burden droppped dramatically over a few months.

                              --Dave

                              Dave Churchville
                              http://www.extremeplanner.com/blog


                              --- In extremeprogramming@yahoogroups.com, David Carlton <carlton@...>
                              wrote:
                              >
                              > On Fri, 2 Feb 2007 21:47:20 +0100, Laurent Bossavit <laurent@...> said:
                              >
                              > > David,
                              > > I suggest thinking about how you read your mail.
                              >
                              > Right. When I'm productive, I don't constantly read my e-mail. But I
                              > read it a lot more often than once a week. Which what I was trying to
                              > get at in my response: I agree that batching is frequently good, but I
                              > also think that small batches are better than large batches.
                              >
                              > If an important part of my job involved responding quickly to e-mail,
                              > though, I would find a way to constantly read my e-mail, and structure
                              > my other activities to accept that level of interruptions.
                              >
                              > David Carlton
                              > carlton@...
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.