Post Closed as "duplicate" by Doc Brown, Bart van Ingen Schenau, GlenH7, Thomas Owens of
3 deleted 868 characters in body; edited tags
source | link

I haven't seen this particular question answered elsewhere on here, so here goes:

I'm working at my first software internship, and it's great so far. One problem I'm having, however, is getting clear requirements from my co-worker (we'll call the personhim Person A) who assigns projects. Normally, I get requirements from a co-worker/manager, design/code/test my changes, and eventually commit them for integration in our product. The problem is that, fairly often, it is virtually impossible to get clear requirements from personPerson A. I will ask questions to better understand what problem is being solved, and one of the following often happens:

  1. The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

    This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  2. Person A often barely understands the requirements.

    These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

    A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

  • Person A will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

Does anyone have adviceThis will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to help in this typewaste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  • Person A often barely understands the requirements.

These factors add up to wasting a lot of situation?development time based on simple misunderstandings of what needs to be done.

Co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

How do you wring clear, correct requirements from someone who understands them but does not have the inclination to take the time/effort to explain what they actually are?

I realize that I am placing all of the blame for this on A. Also, I am leaving out person A's perspective, who probably sees us junior developers as an annoyance. However, for this particular case, I don't see where I would be at fault, although I would like to know/improve if I am at fault. I realize that I am taking the other person's time, and thus I'm under an obligation to be attentive, brief, and do as much up-front research as I can to take up as little of the other person's time as possible. However, I'm not sure how you research a problem that hasn't been stated.

Am I missing something? Do I have the wrong attitude when approaching this problem? I do not want to be a complainer.

I haven't seen this particular question answered elsewhere on here, so here goes:

I'm working at my first software internship, and it's great so far. One problem I'm having, however, is getting clear requirements from my co-worker (we'll call the person A) who assigns projects. Normally, I get requirements from a co-worker/manager, design/code/test my changes, and eventually commit them for integration in our product. The problem is that, fairly often, it is virtually impossible to get clear requirements from person A. I will ask questions to better understand what problem is being solved, and one of the following often happens:

  1. The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

    This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  2. Person A often barely understands the requirements.

    These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

    A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

Does anyone have advice to help in this type of situation? How do you wring clear, correct requirements from someone who understands them but does not have the inclination to take the time/effort to explain what they actually are?

I realize that I am placing all of the blame for this on A. Also, I am leaving out person A's perspective, who probably sees us junior developers as an annoyance. However, for this particular case, I don't see where I would be at fault, although I would like to know/improve if I am at fault. I realize that I am taking the other person's time, and thus I'm under an obligation to be attentive, brief, and do as much up-front research as I can to take up as little of the other person's time as possible. However, I'm not sure how you research a problem that hasn't been stated.

Am I missing something? Do I have the wrong attitude when approaching this problem? I do not want to be a complainer.

I'm working at my first software internship, and it's great so far. One problem I'm having, however, is getting clear requirements from my co-worker (we'll call him Person A) who assigns projects. Normally, I get requirements from a co-worker/manager, design/code/test my changes, and eventually commit them for integration in our product. The problem is that, fairly often, it is virtually impossible to get clear requirements from Person A. I will ask questions to better understand what problem is being solved, and one of the following often happens:

  • Person A will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  • Person A often barely understands the requirements.

These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

Co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

How do you wring clear, correct requirements from someone who understands them but does not have the inclination to take the time/effort to explain what they actually are?

2 Change to numbered list and indented blocks to more clearly separate the 'often happens' section from the rest of the question.
source | link

1) The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

[I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

2) Person A often barely understands the requirements.

These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

  1. The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

    This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  2. Person A often barely understands the requirements.

    These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

    A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

1) The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

[I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

2) Person A often barely understands the requirements.

These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

  1. The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

    Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

    Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

    [I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

    This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

  2. Person A often barely understands the requirements.

    These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

    A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

1
source | link

Gathering requirements from confusing co-worker

I haven't seen this particular question answered elsewhere on here, so here goes:

I'm working at my first software internship, and it's great so far. One problem I'm having, however, is getting clear requirements from my co-worker (we'll call the person A) who assigns projects. Normally, I get requirements from a co-worker/manager, design/code/test my changes, and eventually commit them for integration in our product. The problem is that, fairly often, it is virtually impossible to get clear requirements from person A. I will ask questions to better understand what problem is being solved, and one of the following often happens:

1) The person will interrupt mid-sentence to think out loud, derailing the current conversation. Sometimes this is for good reason. Example:

Me: "So if there should be a table mapping Bazzes to Foos, what if there were-"

Person A: "Actually, I wonder if we actually need to add a BizzleContainer in this here."

[I wait a few minutes for A to think through their unrelated thought, and try to help solve it.]

This will repeat a few times, and by the time the conversation is done, I'm more confused than when we started and half an hour has gone by, so I don't want to waste the person's time any longer. Note that I wouldn't mind if the interruption was related to the current topic, but it seems that interrupting someone to take a conversation down a completely different path is poor form.

2) Person A often barely understands the requirements.

These factors add up to wasting a lot of development time based on simple misunderstandings of what needs to be done.

A related problem: co-workers B and C are capable of clearly expressing what needs to be done, but they are often overrun with demands for their time. So rather than annoy B and C to get requirements clarifications, co-workers often go to A, and get less than satisfactory results.

Does anyone have advice to help in this type of situation? How do you wring clear, correct requirements from someone who understands them but does not have the inclination to take the time/effort to explain what they actually are?

I realize that I am placing all of the blame for this on A. Also, I am leaving out person A's perspective, who probably sees us junior developers as an annoyance. However, for this particular case, I don't see where I would be at fault, although I would like to know/improve if I am at fault. I realize that I am taking the other person's time, and thus I'm under an obligation to be attentive, brief, and do as much up-front research as I can to take up as little of the other person's time as possible. However, I'm not sure how you research a problem that hasn't been stated.

Am I missing something? Do I have the wrong attitude when approaching this problem? I do not want to be a complainer.