Impressioning - Let's talk about rake keys. These are also called gypsy keys. You take a key blank and file it down. In essence you use the key like a pick. There is a la...
Turns out my normal backup was also out of the office. That's okay. I trained the new guy on this system. Unfortuantely he told the managers that he knew nothing about the operations. Fail. I guess I trained him up but he did not use that knowledge. So he forgot it all.
Today I was scheduled to give a one hour session on the system. I did so. Took around 30 minutes to give a high level overview plus a hands on demonstration on how all the pieces get run. Then a manager asked me to prep the audience to respond to problems. Another manager asked that I give them the steps to "reset the data".
Unfortunately the only way to get familiar with the system is to get your hands dirty. You got to resolve a bunch of trouble tickets. Only then will you get the chance to dig deep and understand what the heck is going on. That's how I learned. That's how my backup learned. And that's how everyone else is going to need to learn. Sorry. Once again there is no silver bullet here.
Sometimes I am able to detect some requirements that are not necessarily new. They are just newly documented. It is a problem that they are just lumped together with the new requirements. But that is a story for another post. There were there requirements at the end of my mapping which seemed strange to me. They did not seem to be related to the new functionality. They also did not seem to be things the system already did.
I decided to get in touch with our requirements lead. Apparently these were requirements previously collected but never implemented. They need to be completed along with all the changes I am working on. That is a bit tricky. They should not be mapped to the new design I produced. They need to go with a future design that was yet to be written. Tricky.
The little time we actually spend on the new features causes the schedule to drag on. Our team decided to record the time we spend on tasks during the day. Iteration one is using Excel spreadsheets to track everything. Hey. I am game for anything that tracks actuals.
Initially the team wanted me to record start and stop times for tasks. Dude. I work on all kinds of tasks and get interrupted from each all the time. There is no time (no pun intended) to record all those starts and stops. The goal here is to collect duration of tasks. Therefore I am only record the daily duration on every task I do.
The team lead thought we should record down to the 15 minute increment. Nope. Thirty minutes is the least I can do. Otherwise I am going to be wasting more time recording the stuff. Pretty soon I hope we can use a tool to collect this data. But spreadsheets are good enough for right now. I find that I am even more diligent in recording everything I do, including all the interruptions.
This is the trick for collecting metrics. You don't want the job of collecting the metrics to take up a lot of time. You also want it to be accurate. I remember when I used to track the time we spent fixing each bug. I had to collect all the info. Then I would put out reports on the subject. I did this until I was able to convince my boss that it was not time well spent.
I had thought that the goal for this new metrics collection would be to fine tune our estimation process. That way we can have more accurate projections on how long new work will take. My manager said he thinks this will help us report status on the new work as well. Let's just hope I don't have to start spending my life collecting metrics from the team.
Other people lean on me for help. Hey. That's usually not a problem. I can give some good developers a few pointers. It will help them cut through a lot of confusion to get their work done.
However there is some abuse of my help. Slackers want me to hold their hand while they do their work. That might benefit them. But I got my own job to do. Can't let people waste my time. Not sure how to communicate this to the slackers. Maybe I will just not take their calls.
Then we get experts to think about a type of design in their mind. Once such a design has some meat, we will try to count up all the parts it will take to implement that design. This includes different GUI screens, interfaces, database code, and so on.
Once we know the pieces of the implementation, we decide to quantify them and rank them as being easy/medium/hard. Then we plug in how experenced the resources are that will implement the solution. This all goes into an Excel spreadsheet that has some smarts built into it. The result is a number of hours it will take for software completion.
Wouldn't it be easier if we did not have to rely on the experts to do all this analysis? I would like to send a business developer out to the customer, and have them be able to quickly estimate what the work is going to cost. We need something like Software Schedule Estimator for this job.