NOTE: These lecture notes contain more detail than
Dmitry's notes because we didn't want to omit any idea we found important
or interesting (or funny; in the case of the Dilbert cartoon).
Objectives:
What are customer-orinted practices?
Who must be kept happy to reduce project friction? How?
How to mangage customer expectations.
What is principled negotiation?
What is involed in creating a productive environment for
developers?
Summary/Key points:
If customer relations are a top priority, many development
problems disappear; including slow development. Good relations mean customer
will have improved confidence and perception of projects progress and value.
Unrealistic customers expectations cause friction and increase project risk.
Not every software developer solution good for customers - be dynamic.
Principle negotiation is a strategy that relies on improving
communication & creation of win-win options.
Productivity environments are effective work environments
(free from noise / interruptions) that are essential for maximizing output
efficiency of software developers.
Management:
Review last weeks lecture
Discuss how customer-oriented might (hypothetically) relate to your project
Lots to material to cover this lecture.
Chapter 10 - Customer Oriented Development
Not every known software developer solution good for customers - be dynamic.
If customer relations are a top priority, many development problems disappear;
including slow development.
In the end, customer's perception of your development speed is all
that matters.
Identify the Customer:
Customer can be a client, marketing group, end-user, or the boss.
If customer don't like your product, they won't pay for
it!
10.1) Customers' Importance
Easy access to end-users = critical success factor.
Good relations (and communication) with customers creates a cooperative
relationship, and can eliminate much inefficiency and major development errors.
Side-effect: customer has an improved perception of
development speed and confidence increases - especially if developer provides
high visibility of progress. Customer's attention shifts away from
development speed and towards functionality, and quality.
Improved Efficiency:
Ideally, customer begins to understand the important of reviews, management,
monitoring, progress - this results in less rework.
Reduced Risk:
Ways customers can pose risks to the schedule:
doesn't understand what they want
won't commit to set of written requirements
insist on new requirements after the cost and schedule have been fixed
communication with customer is slow
won't or can't participate in reviews.
are technically unsophisticated
don't understand the software-development process
Establishing a good working relationship will reduce these risks.
Lack of Friction
If develop doesn't get along with customer a lot of time is spend
on distractions making developer less efficient and motivated.
Reasons for friction:
Customer demanding impossible delivery dates, demanding new requirements
and refusing to pay for them, omitting clear acceptance criteria, and
inadequate monitoring the contract's progress.
Developer promising impossible delivery dates, bidding artificially
low, bidding on projects for which the developers lack necessary skills,
developing products with low quality, missing delivery dates, and providing
inadequate status reports.
Making a partnership with the customer, they begin to cooperate to find
realistic, mutually satisfying technical solutions.
10.2) Customer-Oriented Practices
Categories:
Planning - build customer satisfaction into your project
Requirements analysis - understand the real requirements
(and avoid rework)
Design - build in the flexibility needed to respond quickly
to customer-generated change requests.
Construction - keep the customer confident about your progress.
Planning
Select appropriate lifecycle model – must provides the
customer with tangible signs of progress.
Identify real customer – keep them happy
Establish efficient method for interacting with customer –
insist on a single point of contact. Avoid situation where every decision
requires approval from six customer representatives - development speed
will suffer terribly.
Create win-win project - identify “win” conditions
for all parties involved.
Manage risks - pay special attention to customer-related risks
in your risk-management planning and risk monitoring.
Requirements Analysis
Requirements are often stated vaguely, which creates the possibility
of confusion.
Importance of gathering requirements
Can be more than twice as productive if customers have proper active
participation.
Customer involvement can help development speed, but it isn't sufficient
by itself to improve productivity.
User requirements help customers figure out want they want - user interface
prototyping, evolutionary prototyping, and Joint application development
(JAD) sessions can help in this process.
Some strategies:
Conduct focus groups that help you figure out what the customer wants.
Videotape customers using the software.
Conduct customer-satisfaction surveys to obtain a quantitative measurement
of your relationship to your customers
Design
Employ design practices that allow your customer to change their minds
occasionally
This can be achieved by identifying changes that are likely and encapsulating
the data so that changes are easier to implement.
Construction
By now, customer should be so invested in the project that their level
of risk is greatly reduced.
During construction:
Employ good implementation practices that create readable, modifiable
code (which will improve your ability to respond to customer change
requests).
Use progress-monitoring practices such as mini-milestones so that
you can inform the customer about your progress.
Select appropriate lifecycle model.
Customers like progress that they can hold, or can see on a computer
screen.
10.3) Managing Customer Expectations
Try to set expectations explicitly so that any unrealistic assumptions your
customer might have about the schedule or deliverables are addressed promptly.
For no reason allow customers to have unrealistic expectations (about schedule,
cost, or functionary) - it will only cause friction and increase project risk.
VERY TRUE to life.
Chapter 29 - Principle Negotiation
Principle negotiation is a strategy that relies on:
1. Improving communication
2. Creation of win-win options
Explains how to respond to negotiating tricks used by others.
Can be used during:
Requirements analysis
Scheduled creation
Feature change discussions
And at other times
It's beneficial because it clarifies expectations and identifies
exactly what is needed for success.
Effective use depends on:
1. Separating people from problem
2. Focusing on interest, not positions
3. Inventing options for mutual gain
4. Insisting on the use of objective criteria.
Used on any kind of project
Chance of first time success and long term success is very good/excellent
Very good improvement in progress visibility
Decrease on schedule risk
No potential reduction form nominal schedule.
Chapter 30 - Productivity Environment
Productivity environments are effective work environments (free from noise
/ interruptions) that are essential for maximizing output efficiency of software
developers.
Present work environments are detrimental to software development due to
overcrowding and interruptions. (Interruptions approx every 11 minutes)
Software developers need long periods of uninterrupted concentration.
An effective productivity environment allows developers to reach a state
of Flow Time and provides them with surroundings that meet their hygiene needs
therefore improving their morale, motivation and productivity.
Flow Time: a relax state of total immersion in a problem
that facilitates understanding and the generation of solutions (DeMarco
and Lister 1987) (requires 15 minutes or more to enter this state). Developers
work in this flow time until fatigued or interrupted terminates it, therefore
increasing efficiency.
Hygiene Needs: basic conditions a worker needs to work
effectively (adequate lighting, air conditioning heating, reliable power,
bathroom facilities, desk space, maintenance of equipment, working hours,
communication, applicable software tools, readily available supplies etc.
Inadequate rather than adequate office space erodes
motivation and productivity
Lack of productive environments is detrimental to motivation, morale and
productivity.
As team leader, manager you need to negotiate a productive environment if
you're serious about efficiency & productivity.
Dilbert tells all.
30.1) Using Productivity Environments
Productivity Environment characteristics:
80+sq feet floor space per developer
15+sq feet desk space (must fit resources) & workstation configured
to developer's preference.
Some means of stopping phone interruptions (email/answering service/ringer
off).
Means of shutting out unwanted noise.
At least 15sq feet of bookshelf space.
Authors additional factors:
Office with external windows.
12+sq feet of whiteboard space
12+sq feet of bulletin board space
Convenient access to:
other project team members
high speed printer
photocopier
conference room
common office supplies.
Tiny little pictures of "good" cubicles.
Not important.
30.2) Managing the Risk of Productivity Environments
1. Lost productivity from status oriented office improvements.
Upgrades done as a cosmetic (status) enhancement and do not support
productivity improvements.
2. Transition Downtime
Loss of time – moving, reorganizing, etc
Loss of morale if environment doesn't suit developers
(Assume loss of a min. of 1 person week per developer)
3. Political Repercussions of preferential treatment for Professionals.
Others may see private offices for software developers as preferential
treatment.
30.3) Side Effects of Productivity Environment
Improvements in productivity, motivation, morale, satisfaction and retention
rates
30.4) Productivity Envirnoments Interaction with Other Practices
Can be used in conjunction with any other productivity practice.
30.5) Bottom Line on Productivity Environments
DATA: Strong correlation between
productivity and quality of workplace.
Developers should be involved throughout the design process.
30.6) Keys to Success
Avoid status oriented office improvements. Focus on office characteristics
that count.
