How to refer a site to a friend without quarreling
This article is perfect for those who are just planning to send something to a friend or have already started working on a project. In it, I will describe what things are best discussed in advance so that you successfully complete the project.
A little about myself
I'm a front-end developer, mentor, and have been making Angular websites for money for 5 years now. Worked as a freelancer, in large companies and in startups. In addition to my main job, I completed 8 side projects. The mistakes I made became the basis for this article.
I am not a lawyer or a professional at negotiating with people. I learned how to communicate with people, mentored, worked with specialists, but I’m just a developer. I love writing code and getting paid for it.
Agreement
Ideally, yes, but that is not the subject of this article. A contract is a win-win when you do something for money. But we still just want to help someone, right? Imagine that you asked a good friend to help with some difficult matter, and instead of saying “ok,” he gives you several pages of some reading about responsibilities and obligations. That's right – yes. Comfortable – hardly. Even if he reads it, at the end there will still be a lot of questions “why” and “why”, believe me.
Let's just help the person.
Tell us what development is
Tell him what your job looks like while you go to the coffee shop with him. Tell me, for example, what you need to do for him to see a new feature. Or what the process of finding and fixing bugs looks like.
Yes, our goal is to make a product that satisfies our customer. But our customer knows nothing about how it works from the inside. Of course, to see beautiful pixels in the browser, he doesn't need to know what's under the hood. But in this way, you will immediately cut off a bunch of “why?” questions.
“Why can’t you move this block a little to the right for me at 10 pm?”
“Why is there a bug on our website?”
All this can be discussed in the course of everyday communication. It won't take much time, but it will give the customer a little insight into what's going on.
Determine the scope of work and remuneration
Discuss what exactly the customer wants. Record this. What it should look like, in what time frame he wants it and when the work is considered completed. Draw up a site diagram, a rough view and ask questions.
Based on this, estimate the cost of the project. Also, don’t forget to estimate the cost of the edits.
Ask for help with requirements gathering
Find someone to help you collect requirements from the customer. If you have been in IT for some time, then you probably know product owners, managers or leads. Whatever you call it, such a person will help you a lot.
The fact is that after the first month of development, you will understand that collecting requirements, running them and collecting feedback is an extremely difficult and exhausting process. Don't underestimate this part.
Therefore, such a person will save you a lot of time and effort. They can be spent on development.
Record your progress
Create a task tracker and enter each requirement there. Create a chat and try to discuss everything related to the project only there. Treat the customer's wishes responsibly and respectfully.
Try to work according to the principle:
Collected requirement
Created a task
Done
Collected feedback
And so on in a circle. This way your work becomes more transparent for you and for him. Your work should always be recorded.
Move with small releases
Agree to develop the site in releases. For example, once every 2 weeks.
This point follows from the previous one. By moving in small steps, it will be easier for you to track your progress and record it.
Determine product support timeframes
After release, you cannot support the product indefinitely. No one can stop you from doing this. But I think you don’t want to receive a message a couple of years after the release, when you’ve already forgotten about this project and are working on another one, saying that there’s such and such a bug in the admin panel if you do this and that.
Think about how long after release you are willing to support the product for free. After this time, fixes are paid. This way you don’t fall into the trap when the customer thinks that you will fix his online store for free for the rest of his life, because you once wrote this code.
Conclusion
I will be glad to receive criticism. Thank you.
