In this article we will talk about three important points that should be agreed on shore with the developer / studio. These rules have saved our clients money, and us nerves.
Downtime
Imagine that you are working with a developer/studio/contractor using the T&M format (in a previous article I wrote about the pros and cons of this format). In this format, the performer receives payment for the hours spent on the project.If a studio hires developers on staff, then it pays them a fixed salary per month. In other words, the company buys ~160 working hours per month from a person and tries to sell them.If the company did not sell part of the watch, then it lost money. This forces the company to rush development or set a minimum limit by the hour.
CEO along when developers are idle
It takes time to come up with and test features, which you will not have in this format of work. Every day of delay creates tension between you and the contractor.If you don't have huge budgets for a product, then pay developers for working hours. Agree on who will pay for downtime and how you will solve related problems
Engagement
A third of our clients abandoned the previous team due to low engagement. And no, engagement is not about overtime on weekends and not about "being in touch 24/7".
Engagement is the desire and ability of developers to think about the meaning of what they are doing. The customer does not always make the right product decisions. Look for developers who will argue with you and prove you wrong.Such developers can cost more, it can be more difficult to work with them, but it's worth it. Look for studios that allocate you a manager who can manage the product, not just the project. Involve a system analyst in the project, if possible.Discuss the level of involvement on the shore: will the developers argue with you, or just work according to your TOR?
Engagement is the desire and ability of developers to think about the meaning of what they are doing. The customer does not always make the right product decisions. Look for developers who will argue with you and prove you wrong.Such developers can cost more, it can be more difficult to work with them, but it's worth it. Look for studios that allocate you a manager who can manage the product, not just the project. Involve a system analyst in the project, if possible.Discuss the level of involvement on the shore: will the developers argue with you, or just work according to your TOR?
No micromanagement!
Micromanagement is a management style that implies the control of each step of the performer. Micromanagement from the customer appears due to lack of trust and creates a toxic atmosphere. In order for you not to have the desire to micromanage, create transparent and convenient project management tools.
I advise you to collect product requirements in Google documents and work out proposals through Google comments — so they will not be lost.
Comments on design/UX/animations can be left as comments in figma — by analogy with Google docs.
Ask the developers to set up an automatic pipeline for publishing the app in TestFlight (for iOS) or generating an apk (for android). We receive feedback from the client with each new release. The customer looks at the result of our work at any time and in any place.
If you work by the hour, then create a transparent reporting process. Ask developers to use trackers and collect reports in hours in one place. We use Clockify (Toggle is also a great option). You don't have to ask the project manager every time about “how much money we spent".
Comments on design/UX/animations can be left as comments in figma — by analogy with Google docs.
Ask the developers to set up an automatic pipeline for publishing the app in TestFlight (for iOS) or generating an apk (for android). We receive feedback from the client with each new release. The customer looks at the result of our work at any time and in any place.
If you work by the hour, then create a transparent reporting process. Ask developers to use trackers and collect reports in hours in one place. We use Clockify (Toggle is also a great option). You don't have to ask the project manager every time about “how much money we spent".
At the same time, try to trust your team and not bother with constant questions in the spirit of “why did this task take 5 hours, although we planned 4"? I wrote about trust in the first part of this article.
What should we agree on?
Agree on who will pay for downtime. Are you willing to pay for them?Agree on the level of engagement. Are you ready to give developers the freedom to make decisions? Agree on transparent processes so that you don't have to micromanage. Are you ready to trust the developers?