因为总总原因，下面这篇博文并未真正完成，等到现在想去完成的时候，发现自己当时的想法还是有挺多幼稚的地方。
这几个月来，自己也亲自体验了一把系统的架构工作，虽然仍然对web框架的使用等等技术问题还是不甚了解，但从现在的角度再去审视产品的系统设计，还是有些进步的。先把未完成的博文贴于此，对其中自己不是很赞同的观点一一作出反驳，仍然有许多不足的地方，亦当做是一种记录吧。
----------------------------------------------------------------------------------------
——下划线 是我对自己所写内容的点评
项目整体感受及收获
我们的项目团队是一个不算大也不算小的集体，但绝对能够算是齐整，产品设计师（PD），项目经理（PM），技术经理（TM），开发（Dev），前端（FDev），测试（TE），视觉（VD）一应俱全，人人都有明确的分工，不需要一个人分职担当其他工作。这样的好处是由于有了明确的职责划分，职责内的人员可以在项目的某一领域专注开发不被其他琐事干扰；坏处是明确的分工导致项目间各项工作需要及时沟通，各项工作的分工也必须明确，将因为工作内容交叉所导致的风险降低到最小。
关于沟通。在项目中，我司职开发一职，作为团队的“小尾巴”跟着PM，前端及TM的后头，不断的问这问那，在问题中领悟，在领悟中成长，在成长中总结、归纳，将经验适用于一些其他的方面。项目过程中，我遇到的最大两个问题是沟通与时间利用。这里的沟通并不是会说就行，沟通的力度及粒度需要有一个好老师言传身教，总结一下就是：凡是自己觉得有可能有问题的地方，那就必定是问题，沟通解决。最小程度，也必须让相关人员明白这个问题的程度，了解问题所产生的风险影响是否重大，可否避免；在项目过程中，遇到技术问题，如果能够沟通解决的，在了解问题情况后沟通解决，通过沟通降低技术风险，减少项目在项目进度上的可能奉献。
关于时间管理。时间管理不仅仅是项目中的问题，更渗透到日常生活中的方方面面。譬如在忙的时候：因为项目总体进度在前期落后了原定计划1～2天的时间，自己写代码也不够熟练，加之对很多工程中需要用到的东西完全不了解，同时还因为自身原因不得不在工作日请假一天，为了将这几天的进度补回来，不至于影响提测时间，必须利用加班时间将任务赶完。也有闲的时候：项目代码合理模块化后，后期的很多页面可以通过简单的参数配置完成。5个展示页，平均花费30分钟/页，比项目原定计划为5天的工作量缩短为了1天。将多余的时间用来把项目繁忙时落下的学习工作给补回来，还是将时间用来休息——时间的掌控能力。
另外，在“硬”技能上，产品设计、详细设计、开发编码、自测等方面经过项目各个阶段的总结与教训，也有了一定的提高：该做什么样的产品，如何控制需求，详细设计与人员分工，项目结构如何分层，如何减少无用代码，如何写单元测试，如何自测……
——沟通的技巧及度非常难以把握，首先要如何将自己的想法正确的表述给对方？有时我们会习惯于通过不断的事例举例去描述一个问题，但是不恰当的举例反而会导致讨论话题无主题，往往会变成讨论另一件事。另外，小组内讨论的时候，当有人的表述不能让人明白时，也尽可能的不要帮他去叙述，每个人的想法即使大体思路上一致，细节点上还是会有很大差异，这样很容易扼杀了一个团队的灵感。
——对于自己负责的部分，在沟通前必须要建立强烈的自信心，在沟通过程中，不能随着他人的想法随意的更改自己的工作。不管是产品还是技术，必须要有自己坚守的原则和方式。
项目前期工作
按照我对项目的理解，项目的前期工作可以概括为：
1. 需求分析产生Functional Requirements Document（FRD、功能需求文档）。
2. 技术选型选定开发语言、存储技术、框架、网络等项目开发及运行环境。
3. 详细设计抽象项目模型、建立较为稳定的数据库表结构和service方法（防止后期因为设计不良而导致大量变更）。
4. 通过详细设计及FRD文档，制定完整的开发进度安排，估算资源使用情况，申请调配资源。
——当时还未真正的从零开始进行项目，如何产生MRD也是一个精细活，不要小看PD的工作。一个优秀的PD，应该同时具有眼界、技术实现、数据分析、设计等技能。一个好的MRD应该能够真正的去打动别人，让人们对项目的前途产生强烈的信任感！
产生FRD
首先，明确FRD的功能。FRD是从“不明确的”需求向“明确的”开发意图进行过程中最重要的产品细化过程。FRD的产生意味着需求的真正明确及项目前期需求分析工作的完结。因此，FRD必须包含的元素有（按我理解的重要程度从上至下）：
1. 项目概念及模型。“产品概念”及“产品模型”不是“虚幻”的两个词，通过“产品概念”进行产品定位，明确产品意图。“产品模型”是产品的设计抽象，将产品概念以具像化形式输出。一个通俗的比方，“产品概念”可以是我们想要做一件事，“产品模型”是我们做事的方法。
有了产品概念及模型后，产品就不会无目的的变更或者扩展。同时也可以依靠产品模型建立进一步的抽象模型，用于数据模型的建立及service方法的凭据。甚至可以依靠模型进行多阶段的拆分，进行有条不紊的迭代开发。
2. 产品中各个业务模块的输入、响应及输出的设计。更为官方的叫法应该是用例设计。用例设计的目的是提供开发和测试准确的模块功能凭据。例如：进入“首页”后（输入），显示导航条下方的轮播广告（响应），轮播广告按顺序显示8条，如果对应位置没有设置广告则由后一条广告代替输出，若广告都不存在留白显示（输出）。在这个例子中，仅输出较为复杂，而且用例也相对简单。在实际的操作过程中，往往会因为输入->响应->输出的级联及多重状态组合的关系而变得异常复杂，而不能设想周全。不过这些用例会在未来的开发过程中逐步明确。因此，这也是PD需要存在于项目的整个过程中的原因之一。
如果将项目概念及模型比喻为想做一件事和做一件事的方法，那么用例设计是做一件事所用方法的具体表现步骤。“我想吃饭；用碗和筷去吃饭；先拿起碗盛好米饭再拿筷子吃饭，如果筷子掉了就……”
3. 系统分析。用于对项目的技术选型。一般记录系统的预测Page View（PV）之类的可能负载量，通过系统负载选择相应的技术手段解决。因为一个系统的响应时间也是产品需求的一个重要组成部分，因此系统分析必不可少。
“我想吃饭；用碗和筷去吃饭；先拿起碗盛好米饭再拿筷子吃饭，如果筷子掉了就……；另外，我现在很饿了，不能吃的很慢，但吃的太快也会噎死”
4. 其他。可能是监控，日志等其他涉及项，一般会视具体的要求不同而变化。
“我想吃饭；用碗和筷去吃饭；先拿起碗盛好米饭再拿筷子吃饭，如果筷子掉了就……；另外，我现在很饿了，不能吃的很慢，但吃的太快也会噎死；另外，我要记录一下这次吃饭的情况，思考总结之后用更好的方法吃饭”
上述吃饭的例子实在是有点通俗，但我所认为的FRD应该由这4个基本组成部分组成。FRD是一个项目的前期思考和总体规划过程，目的是形成一个统一“做事”的准则和标准，用于之后各个步骤的平稳进行。但是，这个思考过程不能过于细致，不能要“吃饭”还要去想如何去做一副碗筷，用什么材料做，在什么天气做……这也就是所谓的FRD以需求驱动，考虑业务场景，不考虑技术细节的原因。
——这里“吃饭”的例子就属于沟通过程中举例不恰当的一个表现，本意是想通过这个例子把FRD过程中所涉及、所需要考虑的点具象描述，但这种举例方式在描述此类问题时的合适吗？
——在进行FRD的过程，应该对需求已经有很明确的了解，产品的细节也应有详尽描述，否则FRD的过程会异常艰难，甚至会影响到后面的开发进度预估及项目总体进度推进。但FRD的完结，的确意味着项目开发前的所有准备工作已经完成，可正式进入开发流程。
——做一个延伸，产品的概念也可以是产品的总体规划及思路，根据此产品设计时突出产品的功能，根据此技术经理会考虑到系统的未来发展及升级，产品模型的产生需要不断的迭代优化，很难一步产生一个最优版本。同时，在进行系统逻辑设计时，应尽可能的预估技术难点，抛出问题讨论解决。
技术选型及产品UI设计
对一个完整的团队而言，产生完整的FRD后，接下来的任务就要交给VD和TM了：视觉设计，技术选型及系统设计。这三者的关系是视觉设计与系统设计同步，技术选型于视觉设计完成之后，系统设计后期。处理好三者关系的要点是：系统设计不涉及与特定技术相关的设计，在设计模式层次对产品进行抽象设计。
还是拿吃饭的事例进行比喻：“要有一个吃饭的碗，这个碗应该是半圆球形，且有个底座用于放置。这个碗有一个材料属性，可以是铁的，也可以是瓷的，但暂时未知。这个碗有样式属性，可以是带花边的，可以是带雕刻的……另外，这个筷子可以是……”。至于用什么材料做碗，做筷子，那是技术选型的事。在视觉设计完毕及系统设计后期，能够对产品从抽象和具象方面有非常直观的印象后，才能真正确定技术选型。因为技术选型的目的是为了平衡项目的时间和系统可用性。这是一个本末问题。
——产品UI设计相对于整个工程而言所消耗的时间是最少的，因此其开始时间可以较为随意，之前的项目过程中走的是正规流程，因此UE切入时间较早。对于一般的web项目前端的开发总耗时大约是后台代码开发时间的30~50%左右，前端有一段较长的缓冲期切入项目流程。
——对于系统设计及技术选型，应该在FRD期间完成，故之前的理解就不那么正确了。
——举例依旧不那么相当
----------------------------------------------------------------------------------------
自我批判结束，
后面，将会对产品的设计流程进行总结，期待下一篇博文！
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
