| || |
Department Performance forum
My department is not likely to add more Performance engineers in the next year or so, but I do feel that being the sole Peformance engineer, it's hard for me to do my job (designing and running tests) and share my knowledge with other teams in the department I work for. The thing is, I wish I could share the knowledge, as these teams run their own Performance tests, and are rather clueless about it, at least in my POV.
I was thinking about setting this Performance Forums, a gathering of QA personnel from several teams, meeting on a weekly basis in order to discuss Performance issues. This way, Performance methodology in the department is increased, I get to share my knowledge and everyone is happy.
What do you think of the idea? Does anyone has any experience with similar concept? What would this Forums's responsibilities be, if any? What should it discuss? Should R&D personnel be involved, or should we just leave it QA?
[ 09-26-2004, 01:43 AM: Message edited by: olapidot ]
Re: Department Performance forum
I think its a great idea. I would aim for as wide a cross-section of representation from different groups as you can get - with the objective of increasing the understanding of performance issues as early in the product life cycle as possible.
In a slightly different context I was one of the people instrumental in getting a similar sort of performance forum established on a very large, multi-vendor project a few years ago. Whilst it sounds as if you are talking about a forum involving different groups inside your organisation, I think many of the issues and benefits will be similar.
In our case, the project in question was under serious threat of failure at the time, due to major performance issues, and a culture of finger-pointing was developing amongst the various vendor teams involved (s/w development, facilities management, database, network operations, LAN).
We established a cross-vendor forum and worked hard on creating a "no-blame" culture - the objective was to work together to find and fix the issues - no hiding behind contractual responsibilities. We made a point of holding the forum on "neutral ground" to reinforce that culture (and supplying good coffee and biscuits to help entice people along to the meetings!).
Three or four years on, many of the original group (myself included) are no longer involved in the project but the forum still exists - though having sorted most of the performance issues its brief has grown somewhat to encompass other technical issues.
There were several key things that we got out of it, notably:
* Looking at the big picture, with input from all parties at the same time, we managed to focus on the problems themselves - rather than the previous "silo" approach where each party's objective seemed to be to prove that it wasn't their fault.
* People came to understand what other parties' roles involved (and that maybe other peoples' jobs were difficult too). There was much better consultation and cooperation between the parties as a result.
Getting the right people involved is key. Architectural understanding is important. I'd also choose people who are keen to contribute and learn rather than people who are there because they've been told to be.