On Jan 16, 2008 9:03 AM, Darren New <[EMAIL PROTECTED]> wrote: >> > > Definition is hard > > to outsource depending as it does on the "customer" who often > > must be worked with face to face. Implementation OTOH is > > realtively easy to outsource if one has a good solid definition, > > which is, of course, a _big_ if.
First I completely agree that your list does a good job of defining the problem. I do _not_ think that you avoid the probem by avoiding outsourcing. You have these problems whether you outsource or not. So let's take them one by one. > Assuming you (a) have a customer who knows what they want, Of course you do not have a customer who knows what they want. That is one reason why definition is hard and requires a lot of face to face. I must say I have almost never had a customer who knew what they wanted. A key role any consultant (or definer, which I consider basically a consulting job, no matter what the contractural relationship is) has is to figure out what the customer needs and help them to understand that "they don't always get what they want, but if they try sometimes, they just might get what they want." Reason (a) is a major reason why this part of the problem cannot be effectively outsourced. >(b) you can figure out what the customer wants, If you cannot then you really should _not_ be doing the job. Worse I would say you are failing. Now, admittedly many projects and many consultants fail at this point. >(c) the requirements don't change in the time it takes to write it, Then you are taking too long to write them. Moreover if you just start writing code the project is even more likely to fail for the same reason. Unreasonable expectaions are a common cause of failure. Important exception is RAD/Prototyping, which I personally love where it is appropriate. But see "tall thin man" below, which to some extent uses RAD to construct the system definition. >(d) you can express that to the programmers who don't > speak your language natively The guys I have outsourced with, mostly Mexican, have all spoken English quite adequate to the task. Most educated Indians speak and understand the King's English at least as well as I do. > and never even met the customer This is an advantage. It forces you, the system definer, to do your job. Why must the implementer meet the customer? I worked for a decade as an outsourcer for a guy who was contracted to a Norwegian oil company. I _never_ met the customer, but David K. Walker, could tell me what to implement. Now I will admit that DKW is good. But dammit, that is my point. You need to be very good to do a decent job of system architecture and definition. >and quite possibly never had anything to do with your > customer's type of business, Well if the person/group doing the definition/spec have not then they have the same problem. (e) that you convince the outsourcees that > they should do what you need rather than what's easiest and most > profitable for them, The same exact problem lies with any organization that contracts to have another organization develop software for them. Indeed this problem exists within organizations. MIS propensity to serve themselves rather than their corporate customers is legendary. > and (f) you have a way of telling that what you got > back is what you asked for, and > (g) you can tell before you start which > outsourcing group will actually be able to accomplish what you're paying > them for, Clearly you have no clue how to manage a software project. I suspect though that you are one hell of a good implementer and find as I have that "management" is often (but not always) synonymous with "stupid practices." > and (h) you can convince them to work on your project to the > exclusion of other projects that might come later but are more profitable. See immediately above. > None of these are even middling, let alone "relatively easy". I agree. That is my point as well. Further this cannot be outsourced (unless the outsourcers do face to face, as e.g. a consulting company might do.) > By the > time you can clearly write unambiguous specs and have an inexpensive way > of ensuring that the result meets those specs and is flexible enough to > meet your future needs, you have reduced the problem to something you > might as well just finish yourself - you've already done 90% of the work. This depends on the project. I use to agree with you. I no longer do. For small projects it is true. For larger projects, where the architecture is critical, I think you are wrong and that your approach will not work. An alternative approach that some say is the only way that ever works is to start with a small project then when that is successful to flesh it out. I always want to see what I call a "tall thin man", a prototype that touches all of the bases with as many stubs as necessary as early as possible. The "tall thin man" encapsulates the architecture but will not have much functionality. I literally consider this the most important part of the spec. Good exchange, BobLQ > > -- > Darren New / San Diego, CA, USA (PST) > It's not feature creep if you put it > at the end and adjust the release date. > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
