To content | To menu | To search
Thursday 18 August 2011
By Jan Verlaan on Thursday 18 August 2011, 10:59 - Maintenance Policies
When you want to have more insight in the bug solving process you should register hours spend directly on reported defects
Such hour registration gives you insight the usage of time for:
By Jan Verlaan on Thursday 18 August 2011, 10:56 - Maintenance Policies
When Maintenance is not part of Development the transfer of a released product need to be arranged well.
The following need to be arranged and is the responsibility of Development:When a product transfer is not done properly Support and Maintenance will not be able to provide the correct service levels to the customers. Money is lost. Development is responsible for this loss when one of the above points is not arranged well.
Tuesday 16 August 2011
By Jan Verlaan on Tuesday 16 August 2011, 13:12 - Maintenance Policies
A customer only wants you to build his requested functional fchanges and not those of other customers. A functional change, especially an unexpected one, could severely upset the customer system or his systematics.
You have to decide how you will coop with such requests. Keep in mind that there will always be a big grey area. An area under the influences of threats of contracts breaches or lawsuits.By Esther Verlaan on Tuesday 16 August 2011, 13:09 - Maintenance Policies
All changes done in the source need to be marked. Marking makes it possible to trace changes and to collect all parts of a solution and provide it to the customer.
A solution could cover several sources. When a solution turns out to be a bad fix all adjustments of the solution need to be found. To be able to do that, all changed need to be marked with the solution number.
The solution number makes it possible to discuss the error with the Customer and the Support Analyst. You are sure you are all talking about the same problem and thus about same source(s).
Solutions that turned out to be Bad fixes must get an indication so Customers are aware of it. When a new solution fixes the bad fix, a reference to the new solution must be given on the old solution so customer can download it. All this must be visible for Customers when they look at solutions in their self-service solution database.
By Esther Verlaan on Tuesday 16 August 2011, 13:06 - Maintenance Policies
Sources programmed clear, concise and readable require less maintenance time than those who are complex, large, and non-readable.
You require directives on the way sources are written. This starts all ready in Development. Make sure Development provides proper code that is easy to maintain. Depending on the language used directives should be given. The re-use of functionality (functions, dll's, etc) is one of the most important points next to a readable source.By Jan Verlaan on Tuesday 16 August 2011, 12:10 - Maintenance Policies
When you receive support issues that turn out to be defects you could decide to only solve it at the customer site. It is cheap for the short term. What happens when the customer upgrades to a newer version or service pack depends on your amount of pro-active maintenance!
When there is no pro-active maintenance in place the customer will run in to the same error again after upgrade. That will definitely harm your customer's level of satisfaction.Pro-active maintenance is wise when you have several (newer) versions of the product. Know errors will not return and your product will improve.
Monday 15 August 2011
By Jan Verlaan on Monday 15 August 2011, 16:27 - Maintenance Policies
Each product has a Product Life cycle. You have to inform your customers upfront about the Product Lifecycle of your product. How long will the product be supported by your organization is important to know for customers.
Lifecycle times depend on: