2 ms·

A problem I've seen from both sides of this fence is that one side tends to over-simplify what the other side needs to do to get something done. A business guy

by icey 17y ago

A problem I've seen from both sides of this fence is that one side tends to over-simplify what the other side needs to do to get something done. A business guy may say "oh just slap this together and you're done", while a software guy might say "just go get some sales and we're golden". I think taking a few minutes to find out the actual effort required to make something happen can go a long way; for both business people and software people. The other thing that I see happen a lot is that business people tend to want to say "yes" to everything, while software people tend to want to say "no". It makes sense in context, business people want to do whatever it takes to make successful sales, while software people generally want to keep a manageable feature set (they also tend to know the full problem domain a little better than most of the business people they deal with; at least from the technology front). Of course, these are all generalizations, so you have to take them with a grain of salt.

sidmitra 17y ago
>is that business people tend to want to say "yes" to everything, while software people tend to want to say "no" That is so true, and i see that every single day. I guess NO is a bad word in marketing/sales, whereas it's actually a pretty good one in the dev world. It usually means, less feature bloat, lesser maintenance.
pasbesoin 17y ago
> they also tend to know the full problem domain a little better than most of the business people they deal with This is too often overlooked. It is development's job to "re-engineer" this domain in some fashion. Don't neglect the expertise they bring to the table and/or acquire in doing so. And... if you are dealing with a corresponding "business type" at the client/customer, realize that this applies on the other side, too. When working with/through such contacts, you may not being gaining a full picture of what their end users really need. Better model: Put the users and developers in closer contact with each other. Use your expertise to mediate this especially from a financial and legal perspective. Scheduling fits somewhere in between, and should have the active participation of both parties -- business and technical on your side, and ideally both business and technical on their side as well. It can be like a light bulb going off, when e.g.your tech lead finally gets to communicate directly with theirs. An hour -- sometimes 15 minutes -- of direct communication can obviate weeks of "memos" and such. Especially if they are freed to communicate in a forthright manner on an ongoing basis. Your job is to define the boundaries of communication and to adequately defend property rights and profitability. Don't insert yourself too heavily into nor try to micromanage the rest. Assuming you have good staff. This is based upon my ad hoc observation of situations that have worked and situations that haven't. I'm not formally an "expert" in this.

by icey 17y ago

sidmitra 17y ago

>is that business people tend to want to say "yes" to everything, while software people tend to want to say "no" That is so true, and i see that every single day. I guess NO is a bad word in marketing/sales, whereas it's actually a pretty good one in the dev world. It usually means, less feature bloat, lesser maintenance.

pasbesoin 17y ago

> they also tend to know the full problem domain a little better than most of the business people they deal with This is too often overlooked. It is development's job to "re-engineer" this domain in some fashion. Don't neglect the expertise they bring to the table and/or acquire in doing so. And... if you are dealing with a corresponding "business type" at the client/customer, realize that this applies on the other side, too. When working with/through such contacts, you may not being gaining a full picture of what their end users really need. Better model: Put the users and developers in closer contact with each other. Use your expertise to mediate this especially from a financial and legal perspective. Scheduling fits somewhere in between, and should have the active participation of both parties -- business and technical on your side, and ideally both business and technical on their side as well. It can be like a light bulb going off, when e.g.your tech lead finally gets to communicate directly with theirs. An hour -- sometimes 15 minutes -- of direct communication can obviate weeks of "memos" and such. Especially if they are freed to communicate in a forthright manner on an ongoing basis. Your job is to define the boundaries of communication and to adequately defend property rights and profitability. Don't insert yourself too heavily into nor try to micromanage the rest. Assuming you have good staff. This is based upon my ad hoc observation of situations that have worked and situations that haven't. I'm not formally an "expert" in this.