Request for Change: Unterschied zwischen den Versionen

Version vom 9. Oktober 2014, 06:11 Uhr

Why this?

Customers ask for features regularly. In the longer past some things were installed where they were needed. Then we changed to a policy wich aimed to keep all the servers set up the same way. Denial of requests happened more often. But the side effect was, that the same questions were investigated and decided multiple times, as we lost track of the requests. So we will protocol them here from now on.

With the information gathered we can now see

• what clients want
• popularity of a request
• why the clients need it
• which information was available at the time of the decision
• why the decision was taken like this

PHP

SSH2

1. Link: ssh2
2. Decision:
   • Result: will not be installed
   • By: hja
   • When: 23.09.2014
   • Reason: security concerns (opening possible abusive ssh connections to other machines)
3. Workaround: phpseclib

Frameworks

node.js

1. Link: node.js
2. Decision:
   • Result: not possible
   • By: jre
   • When: 08.10.2014
   • Reason: needs ssh access to the web account
3. Workaround: -

Phalcon

1. Link: PHP Framework
2. Decision:
   • Result: will not be installed
   • By: hja
   • When: 07.10.2014
   • Reason: The efforts to install are far to high for a single client (setup, compilation, etc.). It is of no use for other clients, as it needs an own language
3. Workaround:

How it works

A new request

You have an incoming request that needs to be judged, copy both parts of the template source. Fill in the headline(s) and the link in the first part of the template. If the scope (i.e. "PHP") is already listet, skip it. Then fill a table row with date, reason and contact address of the client.

Now inform the one that should decide about this entry.

First decision

The decision taker will fill in the decision part of the entry and inform you that it's done.

Workaround

Find a workaround if possible and not given yet by the decision taker and leave it there.

Client information

Time to tell the client what the decision is and why it was taken like this. If you get feedback, add it to the table row of your client.

It is asked again

(So it must have been denied or postponed until now.)

Add an additional line to the table like before with your clients reasons to have it. Inform your client about what was decided in the past. And note his feedback as soon as it arrives.

Escalate it again

You may escalate the request again, if you feel that:

• your new reason has changed the importance of the request (i.e. postfinance requires it to continue my payment processing module!)
• there are more than 5 times the same reason given in a short period of time (ie. 1 request/month)
• the reasons of denial or postponing are not valid anymore

Entry Template

==Scope/Environment/Parent==
===Module Name===
# '''Link:''' [http://google.com provide a link]
# '''Decision:''' 
#* '''Result:''' 
#* '''By:''' 
#* '''When:''' 
#* '''Reason:'''
# '''Workaround:''' 

{| class="wikitable"
|-
! Request Date
! Customer Email
! Motivation (why needed?)
! Customer Feedback
|-
| 
| [mailto:abc@def.xyz Customer Name]
| 
| 
|}