The author has the honor to join the smart camera team for more than a year. Based on my own shallow experience, I will briefly talk about: For project management, what is the difference between the development of smart hardware products and ordinary Internet products, and what areas need special attention.
First: the iteration cost of hardware products is much higher than that of software.
It is reflected in two aspects: on the one hand, the R&D cycle of hardware products is long, and on the other hand, the R&D cost of hardware products is high. The main reason is: the overall design of hardware products affects the whole body. Even if it is modularized, if some changes are made to the function/design, such as changing Latest Mailing Database the connection method of a hardware device from Bluetooth to wifi, it is very likely that It will involve changes to the pcb board, which needs to be redesigned and produced before the effect can be checked; for software, even if it is a global change, the modification cost is relatively small, and there is no time to wait for production.
Therefore, the idea of "running in small steps" commonly used in Internet product development is not necessarily applicable in hardware research and development. The author's experience is to consider the rationality, accuracy and subsequent production efficiency of hardware design as fully as possible in the early stage of research and development. Instead of modifying the design draft multiple times during the development process.
Secondly: Based on the above situation, the version rhythm and function arrangement of software development need to fully consider the cooperation with hardware .
For pure software Internet products: as long as the current requirements are sorted out and sorted by priority, the version cycle can be fixed gradually according to the development rhythm of the team (such as one iteration every two weeks), and the requirements can be arranged according to scale and priority. Go into releases and deliver them at a fixed rhythm.
However, software development involving hardware is likely to be affected by the delivery time and version of the hardware, and some originally planned functions and interfaces may also change. Therefore, the content of the version delivery and the version cycle need to be flexibly adjusted according to the hardware conditions. , you can consider managing interdependent functions separately, or adjust the scope and time of version delivery as needed. For smart hardware development teams, embracing change is even more needed.
In addition: Version scheduling needs to consider the time and risk of joint debugging of software and hardware .
A special point to be mentioned here is that intelligent hardware products involve software and hardware interfaces, and interface specifications need to be defined in advance to avoid problems with joint calls caused by interface problems.
However, even if this is achieved, there is still a relatively large risk in the joint debugging of software and hardware. Whether it is compatible, whether the firmware (that is, the software system in the hardware device) will cause the software to crash, etc., all need to be fully tested. Therefore, it is also necessary to fully consider the risk and impact of joint debugging when version scheduling, leave enough time to deal with problems, and prepare for risk response as much as possible.
Finally: the functional definition of an intelligent hardware product usually affects both software and hardware .
Defining a product function, or changing a function, needs to consider its impact on both software and hardware as a whole, and make associated adjustments and changes.
For example, if the night vision module is removed in a smart camera, it seems that only the hardware has been changed, but in fact, the software needs to be considered. Without this function, the night vision related interface, the switch button and operation prompt of this function, Whether it is necessary to make corresponding adjustments, and identify camera versions with different functions, so as to better match the functions of different versions of hardware.
Another example is the firmware upgrade of smart hardware products. It seems that only the OTA (automatic upgrade) module needs to be added to the hardware, but the corresponding upgrade page also needs to be added to the app. If there is no overall consideration, problems will arise.
In fact, there is the most important point: the details determine success or failure .