First, a side note: There was massive snowfall yesterday and this morning. The drive to the central office of my new employer is about 40 miles from home. It was orientation, so I felt it important to go anyway. This was a mistake. I came very close to destroying my car and possibly myself via collision with snowplows, and only a well-timed swerve when braking proved impossible kept me from being a snowplow sandwich. It is NOT worth braving dangerous driving weather, even for a very important work meeting.
That said, I did go to the new job, and I did get some orientation. I took notes. Lots of notes.
I got to meet the CEO face to face. He’s a younger guy, five or so years younger than I am, but very ambitious and very likeable. He also doesn’t try to hide it when things aren’t being done as well as they could, and he listens to criticism.
I got to meet a couple other new hires. One’s in IT and seems to be a likely ally, which I will need, as the laptop they assigned me is locked down and I can’t install my own software on it without IT administrator access. This is not an acceptable situation to any self-respecting developer. The new IT person, whom I’ll call 80’s Hair, understood and appreciated this.
The other new hire is the BA-slash-PM-slash-QA expert. She’s going to be wearing three hats, which I suppose is tenable for now, but that role needs to be broken apart. She and I are working on building a good rapport, as we’ll be working closely together in the months to come.
It was also “monthly meeting” day, which meant a group lunch. This was a chili cookoff. And me without my special homemade chili. (I’m quite a foodie, I admit.) But the chili I sampled was plenty tasty and I had time to get to meet more of the people in the main office.
But the big thing today was what we term ‘drinking from the fire hose.’ The concept is being flooded with more information than I can possibly absorb at once, and all I can do is try to take in all I can.
This particular firehose was learning about business processes, specifically order fulfillment and customer service. The former is the basic result of the e-commerce sites which I’ll be responsible for; the latter is the basic conduit of feedback from the customers. The OF guy spent about 90 minutes illustrating his process to us. He showed us how it began with the output from the existing e-commerce site, printing out packing slips, distributing them into bins, filling the bins from inventory, bringing them to the packing area, and packing the orders in bubble envelopes or boxes, labeling them and marking them in the e-commerce site as shipped. I learned about the basic pain points, the basic points of failure, how those points are caught, and the time invested in the process of catching them.
On the other end, the customer service manager and workers had much input from their customers, and that information doesn’t seem to have a distinct process for getting back to development to be incorporated into future development requirements. Both the new BA and I are keenly interested in remedying that situation.
After that, I was exhausted and packed up my new work-assigned laptop for home on the (now much better plowed) long road. I was requested by the CTO to call him to go over some stuff. So, I did. I was tired, but CTO and I talked and planned out the next couple weeks. I also confirmed with him what earlier conversations with the CEO and document review made me suspect: The nearly-complete current development of the core website was done without a clear requirements document — which made its development go badly up until now. CTO’s high priority for when he is in town the next two weeks, and therefore my high priority for the next two weeks, is to define those requirements tightly. Once that’s done, BA can develop a test plan, and I can evaluate the current state of the project against those requirements, and identify the difference between the two. From there I can plan out development and estimate a time to completion — and then release.
Once that’s done then CTO and I can ensure that all future development will be done against a clear set of requirements, and a business owner of those requirements.
TL’s First Rule Of Development: Without clearly defined and accepted requirements, there is no effective way to know when development is complete, nor even to know what exactly needs to be developed.
Sure with vague requirements like “Make it work like that thing worked” you can get a decent idea of what you’re trying to develop, but it’ll never be clear, and whoever the business owner is will be able to push scope creep into your process with nigh-impunity — other than crashing your sprints and breaking your deadline commitments.