一、软件工程基本原理
著名软件工程专家B.Boehm在1983年提出了软件工程的七条基本原理，其中三条分别是：
1、用分阶段的生存周期计划进行严格的管理。
2、坚持进行阶段评审。
3、实行严格的产品控制。
第四条则是——结果应能清楚地审查。
把软件的开发过程拆分成多个阶段，使得每个阶段的任务相对独立，就可以实现不同职责和岗位的角色进行协作，从而降低了整个软件开发过程的困难度和复杂度。
下面讲讲敏捷开发和瀑布流开发
敏捷式开发的源头是定制软件服务
二、敏捷开发
1、产品经理就是项目负责人
2. 使用敏捷方式不等于不做产品规划
使用敏捷开发的过程中产品仍需要明确定义整个产品的方向和目标，设定产品里程碑，只不过在敏捷迭代过程中所有的里程碑尽可能缩短其周期，通过使用反复迭代与轻量级的机会评估方法代替冗长的市场机会文档等纸面材料；
3. 产品经理与设计师的工作应领先团队1-2两个版本以上
为了确保在项目推进过程中有足够的时间攻克技术上的难题，需要让产品与交互设计和视觉设计师提前完成产品设计，充分发挥三者在产品设计过程中的主导作用；
同时保证开发人员在产品设计与交互设计阶段始终处于参与状态及时反馈关于产品的可行性、成本与解决方案的建议，在问题的出发点就将其解决；
4. 尽量把产品设计拆分成独立的部分
虽然将产品拆分成多个模块，但是也不能将其拆分的过于细碎，好比建造一座房子，你不能每次只建造一件房子，目标是设计出符合所有基本需求的产品，在这一过程中要求设计师需有更快的响应速度，去做经过市场验证后的调整；
5. 产品主要的工作是定义有价值、可用的产品原型作为产品基础
在敏捷开发过程中产品更需要注意，每次交付到技术同学手里的原型是经过测试与目标用户验证的，避免浪费任何资源，哪怕是一个开发迭代周期；
6. 让开发人员自主控制所有迭代周期
有的产品功能可以在一个迭代周期内完成，而有些需求确需要多个版本的迭代才能完成，而这些迭代周期应该尽可能的让技术同学去规划，产品只需把控最终的判断是否与规划相符合；
7. 除非达到预定目标否则绝不轻易发版
产品经理必须保证给到用户手中的产品是正常符合预期的，过度而过度频繁的更迭会让用户失去安全感，所以没有达到产品预期里程碑与阶段预期时绝不可妥协上线；
8. 每次迭代之后需向整个团队展示下个版本的需求设计与上个版本的数据回归
让大家看到工作成果可以极大的加深整个团队的信心，在敏捷开发过程中每一个产品即是一个小团队的领袖，产品经理需要让这个团队有更加积极的状态。
三. 瀑布式开发
非正式瀑布流程，也是目前很多互联网公司依旧在使用的方法：由市场/运营进行需求收集，交由产品对需求进行产出文档，统一进行研发和设计评审，评审之后由开发制制定开发计划、设计软件架构，由设计进行交互与视觉设计等细节设计，最后正式进入开发、测试与部署上线。
瀑布式开发的基本原则：
1、采用阶段式开发，即软件开发过程中分为固定几个阶段：完成需求文档、设计软件架构、完成交互细节、编 写代码、测试、部署；
2、采用阶段式评审，每个阶段结束由上到下进行相应的评审，评审通过后进入下一阶段。
四、浅谈互联网项目中业务多线并行风险管理
1、多线风险，可能给团队带来多种问题。
一是延期问题
二是资源冲突问题
三是沟通问题
四是团队成长
总结主要呈现如下特性：
1.团队内存在多条目标独立的业务线在同时进行，且目标完成时间是受限制的；
2.业务线间在逻辑上存在耦合，即存在一条业务线逻辑变动影响到另外一条业务线逻辑的情况；
3.整体资源是有限的，即存在业务线间共享资源的情况，并且业务线发展会受到资 源投入情况的影响；
当发现有这些多线相互影响的情况出现，我们可以从以下几个问题寻找问题的根源：
1.业务目标是否聚焦，是否在同一时间想达成多个目标，而策略和资源跟不上；
2.工作的优先级是否明确，是否在出现冲突时能快速决策，保证价值最大化；
3.技术上，是否实现各模块“高内聚，低耦合”；
4.人力资源是否匹配了业务发展需求，是否原本计划中的人员没有到位；
5.组织结构是否清晰，人员权责利是否明确，每项工作的负责人是否确定；
6.人员技能是否需要提升，人员能力是否能应对多种的需求；
2、解决方法，减小多线影响
在需求分析阶段：
需要判断产品给出的需求是否描述清晰，其他团队成员是否完全理解了需求意图，是否安排了需求澄清环节。
在设计阶段：
包括交互、视觉和技术架构设计等，需要确认设计是否符合需求的目标，尽早识别设计和需求的不一致；
在排期阶段：
需要考虑如何提升任务估算的准确性，准确识别出关键路径和各节点时间要求及缓冲配置；再是，考虑迭代内任务及资源的依赖关系，如任务是否有固定的前后置关系，人力资源是否存在冲突。
在研发阶段：
鉴于多线情况下变更影响更加复杂，需要特别注意需求变更的发生，一旦发生需要考虑其对整体业务的影响，慎重执行变更和影响分析；再是，利用每日站会等形式，跟踪任务的进行状态，是否有新增、变更或评估偏差的任务被发现，及早识别可能造成影响的因素，减小控制成本。
五、任务管理
1、明确核心目标
作为产品总监，首先就是需要明确自己的核心目标，有些是比较实在平台的运营指标，比如营收、日活、月活、用户数等，有些是比较务虚的指标，比如半年内打造一款知识付费的SAAS产品雏形。
对于多任务指标时，最好是要分阶段和分人头进行指派，可以团队集中兵力头3个月集中完成某一个指标，让其形成惯性之后，然后再去开凿第二个指标的达成通路；
也可以将不同的指标分派给不同的人，贯穿全年去进行达成，总之就是让团队更加有节奏的聚焦在核心工作上，而不是精力分散，一下东一下西。
同时在明确目标之后，一切内部和外部的协同，都应该围绕着核心指标来进行开展，所有能够支持目标达成的计划安排，外部协作需求，优先级都应该排列在第一位，其余的非重点项的优化工作可以往后排列。
2、任务量
合适的任务量，是决定项目成败的前提条件——在产品规划的交付物方面提高要求，不使交付物成为项目开发的障碍。
任何项目都会有自己的目标，目标在制定的时候需要尽可能的做到可拆解、可落地，让团队的成员清晰的认知到自己的行为对团队的结果是有影响的。
不在一个版本内规划超过合理开发周期的任务量。
不把没有思考清楚或不完整的功能放入产品规划中。
3、执行者
执行者就是项目的开发团队。
信任开发团队，比怀疑和苛求开发团队要来的划算，良好合作一定建立在互相信任的基础上。
相比去苛求开发团队完成不能完成的任务，不如反过来思考：如何根据需求的优先级来缩减任务量？
给予项目合理的任务时间，是保证项目质量的重要条件。
每1-2周，固定时间对项目目前的进度进行整体说明，并准备可演示物进行演示，判断当前项目的进度和阶段产物是否符合要求。
通过这样的方式，能够及早发现进度问题或影响进度的问题，从而提高对项目异常的反应速度。
还需要对交付物进行如下两个层面的检验：
1、功能层面：这部分工作可以交给专业的测试团队完成，但产品团队一定要在过程中积极参与及跟进；
2、实际使用层面：这部分则需要产品来独立完成。使用层面的检验——即产品团队模拟真实用户的各种使用场景，使用时的行为，输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现，但被用户正式使用很快会遇到的问题。（这一点2B的业务类产品尤为重要）。