Since its establishment, the company has also done many projects, some large, some small, some short-term, and some have been cooperating for a long time. And the customers encountered are all kinds, some are in arrears, some do not do half of it, and some are very happy to cooperate. Most of the projects we have done have been put into operation and have been well received by customers, but there are also some that need to be reflected and lessons learned.
Project 1: Industry products of traditional enterprises, mobile applications and PC management systems
Party A: For this newly established network technology company under the group, the staffing consists of one product manager, three designers, and two developers.
Development method: remote remote
This project is the first project after our company was established. It belongs to the kind of medium- and long-term pay-per-person project. Because it is just starting to do it by yourself, first of all, it must be based on the premise of survival. At the same time, it is necessary to hone the team and accumulate experience. The mentality took over this project.
Party A's company is subordinate to the group company, so funding is not a problem. The person in charge of Party A is also subordinate to the group company. It can be said that they know nothing about the Internet. The demand is still a semi-finished product. For a group of novices including us who just started outsourcing, the project progress is extremely difficult and slow. As a result, Party A makes our developers fly over from time to time to participate in the discussion of product requirements and the management of Party A's technical team. Although Party A pays this expense, it is really time-consuming and labor-intensive, and it may be the thinking of traditional enterprises. As a result, discussions must be met with people, and they are uneasy about remote communication.
In the process of development of this product, we gradually discovered the complexity of its industry. Not only is the development difficulty increasing, but also the demand changes are becoming more and more frequent. Sometimes it is exaggerated to the extent that after a version of the APP is completed, a word from the company boss, most of the The page design had to be overturned, and it was because Party A's project funds were abundant that they dared to toss like this. One of the things really opened my eyes. Party A let us fly over to discuss product solutions. I thought we were watching PPT in a small conference room in the past, but we were too naive. The large meeting of the leader and several small leaders of the group, each leader takes turns to speak, you come and go, the whole meeting is full of enthusiasm, and the conference room is full of smoke. There is neither any plan display nor some functional requirements. In the end, there is no Any conclusion, did a bunch of useless work. This kind of management of Internet companies with traditional corporate thinking is inherently problematic. Internet companies want creativity, efficiency and the ability to solve problems quickly, and such large-scale, time-consuming and meaningless meetings are the most taboo. This also lays a hidden danger for Party A's Internet technology company and the final product failure.
After more than 5 months of stumbling and repeated revisions, the first version of the product was finally launched. It is conceivable that the marketing effect and response were not ideal. The needs and industry pain points proposed by Party A were not what the users really wanted. The numbers never go up.
Summary of experience: Since it was our first project, the project was carried out in a hurry, and some aspects were not considered comprehensively, so in the process of cooperation, we were sometimes passive and did some work that was beyond the scope of Party B's development. At the same time, Party A's company lacks experience and the development needs are unclear, resulting in a certain degree of waste of time and capital. As Party B, we should give proper guidance in the development process, which is not good enough. When taking on this kind of project, the preliminary contract must be signed, the division of labor must be written, and then the requirements must be clarified to avoid rework and wrangling during the development process. However, this development experience is indeed a good experience for our team. It has honed the cooperation among team members, enhanced technology and problem-solving ability, and laid a solid foundation for future project development.
Project 2: APP side of smart home products
Party A: Smart Home Technology Enterprise
Development method: remote remote
This project was introduced through relationships, and the project funds were also negotiable. The demand and design were also very strong, so I was very relieved to continue. During the first phase, it was very smooth. The needs and functional requirements of Party A were completed on time. Anyone who has done such projects knows that the most troublesome thing is hardware debugging, and sometimes they have to fly over to do on-site joint debugging. , the first phase was launched on time, and Party A also cooperated very well. Every part of the funds was in place on time, and the initial cooperation was very smooth.
After the first phase was launched, we began to determine the requirements for the second phase and signed the contract. The second phase was mainly about adding and upgrading functions. Based on the cooperation in the first phase, we were very relieved to Party A, and there was no mandatory requirement to pay the advance payment first, but this is true became a major failure of the project. At the beginning, the development was in full swing according to the needs, and I didn't find anything unusual. I gradually found that it was a little bit stale. Some changes were needed to the originally set requirements. Well, since the previous cooperation was very pleasant, bear with it. Change it, and then there is a functional logic to re-do it. Forget it, so much has been done, let's continue to do it. In the end, the functions of the second phase were finally changed, the bugs were fixed, and the tests were passed, and I was waiting for the money. Party A proposed that their customers were dissatisfied with a function and needed to make some changes. After the changes, they would pay money. We were almost scolded. In the end, there was no way to do it. I thought that I could finally get the money after this change, but I didn't expect that there would be some moths, and so, over and over again, a little function was changed, and a few bugs were changed. The money was not given, it was dragged on like this, and finally it was a bolt from the blue. Due to the unsatisfactory product promotion of Party A, the operating cost was too high, and no one took over, the company went bankrupt directly, and the money for the second phase was completely hit. I was thinking about flying over to go through the legal process, but because there was a relationship in the middle, I felt that it was too time-consuming, labor-intensive and expensive, and at the same time I had a project at hand that I couldn’t get out of, so I had to let it go. It is to pay tuition fees, and it is a big lesson to buy.
Experience summary: No matter how many contracts are signed, no matter whether there is any relationship between the project, one code is one code, and advance payment must be paid. This is the minimum. Make sure your own interests are not infringed, so as not to suffer dumb losses. A small company like ours really can't afford to toss it, and the pro test is effective.
Project 3: A complete solution for a relevant system of a government department
Party A: a technical service company
Development method: remote development in the same city
This project was developed by our technical team entrusted by Party A, without any technical developers, just an intermediate role in demand collection. The contract is also signed with Party A, and the project payment is paid in installments. In the early stage of the project, we mainly communicated with Party A and relevant personnel of government departments, sorted out the project requirements, and determined the final implementation plan. Everything went smoothly. We first produced the UI design drawings, and the products involved include Android, IOS, and WeChat public accounts. , PC-side website and management system, and crawler system.
In fact, when this project started, we were also conflicted in our hearts. We have learned from some colleagues that doing government projects may involve a lot of work, communication costs are too high, and sometimes we need to move around. But there is Party A in the middle. We thought that we would only act according to the contract with Party A, so we relaxed our vigilance. With the development of various terminals, problems will follow. The leaders of government departments feel that this is not good, and that there is a need to make changes, so they put pressure on Party A. Party A relies on this to survive, so they can only accompany Laugh, and then communicate with us to change some functions. At first, we could accept it once or twice. Later, it became more and more frequent. I felt that the contract signed was useless. The leader said a word, and Party A came to us. Stop the development and let Party A handle it by itself, because the further the development cycle is, the more unfavorable it is for us, and the time cost is too high.
Finally, the development and testing were completed. When the government department accepted the acceptance, a big problem came. The government department changed its leadership team, and the remaining 30% of the project funds were about to be received and were taken back. As soon as the leadership team changed, Party A had to move around again, re-demonstrate and apply for acceptance of each product. In order to cooperate with the acceptance, we made some changes to some of the requirements put forward by the new leadership. When the acceptance was finally started, the government department again The requirements document began to pick faults, word by word, but there are indeed some deficiencies in the system. Although it does not affect the overall function, it cannot pass the review. In this way, you are going back and forth. The 5-month construction period has not been delivered for almost a year. There is no way to do it. Now it can only be consumed like this. So far, this project is a failure.
Experience summary: You must be cautious when accepting government projects, unless you have a very hard relationship, and you really can't afford it in time. If you have to accept it, you must increase the upfront payment to reduce your own risks. Secondly, when reviewing the requirements document and signing the contract, you must check it carefully, write what you can do, and try not to write what you can't do that is not in the system, so as to avoid functional defects, and ultimately both sides will suffer.
Although the above are some less successful cooperation cases, but these are only some cases, most of the parties still keep their promises and act according to the contract. However, I think that you must first be upright, technically strong, and not deceive customers, so that customers can trust you, and secondly require customers, so that you can gain a firm foothold in this circle, cultivate a good reputation, and ultimately survive and develop. It is true that outsourcing projects have certain risks. If you are not careful, you will be empty-handed. Take the following points to ensure that you do not overturn or avoid overturning. When signing contracts or agreements, you must be careful and pay advance payments according to project conditions. Less risk, less points, needs must be clear, try to avoid changing! I have never taken over a project on Yunwoke before . Later, I heard from my peers that the projects on this platform are very reliable. Not only are the projects true, but they are also funded. Later, I took over a few projects. We build a high-quality technical service provider.