Re: customer groups
- --- In firstname.lastname@example.org, Brian Marick <marick@...> wrote:
> 1. I've been the customer / product director on two projects, oneCouple of thoughts from my experiences, both as a developer and
> going on now. I find that I spend a lot of time making small
> decisions, be they GUI-related or "functional". How does that work
> with a customer team? Do programmers ask the most appropriate
> immediately available customer? I'd hate to have decisions slowed
> down because only one person can make decisions about GUI tweaks or
> because consensus among the customer team has to be reached rather
> than assumed.
1. I always tried to find the *most representative* person to act as
customer proxy. If that person didn't have a clear answer, then I'd
go down the list to the next customer rep.
2. Trust-based relationships were absolutely key. My customers
trusted that I would do what was best for them and the company, not
just what they asked for. At some point as a developer, you do make
decisions implicitly, but only after gaining a deep understanding of
your customer's needs and goals.
3. As a product manager, I stayed very heavily involved in the
development process until the trust and communication reached a "flow"
state. I trusted that the team would ask questions if they ran into
difficult or ambiguous problems, otherwise I assumed they would do
something reasonable instead of asking about thousands of trivial things.
> 2. The customer / programmer relationship often seems to me aAgain, in my experience, yes, the customer/programmer relationship did
> personal one. Rather than serving the company, the User, the stock
> price, or some other abstraction, the programmers want to make that
> person, Nickieben, the one sitting in that chair over there, happy.
> Provided Nickieben is making decisions that serve the company, User,
> etc., the personal relationship is an advantage, I think.
> Do the programmers form the same attachment to a team-that-speaks-
> with-one-voice as they do to a human who really truly has only one
> set of vocal cords?
tend to be a personal one. Another developer couldn't just talk to my
customer and have the same kind of interaction. The trust and deep
understanding wasn't there yet.
Even when I was no longer involved with one project, I was actually
called in to "translate" customer requests so that newer developers
could understand them.
Software development has a distinctly human element, no matter what
sort of processes we try to put into place. Humans prefer to work
with people they know and trust. Good relationships make better software.
- Alexander Johannesen wrote:
> If you can hide your work from them,Which, honestly, I don't think is unreasonable. From the perspective of
> then great, but there is this notion of teamwork going on here that
> requires a certain ... mediation to old progroms.
the waterfall person, all problems can be solved with a little more
planning, and failing to plan it all up front looks dangerous and the
fast route to failure. Until you have seen it work, it's easy to believe
that agile processes are impossible. I sure did.
When dealing with people like that I'll generally try one of two
approaches. The first is "Well, let's try an experiment." We find some
level of risk that they are comfortable with and try out agile methods
in that context. If the experiment is a success, we try a bigger experiment.
The other is, "You do what you think it takes." If they want a big spec,
then sure, they can write one up as we have our discussions around the
product. If they think a continuously updated spec is important, then
great, they should keep updating it. If they want a big MS Project
thingy, fine, we'll make sure all the necessary data is on our wall of
I don't know if those are helpful to you, but they've worked for me.