tim norton
Posts: 1
Nickname: free2form
Registered: Jun, 2004
|
|
Re: The Tortoise and the Hare
|
Posted: Jun 10, 2004 8:40 PM
|
|
I have hope for all the cause that we are all aiming @, a day when business and all its functional constituents engineer a position where it delivers high quality software which meet time to market & business continuity requirements.
In the comments, noting Mike Spille i see signs of a critial bridging role which will continue to further aid how we as people collectively work together to create better software and business applications; someone technical with a fuller appreciation for the realities of business and the difficulties of managing 'overall business success' in light of the product being software.
As someone who has to for reasons of maintaining 'business balance' kept a deliverable/product focus while always striving to increase quality and longevity of software outputs, i have a different yet complimentary view from the core article body presented here. Although i may not be able to do the actual yards required, as a technology business person endevour to create the organisational and business environment that enables this; such as getting the capital to employ those who can directly increase quality, secure initial customers and deadlines which will give the product momentum and exposure so that there will be time for additional review and focus on process. From here their can be a future with more empathetic customers who will be more understanding of the quality issues we face as software development companies trying to meet their often tight deadlines. I have come to learn that customers can grow to understand to appreciate the value of quaity in the underlying application they are buying into, but to get them there a relationship of customer fcused deliverables has to first be built. Something often only seen on the front line with the customer.
I often find myself a little isolated with teams of highly technical people who for valid reasons of facing the hugely complex task of deisigning and building the software that delivers the marketable application, find it at times difficult to empathise with what are in the current world framework, relatively fixed business requirements.
The negotiation which goes on with clients is not always ignorant, the discussions of mgmt not always naive to the the downfalls of doing things fast, but when considering things strategically, and ensuring the business is a going concern with acceptance from customers and shareholders, quality of the software which is no doubt a huge part of the businesses asset, still in the end has to remain just that, a part! In the end the right customer relationships are also as huge an asset, and securing these desired relationships almost always comes with short term demands and time to market soon becomes the 'current top priority'. Flexing your powers of persuasion and asking customers to understand your position as a vendor 'and' the reqests of your developers, often has to come in the second round , as customers unfortunately firstly expect you to open your ears and not your mouth ; )
Although often spoken ignorantly, these are not just words for ignorant marketing & sales exec's, these are realities of the business world, not to say they need drive everthing, else we would just create rubbish software delivered on time, but they play more of a factor than is often understood by software developers when a software development business makes decisions.
My experience suggests this gap in understanding, which i am only suggesting is a two way street, not the one way suggested in the guts of this article, is exactly the issue that creates the conflict and unhappiness i can hear through this article, and experience with developers.
Business people need education to appreciate the realities of software development and its absolute cornerstone/primary value in building a sutsainable business, and the fact it is no simple thing. While this is true we need to acknowledge that take-up is limited and need to focus on the issues preventing take-up. Maybe as the leaders of this change developers might start to consider the importance of themselves understanding the fuller business environment, and the factors that influence the decisions that come to burden them so much; such as 'unrealistic deadlines'
Maybe the business was faced with the challenge of :
'its unrealistic to deliver this application in the extended/desired time frame of the developers and still keep our customer/revenue, therefore it is unrealistic that we shall continue as a going concern' the outcome of this i am sure is clear, there is no business and no continued development.
I speak of this from nothing short of real experience, where this extremely difficult challenge is what management was/is faced with.
Perhaps it really hurts certain technically oriented business people to see a piece of software hacked together, perhaps they can see how it comprimises there business & product strategy, but perhaps they also have little choice, as faced with making adecision they are left in isolation to make the best one for the business as developers remain only concerned with quality and longevity of the software, not longevity of the business.
|
|
Previous Topic
