Prompted by a mail from Transfer Intelligence I’m re-running my 2005 Transfer Customer Service test. Results to be posted in a couple of weeks!
Incidentally we used Snow Trip last year who were great. Only complaint was there was barely room for us and our luggage in the coach on the way home. We all got in though so all’s well that ends well
PS: If you quote “TINFAM” to Transfer Intelligence you’ll get a 5% discount if you pay at the time of booking and book by email before the end of November
/Snowboarding
/Snowboarding
I came accross this article by Zarar Siddiqi that I think boils down to the relationship between a developer and a Project Manager (PM) or Business Analyst (BA).
In some organisations there is a ‘them’ and ‘us’ culture which is fatal to any project. The whole project team is responsible for making the project happen. The situation he describes is certainly flawed and I agree that the PM has to take ultimate responsibility for the failure of the project (this is after all their job). However as developers there is a lot we can do to help beyond delivering to the spec on time
The first problem is one of misunderstanding/poor communication. This is tricky to rectify because it depends on the attitudes of the PM/BA in question. In an ideal world they are approchable people and welcome the fact you’re making an effort to clarify and agree requirements before during and after building them. If not you need to carefully explain the ramifications of getting it wrong (their bonus/pay/reputation is reflected by the success too!!)
The second problem is related to non-developers (understandably) not understanding the impact of changing or adding a requirement late in the project life-cycle. This is made worse by the fact that some changes are easy, some aren’t and a non-developer usually can’t tell between the two. This is simple to fix! Everytime I come to one of those points where a decision will fork my code off in one direction or the other I sit down with the PM/BA and explain the options and the estimated effort if we go the wrong way. This can be as simple as “Option A is easy (2-3 days), Option B is hard (10 days), if we need to change our mind it will be another 10 days”. They neither need to know or care why.
In summary: Keep talking, make sure everyone understands what you’re doing and how hard it is to change, be honest and deliver on time.
/Technology
/Technology
Recent Comments