The below are only the points.
Read the original article in [www.littletutorials.com].
Really awesome.
In fact, the author of this article inspired me to restart my knowledge sharing activity and started writing few thing in the web.
Sec-1:Set yourself up for success
Read the original article in [www.littletutorials.com].
Really awesome.
In fact, the author of this article inspired me to restart my knowledge sharing activity and started writing few thing in the web.
Sec-1:Set yourself up for success
- Define early on what success means for you, the team and the business
- Believe in the project: idea, architecture, time, team
- Understand the domain, the business requirements and the technical challenges
- Know your team: strengths, weaknesses, ambitions and personalities
- Have a plan as a result of a planning activity
- Be part in the design of everything
- Get your hands dirty and code8. Act as a communication proxy for your team
- Make sure everybody understands the big picture: their work has implications
- Fight for architecture and design consistency
- Know the status of everybody’s work and detect slippage
- Record technical debt if you need shortcuts but try to maintain architectural integrity; report the debt
- Use the process that makes sense in your particular case
- Avoid dogmas - question why everything is done the way is done; make sure everybody else knows the reasons
- Avoid design by committee; listen to everybody but make your own decisions
- Gain the team’s respect with the quality of your work and by doing what you are preaching
- Be fair
- Admit your mistakes
- Publicly recognize both team’s and individual members’ merits
- Don’t blame anybody publicly for anything
- Build morale and confidence by offering early victories to the team and to its individual members
- Match people and tasks based on skills and their personal preference if possible; explain your decisions
- Work the estimates with the team don’t come up with them
- Mentor people
- Listen to and learn from people
- Explain your technical decisions
- Be sure you have authority along with responsibility
- Be sure you get requirements and not architecture/design masked as requirements
- Explain technical decisions in business terms
- Try to be accurate in your estimates; avoid being too optimistic and don’t push it with hidden padding; explain the need for padding
- Set reasonable expectations
- Understand the relationships and dependencies with other teams or projects
- Accurately report the status with alarms, explanations and solutions; report any technical debt
- Resist pressure for change in requirements, and more important for shortcuts
- Be aware of politics
- React to surprises with calm and with documented answers
Thanks!
Comments
Post a Comment