Teamwork follows its own rules. It requires much more effort from the developer than individual work. It is crucial to understand others and make yourself understandable as miscommunication leads to frustration, decreased motivation, poor quality, delays and can even cost big amount of money. This presentation tries to explain the significance of efficient communication in IT projects using simple real life examples. It shares observations and experience gained while working on a project with large number of specialists, not only developers. Finally, it offers some solutions that can be helpful in dealing with communication chaos.
8. Sources of communication problems
• variety of people
• different perceptions & viewpoints
• different domains
• language barriers
• people rotation
link czy coś
13. Communication with testers
• Use bug tracking system (Redmine, Jira)
• Omit direct emails - they are evil!
• Agree best form of tickets
• Establish common jargon
• Set proper bugs priorities
14. Communication with testers
• Use bug tracking system (Redmine, Jira)
• Omit direct emails - they are evil!
• Agree best form of tickets
• Establish common jargon
• Set proper bugs priorities
15. Communication with testers
• Use bug tracking system (Redmine, Jira)
• Omit direct emails - they are evil!
• Agree best form of tickets
• Establish common jargon
• Set proper bugs priorities
16. Communication with testers
• Use bug tracking system (Redmine, Jira)
• Omit direct emails - they are evil!
• Agree best form of tickets
• Establish common jargon
• Set proper bugs priorities
17. Communication with testers
• Use bug tracking system (Redmine, Jira)
• Omit direct emails - they are evil!
• Agree best form of tickets
• Establish common jargon
• Set proper bugs priorities
26. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Require feedback or more autonomy
• Set priorities (needs vs wants)
27. „Without requirements or design,
programming is the art of adding bugs to
an empty text file”
Louis Srygley
28. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Require feedback or more autonomy
• Set priorities (needs vs wants)
29. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Require feedback or more autonomy
• Set priorities (needs vs wants)
30. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Require feedback or more autonomy
• Set priorities (needs vs wants)
31. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Set priorities (needs vs wants)
• Set priorities (needs vs wants)
32. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Set priorities (needs vs wants)
• Require feedback or more autonomy
33. Communication with business
• State requirements (Preserve things in writing)
• Avoid technical conversation :)
• Visualise things
• Inform about possible delays
• Set priorities (needs vs wants)
• Require feedback or more autonomy
• Inform about progress (Gantt, Kanban)