I work in an organization that is fairly large, being a $500 million organization, having a number of products being worked upon by different product teams. As a part of this process, there are also many common components that are made by a few central teams, which provide functionality common to most of the products. For example, when you consider that functionality such as reading and writing to optical media, being able to open and write to video files, etc are common functionality, it makes a lot of logical sense to ensure that these functionality are done by a common team and then other teams pick it up. It is not such a open and dried system though, there are elements of complexity in these systems though:
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.
As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.
As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.
No comments:
Post a Comment