质量不是独立的，是一种综合作用的结果。要达成产品/项目的质量最优，需要团队中每一个成员的工作质量共同去保证。为了提升团队整体的成果物质量水平，对于批量开展的任务，应该首先做好Demo和样例。
一、系统原型Protype Demo让目标生动鲜活
原型的作用
1、直观的系统原型，可以有效支撑与用户高效的提案及需求确认；
2、与《商务合同》形成有效支撑，帮助PM控制需求范围，为防止需求蔓延保驾护航。例如：防止业务功能以“简单一句话的形式”非正式地与客户达成所谓“共识(口头)”，然而在上线阶段，用户完全按照自己的理解重新解读，从而导致需求范围的严重蔓延，成本超支，且PM缺乏客观证据无法进行商务谈判从而挽回损失或及时止损。
3、“需求系统化，开发如有神”。支持与开发团队高效的业务传递，动手前开发团队就具备“胸有成竹”的信心、目标及统一认知。
二、“榜样的力量是无穷”，除了人，还有项目工作成果物。
实现了需求系统化（系统原型Demo）：需求完整、清晰、生动地呈现出来。接下来，就是设计、开发实现了。而工程过程中的样例Sample的质量，将会决定后续开发过程的状态是：绿灯还是红灯？
A、【一路绿灯】“朝辞白帝彩云间，千里江陵一日还”的洒脱。
B、【红黄往复】道路阻且长，会面安可知? 痛苦纠结。
Demo的作用
正所谓“磨刀不误砍柴工” ，通过第一份项目工作成果物(如：设计书、模块代码等)的充分试错，打造一个高质量的Sample（包含了技术方案、实现效果、规范、试错问题归纳预防等多方面），然后进行团队培训，再批量开展类似工作；这样一来，我们收获的比将是“高质量成果物快速输出的良性循环”。
三、应该避免的错误思维坑
1、需求设计：就先这样吧，等到时候再说。
——到时候是什么时候，到时候范围蔓延怎么办？到时候搞不定怎么办？做原型：通过做到位、促使想到位。
2、过度承诺：明知无法兑现的承诺是慢性毒药、是定时黑洞。
总之，使客户满意的核心原则之一是“谨慎承诺和交付更多”。
谨慎承诺和交付更多
——当我们过度承诺和交付不足时，我们最终会遇到用户的失望、不满。心怀不满的用户会导致更多的客户投诉，损害公司信誉。所有直接与用户打交道的团队成员都需要遵守纪律，避免过度承诺的陷阱。
3、程序编码：先把代码写出来，再说。
—— 代码是手段，不是结果。我们要产出的是能够兑现用户需求承诺的有效代码。因此，首先，代码应该按需求确定度来区分优先编写次序。需求清晰明确、工程师理解充分、到位后：应该尽快编写；切不可本末倒置。其次，代码精简清晰为宜。我们在表达同等需求量的前提下，代码的结构越简洁清晰，其代码量相对较少，其可维护性越高，代码质量也相对较高。
综上，原型Demo和成果物样例，应该体现并代表：开发团队+组织平台的经验能力集合最佳水平，也极大程度上决定了项目的整体质量水平。因此，项目团队全体成员及支持部门团队，均应非常重视！
网友评论