Skip to content

Latest commit

 

History

History
63 lines (53 loc) · 5.35 KB

time-tracking-how-to.md

File metadata and controls

63 lines (53 loc) · 5.35 KB

Time Tracking How-To

Please start by reading all the information about the time tracker that can be found in our [handbook] (https://github.com/reef-technologies/handbook#time-tracking).

Below you can find time-tracking rules which were co-created by company staff members.

How-To

  • As per a legal agreement, Reef Technologies only pays for the time that is tracked by the company's time tracker (Hubstaff as of writing this document).
  • Usually, we do our work in front of the computer, but if you need to sketch something on paper or do some deep thinking away from the computer, it is allowed required to track that time – as long as you're fully dedicated to a company project.
  • We stop the timer when we are not working. See examples below.
  • There are two types of projects:

Internal (RT / *) – the time is paid by the company
External – the time is paid by our clients

  • In case an external project has not yet been created in Hubstaff, or you don't have access to the right project, please use the special option OTHER / just-in-case, mention it to the project manager and rebill that time when you've been given access.
  • If you are working on an external project for the client, you should bill all your time spent on this project onto it. Knowledge gathering, environment preparation, actual programming, attending meetings, responding to emails, or working on the design – track it all.
  • If you need to learn a framework, library, or language to deliver value to the project, bill the learning to that project. If it took you a long time to learn a new skill, please mention it to the PM of that project. They will make sure it is billed fairly. For example, they may choose to discount the client for that week. This heavily depends on contract terms and is generally a tough decision, but please do not worry about it – that's what we have PMs for. They have the tools and procedures to deal with such issues efficiently.
  • If you think that in order to deliver better value for a project, it would be helpful to contribute to an open-source project first to, for example, fix a bug or add a feature, please first talk with the PM on that project.
  • The company doesn't care about activity levels ("activity level" in hubstaff web UI, estimated from mouse and keyboard events). We only use the time tracker to know how much we should charge the client and how much we should pay our staff. It shows 0% activity during most meetings, for instance, so it's practically useless, and so nobody looks at it (not just in Reef but in general).
  • You can add manual time, and inputting a reason is optional. There is no need to ask for permission, but if you make some changes to the time tracked to an external project in the past, please mention it to the PM. In some cases, an invoice adjustment may be necessary. If it is the same day, then there is no problem – this is about changing the time you tracked at least one day earlier.
  • Hubstaff tracks time by the second, so you don't need to work in 10 min time slots like with some other time-tracking tools (cough Upwork cough).
  • Please use Hubstaff to-dos, especially for external projects. It helps to have a more detailed history of our work in case we need it (our clients sometimes ask for reports – please allow PMs to provide them).

How-To use To-Dos

  • Group calls should be billed in related projects (RT / sociocracy S3, RT / status call) without to-dos.
  • All work done for external projects should be tracked in a to-do (that includes reviews, see the review channel agreement for more details).
  • The to-do name should contain a description followed by an issue tracker link.
  • If the to-do does not relate to a specific issue, try coming up with a descriptive name, like deployment, devops
  • Calls that concern a specific issue should be billed to a proper to-do
  • Work done for internal projects should be billed in to-dos if it's a major (3h+) development task.

Common cases:

  • If you're doing a lot of thinking for your task or during a call, and you need to get up and get yourself something to drink (even if it requires menial preparation labor, like coffee). If you spend the whole time thinking about your task/discussion, it is okay to leave the timer on. If you spend your time on other activities, the timer should be stopped.
  • If you're having problems concentrating because someone is messaging you every 5 minutes and you run into a dilemma like: "should I really be stopping the timer every 5 minutes for 15 seconds to reply?", the answer is: tell them you are at work now and you can talk later OR take a break, stop the timer, and discuss whatever you need.
  • Real-life example: Luke is coding for a project. He sees that Andrew asked something on Slack in #random about Luke's earlier post. Luke's reply is a simple yes or no, that doesn't take too much thinking. Luke does not stop the timer in this case. Luke remembers not to answer such messages very often (like every 5 minutes). Otherwise, his productivity will decrease.
  • Another real-life example: Same as above, only this time Luke's answer is a few paragraphs of text about his favorite board game genre. Luke stops his timer this time. If the discussion were not about a board game genre but concerned a code review or internal procedures, Luke would switch the timer to the appropriate project.