和大家分享我是成长之路，帮助一些想从事产品的朋友们提供一些思路，看看能不能帮助到大家发挥优势、补齐短板。

一、我的成长经历

我计算机专业毕业，从大学开始接触计算机原理、数据结构、C语言开发等课程，所以理论基础这块稍牢固一些，对日后工作中的帮助也挺多。大学兼职做网吧的网管，第一份工作是做实施维护，就是工厂的信息办公室，主要解决电脑死机、打印机找不到、接电话线网线、杀病毒等工作。后来到大城市就先从网页设计开始，自学了Photoshop、Flash等软件（有过一些基础、难度不大），主要就是做网页效果图。后来因为要给程序员切图，切的多了也做了点前端工作，自学了HTML和CSS（不是现在的前端，VUE等），也了解了些javascript、jQuery等，简单的sql查询也行。

在外包公司给国企做了快10年外包左右，钱少事少离家近，生活很是舒服，但发现自己的总是停留在舒适圈对自己不太满意，也是因为工资低，就跳圈外直接生硬的转到产品方面工作，开始有点不适应，也被吐槽和怼了许多，对自己也挺不满意，但做了几年下来，慢慢适应了这份工作，一直做到现在，现在回头看看转型的决定还挺满意，这份工作适合自己。

二、产品的主要能力

产品是比较吃经验的工作，门槛低但上限高，中间层的差距可以拉的无限大，但经验可以提高容错，只有深度思考和自我学习与总结才能真正的成长，我习惯每个月总结回顾当月工作，看看都有成长和感悟。我把产品能力分为三部分：

（1）产品能力（20分）

产品能力主要是体现在软件工具使用熟练度（Axure、Visio、Office、Project、思维脑图等），文档的写作（如需求说明书、用户手册、流程图等），方法论的灵活运用（用户访谈、头脑风暴、会议主持等）等方面。

这部分我只能给20分，因为工具、写作都是辅助输出，方法运用是经验，只要用时间都可以堆出来，也可以速成，产品水平是拉不开差距，但不能没有，是比较基础的门槛要求。

（2）基础能力（60分）

1. 情商，这是最重要的能力，情商高的人办事让人觉得舒服、饱满，满意度高。
2. 智商，作为软件行业，这部分能力必须要有，特别是一些复杂策略、算法、模型，都要能懂，而且聪明人有大智慧，能把复杂问题抽象化、模型化，能深度思考。
3. 逆商，作为三方的桥梁（客户领导、公司同事、真实用户），一定会承受多方的压力，在资源有限、关系复杂、诸多不确定的环境下如何办成事，心态要好、情绪要平稳。
4. 沟通，要做到无论多复杂的事，一句话把事说清楚的能力，想像一下在电梯里只有20秒时间，如何介绍自己，让给别人留下映象（给对方一巴掌不能算），或者一句话介绍一下大数据是干什么的。
5. 演讲，主持会议、用户培训、领导汇报等很多场合需要在公众面前发言，如何能自信、从容、有条理、简洁的把事说清楚，不是件容易的事，只有一个笨办法“多讲”！先和最熟悉的人讲，再慢慢对多个人讲。
6. 善良，善良的品质很重要，不是鸡汤，在灵活多变的环境里，有很多“捷径”，只有出于善良的目的，才不会把路走歪，才能赢得认可和尊重。有人会想我的想法别人怎么知道，完全不是，对一个人、一件事的善，会从各种细节里流露出来，有句话说的好“有两种事无法掩盖，一是咳嗽，另一是爱（善）”。
7. 领导力，产品经理自带“经理”两个字，就要有主持能力、能扛事、能拍板，而且产品经理和项目经理常互通，所以领导力是很重要的能力。

其它还有很多基础能力，如谦和、健康、爱分享、为别人着想、幽默、爱阅读等，都是加分项，做产品如同做人，产品和一般人不同的是，他是在聚光灯下会被放大，能拉开产品能力的差距重点看基础能力。

（3）行业能力

行业能力是非常宝贵的财富，如果能在一个行业里干三年以上，基本上就可以建立自己的舒适圈，如果有点理想和追求，成为行业领军人材，那干到退休都没问题，而且退休后还有人请回去做专家和顾问。

但是选行业也要慎重，夕阳行业、领域过窄过热都要注意，比如BP机专修行业、啤酒瓶盖生产工艺制造、英语培训等。

另外要注意的是，行业能力可以通过经验来补充，所以这块很容易被赶超和替代，不能坐吃山空、守株待兔、温水煮青蛙。

（4）复合能力

产品的复合能力算隐藏能力，要做T型人才一专多能，我就是美工、前端、产品、项目管理都了解点的人，其中在沟通和写作两块更突出一点，所以在完成基本工作的同时，各方面也能及时顶上。这种能力如同未开放的接口，平时没人注意，但需要时暴露出来，调用者就会觉得很灵活和惊喜，也提高了存在感和不可替代性。如何给自己打上更多正面标签，值得大家思考。

三、各岗位转产品的优缺点

（1）设计（美工）转产品

• 优点
  • 见多识广，美工做图时要找大量的素材，所以看过的界面、风格、交互都比一般人多许多，所以在产品设计时有很大的优势，而且在找材料这块也比较方便，模仿力强。
  • 审美高，产品工作中有很多是对外宣传和汇报，PPT做的漂亮，原型做的工整，看起来赏心悦目、专业度高、客户有被尊重的感觉。
  • 与美工、前端沟通方便，界面意见专业。
• 缺点
  • 计算机知识不足，如果非计算机专业的朋友，那这种情况非常明显，比如和开发交流时“与或非交并补”、“封装继承多态”、“冒泡算法、二叉树、工厂模式”用这些词开发听了就很舒服，秒懂，开发说的技术难点和现实路径也好共情和解决。和客户交流时也会用一些比较专业的名称，比如富文本框、干系人等（不是要说学产品黑话，甩动词大词没意思）。
  • 容易陷入细节，产品的输出是为了把事讲清楚，好的美工一定有强迫症，看到细节地方总忍不住想动动手，提出的问题可能也比较偏细节和体验类提升。
  • 美是主观的，美工的工作成果是被否定的过程，所以大多有摆烂和服从的影子，但好的产品要有主见和坚持。
  • 从平均水平来说，美工的工作强度比产品低一些，产品的杂事多、关系复杂，要有心理预期。
• 建议
  • 需要系统地补充计算机、项目管理、产品管理等知识，建议考PMP、NPDP、高软等证书，以考带学，还能有产出。
  • 美工在团队中属于支撑型角色，成为产品后要从幕后站在台前，要敢于发言，暴露缺点，快速成长。
  • 转型一定有阵痛，可能要从零开始，要有心理准备。
  • 产品的工资不一定比美工高，但相对来比高一点，美工的路也可以走比较远（但最好是设计出身，我就是计算机出身遇到瓶颈才转的产品）。

（2）开发（前端、后台、测试等）转产品

• 优点
  • 岗位转换比较平滑，很多团队中可能因为没有产品人员，开发临时顶上，做着做着就转到产品
  • 与开发人员沟通方便，不言自明
  • 能兼项目经理，对进度把控、成本评估、风险预估比较擅长
  • 理性思维、能抗压、能吃苦
• 缺点
  • 沟通是个大难题，也很难在短时间内提高，和一群开发开会几小时都没问题，但站在客户面前时就有点怯场
  • 交流时容易陷入开发思维，答应需求时过于爽快，想着这个功能简单加个表就行，那个功能简单做个接口就好，这玩意加一小时班轻松就搞定。
  • 审美堪忧，不考虑交互，把客户都当神人（要把用户当小白）
  • 思维模式转变，把自己从开发人员转变为对方人员，把能用向好用的方式转变，把完美向完成的标准转变，要掌握包容与妥协的平衡。
• 建议
  • 开发人员一般有两个上升通道，一是专业技术、二是管理，在中国基本上都是要走管理，所以做产品经理或项目经理都是不错的选择，但我更推荐开发转项目经理，那边技术能力有更大的发挥。
  • 开发转产品一般都是因为工作压力过大或枯燥，或想着岁数大了卷不动，但产品工作也同样有这样的问题，转之前想清楚想要什么，想想未来5年要过什么样的生活。

（3）其它转产品

其它如商务、运营、相关专业（如数学、通信等），基本上同美工转产品相似，要从零做起，补齐产品能力和基础知识，快速上手、多开口、多暴露缺点、多寻求别人帮助。

四、总结

为什么要做产品呢，因为名称中带个经理吗、因为可以去各地出差或见不同的人吗、因为工资高吗、因为门槛低吗？

想清楚再决定，这里有个简单的测试方法，b站有个up主叫“产品老曾”，多看看他的视频，看看我们的思路能不能跟上他的思路，看完100个视频再做这个决定，要不要转产品。

24年前三个月都在忙着投标相关工作，参与了三个标书的编写和评定，把这段时间的所见所闻做个简单整理，分享给未投过标书的朋友们，希望能共同学习与成长。（本文不涉及具体单位和项目内容，都是个人见解，不太全面和深入，大家多包容）

一、整体流程

最近在学习高软，正好这张截图能完整的介绍项目前期的主要工作，我们作为供应商和投标人，主要是关注“乙方编制标书”和“乙方递交标书”（一般递交和评审在同一天进行）两个环节。

二、甲方招标之前的工作

做为成熟和深耕多年的软件公司，在官网上看到甲方招标公告之后去应标是头铁，这种方式一来时间仓促、二来成功率低。投标一般都是有倾向性和预判，早早和意向客户做好关系，提前做好准备工作和需求沟通，有些大型客户和大型项目，可能从立项阶段就参与其中，这种项目成功机会确定性非常高，也是目前的常态。

当然也有那种海投的公司，专注网上的投标信息，不管大小的标，只要能和公司营业范围沾边的就去投标，反正有枣没枣打三竿子，总能拿下些三瓜两枣，能做自己做，不能做分包或整包出去，但这也是有隐患的，这里不展开聊了，有点跑题。

三、甲方招标

（1）招标主体

一般大型项目（百万元以上）都走社会公开招标，而公开招标基本上都是使用第三方代理机构来操作，因为一来招标工作细节比较多，这种事交给专业人来做，二来规避风险，如果有些差池，造成工作失误会对后续工作埋下大雷，这种纠纷需要招标单位担责。

（2）标书编写

正常情况招标单位按照代理机构要求提供资料，格式化内容由代理公司来编写，做好后请招标公司审阅确认。

标书内的要求部分分为商务部分和技术部分两块，因为软件行业的专业度高，客户很难说清楚要什么，比如我想要一匹跑得快的马，但客户真正需求是要辆汽车，所以技术这块写得五花八门的都见过，其中也有不少操作空间和后继容易扯皮的地方。

（3）标书内容

一般标书都会介绍清楚背景、须知、要求、格式等内容，体量较大，内容也很官方，一定要仔细阅读，有不清晰的地方要问代理人（主要是商务材料部分）。

1. 招标公告：这里是介绍项目名称、项目编号、最高限价、文件的获取、提交方式，时间节点和联系人信息等。这里需要重点关注的“资格要求”，如果有不符合项，那就没必要浪费双方时间。（这里可以通过量身裁衣的方式筛选乙方，这叫“控标”）。
2. 投标人须知：本章是对招标细节做详细的阐述，比如：保证金、是否需要现场踏勘、是否需要样品、是否需要述评等，内容比较琐碎，但其中隐含着细节，不可忽视。
3. 评标办法：重点来了，这里最重要的是“评审标准”，其中有符合项有一项不符合就没必须参加投标（比如CMMI3认证、国密二级等）。另外就是评分标准，分为商务、技术、财务三部分，每部分再有小项，由专家评审打分。
4. 技术和商务要求：这里重点是技术要求，一般都细化到每个功能点上，也是软件公司重点要响应的部分，别看专家现场只是翻翻，没时间细看，但就是简单翻翻，对有经验的人来说，就能主观地感受到各家的差距，就像我们拿到软件的产品手册或用户手册，只要看几页，就能知晓此款软件的专业度、能力水平、主要功能和范围。
5. 拟签订合同主要条款：这是中标后的事，和招标阶段工作的关系不太大，重点关注下付款方式、交付时间和地点
6. 投标文件格式：一般是以此章给出的格式为基础，制作投标文件，格式要求的有粗有细，根据要求操作。这里要留意分册、装订、封装、盖章、刻盘等制作要求。

四、乙方编制标书

前面哆嗦了许多，终于到了最核心的环节“写标书”，千言万语都是泪，谨小慎微熬夜肝。

正常软件公司写标书分为两波人，一波写商务部分，这里主要是收集资质、证书、报告、文件，注意行文格式，做总校对和装订。另一波人写技术部分，针对技术要求写技术方案。

（1）商务资格项

这是标书的刚性指标，如法人证书、代理人证明、投标函、保证金凭证、资格项、财务报表、承诺书等。这里一定要细心，缺一不可，要有多人多轮交叉着审阅，不然一切白忙。我见过财务打款单位和投标人单位名称不同的、财务报告上的注册会计师离职、项目负责人近6个月社保缺开标前一个月等情况废标的，这种特殊情况和细节都要提前写好情况说明材料。

（2）商务加分项

这部分内容，没有不扣分，有就加分，大家都在努力的堆分，其中分为两类：硬性要求，如CMMI3级认证以上、保密二级以上、近三年流水、高工人数等，临时不可改变的。软性要求，如报价、质保时长、应急方案等。以上加分项都要提供证明材料，不然专家是不认可符合拿分，毕竟口说无凭。

（3）技术方案

技术方案的难点在于：

1. 需求不明确，这是没办法，无法联系到业主，招标公司不会解答技术上问题，只能凭自己的理解来写。
2. 需求遇到知识盲区，这种情况一定会有，没有全能都懂的情况，过去都是翻资料或找供应商来帮忙写，现在有ChatGPT方便了许多。
3. 硬件与土木方案，这块一般要找第三方提供。
4. 时间仓促，都是临时成立工作小组，还有本职工作，很难有条件静下心来写作，所以大多是加班来做，也来不及细审和校对。
5. 其它：文字功底不强、文件格式不统一、word不太会用等。

（4）报价方案

正常的报价方案都是由三种方案混合得出，再凭经验做一些调整得出

1. 自下而上，由技术功能点分解后，估出大概工时，累计得出总工时，乘上人力成本（正常行业价格1000元/天），留出软件行业的足够的利润，做个加权就能做出总价，这种方式比较科学，但缺点是需求不明确且费时费事。（目前软件行业的毛利润在 50%以上，但实际利润看项目经理的控制能力、客户的关系等多种因素，净的利润可能只有10～30%左右，当然有很多亏本和难要尾款的项目）
2. 自上而下，正常就是报最高限价的90%～99.9%，然后看能不能干，干活的范围定多少合适，就基于这些范围来写技术方案，把方案范围和标书要求两边对齐，这种比较简单粗暴，而且收益最大化，用得也是最多。
3. 专家经验，根据市场标准、行业标准、客户的最高限价、公司的战略、期望利润、竞争对手可能的报价等因素来报价，这种方法最简单（拍脑袋），主要看“专家”水平（其实也不太玄乎，有经验的人看需求，心算就大概知道报多少）。

关于价格的评分有多种方式：

1. 低价优先，这种多在一些价格不高、门槛不高、需求明确、产品成熟和标准化高的项目中，谁做都差不多。我们做的多是定制软件，这种还没见过，可能硬件方面有些，比如机房建设、扫描枪与RFID标签等。
2. 平均价（偏差）法，这种见的比较多，报高、报低都不好，报合理最好。举个例子：A、B、C、D四家报价，A、B报100万，C报80万、D报50万。最后求个平均数为82.5万。那C家得分最高，因为他80分离平均数82.5分最接近，A、B、D在报价部分会被减分。
3. 其它方法：加权法、混合法、剔除最高最低价等

（5）盖章签字装订包装

具体要看标书要求，一般有经验的公司都熟悉规则，从源头上规避风险。新手容易翻车，比如就听说因为有某页少盖一个章废标的情况。

五、评标工作

（1）接收标书

有的会提前要求提交标书，电子版或纸质版，多是在开标当天大家大包小包地扛着、推着标书进场，堆在会议桌上。

要注意的是封条、外包装别在运输过程中破损，这就说不清了。

（2）开标程序

1. 规定时间到场，点名、签到
2. 宣布启动开标和注意事项，手机关机或锁在外面等
3. 检查文件包装是否完整
4. 唱标（最紧张刺激的环节），工作人员现场拆包，大声宣布投标人名称和报价，聪明人都会记下来
5. 开标完成后，所有人离场，进入评标环节，一般当天出结果

（3）评标工作

市面上招投标多采用“双盲”评审方式，就是招标人与投标人、招标人与评审专家、投标人与评审专家、投标人与投标人之间都不认识，主要避免“潜规则”，破坏了招投标的公平公正。

一般评标由评标委员会负责，委员会由多名不同职责专家组成，可以是从专家库里盲选，也可以是甲方指定人员，专家人数视项目体量决定，一般都在7人以上。

然后在小房间里，先评资格项，如果发现资格不符合情况，可能会让投标人解释，或者不听解释直接废标，就请签字回家。

再后就是方案评审，可能会有答辩环节，会逐个进去讲解方案，一般每家10～30分钟，用PPT、DEMO、视频都行，这块看要求，遇到懂行的专家三两句就问到点子上，把底摸个清楚，这个就看答辩人的水平和准备的充分程度。

（4）定标工作

目前定标有两种方式，一是评定不分离，一是分评定分离。

如果评定分离，那评标委员会给出中标候选人名单（一般3家），再由定标委员会来决定选择哪一家。（这种一评一定的方式，中间可操作空间就多了些）

如果评定不分离，那定标工作也由评标委员会一并负责，当场就能宣布中标结果。

在宣布时会请中标候选单位进场，宣布中标结果或评分排序，没中标的就可以洗洗睡了。

当然，还有其它定标的方法，比如抽签法、低价法等，只是听说没遇到过。

六、收尾工作

（1）公示

一般定过标后，会挂网公示（一般是3天以上），再交有关部门报备，整个招标工作就闭环。

（2）合同签订

这就是下一个环节，基本上就商务出面，先进行洽谈，由甲方或乙方起草合同，然后法务、财务、领导等走流程审批。

（3）首付款

大家肯定关心这块内容，多说几句，一般付款方式在投标时就约定好，软件行业基本上就是3331，首付30%，里程碑（上线、部署、试用等）30%，验收30%，质保完成后10%，也有3421、343、2521等，就看甲方强不强势。

合同流程走完，乙方先把首付款的发票开具后交给甲方，然后就等着收款。基本上中标后前期人员就可以先进场干活了，两边工作并行。

顺带说句，见过有公司为了拿标前期承诺比较多，真正干活的时候傻眼或就是存心想糊弄，就为了拿首付款，后面就慢慢着拖着。这也没办法，就算走法务或拉黑名单也不影响，换个壳再投下一家。因为软件是无形服务，一个功能点大了小了都能做，定义模糊、取证难，司法成本高，最后多是不了了之，可能打赢了官司公司都倒闭了，法人跑了。

招投标中有趣的事还挺多，篇幅有限只能收着说，如果有大家兴趣，可以再开一期，讲讲过程中的小故事，比如围标、废标、恶意竞争、对招标文件质疑、提供虚假材料、代理公司失误等，我们老总说这其中没什么捷径和教程，只有吃的亏多了才能老练精明，所以投标一定要有经验丰富的来主持工作，不然大家瞎忙没结果。

接口设计对产品经理是比较高的门槛，如果能跨过这一步，不但是对自己的综合能力大幅度提升，而且能更加熟悉系统的细节，对后期的同类产品设计有极大帮助。

接口设计需要一定的代码能力、抽想思维能力、沟通能力等，对综合要求比较高，因此不可有明显的短板。

在设计时要做到每个细节的把控，以免上线后造成问题返工，而且返工可能不是单方面，可能双方或多方，一定要仔细和完善。

一、基础知识

1、精通业务流程

接口设计一定是在熟悉现有业务的前提下再做扩展对接（少数情况系统建设与接口同步进行），所以一定要对自己系统的流程和逻辑非常熟悉，不然在对接过程中常常卡顿，就显得不专业。当然现在系统越来越复杂，也不可能做到全能，总体要有得放矢。

2、读懂API

在做接口设计时，如果是新手，建议多参考并了解不同开放平台的接口样式，比如百度地图等，这样做的目标是看看行业标准和有全局思维

重点是公司内部的开发文档，比如数据字典表、内部接口文档等，搞清楚后台与前台的对应关系

梳理API是最难的一点，也是最花时间的一点，不能因为复杂、庞大就放弃，解决困难最好的方法就是面对困难，和产品、技术人员一点点啃，完成后收获会很大的

3、要有项目管理意识

接口设计就是一个小型项目，有启动、规化、执行、监督、收尾，每个环节有对应的管理方法，最快的学习方式是掌握PMP后裁剪出适合的方案

二、需求调研

1、业务背景

做接口的目的、意义、必要性、可行性等考虑

2、业务场景与逻辑

使用者是谁、入口、出口、分支、循环等，简单的可用文字描述、复杂的应画流程图

3、产品原型

改造过程中如果涉及对现有页面改造或对前台展示、交互有影响，应辅以原型说明

4、进度计划

双方协商好工作后，根据工作任务安排时间表，初期需求模糊可定一个大概范围，做到渐进明细

 

可参考 NPDP 中提供方法

 

三、接口设计

1、接口基础信息（必要）

（1）接口名称：一般公司内都有命名规范，比如英文/拼名、驼峰/下划线、前缀/后缀等

（2）接口地址：调用接口的位置（注意内网的特殊访问处理）

（3）通信协议：调用第三方平台接口需要进行系统间的通信，目前常用的协议是http和https；简单理解https是http的加密版，可以将用户到服务端请求的信息进行加密，避免因明文传输被截获而获知用户信息

（4）请求类型：基于http协议的常用请求方式是post和get

（5）响应机制：同步、异步，简单理解同步接口即实时返回消息给调用方，异步接口就是可以延迟返回消息给调用方；实时性要求高的且只能线性工作的需要采用同步接口，其他可以优先使用异步接口；

（6）接口描述（应用场景），对描口的简单介绍，供开发、产品、测试等团队成员看懂即可

（7）接口示例，一般都是 json 格式，这块不需要产品人员来写，接口文档写完后由开发人员补充即可，例如：

{

“resultCode”:200,

“resultDesc”:”新增成功”,

“demandCode”:”X202110090001″

}

（8）其它，比如安全限流、同时并发数、日使用次数等

以上接口基础信息必填，如果的确没有场景也应说明原因

 

2、消息头（非必要）

最常用的是调用第三方平台接口通常需要进行接口鉴权（比如登录身份验证），服务端判断用户端是否有调用接口的权限

3、请求参数（必要，核心）

产品经理需要根据业务需求明确接口入参中需要哪些字段信息以及字段支持的类型，一般以表格形成，表格由“名称、是否必填、字段类型、描述”组成

注意参数名称的命名规则，应清晰、简洁、统一

4、返回结果（非必要）

（1）根据业务需求定义返回的核心字段信息，一般有几种：“成功/失败、成功/失码代码、文字描述、返回参数“

（2）成功和失败都要有代码，比如：（成功）200，OK ResponseDTOOfstring、（失败） 401 Unauthorized、403 Forbidden、404 Not Found

（3）如果有返回参数，应参考“请求参数”，考虑“名称、是否必填、字段类型、描述”，并准备示例。比如请求地图的轨迹，那返回可能是 json 的经纬度数组

5、约束条件（非必要）

字段约束条件是为了保证接口的有效性、安全性，这点是产品经理跟业务方沟通达成一致后提供给技术人员，比如：图片文件尺寸限制、文件名限制、全量覆盖还是增量补充（对重复性剔除）等

 

接口设计要出接口文档，并由内部和外部评审通过方可执行（重要，多轮）

 

四、接口测试

接口测试虽然是测试的工作，测试内容也覆盖众多，但是作为产品可以简单了解以下内容即可，如，

1、接口可用性

即接口是否可以正常调用，正常返回结果，异常正确处理，正常返回错误码等

2、业务需求覆盖

即接口输入输出是否遵循产品需求文档描述

3、边界规则遵循

即接口是否满足业务规则和字段约束条件

4、性能条件

通常接口上线前需要经过压测达到性能指标才可，包括某并发量下的tps和耗时等

 

五、总结

这篇文章只是针对产品小白的接口入门，对接口文档设计做一个框架性描述，其中每个知识点都可以拿出来细琢磨。接口设计也分大小，小到一个图片上传，大到与支付宝、银行对接，先从基础的熟悉起来，慢慢成长。

对于产品来说接口工作要投入的精力大概分为4：4：2，即4分沟通协调、4分设计讨论、2分跟进，一定要多沟通，切不可以蒙头闭门设计。

接口中请求参数、返回参数要和团队逐一确认，对不确认的地方不可含糊和自认为做主。

接口一旦设计完成上线，再做修改时要通知对方，做变更处理，不然出了问题，对方不知道还要花时间精力排查问题，避免引起矛盾和扯皮。

公司之前系统的组织架构因为赶进度和初期业务简单的原因没做深入的规划，随着系统功能扩展和业务的扩大，旧的组织架构渐渐的无法满足需求。最近正在做手做平台的组织架构的设计，目前还在评审阶段，但有不少感悟，在这里和大家简单分享一下，内容比较多，可能要分几个篇章，本篇先介绍前期思考和大的方向。

 

一、什么是系统组织架构

狭义来说，组织架构是公司、部门、组织成员在组织内的上下级关系的层级体现，常以树的方式展示，并为这些树节点分配各自的属性，仅供浏览使用，不做进一步操作。

广义来说，组织架构还要包含功能权限、数据权限和特殊定制功能（比如工作代理、一人多岗等、指定操作等）

 

 

二、组织架构主要解决的问题

对于功能权限来说：（1）我能看什么；（2）我能做什么；

对于数据权限来说：（1）自己看自己；（2）自己看别人；（3）别人看自己

系统中只有清晰和完整的组织架构体系，才好进一步做权限的控制。如果这块没有想做规划，遇到问题只是补丁的方式追加，渐渐的系统稳定性、效率都会下降，复杂度、BUG率都会上升。

 

三、组织架构设计中主要考虑哪些因素

组织关系：现实中组织的关系，是否上面有集团，下面有子公司，是否有部门和子部门，组织架构中是否包含客户的甲方和乙方的组织架构等

组织运行：是否有审批流、是否有跨部门职能、是否一人多岗等情况

权限管理：各终端的权限、菜单的权限、操作的权限、数据的权限

现有改造：旧系统、旧架构中哪些数据可以保留，保留后如何迁移，对业务的影响

可扩展性：是否可以将组织架构抽离为基础数据供多系统共用，是否方便与第三方对接，是否可以关闭某些功能做到简化

 

四、组织架构设计的设计难点

（1）权限的维度，一般是功能权限（菜单、按钮）、数据权限（工作审批流、项目或合同订单等）

（2）权限的深度，一般是公司 > 部门 > 人，是否含有子公司和子部门

（3）查询的效率

（4）交互的设计

 

以上是简单介绍系统组织架构的概念和产品设计时要考虑的方向，下一节介绍我是具体从何入手来做组织架构设计。

 

 

选说结论，需要精美，但不要本末倒置过度追求精美。

 

一、原型的目的是表达清楚功能和逻辑

做原型的目的是为了和技术、用户、客户交流思想的时候减少误差，通过图形的方式有让对方有直观的映象。原型图只是工具之一，我们还可以用手绘、word、PS等方式绘制原型，不能本末倒置，为了美观做原型，或以美观做为考核指标。

二、太精细会吸引注重力

从观察来看，原型越细致，讨论问题的时候，谈话思话会偏向细节的推敲上，让谈话变的冗长拖拉。人的注意力是稀缺的，而且是没有耐性的，原型要突出重点。

三、太美观会干扰设计师的判断力

（1）当我们给图标定义、按钮着色、对齐分布都非常工整，人都是有惰性，设计师拿到后也会按照这种方式延续做一些细节调整。好比好的厨师拿到一支活鸡，心里有无数种做法，但拿到煮好的鸡之后，可能只能白切。

（2）人对花很多时间的东西都有情感，当被精美的原型被修改和舍弃时有难免有抵触心理，这样产品人员和设计师容易站在对立的角度。

（3）当精美的原型被客户接受认可时，设计如果变化不大，提升不高，会认为设计没有工作量和不重要。

四、更多的精力应放在想法和创意上

专业的人去做专业的事，我相信产品人员有审美和创意，但如果同样时间放在方案、文档、思考上，产出的价值会更高。如果有本事在精美设计上产出更高，完全可以转为设计师或上升一个层次。

总结，没有绝对的精美和简陋

最后，精美自然没有问题，只要在度上做个掌握，这个度是对方的接受程度和资源的允许。我相信精美的原型自然能提高沟通效率和美誉度，好钢用在刀刃上，让我们做更有价值的事。

我们谈的是过度精美，不能以“原型不需要精美”为借口，对产品工作敷衍了事，那是对对方和自己的不负责任和不尊重。

一、简介

JSX 是 Javascript 与 XML的结合。利用虚拟DOM来减少对实际DOM操作，从而提升性能。简单的说，在javascript中插入HTML标签，从而使代码更加简洁、易读、减少BUG机率。

我JS的水平仅限使用 jQuery 操作DOM，但JSX非常简单，抓住下面几个特点就能上手试用。

二、JSX与JS、HTML的异同

HTML举例：

<ul class=”my-list”>
<li>First Text Content</li>
<li>Second Text Content</li>
</ul>

---

JS举例：

var child1 = React.createElement(‘li’, null, ‘First Text Content’);
var child2 = React.createElement(‘li’, null, ‘Second Text Content’);
var root = React.createElement(‘ul’, { className: ‘my-list’ }, child1, child2);

---

JSX举例：

var root =(
<ul className=”my-list”>
<li>First Text Content</li>
<li>Second Text Content</li>
</ul>
);

 

因为class、for 等是 javascript 关键字，要用 className、htmlFor 代替。

 

三、特点

（1）解析方式

• 在解析时，遇到 < 符号，JSX就当HTML解析
  • <h3>输入</h3>
  • 转换成：React.createElement(“h3″,null,”输入”)
  • 返回一个 ReactElement 对象
• 在解析时，遇到 { ，JSX就当Javascript 解析。
  • var msg=”我是ABC”;
  • <h1>{msg}</h1>
  • 转换成：React.createElement(“h1”,null,msg)

（2）ReactJS 自定义标签

• HTML标签，首字母小写
• 自定义标签，首字母大写。比如：
  • var ShowEditor=React.createClass({ … });
  • React.render(<ShowEditor />,document.getElementById(‘example’))

（3）使用ES6的语法

• var props={}; props.foo=”1″; props.bar=”1″;
• <h1 {…props} foo=”2″ >欢迎</h1>
• 转换成：React.createElement(“h1″,React.__spread({},props,{foo:”2″}),”欢迎”)

（4）自定义标签属性（凡是以 data- 开头的自定义属性，可渲染到页面）

• <h1 data-test=”A” test=”B”>欢迎</h1>
• 网页显示结果：<h1 data-test=”A”>欢迎</h1>
• 用途就比较多了，可以传递参数、作为注释、作为jQuery筛选条件等

（5）_html: 为前缀的字符串，只显示HTML内容，不显示DOM节点。比如：

• alert(“<strong>重要</strong>”)
  • 显示结果是：<strong>重要</strong>
• alert(“_html:‘<strong>重要</strong>'”)
  • 显示结果是：重要

（6）style样式使用

• 用双括号包裹 {{  }}
  • 外层{}按照JSX语法，比如：
    • var myStyle = {
      color: ‘#ff0000′,
      fontSize: ’14px’
      };
    • <h1 style={myStyle}>你好</h1>
  • 内层{}是JavaScript对象，比如：
    • <h1 style={{fontSize:’18px’,color:’#f60′}}>你好</h1>
• css用横线连接的属性，转为驼峰方式连接
• 多属性赋值方式用JSON格式

（7）事件绑定，用onClick 调用bind方法（设定作用域，要传递的参数）

（8）数组递归

• 数组循环,数组的每个元素都返回一个React组件。比如：
• var lis = this.todoList.todos.map(function (todo) { … }
• var ul = (
  <ul>
  {lis}
  </ul>
  );

---

 

在我看来JSX更年轻、简洁、优雅、可读，学习这款语言的思想，可以使代码思维的边界明显扩展。

但过于灵活的混杂自然洐生出杂乱和随意，另外技术的高速发展让新人无所适从，比如ES4、5、6写法有很大的不同，相信还需要时间来沉淀和检验。

最后在学习的过程中了解到 Vue + week （阿里前端）也在做同样的事，不过市场占有率太低，不在对口公司工作，很难有机会深入使用，人材、资源、技术升级都是风险，不太看好。

 

最近几天有种感觉，快要接近配置成功的部分，没想到今天早上就意外调通了。并没有什么惊喜和感慨，因为一直有这样的信心和预期，这一刻只是早晚，而且更难的才刚开始。

整理一下昨天遇到的问题：

• 启动服务  react-native start
• 发现 8081 被启动
• 执行 “netstat -ano|findstr “端口号”” （注意，端口号外面加冒号，显示结果最后一行为此进程，记住【进程号】）
• tasklist|findstr 进程号 （查看具体的程序，记住【文件名】）
• taskkill -f -t -im 文件名（强制、递归 删除本程序及其子进程）
• 我的 8081 端口是 nodejs 占用的，凭感觉不能直接删，想换 nodejs 或 react-native 的端口号
  • 找了一堆方法没成功
  • 放弃，直接杀进程，没什么改变
• 仍然提示   could not install the app on the device（没有安装 app设备错误）
  •  adb devices （查看设备连联情况，连接上了没有问题）
  • 修改Genymotion的SDK不使用自带 SDK。
  • ->Settings->ADB tool connection settings 为Use custom Andrdoid SDK tools
  • 把模拟器和真机都插上，还是问题存在
• 我觉得我的思路错了，可能是其它问题。
• 仔细查看问题提示语句（很长大概30多行），我只注意了最底部红色提示部分，没注留头部的白字问题。
• 有一句引起了我的注意 java.util.zip.ZipException: error in opening zip file
• 我尝试删除了 tomcat 、下载绿色覆盖、删除 react-native 自建的项目，重新初使化。
• 还没来的及检验，一天时间就过去了
• 第二天莫名其妙成功了，我觉得是 jdk 的问题。

 

---

 

虽然遇到的问题非常多，但我觉得现在找答案越来越方便，报错的提示也非常清晰，基本上只要用心都可以花时间解决。

有三个能力非常重要：

• 搜商（针对具体问题，如何去提取关键词，如何去请教别人和发问，如何高效的寻找）
• 英语（计算机英语简单阅读即可，3秒内找到一段文字的关键词，大概是讲什么内容，详细内容可以交给翻译软件）
• 平常心

刚解决完2033、2052、2053问题，把nodejs 和 React-native安装完成 ，初使化项目成功，这只是冰山一角、长征一步。

紧接着运行项目时发现问题。

• react-native run-android
• 报错提示“没有安装app设备……”
• 看教程说要装 android SDK
  • 装 SDK 先要装 JDK
  • 再装 Eclipse
  • 我装的是 myEclipse，和 Eclipse 的区别是（后者是基础、不收费，前者是威力加强版，并且要收费）
  • 装完后破解 myEclipse
• 然后去 google 下载 Android SDK
  • 先翻墙
  • 官网发现现在 google 不支持 SDK 工具下载，用 Android Studio 集成了 SDK，这是个类似 eclipse 的开发工具
  • 当然可以去其它地方找到 SDK，我想了想，Android Studio 可以代替以前4个软件之间的窗口切换，而且是前沿技术不易淘汰
• 决定使用 Android Studio(Native客户端)+WebStorm（RN服务端）
  • 下载安装 Android Studio（大概700M），在公司翻墙速度比较慢，晚上回家下
  • 打开 Android Studio 的 SDK manager
  • 因为工具栏被收起，上网搜到工具栏打开方法：菜单 > View > ToolBar > 打开 SDK manager
  • 下载各个版本的 SDK（翻墙）
  • 听说自带的模拟器不太好，下载 Genymotion
    • 先去Genymotion官网
    • 注册发现要收费，个人版 136美元/年，企业版 412美元/年
    • 去网上找点破解版，听说Genymotion官网有不收费的版本，只是链接藏的比较隐蔽。
    • 我就信了回官网，找了好大一圈，全英文的页面我逐段翻译，每个链接都点开试试。还是没找到，网速又慢。
    • 回头又去找破解版，好心人给了个官网免费版链接 https://www.genymotion.com/fun-zone/
    • 装完了运行报错，要装虚拟工具  VirtualBox，好在以前开发网站要支持 IE6，用过这软件
    • 运行起来后要装手机模拟器，每个模拟器300M（要翻墙）
    • 第二天早上

好了，这就是两天的成果，我就像一个小企业老板，拿着一堆资料跑到各个行政大厅去盖章，这个说你资料填写不对，那个说你手续不全，给了一大堆资料回去慢慢研究，还有许多热心的三姑六婆来出主意，最后大家开心的各回各家，烧饭、看剧、奶孩子，留我一人在风中凌乱！

其中许多的细节，比如JDK环境变量配置、eclipse ADT 插件安装、网上好不容易找到的教程，看完才发现是 liunx 版等等，太多记不清了，这过程痛苦且充实，因为我每前进一步都是发现一片新大陆，这些学费不论是现在还是未来都是要交的。我有一种感觉，虽然路非常艰难，但一直没有走死，不像当年学FLASH的痛苦，一个问题能卡好几天最后无奈放弃，那才是真正的挫折。

我在配置React Native 环境的时候，找到玩解迷游戏的感觉了，我甚至希望不要快点把环境配置完，期待每次解开问题的惊喜！

首先去官网下载 nodejs 最新版本，安装就报 2203错误。然后今天一天我就在解决问题中度过，收益良多。

1. 先在百度上搜 nodejs 和 2203 关键字，没有太帖切的答案
2. 去知乎和CSDN上找了一大圈，试了很多方法也没成功
3. 把环境变量的用户和系统反复配置几遍，正反斜杠都试用一遍还是不行
4. 用管理员命令行启动软件，还是没启动成功
5. 想用administrator超级用户，win10家庭版不支持，想升级win10没成功
6. 给nodejs、系统temp目录、配置了system权限，不管用
7. 翻墙去google上找答案，用翻译软件翻，没太多收获
8. 最后把问题扩大，只搜 2203问题，终于在一个不起眼的角落找到一个方法，把环境变量temp和tmp删除，成功了
9. 然后又弹出2502和2503问题，这就简单了

具体解决方法：

• 官网下载 https://nodejs.org/en/
• 报2203错误时，把环境变量中的 temp和tmp删除
• 报2502/2503错误时，步骤如下：
  • win + x
  • 选择“命令提示符（管理员）”
  • msiexec /package “c:\nodejs\node.msi”
  • 格式一定要写对
• 配好环境路径。path追加 C:\Program Files\nodejs
• win + R，输入cmd
• node -v 看一下版本，npm -v 看一下版本
• 安装环境 npm
  • npm install express -g
  • npm install jade -g
  • npm install mysql -g
  • npm install -g express-generator

想自学一个软件，每个角落都是困难，如果有人点拨一下，会省很多时间。但如果自己解决，会有非常大的成就感和自信心。