Too often I get a plea for help wherein a development/delivery manager runs into problems taking a system into production. Guess most often where they run into trouble .. yep ! Performance.
When questioned about the technical details, same old pattern. Lack of understanding of underlying middleware, database, 3rd party tools etc.
When a team displays such a lack of understanding, what I hear is the team saying to me - "I can code it, however, I don't know how to actually make it work !"
Performance considerations are intrinsic to good development practices & design. While a focussed effort on performance optimization for a week using a highly skilled team always yields amazing results, it is a bad idea to deliver under that assumption.
This is often the simple difference between average and good teams.
3 comments:
Hi Milan,
one factor which influence in deciding whether the team is good, average or execellent is "Time", isn't it.
In every team only 30-60% people understand what is the requirement out of which, 50-60% understamd what to do, out of which only 30-50% understand how to implement it. it becomes hectic to make other understand how to implement, but for this an extra time is requirement, which unfortunately is not available.though if they take out time to make others understand, then again question comes how much they understand and how they gonna implement.
According to me the first and foremost thing Gaint IT organization should have is PROCESS, it should become a habit.
Most of the Gaint E2E projects have more
1) Politics than Process
2) Complaints than Compliments
3) Favouratism than Focused
....
regards
srikanth@techie.com
Well , I would say "Time" is not a deciding factor whether a team is good or bad. I believe Its a completely wrong parameter to measure the efficiency of a team. Charecteristics of a good team are
-Everyone participates actively and positively in meetings and projects.
-Team goals are understood by everyone.
-Individual members have thought hard about creative solutions to the problem.
-Members are carefully listened to and receive thoughtful feedback.
-Everyone takes initiative to get things done.
-Each teammate trusts the judgement of the others.
-The team is willing to take risks.
-Everyone is supportive of the project and of others.
-There is plenty of communication between team members.
-Team decisions are made using organized, logical methods.
-Full team acceptance is expected as decisions are made.
-Dissenting opinions are recorded, and may be revisited if future situations dictate.
-Team goals are given realistic time frames.
-Everyone is focused on the ultimate goal of the project, while also digging into the underlying details
Communication is very important. In your example ,When 30-60% in a team has good understanding of a requirement why are others not having it.
Team should be always open to ideas and oppertunities than talking process all the time..
Most of the Giant IT services companies have a big fundamental problem today. Most of the teams have lot of freshmen & freshwomen (to be politically correct). Most of them under-go a 3-6 months of training and are put on the LIVE project and will bill the customer for their On-The-Job Training.
What is the incentive for the team to really understand the system issues affecting the business? Nothing ....
Moreover, to mask this issue most of the companies are moving to Fixed Bids. Though the risk is passed on to the vendor /partner, the team members still do NOT learn the basics.
Why would they ever look at improving the throughput or look at making the system scalable or resilient unless mentioned in the contract and governed by strict SLAs. The customers are becoming smart but these companies are becoming smarter.
All the best.
Post a Comment