| || |
Oops. Corrected the last paragraph.
Well, I'm finally in a startup company as the Director of QA reporting to a VP of Technology and Operations that is experienced, professional and understands the importance of a defined software/hardware development process. The challenge I'm facing now though is that he doesn't seem to be very motivated. He understands the importance of defining and communicating the process throughout a company. Making sure everyone understands what their role is in the development of products at the company. But I think it's been attempted several times and the implementation never stuck. I don't know why it didn't stick, but I do work for a media company. That means half of the company are creative artistic types who don't have much knowledge of process. The other half are technology and marketing types who do. The two groups clash. It's believers in chaos versus the believers in organized process. Seems that never the two shall meet. I saw this when I worked at my last two dot coms as well. Same two groups.
My VP says he's not the best man to lead the charge. I think he gets irritable quickly when people don't understand the importance defining the requirements up front during the design process. I understand his frustration. The CEO at a major dot com I worked at said that he didn't believe in requirements. He said, "They will always change. It's a waste of time to concentrate on creating a Marketing Requirements Document." Needless to say, most of the projects there were not released on schedule and never properly met our customers needs.
My VP is pointing his finger towards me as the person to lead the charge to implement a product development process. At least at my level of management. He says that he's confident that he can get full support from our CEO and COO. That makes me feel much better about being involved.
Just curious if any other QA professionals out there have been involved in the successful definition and implementation of a product development process while working in a startup company. One of the things I've learned over my 16 years in QA, is that you get a group of key managers involved in defining a product development process. You do not define your own process and try to get the rest of the managers to follow it.
I would love to hear your war stories. What worked and what didn't work.
We have similar positions, time in the industry, and background. I feel the pain also. Your last comment about having the development managers define the process is the one that I have used over and over and seems to work the best. As a QA director, I've always positioned myself as the champion of quality and not the owner. Everyone is responsible for making a quality product.
As you know, putting up process that no one agrees with won't work. IMHO, a QA organization should support the development infrastructure with tools, pubs, testing, CM, and tech support.
In the past when my team didn't receive proper specs or requirements, I would write them myself and then pass them back to development and marketing. Needless to say, they never agreed with it but they would redline the docs and I would have something to validate against. You can't make this a habit though.
One good method I used is to document the lifecycle, put it up on a wall that everyone can see daily and then grey out the documents as they are complete on the chart. It will be obvious to everyone what documents aren't finished or are late.
Even if you have exec staff "backing" doesn't mean taht you'll have their support as you most likely know.
I am having similar problems in my current startup. A team of Unix developers don't want to document anything until the product is finished because they say the document will change. Myself and my tech pubs person attend every meeting they have to document things. I let their manager know that I have to take my tech pubs person to do their work not allowing for the customer docs to complete. He finally put the pressure on his people to sit down and document what they're doing.
It's a thankless job and sometimes you have to be a jerk. I try to be a pleasant jerk when I have to. :-)