Wednesday, May 2, 2007

The eternal fight

It seems like there is always the eternal struggle between dev's and the "non Dev's". You know what i am talking about.
BA's who give innaccurate or incredibly loose requirements yet want you to build a something exactly how they or the customer want it...
PM's who want you to do something that will take 5 weeks to do it in 1 and after you pull uber over time to finish it they then think they were right, it did only take 1 week... and it your fault that it hasnt been tested properly or fully completed...
Sales people who promise the earth and have no idea what nightmares they are putting the team into.... etc etc

And poor old us. The developer gets to shoulder the brunt of it... well so we think. A couple of things happened today that got me thinking, if the average Dev could properly comunicate then alot of these issues could be reduced. Firstly if there is a technical person who will be directly involved in the dev at the time of scope to check everything is on the right track... that may help (in the last 12 months I have been gob smacked how often this doesn't happen). Hell, if the techincal person is presentable and articulate, let him/her come to the scope meetings or be involved in the sales process. Gee that sounds good! In my mind this is a double win, if handled properly. Then the major dev issues come up early, and if they dont, then it was missed by the dev anyway who can no longer point the finger.
Also picking your battles is always something we should be aware of. If you bitch and moan about everything, when i comes to a major issue the PM (or whoever) will just roll their eye's as if to say 'not this again'. Help the non devs to understand the business reason behind your arguement (delivery times & budgets are always good), after all you are suposed to be on the same side!
Its not all doom and gloom. I have been lucky enough to work with great teams such as Neotek, where although conversations got heated, they never got personal and it was always with the intent of making the code, product of processes better. Also the team i work with at Change are a very smart bunch for very different backgrounds where i would like to think we asa collective are learning alot from the others in the team (well I am!).
In short, just because you are a developer doesn't mean you have to be a nerd. Getting people on side with you early on is a big help when things get tight at the tail end of projects (or even just iterations!).

sorry just a bunch of random thoughts, but i thought i would throw them out. :)

No comments: