From System Performance Optimization to R&D Process Improvement: Measuring and Optimizing Workflow

Many technical professionals work hard, take on increasing responsibilities, and are promoted to management positions, yet they often lack formal management knowledge and continue to operate as individual contributors, causing delays in their core duties.

After extensive reading, they become R&D supervisors while their technical skills fade, prompting the question of whether technology and management are completely separate paths. The answer is no; both require quantitative analysis and global optimization.

An illustrative scenario involves a program running on a ten‑server cluster that processes image recognition tasks. Business volume increases, and the boss asks for optimization. Various suggestions arise—upgrading the database, refactoring code, adding servers, or moving to the cloud—but the first step is to measure the current situation.

The first measurement step is to understand the program’s function and workflow.

The program’s architecture processes images by receiving them via a network port, extracting information, comparing against an image library, and outputting similar images.

Metrics are collected: 1 000 000 images per day, recognition takes 0.5 s per image, and comparison takes 0.4 s per image.

From these numbers, processing one image takes 0.9 s; a single server can handle 96 000 images per day, so the ten‑server cluster can process only 960 000 images, falling short of the target. Approximately 11 servers are needed.

Rather than immediately buying more servers, the analysis shows that recognition and comparison run serially, leaving GPU and database resources under‑utilized.

By splitting the program into two services connected via a message queue and deploying them on separate servers, the architecture changes.

New throughput calculations show that the recognition service (Program X) can handle 172 800 images per server per day (requiring about 6 servers) and the comparison service (Program Y) can handle 216 000 images per server per day (requiring about 5 servers), still totaling roughly 11 servers.

However, the new design reduces the need for GPU‑equipped servers from 11 to 6, saving significant hardware costs.

The architect further suggests increasing the concurrency of the comparison function by four times, which raises its throughput dramatically; now only about 2 servers are needed for comparison, bringing the total to 8 servers (6 GPU + 2 non‑GPU).

This technical optimization example demonstrates that enterprise management follows a similar process: measuring workflows, identifying bottlenecks, and optimizing the overall system rather than isolated parts.

An example of a defect‑resolution process in a software company shows multiple handoffs among operations, development, and testing, each causing delays and wasted effort, highlighting the need for a value‑stream perspective championed by DevOps.

The key lesson is to first clarify the entire workflow, measure it, and then perform holistic optimization; local tweaks without a global view can be counterproductive.

Unlike IT systems, business processes are often vague, with unclear role definitions and responsibilities, making documentation and standardization essential.

Technical staff who transition to management have an advantage because they understand the actual workflows.

Once the workflow is clear, visual tools such as Kanban boards, resource‑allocation charts, and burn‑down graphs can be used to locate bottlenecks, and lean‑production methods from manufacturing can be applied to achieve substantial efficiency gains.

Author: 小陆 (Source: www.cnblogs.com/lane_cn/p/13685179.html)