REQUIREMENTS !

The more I work, the more I see "strange" behaviour both on the side of our customers, both on our side and on my personal side. I will try to understand way better why we are so changing, hectic, often unpredictable in our business hours.  I guess all this could be linked to the Complex, Complicated thing...

I just watched this TedX video of Frédéric Falisse explaining his Questiolgie and found it very interesting. The video is in french but it has English captions. I think it could be greatly useful while gathering elaborate or difficult requirements. As far as I understand it, he proposes four tips for asking good questions 1. Change of mental posture  If the interviewed is already an actor , remove him from the action and ask for a feeling . Do not ask "why do you get stuck" but "what do you feel when you feel stuck ? If instead he starts with an emotion, ask about an action. 2. Double the verb Like in the phrase "What are you afraid of when you are afraid of losing control?" 3. Reconcile Use right and left hands  "When you fail a test ... Makes you lose control over future choices" 4. Project in the future i.e. What will happen if you fail the test? Here's his main site  https://www.questiologie.fr/ Have a great day!

I am involved in my first two small User Centered projects (UX) and.... to my big surprise ... in both projects we are asked to do design WITHOUT talking to the end users ! We talk with some "intermediaries" that THINK they know what the users want.  Ah ah

We all know that many software projects don't end up well because in the beginning phase it is not clear what will really be useful, yet there are always more job postings for Technical Analyst or Architect than for "Requirements Seekers". Perhaps many believe that intelligent and experienced people in their field can also explain well all they need from a software application. I don't think so, and I believe this is a very specific job. I think we need more Socrates-like people, that is,  meticulous and sometimes "pain in the ass" persons that can really "extract"  everything they can out of those users who express their (often complicated) business needs.

At training courses they talk 6 hours about listening, win-win, batna, zopa . Then when you explain to them the real cases... in 3 minutes they switch straight to old Cardinal Mazarin tactics. Tactics of which I am ALMOST already an expert ...

Your product or service has problems ? Half of the problems comes from a bad analysis.  Half of the bad analysis comes from  the fear of asking a lot of questions .   Be bold, be an Analist !

The man that you treat as a "miserable" supplier all year long, one day comes and saves your ass. - me  -

This might be a little off topic, but after reading this article from USA Today , I thought the software industry should be inspired by the airline security system. As far as I know, the reason why air flight is the safest way of traveling is much due to these aspects. One, all the parts involved work toward ZERO fatalities . Two, their effort is never "good enough" . Three, they have a very open mind, sharing all the information about problems and crashes (the system was born when planes were "constantly" crashing so the pilots were very interested in sharing their experiences !) Four, unfortunately aircafts can't really pull over to change a flat tyre or stop to check their engine along the road ! Airplane manufacturers are therefore forced to build better, safer airplanes with improved safety and performance. Maintenance technicians are also forced to improve procedures to enhance reliability and safety and I think that regulators contribute wi

Some managers don't find the time to evaluate new suppliers, not even 10 minutes on the phone. Then they complain for weeks  that they are stuck in a project that does not take off in 2 years. Because of the supplier....

Yesterday I was reding about movies screenplays and found some analogies with writing requirements . The screenplay must be readable, because filmmakers need to understand - what they are talking about, - who will be there, - how much it will costs - etc. It is usually roughly divided in three parts: the set-up, the development, the epilogue (eg. 30, 60, 30 pages) Many things change before and during shootings: dialogues change, sometimes you shoot a scene at night instead of during the day, etc. so.... "If you don't like changes, then go write poetry". This one rings a bell, doesn't it ? Also, it will be read by the actors, who will interpret it and change it in some ways.

If someone should ever force me to summarize this blog in a single line, it would be: Listen carefully, be attentive and... be humble !

Currently reading Jim Arlow's " Secrets of Analysis: Generative OOA with NLP, Literate Modeling and M++ ". I found it extremely interesting, first because it has a lot of extremely interesting hints and tips and emphasizes the importance of communication Second, it introduces a simple but useful meta-language, called M++, that allows to recover information from deleted, distorted and generalized communications. It is an extension of the work on language patterns by Bandler and Grinder. M++ could gives you a set of simple, powerful communication strategies that you can apply straight away in your job. M++ (and the original Meta Model) specifies how you can use language to clarify language. It deabstracts to uncover distorted, deleted and generalized information.

Why ? The more I think about it, the more "why" is the word when it comes to requirements gathering. The question "Why ?" has two different meanings: THE PAST : you ask questions to understand the cause, what has happened in the past. THE FUTURE : we ask questions to understand what the user will need in the future, what he wants to do.