@芯享 2016 – 07

期望

【提升质量】提高项目开发的质量，规范工作流程，对开发过程和结果都进行质量监控。

【文档驱动】规范流程的具体实现方案，有据可依，健全问责机制。

开发流程

【项目可行性分析】生成用户的需求文档后，仍然要进行可行性分析。为了用户，也为了不让自己的精力投入到注定要泡汤的项目上。最好的状态是，伴随着项目的经历，积累行业的竞争力。

【合作伙伴】选择靠谱的合作伙伴，与诚信正直的人合作，避免被套路，规避风险。更容易建立彼此的信任，形成良性合作。

【客户档案】

建立客户档案，客户名称，公司职责，在该项目中所起的作用，划定职责范围。

明确项目干系人，与对方公司的所有干系人进行沟通，明确对方的预期。

从了解客户审美的角度来讲，可以问客户要他比较喜欢的APP或者Web，在进行视觉设计的时候，可以将其元素纳入设计规范中来。

【需求分析】

客户的需求不是需求。

争取软件设计的主动权，客户提供的设计图，有利于了解用户需求。在沟通用户具体的需求后可进行重新设计。

还要对设计图中涉及的元素进行说明（名称，定义，来源等详细信息），落实到文档中。要形成精细化的需求描述文档。

【需求变更】

客户的想法：我都付了X万了，改一个小功能都不给我改！！<气愤ing>

尾款还要扣一下，万一开发组拿钱跑路了怎么办。

需要跟用户解释需求变更对我方开发的成本增加，明确何为需求变更，参照文档，有据可依。

对开发成本根据开发需求进行动态调整，需求精细化。

【实事求是】生成需求文档后进行价格估算，实事求是。如果开的价过高，只是一时利益，后期会失去用户。如果开的价格低了，会让公司受损，影响开发积极性。

这样才可以大胆的让用户参与到软件的开发过程中来。

【客户在过程中的参与，而不是仅仅验收成果】让客户参与到开发进程中来，减少之间的沟通成本，让需求提供方参与到设计中来，用户也可以对开发进度进行监控，和及时确认。阶段性成果转化为文档生成后，进行签收，邮件往来。阶段性验收付款结算，最大限度降低风险。

【用户体验至上】以保证用户体验为基本原则（避免后期纠纷和债务）同理心，站在用户的角度思考问题。用户体验至上，不能以给多少钱办多少事情的心态去写代码。

【视觉设计稿】

客户对于UI的需求提升（布局，颜色，切换动画）。

用户往往提供了一系列视觉稿，就以为需求很明确了。实际上视觉稿中的元素名称，往往会引发歧义**。

视觉稿不代表最终效果，会让用户产生错觉。

【时长估计】交互设计出来之后，根据具体的页面，数量，复杂度，UI需求，交互动画等等，让UI，前端，后台，测试，各自给出自己的时间预估，项目经理综合考虑，加上预留时长，避免延期交付的尴尬。

【开发成本估计】根据开发所需时长，用户要求的时长，各自的工作量，人力成本，和硬件投入（服务器，短信API，图片视频云存储等）综合考虑

【测试】不要直接丢给用户，出现问题多了之后，影响信任感。要留出1/3的工作时间进行代码测试（单元测试，集成测试等）。
测试专业化，可以考虑增加测试专职人员，将测试融入到整个开发流程中来。对BUG产生报告记录。

【项目验收】验收时不能由需求提供方的某个领导或职员来验收通过或不通过，发生争执时，回到文档中来，有据可依。

个人

【良好的沟通】项目经理的沟通能力决定项目成败，同理心的培养。
沟通时，避免所有的琐事都劳烦客户，但是要考虑到软件体量的大小，如果是大体量的软件，还是要事无巨细为好。

【合同&邮件】先小人，后君子。口头承诺无效。每一个项目开始前，签订合同，保障大家的利益，明确基本薪资待遇，让大家有底。

【客观 就事论事】不问情绪，基于双方利益，看目标和成果。
团队内部，不应该太过于考虑对方情绪，工作过程中，对事不对人，哪里不对哪里不好就应该直接说出来。批评或训斥，会让一个职员一时的难堪，也可以大大加快进步的速度。

【快乐】心存善念，追求员工和客户的快乐

【追责】邮件往来，留有证据。设计有效的问责机制（内部成员的话，请客吃饭或许可行，哈哈）

【冲突】公正，善意，逐步。实在解决不了了，考虑第三方协调。