项目接近尾声，第一个完整从0跟到1的项目，在这过程中还有很多不成熟与不完善，但退一步讲，这是对一个刚毕业的学生很好的锻炼机会。在整个阶段，不断通过新的工作内容吸收新的营养，迄今为止，已有很大的收获。
与之前总是停留在需求分析与产品设计不同，这次是看着项目通过开发人员完整成型，才知道在需求对接时有很多方法和技术上的问题，才知道自己所谓的完整设计其实还差的很远，才知道之前一直听到的沟通，管理，开发究竟对一个产品的整个工作内容来说意味着什么。
这篇文章首先就说说我在这次项目中感受到的一个产品应该具备哪几个方面的能力：持续设计，有效沟通，安排得当。
一、详细设计
设计能力是产品的基本功，但在一个完整的项目周期，还需要具备持续设计的能力，它包括需求获取，设计呈现与设计变化。
在需求获取过程中，有四个来源：
1，甲方给出原始需求，与甲方确认他们要的是什么，确保每个词都明确；
2，在与其他厂家合作时，确认他能提供设备的能力都有什么，通常如何呈现；
3，与领导沟通，看在顶层设计（比如商务因素，公司方向）方面对产品有哪些建议；
4，我通过对需求方，类似项目以及原始需求的理解，挖掘出更丰富的内容。
最后将所有需求梳理出一套完整的框架，保证每一条都是明确的，可追溯的，否则每一个不确定性后期都是给自己和项目组挖的坑
需求明确后，会基于过去积累或开脑洞进行设计，设计呈现有几种方式，不同的方式处于不同的目的：
1，脑图。这个对于自身形成完整的设计框架是非常重要的，产品有哪些功能，子功能，如何交互，包括哪些字段一目了然，在和别人聊设计时可以很快找到是哪里的东西，有哪些内容；
2，高保真原型图。如果想做到持续地优化设计，自己有一套完整的设计图是很重要的，既让UI高效出图，也可以让开发明确交互，而且可以不被开发进度所限制，可以随时体验产品，然后不断体验，进而做出优化；
3，文档。在产品工作过程中，很多设计要落在纸面上，即可以让甲方做评审，知悉我们的设计，也可以在原型图的基础上做补充，让开发人员更明确具体内容。
如果说前两条好比我们买的精装房，交付时看起来哪里都不错，但在里面生活才会发现有这样那样的问题，就涉及设计变化。设计发生变化有几点来源：
1，甲方需求变化，引起设计变化；
2，领导提出设计建议；
3，开发人员对设计提出异议，确实发现需要调整；
4，开发时间缩紧，部分能力难以实现，需要变更；
5，在自己体验原型图时，认为某些设计有必要优化。
设计的变化是不确定的，甚至有时频繁的变化会带给其他人不可靠的感觉，所以如何控制变化，对接变化和管理变化是关键，在后面的“安排得当”回详细说明。
二、有效沟通
再说说第二点有效沟通，如果说一个好的设计能力是内功，那么沟通就是招式。在一个产品参与项目的完整周期内，需要在不同时期与不同角色进行沟通，而且有时需要主动沟通，才能及时发现问题，解决问题。
在产品落地过程中，甲方会下发任务书，领导会从顶层做一些指示，我们会把原型图和文档给开发人员，看似一切按典型的流程进行，但我们理解甲方的需求是否正确，开发理解我们的需求是否正确是不一定的，需要我们以纽带的角色主动和他们建立沟通，将每一个不确定变成确定，才能防止整个项目组的无用功工作。
沟通可分为需求获取阶段，设计确认阶段，对外传达阶段。在不同的阶段我们沟通的对象和目的不同。
需求获取阶段，我们的沟通对象主要是甲方和领导。在甲方那里我们要获取明确的原始需求，对于不明确的词句要充分沟通明确，对于甲方也不能清楚解释的地方，要在项目组内充分讨论，或给甲方提出一定建议，同时自己要标记哪里明确/不明确，同时我们在形成完整的需求方案后还要经甲方评审，说明需求框架和细节，才是后续设计的基石。与领导沟通，是为了获取一些“非功能性需求”，对于我们设计的侧重点，用户画像都有一定的指导意义。
设计确认阶段，我们的沟通对象主要是领导和开发负责人。要尽可能频繁和领导同步设计内容，确保领导知悉最新设计情况，甚至设计思路，一方面有利于领导的对外沟通，一方面防止突然较大波动的发生。与开发负责人沟通是为了在设计时，哪些是在约束的时间内技术上可行的，哪些是完全不可行的，从而沟通出新的解决方案，这样的设计才更合理。
对外传达阶段，我们的沟通对象主要是甲方和开发负责人。甲方不定期地需要我们提供设计情况，以ppt，视频，文档的形式，以便确保思路是契合的。与开发负责人沟通是开发阶段的主旋律，可通过需求文档与原型图结合的方式，将前后端的需求逐一明确。
要注意避免直接和开发人员直接对接设计，因为一个功能是多个人员共同开发，要确保每个人对设计的理解一致，所以和开发负责人对接，明确设计内容，由他（们）明确技术架构和内部接口后下发开发任务，便于需求和开发的管理。
在以上沟通过程中发生的需求或者设计变更需要做好时间和来源记录，以便后续不明确时，再次确认设计初衷。
三、安排得当
产品除了理解别人要什么，设计以及告诉别人我设计的东西是什么，还有一个重要的，就是让开发人员清楚什么更重要，自己把控“告诉”的节奏，这需要产品合理安排需求的优先级自己需求变更的周期。
首先要和开发负责人明确哪些功能是要优先开发的，列出功能列表，哪些可以放一放，这样产品在开发时间安排以及随时可能发生的对外展示时更有抓手。
其次，我们理想化的状态是我们根据用户需求设计一套原型图，UI美化，开发落地，测试检验，一切顺利，但是在整个过程中会有很多需求和设计发生变更的时候，这就需要我们掌握如何对接新的需求和设计。
之前说过，尽量避免直接和开发人员对接，而是和开发负责人对接，这样会减少不确定性，同时，也要有固定的同步周期，让开发负责人可以有节奏地把握和下面开发人员的对接，比如可每周更新一次，更新时可两个人共同管理一个表，包括：变更类别（需求变更/设计变更），变更内容，所在位置，设计版本，优先级，如有必要也可考虑加上变更原因，这样开发负责人可以很清楚这周相比之前那里变化了，变化了什么，哪个更重要等。
当然和别人同步的前提是自己要把握好整个需求和设计变更的时间，位置，原因，优先级，所以可以把之前梳理的脑图作为抓手，每周更新哪里就在脑图中做相应的标记，脑图有一个好处就是可以让你很快找到一个大系统里面细枝末节的任意一点，这样可以在别人提出建议或者异议的时候迅速定位到相应的位置，便于管理。
结语
这就是这个项目在产品能力上带给的一些收获，还有很多，我希望可以一直经历，总结，写下去…
网友评论