When you consider the software team, you would have a development team, a testing team, designers (including the user interface designer) and also the management team (and one could include the product managers or the product management team in the set of managers). When you consider these set of people, they have a lot of knowledge about the product and the features in the product, especially the people who are working on specific features. There are a few other people who have the same amount of knowledge on specific features. Given their level of knowledge, they take this level of knowledge as granted when they have a discussion with other people who are not on the team, and it can be difficult for them to realize that other teams do not have the same kind of knowledge that comes from working on the same product for a long period of time.
Any product team will need to work with other teams that provide services such as translating the software into other languages, do the documentation for the software and other related services that the product team will not do. The problem with this concept is that people working in these teams do not have the same kind of knowledge of the product that the product team has, and this can be a source of friction in their interactions. In some of these cases, the software team would do the right thing, find out the level of knowledge of these external teams and prepare time to ensure that these teams get a ramp up of the software program. But, even in these cases, it is a fair approximation that they will never reach the same amount of knowledge as the product team, and expecting such a level is what leads to frustration.
In my experience, the frustration comes when the product teams work with external teams that have little or no experience with the product (and this can happen often enough when dealing with external teams, since these teams typically cannot afford to have dedicated people for handling products, and their attrition rate may be different from that of the product team). So, the product team has some amount of knowledge transfer with the external teams, and assumes that there will be some questions that would come from the other teams. However, it may turn out that it takes time for these new people to understand the product, and the queries only come later in the timeline, and this is unexpected for the product team.
The way to handle this is to have a line of managers who understand that new people take time to understand the functionality of the product, and these people will never get the time that people in the product team have. So, there are 2 processes on how to handle this - prepare an effective training program that provides as much information as possible without over-doing it, and equally, learn from the teams that have gone through such an experience and learn what steps can ensure that the external teams learn faster, and what are some of the common problems and frustrations that can crop up in such a relationship.
No comments:
Post a Comment