Development Support Issue

Owned by gagnier
Last updated: Jun 20, 2022
4 min read

Development support issues arise when clients identify an issue with myTC account portal, API within a development environment. Since these issues are not immediately service affecting they are triaged assigned priority in the development backlog.

Examples of Support Issues

Who was it for?

  • Monitor report issue (FTAE business client reported the issue to me.)

What was the nature of the request?

  • Production issue. The pdf attachment in the email notification (flight test) that was sent to the submitter today was missing.

How long did it take you to complete?

  • It took two hours to look though the error logs and check the database status.

Was it urgent

  • I am not sure about the definition of "urgent".

What did you deliver as a solution?

  • I explained to the business client the possible cause of the issue and current status. One of the legacy system's databases was down at that time and it was failing to generate a pdf. It is supposed to be fine now.

An MTA user is having difficulty logging into GCKey/MTA/a service

Typical questions include:

·        Why am I getting this error message?

Typical workflow for me:

·        Review user account in database if possible

·        Consult with Remi on the state of the users' account

·        Attempt to reset or fix the user account and repeat as required

Scenario

<Client>

Client accesses the MyTC webportal [does not exist] and locates the “Submit Request” link.  Client clicks the link.  MS Form is launched that prompts the client with a series of questions regarding their request.  The client indicates the request is for a support issue they are having with a development environment. The client completes the details of what is required within the form and submits the form [A Request is Generated in DevOPs].

<Client>

Receives confirmation of request via email that includes the DevOps ticket #

<Holly>

Receives email indicating a new request has been received that includes the DevOps ticket #

Holly clicks on the ticket # link within the email to open the DevOps Ticket.  Holly can see who created the request and the pertinent details. It is obvious from the request type that this is a development support issue being requested.

Holly moves the state of the request from “New” to “In Planning” and Holly creates a discussion comment and includes @client email and indicates – “we will triage this request and reach out as soon as we have an assessment”. Holly saves the request update.

<Client>

Receives an email that Holly and team will triage the request. (Includes a link to the request)

 <Holly>

Creates a message thread in myTC Account Teams Support group. “Can someone please have a look at the following ticket # XXXXXX and let me know what we should do with this one. Thanks Holly”

<myTC Account Staff>

Receives a message in myTC Account Teams Support Channel regarding a support ticket.  Each staff should open and read the ticket so they are aware of the issue. Any staff that can respond  on what to do about the issue should do so.  The triage discussion should try to decide what to do with the request <Not our Problem> <Bug or Feature Request> <Proceed>

<myTC Scrum Master>

Respond to Holly that this is not our issue and provides details about who the client should connect with regarding the resolving this issue.

<Holly>

Changes the status of the request to “Done” and creates a discussion comment and includes @client email and indicates – “This request is not related to myTC Account and may require assistance or intervention from another team:  Details provided…”. Holly saves the request update.

<Client>

Receives an email that the request is done.

</Not our problem>

<myTC Scrum Master>

Respond to Holly that this is most likely a bug or feature request and that a triage session will be required.  (follow the service blueprints for either of those request types)

<Holly>

Updates the discussion comments and includes @client email and indicates – “This request relates to a feature request or Bug.” Holly saves the request update.

<Client>

Receives an email that the request has been updated.

</Bug or Feature Request>

<Proceed>

<myTC Account Scrum Master>

Creates an initial PBI/Tasks in the DevOPs development backlog and creates a discussion comment and includes @Holly email and indicate – “This dev support issue will proceed”. Scrum Master saves the request update.

Is there enough urgency to inject this issue directly into the sprint? <Urgent><Handle during the Sprint>

<myTC Account Scrum Master>

Who is the “right” person to take on this issue?  Assign the PBI/Task to the appropriate myTC Dev Staff.

<myTC Account Dev Staff>

Receives an email that a PBI/Task has been assigned to them.

<myTC Account Dev Staff>

Completes the PBI/Task work and corresponds with the client directly (if required). Closes the PBI/Task when the work is completed and includes @Holly @myTC Account Scrum Master in the comments so that Holly is informed that the task is “done”.

<Holly>

Receives the email that the PBI/Task has been completed.  Holly marks the Request as “Done” and include a message @client “ The request is considered completed at this time”

<Client>

Receives the email that request has been completed.

<myTC Account Scrum Master>

Receives the email that the PBI/Task has been completed. 

</Urgent>

</Proceed>