Productivity - Pushing towards 3 (at max 4) completed requests followed by code commits in a span of 8 hour interval on novel support requests

Question

Situation

Right now, I am at a point of realization, that at my present position I am not completing requests with regular interval, have spaced out request completion. But to approach my true ability I want to try to in the course of a day, going for my first attempt, to push my ability to push out 3 moderate sized commits in a span of 1 workday (8 hours).

Scope

It is fair to mention that I work with vanilla PHP, MySQL and Oracle with no framework other than jQuery. And that at present I have taken ample research time, that I can hone in on.

Definition

One commit corresponds to an incoming support request received by email, some which are outstanding but not ready for commit. Right now I am including uncommitted finished support requests that will be pushed through first.

---

I am asking for feedback from the community here as to overall effectiveness of my process in a span of 2 hours maximum with the above information provided

---

Proposed 13 Step Solution (1 Hour 30 Minutes - Max 2 Hours)

Proposed Solution to enhance my productivity (check back immediately by email with manager or requester if I spend more than 10 minutes on a portion each step without comfortable progress)

Preparatory Work for process of steps I have identified, with bullet points specified at first

Identify 4 support requests in inbox and email back log to resolve, considering priority and time to completion. Check with Manager or requester throughout.

For each support request

Capture problem and verify understanding by email to requester (20 Minutes)

10 Minutes 0) Read the email one or two times and write in my own words the problem requested. Open web page of target request to verify problem encountered. Write down questions and clarification needed in step 1...

5 Minutes

1. Create bulleted points of the request to capture the scope of the the current problem (when I do this..this happens), along with the along with bulleted requirement points that I created (this should happen instead...)

5 Minutes

2. Once received, begin formulating a phrased bulleted requirements list break down each specific requirement and ask by requester if the phrased bulleted requirements capture the scope of the solution

3. Email requester with a brief email addressing 0), 1), 2) asking if I understand both problem and solution correctly and completely and wait for response and make necessary revisions before proceeding.

Test Case Formulation (10 minutes)

5 Minutes

4. Write test case list for proposed solution

5 Minutes

5. Test plan adhere to each test case (directly driven by requirements)

Formulate solution (20 minutes)

10 minutes 6) Write pseudocode and draw flow chart (half page, one page respectively)

10 minutes 7) Write out language specific (PHP primarily, and SQL) lines of code to match step 5

Implementation/Test and Validation (40 minutes)

30 Minutes

8. Perform code entry for list of bulleted feature requirements points and incrementally verify inserted code lines into proper code region with testing against test cases

10 minutes

9. Once all cases have passed required functionality... Validate by self the complete implemented solution against principal desired function to check if the understood and desired functionality was met

   Once validated, share workable solution with requester or manager independently validate that solution functions as intended

Revise solution (10 minutes)

10. If not, then get clarification and revise solution starting from step 6

Commit # (5 minutes)

11. If yes, then begin commit process to appropriate branches

Move to Next Support Request

12. Move to next support request

Total planned time for uniform task (1HR 45 MIN up to 2 HR)

Answer 1

Creating a standard timeframe for resolving issues seems like a good idea, until an issue doesn't fit well into the timeframe. It's been my experience that you cannot predict these sort of things. The only thing in your proposed workflow that seems risky is the amount of time you expect to spend.

Each work request, be it an enhancement or defect, will go through each step. The amount of time spent on each step, and on all steps in total, will depend on the scope and difficulty of the work request.

Before breaking your brain about this, find out if there is a Service Level Agreement that applies to this application, and use that as guidance. If no such agreement exists, then you get to define one if you want.

The real question is, are your users unhappy with the level of service they are getting?

If they are happy, then you can keep these steps and time frames private. There is nothing wrong with setting lofty goals and trying to reach them.

If users are not happy with the level of service, then reach out to your customers. Meet with them to see what their expectations are, and whether or not you can accommodate them. Instead of putting all of the burden on your shoulders, look at the wider process of bringing code to production. Slowdowns can happen outside of your control. You can only write code and click on buttons so fast. Identify the other road blocks to progress and work on solutions for those as well.

Answer 2

Your approach for processing support requests seems to be very structured (some would say rigid). It could be a good guidance, or at least a checklist for making sure that nothing was forgotten. But where do the hypothetic timing come from? Is this just a gut feeling? Did you just try your approach on some simple issues? So before setting any timing objective, start to gather data: collect the time spent on a representative set of support requests.

If you're adept of scientific management approach (which was proposed by Taylor in 1911, and which at its highest acceptance lead in IT to the waterfall approach - it is meanwhile known that it can work only in very rare and specific situations), you would then take the average of your measurements and set this as a goal. If someone would have the misfortune to get a real complex request and solve it successfully, you might then blame him/her for not respecting the SLA instead of congratulating for the goo work done. Is this where you're heading to?

With some more statistical insight, you will however discover that the average is meaningless: a small software bug is easily solved. But if it is an incident based on some specific input combined with some peak-time network conditions with complex calculations, it may take much longer to figure out! You may therefore categorize your request by complexity level (low, medium and high), set a different hypothetical timing for each category and no timing for high complexity (if you are preparing an SLA contractual relationship, you should then foresee the need to provide evidence of the high complexity).

Finally, do not micromanage. Define timing only for the larger blocks to neutralize the fluctuations of each detailed task. Don't forget that resolution may as well require iterative steps (the more complex, the more iteration).