"Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?"
Are you sure about it? Don’t you think that if I as developer would be more chatty, I can get more useful requirements from client?
Maybe not ,maybe I just need more to think about their bussiness.
I usually end up directing meetings and I'm usually the one that have a clear vision and plan of what the meeting will be about and what information we need to take out of it, usually my involvement on the meetings are the first 10-30min and then I let the extroverts to enjoy themselves talking about nothing, while I process the data collected and they give me time to check if nothing else could be discussed. I'm not lesser because my introversion, to me, I'm better because of it. I don't envy extroverted people, I imitate them not because of admiration, just because is a tool that get results in my environment.
Also, devs need different information, not always given by the client, the client usually have no idea how the system is gonna be implemented, and are usually not interested on it. Of course it depends of the job and the situation, but in general the topics that the client knows and are interested in are not the ones related directly to devs, that's why there are steps between, not always are just bureaucracy (sometimes it is). Clients don't care if you TDD, OOP, or use X PL instead of Y; they usually don't care if you deploy with Docker or what framework you'll use, designers, sw architects, project managers, etc. Exists for a reason, should be at least, and depends of the client, the job, the size of the project, etc. But to ask devs to deal with, sales, marketing, manage the project, design the system and architecture, deploy and program is unrealistic and counter-productive
You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
But I think that developer have to heavily understand business rules to do a good job
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?"
Are you sure about it? Don’t you think that if I as developer would be more chatty, I can get more useful requirements from client?
Maybe not ,maybe I just need more to think about their bussiness.
I usually end up directing meetings and I'm usually the one that have a clear vision and plan of what the meeting will be about and what information we need to take out of it, usually my involvement on the meetings are the first 10-30min and then I let the extroverts to enjoy themselves talking about nothing, while I process the data collected and they give me time to check if nothing else could be discussed. I'm not lesser because my introversion, to me, I'm better because of it. I don't envy extroverted people, I imitate them not because of admiration, just because is a tool that get results in my environment.
Also, devs need different information, not always given by the client, the client usually have no idea how the system is gonna be implemented, and are usually not interested on it. Of course it depends of the job and the situation, but in general the topics that the client knows and are interested in are not the ones related directly to devs, that's why there are steps between, not always are just bureaucracy (sometimes it is). Clients don't care if you TDD, OOP, or use X PL instead of Y; they usually don't care if you deploy with Docker or what framework you'll use, designers, sw architects, project managers, etc. Exists for a reason, should be at least, and depends of the client, the job, the size of the project, etc. But to ask devs to deal with, sales, marketing, manage the project, design the system and architecture, deploy and program is unrealistic and counter-productive
You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.