Sanding our assholes with 150 grit. Slowly. Lovingly.

IT and Estimates

From my latest post ( http://jdk.phpkid.org/index.php?p=1190 ) :


Wonderful definitions of designations at office.

1) Project Manager is a Person who thinks Nine women can deliver a baby in One month.

2) Developer is a Person who thinks it will take 18 months to deliver a baby.

3) Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.

4) Client is the one who doesn’t know why he wants a baby.

5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.

6) Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.

7) Documentation Team thinks they don’t care whether the child is delivered, they’ll just document 9 months.

8) Quality Auditor is the person who is never happy with the PROCESS to produce a baby.

Each and everything sounds so very true! :)

JD
Permalink JD 
March 16th, 2005
What are job descriptions (e.g. skills and responsibilities) for the "Onsite Coordinator" and "Resource Optimization Team"?
Permalink Christopher Wells 
March 16th, 2005
And now JD is in big trouble.
Tatataaaaaa :)
Permalink Another posters... 
March 16th, 2005
Yes it does sound like it's to do with out-sourcing and/or off-shoring; but I *am* interested...
Permalink Christopher Wells 
March 16th, 2005
The company where I worked, duties of Onsite co-coordinator are as follows:

1. They start requirements gathering at client location. This includes existing system analysis if project involves upgrade of existing system.
2. They do estimates for the project and also prepare schedule.
3. They prepare high level design for project which is sent offshore.
4. Offshore team does a detailed design and the actual build and unit testing. Onsite team makes sure that offshore team is on track.
5. Onsite team is responsible for clarifying ambiguities/issues/doubts arising during build phase.
6. Once offshore team delivers code, Onsite team does Integration Testing (as and when appropriate) and implements it on production server.

Btw, I have never heard of Resource Optimization Team so far, but I guess this role is played by manager who is responsible for group of resources.

JD
Permalink JD 
March 16th, 2005
Btw, if you remove 'Onsite/Offshore' part, the whole story still holds true for any IT project.

The thing I like most:

Client doesn't know if he wants a baby. May be I should rephrase it and say that Client wants a child but not sure whether it should be boy or a girl. ;)

JD
Permalink JD 
March 16th, 2005
> ... duties of Onsite co-coordinator were ...

Ah; so "onsite" means at the customer site, not at the off-shore site.

> ... manager who is responsible for group of resources ...

I don't it's commonly used that way, but I find the word "resources" instead of "employees" or "developers" kind of de-humanizing.

> Btw, if you remove 'Onsite/Offshore' part, the whole story still holds true for any IT project.

Many software vendors (who sell software, not who sell software development services) develope software without being at their customers' sites ... they don't (necessarily) gather requirements from customers, nor build according to customers' spec., nor do integration/acceptance testing and installation and production/operations at the customer sites.

Also, development shops who are already experienceed with the kind of software that they're developing can be quite accurate with their scheduling predictions!
Permalink Christopher Wells 
March 16th, 2005
> I don't it's commonly used that way, but ...

I know it's commonly used that way, but ...
Permalink Christopher Wells 
March 16th, 2005
Btw, definitely the post was targetted towards IT Services and not product development. This is why I am currently building up my skills so that I can fit in Product company instead of services company.

And yes, even I hate the word 'resources' but that's how you are treated. You are merely an employee number for most of the Indian IT Services.

JD
Permalink JD 
March 16th, 2005
"Client wants a child but not sure whether it should be boy or a girl. ;)"

But it'll be wrong, whatever gender you give them, especially if you cover your bases and deliver a hermaphodite... ;-)
Permalink cubiclegrrl 
March 16th, 2005
> Btw, definitely the post was targetted towards IT Services and not product development. This is why I am currently building up my skills so that I can fit in Product company instead of services company.

I have never worked in IT Services. Does it matter what *your* skills are?

I heard rumours that Quality standards can be lower when the software is for use in-house (instead of for resale); but I don't know if that's true, nor what other differences might exist between Services and product development.

It seems to me that the difference between a product company and a service company might be not in the software development (*process*): instead the difference is in the company's *product* ... why might it make any difference to you, whether the person to whom you give the software either uses it in-house, or resells it?

If for example you translate ...

"Onsite co-coordinator" -> "team" lead" or "architect"
"client location" -> "product manager"
"sent offshore" -> "sent to developers"
"implements it on production server" -> implements it on final QC system and on the tech support system

... then the role of "onsite co-coordinator" for example also exists in a product develoment shop.

I can guess, but what's your insight into that?
Permalink Christopher Wells 
March 16th, 2005
> Does it matter what *your* skills are?

I mean, if you're working as a developer, and not working as a product manager, would working for a Product company as opposed to working for a Services company require of you a different set of skills?
Permalink Christopher Wells 
March 16th, 2005
I think there is a huge difference in IT product development and IT Services, even though at the end, they both produce software.

Joel outlines it nicely in his article 'Five worlds of Software Development', http://www.joelonsoftware.com/articles/FiveWorlds.html

IT Services basically develops 'Internal' software.

As you pointed out, quality control can be bit relaxed (and it's not rumor, it's a fact) as environment, where software is deployed, is highly controlled unlike off the shelf product.

Also, whole development is centered around ever changing business requirements unlike product development where you would decide upon list of features to implement and then work on it.

And here is the problem. The business person needs IT system for to do business effectively, but he is not able to articulate exactly how system should look like. Most of the time there is a serious disconnect between what they want, what they are able to describe and what IT team understands. That is my most of the internal project encounter overrun in form of time and money. An IT guy who understands business, who understands what business guy wants is in high demand. [Btw, there are other reasons why internal projects fail, but I think communication gap is the main one. Another prime reason is incompetent developers. Check www.thedailywtf.com, and you will be absolutely shocked to know kind of code which can be found in internal projects. ]

JD
Permalink JD 
March 16th, 2005
I mean, if you're working as a developer, and not working as a product manager, would working for a Product company as opposed to working for a Services company require of you a different set of skills?

Hm.. I would not say that skills required would be much different, but skill level required will be different. For example, you don't need to be an ASP.NET guru to work on most of the internal projects. But if you are creating a web service to be consumed by hundreds of users who all uses different browsers, you better be guru of ASP.NET and HTML/XHTML. You don't have to know differences between Windows 2000 and Windows XP while developing internal software, but you better know these things if you are developing a product.

You can be a *programmer* and do fine in IT Services company but you need to be *developer* to work in IT Product company. Difference between programmer and developer? Check http://www.ericsink.com/No_Programmers.html

JD
Permalink JD 
March 16th, 2005
> http://www.ericsink.com/No_Programmers.html

That's good.

But he says "It's a foregone conclusion that your programmers don't know how to do the non-coding aspects of product development", (i.e. it's something you'll learn after you get the job, not something you can learn before).

Also note that Eric is a *small* ISV. I have worked at Product companies that employed 1000s of programmers (as well as in much smaller companies): in a company with 1000s of programmers/developers, they can (will) still specialize (for example, do nothing but write and maintain the compilers).
Permalink Christopher Wells 
March 16th, 2005
> Most of the time there is a serious disconnect between what they want, what they are able to describe and what IT team understands.

BTW that's not a problem which, IMO, magically goes away when you work for a Product company. In a way the problem can be harder (because you're even further from the customer); or, the problem is the same (as a developer, your 'customer' is the "product manager" of your company).

Domain knowledge remains important. As is is/was a developer himself, Joel already knows about developers and bug-tracking (so he is able to be product manager for bug-tracking software). And I used to write telecomms software, where I could get the (clear and unambiguous and unchangeing) "specs" simply by reading the documented definition of the telecomms protocol to be implemented.

Now (recently) I'm working for a company whose product is medical/diagnostic software: to design this software I have researched competitive software, and I have (necessarily) learned the medical knowledge that this software will incorporate ... this (product/domain knowledge needed to define what the product is) still has to come from somewhere! And, we have some (precious) doctors involved who can help guide us re. the required functionality.
Permalink Christopher Wells 
March 16th, 2005
I would beg to differ. I think Product Companies, do create a  product which they (say Product Manager) have envisioned. This is because most of the time Product Manager is a tech savy guy himself and he can make sure that team is working on the *right* thing.

Now it's a completely different issue whether they should have created that particular product in the first place OR what features should be included in product release. I think in Product Company gap is between what you think your customer wants and what your customer actually wants. It's *very* similar to what happens in IT Services but there is subtle difference. As Joel points out, "no software company can succeed unless there is a programmer at the helm."

http://www.joelonsoftware.com/articles/Stupidity.html

JD
Permalink JD 
March 16th, 2005
> I think Product Companies, do create a product which they (say Product Manager) have envisioned.

Yes, and so do Service companies? They both face the same problem, i.e. a possible disconnect between ...

a) what the Product Manager has envisioned (high-level requirements) and the developers have implemented (detailed design)

b) what customers want, and are willing to buy and use


> This is because most of the time Product Manager is a tech savy guy himself and he can make sure that team is working on the *right* thing.

I don't need (or expect) my product manager to be a software developer. I need to them to know the market to the extent where they're able to tell me "if you can develope X, then we can sell it".


> If you ask me, and I’m biased, no software company can succeed unless there is a programmer at the helm.

He could even more easily say, IMO, that no software company can succeed unless there is a saleperson at the helm.
Permalink Christopher Wells 
March 16th, 2005
> [Product manager knows the market, isn't tech-savvy, specifies *what* the product is]

That's not to be confused with the architect and the project manager, who are tech-savvy and process-savvy respectively, and who sit between the product manager and developers in order to tell developers *how* to implement the product..
Permalink Christopher Wells 
March 16th, 2005
Actually, all that is needed is the *right people*. I mean, all you need is great salesman/CEO, experienced architect, smart developer and boom you have a winning combination! ;)
Permalink JD 
March 16th, 2005
Hmmm.

I think you all need to pick up the book "The Five Dysfunctions of a Team" and read it.
Permalink Peter 
March 16th, 2005
You *all*?

I think it's only two of us (me and Chris) talking here!

JD
Permalink JD 
March 16th, 2005
In Texas, "you all" is singular (means one person), and "all you all" is plural.
Permalink Christopher Wells 
March 16th, 2005
Well, then both of y'all should read it.
Well, then both of all you all should read it.
Well, then both of uhaul should read it.
Well, then both of you all should read it.
Well, then both of youse guys should read it.

Brought to you by the department of redundancy department.
Permalink Peter 
March 16th, 2005
-----"Client doesn't know if he wants a baby. May be I should rephrase it and say that Client wants a child but not sure whether it should be boy or a girl. ;)"------

But then again, maybe a replacement cat or dog would do the trick, and we all know that what he's going to end up with is a goldfish in a bowl.
Permalink Stephen Jones 
March 17th, 2005
This MUST have been linked to in here by now, but it repeats well:

http://www.kuro5hin.org/story/2005/1/28/32622/4244
Permalink trollop 
March 17th, 2005

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: March, 2005 Other topics: March, 2005 Recent topics Recent topics