Guides

Guides is the best source of information if you are interested in the technical details how our engineering team delivers quality software.

Client developer communication

In most of our projects, developers communicate with clients directly on Skype, email, and Redmine. There are a few important rules that developers should follow when talking to clients.

Responding to direct requests from clients on Skype or email

Our goal is to be as responsive as possible. When clients ask developers about a specific feature, a bug, or a question about the project in general developers are expected to answer as soon as possible:

  • The developer who is most familiar with the feature in question should answer the request.
  • If the first person who notices the question is not the person who is most familiar with the feature in question, he/she should ping the appropriate person in the office.
  • If the answer could not be given at a given time (i.e. answer needs to be researched and it will take some time), the client should be informed about it. Simple ‘looking into it’ is enough.

When developer who is expected to answer the question is not available (i.e. not in the office)

If the matter is urgent and the developer who implemented the feature will not be available in a reasonable amount of time, a responding developer should do his/her best to find the answer for the request. This may involve:

  • Asking other available team members for help or information.
  • Getting familiar with an unfamiliar part of the project.
  • Reaching the developer who has implemented the feature.

If the client does not indicate that the question is urgent and the question has been asked after working hours, developers may leave such questions unanswered until the start of a work day.

Responding to bug reports

After the cause of the bug has been identified and time needed to produce a fix is estimated, developers should think about the issue on production servers. Sometimes it might be beneficial for the client and the product to have developers fix live data or apply a temporary fix first and only then start the development of the bugfix. It is especially true if a small amount of effort is needed to produce a quick fix that impacts live users and time needed to produce a generic fix is significant, i.e. requires non-trivial refactoring.

If it is unclear whether it is best to start working on a temporary or general fix, the client should be informed about the situation.

Recognizing unexpected behavior

Sometimes developers notice unexpected behavior in the project. When this happens, the first thing to do is to recognize whether this behavior needs fixing and if the fix can be determined by developers alone. Check the backlog to see if this behavior has been identified by others before. When it is unclear if or what kind of changes are needed, the client should be asked for instructions. Finally, when the course of action is known, a ticket in the backlog should be created.