When you release any software product, there will always be problems. Further, there will be information that will need to be passed onto the customer that can be important, such as the level of Operating System support. Hence information needs to be passed onto the customer, early, either before the actual installation, or when the customer wants to read information about the product on the site of the product:
- There will be some defects or problems in workflow that came too late to be fixed.
- There will be defects or problems that the team decided were not worth fixing and could be passed onto the customer.
- The operating systems that are supported by the application (including the service pack numbers)
- Workarounds for some common issues that could be facing the customer, which could be a description of the problem being faced, the workaround that the customer can use (such as some tweaking of files on the product end, or some patch on the site of the product that could be downloaded by the customer and fix the problem).
- Information about some third party applications used inside the product, including links to their support pages and the like.
These are important information. At times, the development team may feel that a problem that is specific to a particular component or a version of an operating system may not be important, but for the customer who is suffering from such an issue, it is important. And it is important that the team should strive to provide this information to the customer in an easy way, typically providing this information in the form of a Readme document.
However, there is some debate about when the Readme should be prepared. Since the Readme is also supposed to also capture details of issues that were not fixed late into the cycle, the Readme should be made ready as late as possible. But for products that are available in multiple languages, there is the need to have this document translated into all the languages, and in the full form. Hence, there is a limitation of scheduling to determine when the document should be prepared.
We finally made a determination where we tried to figure out when we can prepare the Readme document, and worked backwards. We worked with the team that did the localization of the Readme and tried to figure out the latest by which the document could be localized. Based on that date and some discussions, we finalized a date to that effect, and that was the date which was the final date for the English language version of the Readme document, and then added in some more days for the preparation of the Readme (which included the time taken for collection of all the data and information required for the Readme document to be prepared). This ensured that all late breaking information was captured and yet there was enough time to prepare a Readme document to be included with the installer, and also be available on the site of the product.
- There will be some defects or problems in workflow that came too late to be fixed.
- There will be defects or problems that the team decided were not worth fixing and could be passed onto the customer.
- The operating systems that are supported by the application (including the service pack numbers)
- Workarounds for some common issues that could be facing the customer, which could be a description of the problem being faced, the workaround that the customer can use (such as some tweaking of files on the product end, or some patch on the site of the product that could be downloaded by the customer and fix the problem).
- Information about some third party applications used inside the product, including links to their support pages and the like.
These are important information. At times, the development team may feel that a problem that is specific to a particular component or a version of an operating system may not be important, but for the customer who is suffering from such an issue, it is important. And it is important that the team should strive to provide this information to the customer in an easy way, typically providing this information in the form of a Readme document.
However, there is some debate about when the Readme should be prepared. Since the Readme is also supposed to also capture details of issues that were not fixed late into the cycle, the Readme should be made ready as late as possible. But for products that are available in multiple languages, there is the need to have this document translated into all the languages, and in the full form. Hence, there is a limitation of scheduling to determine when the document should be prepared.
We finally made a determination where we tried to figure out when we can prepare the Readme document, and worked backwards. We worked with the team that did the localization of the Readme and tried to figure out the latest by which the document could be localized. Based on that date and some discussions, we finalized a date to that effect, and that was the date which was the final date for the English language version of the Readme document, and then added in some more days for the preparation of the Readme (which included the time taken for collection of all the data and information required for the Readme document to be prepared). This ensured that all late breaking information was captured and yet there was enough time to prepare a Readme document to be included with the installer, and also be available on the site of the product.
No comments:
Post a Comment