At Usersnap we strongly believe that an improved feedback and communication process will save you (and your team) a lot of time spent on communication in your development process. Picking the right communication tools does not only directly result in better workflows but also affects the time needed to fix a bug which is particularly important if you are publishing your code continuously.
Communication: Development costs’ secret hideout
Phone calls, meetings, IM chats and screen sharing sessions are efficient ways to discuss bugs and planned improvements of every software development project. There are two stashed requirements here: two people need to communicate at the same time. This is not a roadblock if you are sharing a desk but it can be a challenge if you are working in a distributed team or if you simply don’t want to interrupt your colleagues.
On the downside, one-on-one communication is only effective if nobody else needs to be involved after the topics have been discussed. As the famous group intercommunication formula for a team of N people still is N*(N-1)/2, even small teams should focus on effective communication to reduce the communication overhead.
If you are working in a startup environment (e.g. a team of 10) and take into account that some issues will be reported by your customers (e.g. +10 people you should listen to) you easily end up with 190 possible combinations of one-on-one communications streams. Online SaaS productivity tools like bug trackers and project management tools are basically striving to solve this problem by enabling people to communicate in groups, asynchronously. Anyways, the root cause of misunderstandings lies somewhere else.
The inconvenient truth about bug reports
Well, crafted bug tracking tools help you to keep up with the communication challenge. However, in the end, clients will send bug reports and feature request by email which will lack the context of the perceived bug and might read as:
“The blue button does not work”
This is exactly what’s perceived but there is little help here for solving the bug as it requires to guess the context of this bug. Specifically, in web development, it is common to deal with browser-specific bugs (“It works in Chrome but not in Internet Explorer”). Also, the rise of responsive web design introduces another important information to reproduce perceived issues on web project: the current user’s browser size. Developers know what’s necessary to reproduce a bug but clients and users who want to report bugs may not understand why a good bug report necessarily needs some contextual information.
If you are exceptionally lucky those emails might contain a word document with the collected issue or even a PowerPoint presentation with sketches of your clients’ suggested UI improvements. Continue Reading “Save Bug Fixing time with Usersnap” →
