Hacker News Reader

Comment by christophilus | Hacker News Reader

Yes. The most successful projects I have worked on, we (the dev team, not project managers, not designers, etc) went on-site often. We observed our customers. We had lunch with them. We stood behind them as they worked. We asked them questions. We were on very friendly terms with them.

We built systems that literally had people say, "Oh, thank God!" when demoed. I haven't seen any other development methodology that matches it. You really have to understand a problem at a deep level in order to reason well about it.

View on HN

I'd love if that methodology were more common. The "traditional" method usually involves companies insisting we provide waterfall style proposals and they don't want to invest in up-front "mini-project" of having people analyze the problem _first_.

And heaven-forbid any developer actually calls up a customer or subject-matter expert without routing absolutely everything through one or more layers of middlemen and bureaucracy.

"Just send me your questions and I'll pass them along..." Because no one has _ever_ had a question answered and had a follow-up question based on the answer before... /s

True story: Myself and a bunch of internal customers are literally less than 50 meters away in the same office. The blessed middleman is in a different timezone 8 hours ahead.

So instead of a quick conversation 30 minutes with helpful whiteboard doodles, I have to compose my questions and decision-tree into an e-mail and wait at least for a day or two for a reply that may or may not be useful.

Are there repercussions to just walking over and asking them then forwarding the middleman a summary / recap?

There was a "Hey, don't do that, X needs to be in the loop" complaint. (Didn't see it myself, but technical program manager who was also in on the meetings told me.)

Later that remote person left the company, and the position was left unfilled for a year and some projects got mothballed.

I came in my company as a team lead to a very disfunctional department, the developers were frustrated because of unclear requirements and the business side was upset because they could never get their deliverables despite "very clear" 100 page documentation specs and a "detailed" list of requirements.

They would email each other even though they were in the same office more to document everything and CYA than for communications.

On the dev side, I banned internal email for discussions. I told them that they must talk to people first if they are in the office and then send emails of documents, screen shots or whatever.

I also took it on as personal mission to never say "no" to any request and always talk to the person who was making the request - in person - see if we could come up with an acceptable compromise and tell them how it would affect their deliverable.

Absolutely! Being able to watch our customers use our application in production environments, observing how they used it and how they perceived certain features has been so enriching.

We would have spent at least 10 times longer trying to get these insights otherwise, if there was even a possibility that we would arrive to the same conclusion.

It takes a little time to get over the fact that you are no longer building this product for yourself (unless you are building dev tools), but seeing customers use your product happily and telling you how much they value it is well worth the investment.

The book Talking to Humans, shows this concept well, plus the book is free.

http://www.talkingtohumans.com/index

Thank you for the suggestion, it was an excellent fast read, quite concise and insightful.

Reply on news.ycombinator.com