Category:

Positive Statements:

Negative Statements:

  .   .   .

  .   .   .

  .   .   .

Product Vision:

General:

·   High level vision now in place which defines which markets will be addressed and by which products

·   Marketing, Product Management, Engineering, Support working more closely together to create this vision than ever before

Specific:

Ø  “ I now know how products we develop will fit in with the high level vision of the company, and this is satisfying and motivating to me.”

General:

·   The high level vision is at a very high level, and doesn’t really clarify what this means to engineering

·   The product vision is being presented as if from on high

·   Issues and concerns regarding the product vision are not really being addressed

Specific:

Ø  “What does this product vision mean to me?  How do I change my job or do my job better given this vision?”

Ø “I have specific concerns regarding the product vision, but when I try to raise them, I feel like I’m talking to a wall.”

Product Roadmap:

General:

·   A significant effort went into preparing the product roadmap, and, while it took longer than anticipated to put it together, it has been presented to engineering and was generally well received.

·   Specifics on product direction, features, and timeframes were put in place, and people were being informed on their specific roles in implementing the roadmap.

Specific:

Ø  “It was really good to see a well thought-out product roadmap which specifically stated what we would be doing, when, and how I fit into that plan.”

Ø “I really feel that management is now working better together and answering questions that many people have on how to make the company succeed.”

General:

·   While a roadmap was ultimately defined, it took a very long time, and happened only after repeated demands were made on management to deliver it.  Subsequently, the roadmap was ignored and seldom referred to.

·   Specifics were far better than they were in the past, but since the roadmap basically disappeared shortly after being released, many people remain very confused over their role in making this happen.

Specific:

Ø  “It was about time we saw a roadmap!  We’d been asking for this for a long, long time.  However, shortly after it was released and communicated, all reference to it disappeared, and now it’s as if it was never even developed.  What a joke!”

Ø It was nice to see the product roadmap, but my manager won’t even discuss it now, much less let me know how my work relates to it.  If anything, the frustration now is worse than it was before we had a roadmap.”

  .   .   .

  .   .   .

  .   .   .

Resource Allocation:

General:

·   As cutbacks have occurred, attempts have been made to re-allocate resources accordingly

Specific:

Ø “People are re-assigned as others are laid off.  This enables them to concentrate on specific activities rather than overly broad assignments.”

General:

·   Continuing cutbacks and layoffs, quarter after quarter, are severely impacting the ability for engineering to carry out effective development.

Specific:

Ø “We’ve had so many layoffs and cutbacks that we don’t really know what we’re doing right now.  We’ve cut way past the muscle and deeply into the bone.  It’s questionable to me at this point how the company expects us to deliver product according to our ‘roadmap’ or ‘vision’.  We simply don’t have the resources to do the job.”

Ø “If you’re going to cut people, then you have to cut what will be developed.  We’re cutting people, but trying to continue to do everything.  It simply won’t work.”

Organizational Effectiveness:

General:

·   Specific people have good understanding of their roles

·   Some teams are working together effectively

·   Managers are meeting more frequently with their people, and are making honest attempts to address concerns

Specific:

Ø “I know my job, and I concentrate on just doing it.”

Ø “The folks in my group work well together, and we’re honestly trying to work well with other groups.”

General:

·   Morale is generally poor

·   Teamwork is suffering as key team members get laid off

·   Many groups are at each others’ throats rather than cooperating

Specific:

Ø “Morale sucks!  Every quarter more good people are let go.”

Ø “It’s now everyone for themselves; the hell with the team.”

Ø “I will keep working here until I can find a real job elsewhere.”

Ø “Unless and until sales people start to sell, the company is doomed.”

  .   .   .

  .   .   .

  .   .   .

Development Methodology: 

   Stds/Ctrl Sys:

General:

·   Coding standards, requirements for peer reviews, memory leak testing, etc. are all in place and being implemented

·   Configuration mgmt and the change control system ensure that only agreed to changes are accepted, and that changes generate good code

Specific:

Ø “No code is to be released without complying with our design/coding standards, and peer reviews ensure that more than one set of eyes verifies that this is the case.”

Ø “We’ve made significant improvements in forcing people to follow standards that help to ensure quality code development.”

Ø “Our build practices make sure that only agreed to changes are included, and that these changes are signed off to have been inspected by peer review.”

General:

·   While the standards and requirements exist, they are not always followed, resulting in some poor quality software being delivered to SQA, and some reaching customers

Specific:

Ø “If such good standards and development requirements really exist, why am I seeing such a high rate of problems during testing, and why am I seeing any memory leaks?”

Ø “Customers continue to report quality problems, and when they are investigated, they always come back to faulty code.  If our design/coding standards are indeed good, then our enforcement of compliance to these standards is poor.”

Ø “Good standards don’t guarantee good quality.  People have to be properly motivated to design quality in, and not to take shortcuts that undermine quality.”

Development Methodology:

   Planning:

General:

·   Getting formal documentation written before starting development is improving, but still needs further improvement

·   Project Plans are now required for all approved projects

Specific:

Ø “Marketing is now making a serious effort at producing meaningful requirements that development can really do something with.”

Ø “Some developers are making good efforts to document what is to be developed, so that marketing and others can review it in advance to ensure it’s the right thing.”

Ø “The Projects Page on our Intranet has been a great forcing function to ensure that Design Specs and Project Plans exist for all approved projects.”

General:

·   Just recently seeing marketing requirements

·   Functional specs and design specs are typically sketchy at best, and often non-existent

·   Even with Projects Page, some Design Specs and Project Plans are almost meaningless

Specific:

Ø “People typically just started coding without any written documentation indicating what they should be coding.  It’s no surprise that what often gets implemented is not what was really wanted.”

Ø “It is very frustrating to see the steps some developers will go to to circumvent the development methodology; they produce basically blank Functional Specs, Design Specs, and Project Plans, and then say that they’re complying with the process.”

Development Methodology:

   Implementation:

General:

·   Generally good compliance with coding standards

·   Most developers faithfully unit test, integration test, and hold design reviews on their code

·   Tech Writers doing better job of working more closely with developers to write more accurate Tech Docs

Specific:

Ø “Most developers understand that they’re helping themselves and others by following the standards and do a good job at it.  This has improved significantly.”

Ø “Significant effort is being made to ensure that code has been thoroughly tested, including memory leak testing, before it is placed under source code control.  This is resulting in improved code quality.”

General:

·   Senior developers need to be more diligent in ensuring that younger developers follow the standards in coding

·   Some developers are “too busy” to properly test their code, and release “junk” to Release Eng and to SQA

·   Some Tech Writers still allow themselves to be intimidated by Developers, and the consequence is inadequate Tech Docs

Specific:

Ø “Some developers just do their own thing without any regard for the established requirements.  They have an arrogant attitude toward anyone who questions them.  And they’re often allowed to get away with it!”

Ø “To some developers the attitude is that others should be responsible for testing their code, not them.  It’s frustrating and a terrible waste of time to find their problems so late in the game.”

  .   .   .

  .   .   .

  .   .   .