2.3 Internal non-technical

发表于 | 分类于 | | 次阅读

2.3 Internal non-technical

2.3.3 Organizational

  1. 分工不合理（工作难度分配不合理、工作种类分工不合理）
    1. 及时根据当前工作进度调整工作分工
    2. 进行工作分工时跟技术人员沟通
  2. 运转资金不足
    1. 技术中心及相关设计人员慎重研究设计变更，减少设计变更造成的各种损失
    2. 加强设备管理，及时利用，减少浪费
  3. 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
    1. 进行技术决策时与技术人员进行有效的沟通
  4. 低效的项目组结构降低生产率；
    1. 选取一个有强领导力的管理者
    2. 设置一定的奖惩机制，激励员工提高生产率
    3. 对项目组结构进行一定的重构或微调
  5. 管理层审查 决策的周期比预期的时间长；
    1. 管理层审查应设置deadline
    2. 分级审查
    3. 定期向管理层汇报风险/问题
  6. 预算削减，打乱项目计划；
    1. 压缩生产成本
    2. 剪掉优先级低的需求实现
  7. 缺乏必要的规范，导致工作失误与重复工作；
    1. 项目开始前明确良好的规范
    2. 定期检查项目进行是否符合规范
  8. 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
    1. 若存在多方审批，并行进行，选取最优的审批方式
    2. 安排项目时间时预留一定的审查时间

2.3.4 Requirements

  1. 需求已经成为项目基准，但需求还在继续变化；
    1. 明确合同约束，建立需求基线
    2. 建立变更审批流程
    3. 明确和树立需求基线是需求变更的依据
    4. 小的需求变更也要经过正规的需求管理流程
    5. 客户下达变更的流程尽可能规范化，留下书面依据
    6. 分级管理需求变更
  2. 需求定义欠佳，而进一步的定义会扩展项目范畴；
    1. 需求分析工程中对于需求给出明确的定义，有明确的产出文档
    2. 制定需求的基线
    3. 分级管理客户需求
  3. 产品定义含混的部分比预期需要更多的时间；
    1. 项目开发的每个阶段应设置一定的监管，保证项目开发前相关的具体的需求文档已经形成
  4. 在做需求中客户参与不够
    1. 采用原型开发获取客户需求

2.3.5 Estimation

  1. 工作量工作时间工作进度预估错误：
    1. 动态调整工作的进度，实时跟踪项目的进度。
  2. 低估软件规模：
    1. 进行软件规模预估时应当结合历史数据考虑。
    2. 通过科学的战略评估防止评估错误的风险。需要依靠软件开发管理的专家来帮助项目更好地评估。
  3. 低估缺陷修复率：
    1. 提高代码质量和开发管理。

2.3.6 客户风险

  1. 客户对于交付的产品不满意：
    1. 加强与客户进行质量标准制定的沟通，统一双方的标准和检测方法
    2. 技术部门做好软件开发的安排，保证开发的进度。
    3. 产品经理加大与客户的交流与沟通，及时处理客户的需求和意见。

2.3.7 scope risk：

  1. 产品跨领域发展：
    1. Take good care of scope management.

2.3 Internal non-technical

2.3.3 Organizational

  1. Unreasonable division of labor (unreasonable distribution of work difficulty, unreasonable division of work types)
    1. Adjust the division of work according to the current work schedule
    2. Communicate with technical staff when performing work division
  2. Insufficient working capital
    1. The technical center and related designers carefully study design changes and reduce various losses caused by design changes.
    2. Strengthen equipment management, use in time, reduce waste
  3. Technical decisions are made only by management or market personnel, resulting in slow schedules and extended planning time;
    1. Communicate effectively with technical staff when making technical decisions
  4. Inefficient project team structure reduces productivity;
    1. Choose a manager with strong leadership
    2. Set a certain reward and punishment mechanism to motivate employees to increase productivity
    3. Make certain refactoring or fine-tuning of the project team structure
  5. Management review The decision cycle is longer than expected;
    1. Management review should set the deadline
    2. Grading review
    3. Report risks/issues to management on a regular basis
  6. Budget cuts and disruption of project plans;
    1. Compress production costs
    2. Cut off the low priority requirement implementation
  7. Lack of necessary norms, resulting in work errors and duplication of work;
    1. Defining good specifications before the project begins
    2. Regularly check the project for compliance
  8. Non-technical third-party work (budget approval, equipment purchase approval, legal review, security assurance, etc.) was extended beyond expectations.
    1. If there are multiple approvals, proceed in parallel and select the best approval method.
    2. Reserve a certain review time when scheduling project time

2.3.4 Requirements

  1. Demand has become the benchmark for the project, but demand continues to change;
    1. Clarify contractual constraints and establish a baseline of demand
    2. Establish a change approval process
    3. Clarify and establish a baseline of demand as the basis for demand changes
    4. Small demand changes also go through formal demand management processes
    5. The customer’s process of issuing changes is as standardized as possible, leaving a written basis
    6. Hierarchical management requirements change
  2. The definition of demand is poor, and further definitions will expand the scope of the project;
    1. A clear definition of the requirements in the requirements analysis project, with clear output documentation
    2. Develop a baseline for demand
    3. Hierarchical management of customer needs
  3. The ambiguous part of the product definition takes more time than expected;
    1. Each stage of project development should be set up with certain supervision to ensure that the specific requirements documents related to the project development have been formed.
  4. Insufficient customer involvement in doing demand
    1. Prototype development to obtain customer needs

2.3.5 Estimation

  1. Workload working time work progress estimate error:
    1. Dynamically adjust the progress of the work and track the progress of the project in real time.
  2. Underestimate the size of the software:
    1. Software size estimation should be considered in conjunction with historical data.
    2. Prevent the assessment of the risk of errors through a scientific strategic assessment. Experts in software development management are needed to help the project better evaluate.
  3. Underestimate the defect repair rate:
    1. Improve code quality and development management.

2.3.6 Customer Risk

  1. The customer is not satisfied with the delivered product:
    1. Strengthen communication with customers on quality standards, and unify standards and testing methods
    2. The technical department will make arrangements for software development to ensure the progress of development.
    3. The product manager increases communication and communication with customers and timely handles customer needs and opinions.

2.3.7 scope risk:

  1. Product cross-domain development:
    Take good care of scope management.
给咱来个🍰，啾咪