For software products that have had multiple releases over the years, there is a ticklish question about the resources that need to be dedicated for previous released product versions. This is even more critical for software products that have wide usage such as Microsoft Office, Photoshop, and Acrobat. Organizations have stated policies about providing support for previous versions, but there is a cost associated with doing the same. You need to have people who can do defect resolution and testing, you need people who can do all the entire build infrastructure including releasing the software fix. This can add upto a pretty packet in terms of resources, and this can be painful especially when there are time periods when there are no major fixes that are due.
Deployment in these previous support teams can also lead to tricky morale issues, given that people assigned to these teams would feel that they are put onto a team that is less important than those who are part of the team working on the current features. To avoid such morale issues, team can rotate people across these teams, but that comes with its own problems about people not being able to develop the expertise, something that comes only after gaining experience on the team.
A problem with not having these previous support teams - for some organizations and products, such an option is not possible; a full fledged support team is required. Consider somebody using a previous version of MS Office or Adobe Acrobat, and suddenly, there is news from a computer security researcher about a critical zero day or similar intensity defect in the product which could allow a hacker to get into the hole. These events can be a public relations disaster - such blowback cannot be countered just by Public Relations, but there is a need to have a team that can work on a full scale quick research and fix, such that the organization develops a reputation for responding quickly. And it's just not a fix in a previous version, but the same problem may be there in the ongoing version that is being developed and the team needs to get the research done by the previous version team and incorporate the fix in the version under development.
A lot of teams I know slightly under-budget a team for working on previous version defects, and if the problem requires a slightly enhanced amount of effort, then additional people are deployed for working on the defect fix, and are only there on a temporary basis (even though it might have some amount of impact for the current cycle, but there is no real solution for the same). People assigned to such teams are typically team members who are not very high in ambition, and are not necessarily the high rated people in the team. Further, the Product Management teams need to be involved in both sides, since many of the feedback in terms of defects or suggestions are actually coming from customers or end users and there is a possibility that some of them may have value for the next version to be released.
Deployment in these previous support teams can also lead to tricky morale issues, given that people assigned to these teams would feel that they are put onto a team that is less important than those who are part of the team working on the current features. To avoid such morale issues, team can rotate people across these teams, but that comes with its own problems about people not being able to develop the expertise, something that comes only after gaining experience on the team.
A problem with not having these previous support teams - for some organizations and products, such an option is not possible; a full fledged support team is required. Consider somebody using a previous version of MS Office or Adobe Acrobat, and suddenly, there is news from a computer security researcher about a critical zero day or similar intensity defect in the product which could allow a hacker to get into the hole. These events can be a public relations disaster - such blowback cannot be countered just by Public Relations, but there is a need to have a team that can work on a full scale quick research and fix, such that the organization develops a reputation for responding quickly. And it's just not a fix in a previous version, but the same problem may be there in the ongoing version that is being developed and the team needs to get the research done by the previous version team and incorporate the fix in the version under development.
A lot of teams I know slightly under-budget a team for working on previous version defects, and if the problem requires a slightly enhanced amount of effort, then additional people are deployed for working on the defect fix, and are only there on a temporary basis (even though it might have some amount of impact for the current cycle, but there is no real solution for the same). People assigned to such teams are typically team members who are not very high in ambition, and are not necessarily the high rated people in the team. Further, the Product Management teams need to be involved in both sides, since many of the feedback in terms of defects or suggestions are actually coming from customers or end users and there is a possibility that some of them may have value for the next version to be released.
No comments:
Post a Comment