software requirements again, take 483
in [Perl]
|
From: ccc31807 on 2 Apr 2010 08:03 Peter J. Holzer wrote: > The tricky part here is to make everybody happy. That not only means > that the users get what they want in the end, you must also avoid > frustration during the process. I think some points which help are: > > 1) Make clear from the start that the process is iterative. If both > sides are aware that the spec isn't carved in stone but can and will > be amended then it is much easier to do this. Good. I like to iterate very quickly, sometimes several a day, The people I work with frequently expect that I'll have version A ready by noon and version B ready by the end of the day. I can do this because my jobs are usually very simple and short. > 2) Try to avoid passing blame. It isn't important whether the customer > forgot to tell something or changed their mind or whether the > programmer didn't ask the right questions or misunderstood the specs. > The important thing is that a flaw has been detected and must be > fixed. So write it in the specs and move on. (yes, some people always > want a scapegoat for every problem, preferrably before they even know > that there is a problem - but if they don't have to fear they they > will be blamed they are also less likely to blame you) Good. My approach to this is to accept all the blame, whether or not it's my fault. I don't have a problem with accepting the blame, and many times that blame is deserved. ;-) > 3) Keep the iterations short. Firstly, that will enable everybody to > remember what was discussed the last time and secondly, it avoids > wasting much time by going far into the wrong direction. Good. See above. When the software only takes several hours to write, this is easy to do. I have a project that requires more than a day (or two) about once a month. > 4) Fix the most important problems first. That way you will quickly > converge on a version which is usable, although it may not be > perfect. Sometimes this is difficult because you don't know what the 'most important' problem is before you start. Sometimes it's obvious, but sometimes it's that little regex that turns out to be the pivot point. Also, in my situation, requirements sometimes change radically. The project I did last month was totally different from the written specification (and yes, for this one I did have a written specification.) > 5) As soon as the product is usable, use it! Avoid the temptation to > make it perfect. It never will be. Good. In my case, this isn't a problem because the focus is on the end product, the report or document set. My users care nothing about the scripting, all they are looking at is the result, which makes it easy to focus on the major goal. To these points, I would add: 6) Expect the requirements to be wrong. There are more bugs in the specification than in the code, typically. 7) Expect the data to be bad. Something the in the input will always break the script. 8) Expect the job to change. Often the user doesn't know what he wants until you produce what he thinks he wants. 9) Be on your toes and be aware of your environment. Bullets fly! It doesn't matter if the one that hits you is deliberately aimed or is a ricochet. 10) Have fun -- this is probably the most important. Thanks, CC.
From: Charlton Wilbur on 2 Apr 2010 10:38 >>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes: cc> Good. I like to iterate very quickly, sometimes several a day, cc> The people I work with frequently expect that I'll have version cc> A ready by noon and version B ready by the end of the day. I can cc> do this because my jobs are usually very simple and short. Do your iterations include clear statements from the business process owners of what the expectations are for that iteration? If what you mean is that they complain and you fix it quickly, that's not an iteration, that's training them that you are a puppet that dances on the strings they pull. cc> Good. My approach to this is to accept all the blame, whether or cc> not it's my fault. I don't have a problem with accepting the cc> blame, and many times that blame is deserved. ;-) That is NOT HELPFUL, and is a large contributor to your problem. cc> Good. See above. When the software only takes several hours to cc> write, this is easy to do. I have a project that requires more cc> than a day (or two) about once a month. How long do the *requirements* take to write? How long does it take to get approval of them? What process do you follow to make sure the requirements are corret? You're thinking like a code monkey, not a software engineer. cc> Sometimes this is difficult because you don't know what the cc> 'most important' problem is before you start. Sometimes it's cc> obvious, but sometimes it's that little regex that turns out to cc> be the pivot point. Also, in my situation, requirements cc> sometimes change radically. The project I did last month was cc> totally different from the written specification (and yes, for cc> this one I did have a written specification.) You don't know what the most important technical problem is, but that's completely irrelevant. What problem is most important to the business process owner? I can guarantee you that he doesn't care about that little regex. And if requirements change radically, schedules should change radically too. I see it even in good organizations: the developer provides an estimate based on the requirements, the requirements change drastically, and then the business process owner attempts to hold the developer to the original estimate. It's the developer's responsibility to stand up and say, "No, that's crazy talk. You changed the requirements, so the schedule will change." Also, if you start work on a project without written requirements, you're contributing to the problem. You need to get in the habit, even when things seem crystal clear, of writing the expectations down in an email and sending them to the business process owner, saying, "This is my understanding of what you need. Please correct me if I'm wrong, or let me know if you think I've captured your requirements correctly." Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: Charlton Wilbur on 2 Apr 2010 10:31 >>>>> "JG" == Jim Gibson <jimsgibson(a)gmail.com> writes: JG> You get a set of written requirements and implement your program JG> to comply with them. You will probably have to write the JG> requirements yourself, since nobody else will think it is a JG> worthwhile exercise. So you do it, then get sign off from your JG> boss and the customer (end-user). JG> Then, when the program fails to meet the end-user's JG> expectations, you point out how the program actually complies JG> with the written requirements to which they agreed. Then, you JG> revise the requirements to match the user's expectations, modify JG> the program to match the new requirements, and move on to the JG> next problem, iterating until everybody is happy. The trick here is to make it not about blame but about improved communication. The business owner needs to understand that you do not know all the details of the job he needs the software to do. So you have to frame the whole thing not as "It complies with the written requirements, so it's YOUR FAULT it's not what you want," but as "I don't know your job as well as you do, which is why it's really important that I understand what you need the software to do." So if you write the requirements, the business process owner approves of them, and the software matches the requirements, the bug is not your fault, and you should push back HARD when the business process owner tries to make it your fault. If you do this well, you can start teaching the business process owner how to communicate better with you, and get across to him the importance of accurately communicating requirements. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: Peter J. Holzer on 2 Apr 2010 17:19 On 2010-04-02 12:03, ccc31807 <cartercc(a)gmail.com> wrote: > Peter J. Holzer wrote: >> The tricky part here is to make everybody happy. That not only means >> that the users get what they want in the end, you must also avoid >> frustration during the process. I think some points which help are: >> >> 1) Make clear from the start that the process is iterative. If both >> sides are aware that the spec isn't carved in stone but can and will >> be amended then it is much easier to do this. > > Good. I like to iterate very quickly, sometimes several a day, The > people I work with frequently expect that I'll have version A ready by > noon and version B ready by the end of the day. I can do this because > my jobs are usually very simple and short. I was thinking of longer projects. For something that can be done in half a day, revising the specs (if there even is one) isn't a problem. But if you have spent half a year writing the specs and six different people have signed it, it becomes damn hard to change it, even if parts of it were obviously wrong. >> 2) Try to avoid passing blame. It isn't important whether the customer >> forgot to tell something or changed their mind or whether the >> programmer didn't ask the right questions or misunderstood the specs. >> The important thing is that a flaw has been detected and must be >> fixed. So write it in the specs and move on. (yes, some people always >> want a scapegoat for every problem, preferrably before they even know >> that there is a problem - but if they don't have to fear they they >> will be blamed they are also less likely to blame you) > > Good. My approach to this is to accept all the blame, whether or not > it's my fault. I don't have a problem with accepting the blame, and > many times that blame is deserved. ;-) That's not good and definitely not what I meant. You should not accept all the blame (that's frustrating for you (and boy, you do sound frustrated at times) and it undermines your reputation in the company ("that Carter guy never gets anything right")). Instead you should try to create a working environment where blame isn't an issue. If something like your one-task-several-workers problem pops up, whoever notices the problem should just be able to say "hey, the program doesn't handle tasks assigned to multiple persons right now, but it needs to. Can we change that?" and not have to think about who they can blame and why they didn't notice this 3 weeks ago. >> 3) Keep the iterations short. Firstly, that will enable everybody to >> remember what was discussed the last time and secondly, it avoids >> wasting much time by going far into the wrong direction. > > Good. See above. When the software only takes several hours to write, > this is easy to do. I have a project that requires more than a day (or > two) about once a month. That point (and in fact most of the others) was aimed at larger projects. I have unfortunately been involved in projects with iteration times of several months, where from one meeting to the next nobody could remember what was meant by that cryptic paragraph in the specs, or a lot of work had to be scrapped because either the spec was wrong or too vague (and nobody noticed until the part had been implemented). >> 4) Fix the most important problems first. That way you will quickly >> converge on a version which is usable, although it may not be >> perfect. > > Sometimes this is difficult because you don't know what the 'most > important' problem is before you start. Sometimes it's obvious, but > sometimes it's that little regex that turns out to be the pivot point. The "little regex" is never the most important problem. The most important problem is that a task can be assigned only to a single person, or that the report cannot be imported into the accounting program or that the distance between the logo and the first line is 2mm too small. Solving the problem may involve changing that little regex, but the customer doesn't care about how you solve the problem, but only that you do it and how long it takes (and how much it costs). So after identifying the problems you determine a priority and solve the problems in order of decreasing priority. And yes, it is quite possible that the customer cares more about the placement of the logo than about about a substantial problem that only affects only 4 out of 500 reports. > Also, in my situation, requirements sometimes change radically. The > project I did last month was totally different from the written > specification (and yes, for this one I did have a written > specification.) See point 1) above. >> 5) As soon as the product is usable, use it! Avoid the temptation to >> make it perfect. It never will be. > > Good. In my case, this isn't a problem because the focus is on the end > product, the report or document set. My users care nothing about the > scripting, all they are looking at is the result, which makes it easy > to focus on the major goal. > > To these points, I would add: > > 6) Expect the requirements to be wrong. There are more bugs in the > specification than in the code, typically. > 7) Expect the data to be bad. Something the in the input will always > break the script. > 8) Expect the job to change. Often the user doesn't know what he wants > until you produce what he thinks he wants. These are already covered by 1). > 9) Be on your toes and be aware of your environment. Bullets fly! It > doesn't matter if the one that hits you is deliberately aimed or is a > ricochet. This is related to 2). Try to keep people firing the bullets in the first place. At least in your vicinity. > 10) Have fun -- this is probably the most important. That I can agree with. hp
From: ccc31807 on 3 Apr 2010 06:37
On Apr 2, 9:31 am, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > So if you write the requirements, the business process owner approves of > them, and the software matches the requirements, the bug is not your > fault, and you should push back HARD when the business process owner > tries to make it your fault. If you do this well, you can start > teaching the business process owner how to communicate better with you, > and get across to him the importance of accurately communicating > requirements. Charlton, yesterday (Friday) when I came to work, I found a new project on my desk. It was a log file from our corporate call center. The manager wanted to know the locations of the callers. He had attempted to do some of it by hand, but that is an arduous task, and he soon gave up. It was pretty simple to do, and I did it, from scratch, in less than four hours, including finding and parsing the telephone exchange data (which was a little difficult). When I finished, I called the manager in charge and asked what format he wanted the report in. The answer? "I don't know." Think about this -- a manager assigns a project without thinking it through to the extent that he knew the format of the output. Here I was, with nice work and a ton of data, and no way to return it. This is a communication problem. It's not a failure to communicate, but a failure to have something to communicate. It's difficult to say something if you don't have anything to say. We'll get this sorted out on Monday so I'm not worried about it. The point is that the technical person can't work without knowing what the requirements are, and at least in my situation, I am often assigned work with unclear, ambiguous, or absent requirements. Finally, maybe I should add that the whole process is iterative, and that the client doesn't know how he wants the data until he sees the data. In this case, the client and the developer work together through a number of iterations until the client sees how he uses the data, and the developer helps him my writing output in a number of formats. (Quick story -- We had a big push for graphical formatting and visualization, the bosses wanted to 'see' the data. I spent several days and developed an application that took data and spat out gifs, literally hundreds of gifs, bar charts, line graphs, etc. The final result was a 40+ page PDF with eight charts on each page. Guess what? After I submitted this, I never heard from it again. The theory about visualizing data is good, but it has it's drawbacks as well, and you might not realize that you really don't want to 'see' the data until after you see it.) CC |