作者：鲤洋
工作上还是比较能掌舵的，有些沟通的话（与团队成员交流、与自己交流）感觉可以记录一下，主要是产品工作方面的（直接、间接）。保持更新。
对工作较真是好事，但是还是注意度，这些问题并不是绝对的对错，更谈不上谁的对错，只是一个阶段性权衡问题。（今天，测试同学与前端开发同学就产品中的一个点的争论，我去做了判断决定最后执行，并与其中一位持有不同意见的同学所做的沟通解释）
——16.08.01
多想想在一个平台媒介上的功能实现，有没有更加“平台化、媒介化”的专属的，更方便的方式，比如手机上可以扫码去完成信息交流，这个比要用户手动去一个一个选，更加便捷。但是，通用型的方案，也基本必不可少。适应场景是一个大的因素。
——16.07.15
虽然看了，但是理解度不够，还是有问题。可能还是需要实战经验来促进理解，才能真的掌握到。
——16.07.14
提交信息和支付，应该无法作为“开发上的一个事件（要完成都完成，要失败都失败）”处理，所以有可能存在报名信息提交后，没有继续完成支付，那如果用户再进来，直接显示右边的支付页（无需再提交一遍报名信息），会更方便一些。从页面和弹窗的体验来说，这种专门的页面类似于订单，从感知上可能更让人觉得正式，正式也就显得专业可靠了。
当然了，或者说直接从简，提交信息后如果不支付，干脆连信息都不保留，这样去做不管是分页，还是用弹窗，功能上都满足。
这部分当时也没有过多深究吧，时间关系都是尽快出的一版。这个还是看实际开发，怎么快怎么来，下一版有时间我们再优化，你只要确保这个业务组成有，流程能跑通就行。
其实要说对于项目活动的状态，我只分为了3种，“报名中”“报名截止”“已结束”。而对于在“项目活动”详情页里，按钮上面显示的文字，并没有直接用状态词，因为我也在想，用户需要的是他可以进行的操作，至于活动到底是什么状态他其实并不需要去考究，更加直观，所以即使只是“我要报名”，点进去默认应该是“提交报名信息”的页面，如果是系统认为的“代付款”阶段的，就是“支付”页面了，算是一种自动化反馈。这些处理逻辑是复杂的，其实并不肯定应该展示给用户（而且页面交互这种处理会的细节会更多，开发量更大），核心的由背后的系统去处理即可，用户只需要最直接简单的流程去做就好了。
——16.07.12
后面只要不是特别急的任务，尽量都在上面发布一个任务，用来记录工作推进，不管是自己给自己创建的任务，还是别人创建的指派给自己的。
工作记录可历史查看，是对自己工作条理化的保证，也是对各方合作更明确的执行依据，更是对自己的保护。
——16.07.12
有些功能是为了满足功能需要；有些功能是为了满足心理需要。
——16.07.08
公司层面制定的决策，以开会出结论的形式，交付公告文档，来推进整体发展执行；反过来，这些文档也是调整和反推，当初的决定的依据。
口头说的，一个小会说的，任何没有落到文档确认公告的，都是空的。一旦后面纠结起来，理都没有捋出来。
——16.07.08
即使有些因素导致实际功能无法做出来，但只是模拟出来，某项部分用“假的”代替，其实也很有价值，起码是能展现功能的实际呈现地步，更加直观。这在整个产品里，就会增加产品的深度，丰富度。也是为增加产品说服力，提供依据。当然了，前提是，产品需求点里，能包括的内容，否则，就要反过来，影响需求范围。
——16.06.24
今后每项在“协作系统”上面的任务，创建的时候能标明预计完成时间的，一定要标记时间；不能标明的，确认一个可以标明的时间，到时候去标明；完成一个任务之后，在上面将“完成度”修改成100%，并修改状态为“已完成”；一周后，将本周“已完成”的任务项，修改为“已关闭”。
——16.06.21
需求>产品>竞争>市场
发现需求，寻找产品（没有则创造产品），需求被更多团队发现则出现更多产品进而多款产品形成竞争，分析整个市场有多大空间前景如何？
市场>产品>竞争>需求
存在整个市场，找出有哪些产品，分析相互的竞争，除了核心需求外各自的差异化在哪里？
人，是贯穿这整条线。
——16.06.16
产品上线后，收集到的问题，特别是问题性异常BUG，每一条都要在buglist上记录跟踪！让产品质量、技术人员水平等可以通过这些明显显示出来，把握得到。
——16.06.16
做设计，要讲逻辑，感觉更多还是为了团队合作，因为要解释，说服其他人，沟通成本总是那么的高；如果是设计师自己主控，可能都懒得去解释，从自己的美感出发自然会得出好的样式去做就好了，当然前提是确实有设计实力。
——16.06.14
1、打开市场的切入口非常好，“性价比”让这个局面彻底展开，但是，后续迷失了，没有坚持和提升自己的独特性，强行去做高端，低端市场也守不住，起步好，中途断片。
2、天生的出发点就限定了自己的天花板，起步的定位就导致后来用户对品牌的认知，对公司的核心诉求的坚守、演变，没有跟上这个市场的发展。
3、失焦，不专注，故事没有讲好，从一家有品质发烧劲的认知公司逐渐把自己玩成一个大杂铺，low了不是一点点。当初的核心——XX系统的口碑严重下滑。
4、核心业务没有持续超越，手机质量在市场同质化越来越严重的情况下，没有找出突破口，短期的营销红利基本快耗尽，运营后劲不足，产品也只是在浅的层面做扩充，没有壁垒，只是进一步靠短期收益，同时继续损耗品牌价值。
——16.06.08
深入调研理解市场行业，发展趋势，理解自己，尝试从不一样的甚至是更高的纬度去寻找解答，有机会得出跨越式地推进，实现超越，远远甩开对手。
对手越强，其巨大的优势也可能成为巨大的劣势，通过更高纬度的解决方案，甚至可以让其变得无效无关。跟跑，基本只有死路一条。
——16.06.01
在“个人中心”图标区域，如果其中的“积分”记录有变化（或者其他变化），可以在该区域显示一个小红点，用以提示用户，“这里有提示”，以引导用户去看（希望他们注意到的产品的功能点）。不加以引导，只是靠用户探索，可能用户基本就不会看，从而直接忽略。
——16.05.04
学习知识之后纵使后面我不记得它的出处，但它已经成为我的一部分
——16.04.28
不要为所有功能都提供使用说明。
只提供必要的使用说明，让用户能够顺利地使用应用即可；
至于其他功能，留给用户自己去探索。
——16.04.21
运营策略与功能实现，
正常逻辑来说，没有就显示没有，而不是“积分不足”，但由于商城商品过少，如果还没有上着几天就显示“商品兑完”，会给用户带去low的感觉
——16.04.13
现在XX产品的“活动评论”在我们这边没有主动去做量的情况下，用户也在自发的发评论，我们这边可以派个人也适当参与发评论以及去给用户发的评论点个赞，做一下活跃。
——16.04.12
需求真实存在也说明不了什么，更关键的是产品本身主打的点是什么，而这些点中是否包含了需要提供这个需求的理由，否则，该需求就不被纳入要实现的清单中。
实际情况是，也许也在这些点的范围里，但是，基于实际的成本（开发资源有限），需求优先级，暂时不做也是正常的。
一个表面需求背后总有个本质需求，也即一个需求问题，总会找到其更深层的问题，针对这深层的问题去采取解决方案，可能是更智慧的答案，使的是巧劲。
比如，你的解决方案，直接远超对手的解决方案，大家根本不是一个级别的。
——16.04.07
选择“XXX管理员”这个弹窗，其实都不需要。PRD上面的很简单，一个下拉列表即可。一个志愿者组织的管理员顶多不会超过10个，一般可能更少。甚至推广到更大市场，可能这个数量更少。所以，不至于专门还提供一个弹窗来供“这么重”的选择功能。
这里的弹窗只是技术同事偷懒的做法，为了方便直接沿用了之前版本里的功能实现。所以你会看到有些很机械，或者说不人性化的元素，典型的，像“微信ID”放在这里基本没有价值。
你也会看到，这个后台管理系统的界面是非常丑陋的，因为一些原因，界面并没有找设计去做，直接由开发人员自己搞定。目前的要点还是尽快把业务功能跑通为主。
至于你提到的这些UE方面的点，只要是有合适的机会，后面还是会逐步上的。
——16.03.03
1、这种非紧急反馈只需要发到“内部协作系统”对应的版块上面，我还有事情在忙，不可能一直回复这种问题；
2、界面上看起来的修改量和系统实际会有多少的修改量，没有必然的等价关系；
3、产品到底怎么迭代不是看方不方便改，而是有没有需要。有需要的，再难该改也要改，没有需要的，再简单也不用改。
——2016/1/7 10:17:01
1、现在上线的是叫XXX管理员“新后台”，其实是V1.0时期的产物，里面有些功能规划是存在问题的，也可能是需求分析的问题，这在V2.0会重新规划；
2、用户可以提想法进行使用意见说明，这是“用户反馈”，我们先收集着（这时只需要回复用户：感谢反馈，意见我们已经收集了，后续如确有必要会考虑加上，欢迎继续提出建议），然后做完需求分析看看实际的“用户需求”是什么，如果从产品角度审核通过了，才会作为“产品需求”加入到下一轮的产品迭代开发计划中；
——16.01.06
【企业内部协作平台】（工作协作系统、产品公告栏）
地址：XXXXXXXX
1、公司里所有人都分配了一个帐号用于登录此平台（如果你发现自己的登录不了，请及时联系我），
帐号名是 你的QQ号；
密码默认是 12345678
2、此平台中对项目和用户权限做了限制，所以不同的帐号能看到的、能使用的功能，并不一样，避免一些不必要的麻烦。如果有必要的，可以再对部分帐号开放一些权限。
3、此平台可以不登录直接访问部分内容，比如项目的wiki页等，以供快速查看像“产品更新记录”这一类必要的信息；
4、如果需要更多操作，比如“反馈关于产品的改进建议”，就需要登录自己的帐号去操作（目前将所有帐号都提供了反馈问题的权限）
5、要看各产品的更新记录，可以在此产品项目里的“WIKI”页查看；比如，【XXXX】产品项目“更新记录”
地址：XXXXXXXXXX/wiki
6、各产品项目里的“新闻”页，用来即时更新Bug修正，一些发布通知性内容；
7、此平台里的“项目”，主要是公司产品项目，其中还特别建立了2个额外的：产品（工作）相关规范完善、产品问题反馈。
前者是针对现状需要采取的一些改进措施（在此记录并推进），后者是供公司内所有成员来吐槽、反馈产品问题的渠道，这个方法来记录整体更有效率；
8、其中的产品项目，除了普通帐号可以看到的内容，技术部成员还可以看到具体修改问题点以及相关资料，比如分配给你的修改问题，如果你看不到，请及时联系我；
9、此平台的使用还在逐步过渡和完善，后续还会进一步更新。请及时关注各产品项目的WIKI页中更新内容。
10、这个平台的使用也只是“产品（工作）相关规范完善”中的一个方面，后续还会有其他方面的执行出来。在此再次感谢@XXX 搭建起了这个平台功能。
如果对这个平台的使用有疑问，及时联系我。
——2015/12/17
这种事情是这样，不是运营那边说马上要做什么活动了进而感觉出了个需求方案，技术这边马上就往产品上加。
应该是运营策划执行之前，就和产品这边说明，需要整体规划一下怎么做，再看有没有需要安排技术开发，这需要一个周期（有长有短），现在要逐渐规范公司产品方面的工作流。
现在看着可能直接在活动列表里加一列，显示哪个管理员创建的，你们就可以用了，那后面觉得不好用，或者容易出问题，比如需要人工统计，甚至这种这里加一个那里加一个的事情多了，产品越来越四不像，这很多就又要改。所以，要先看看怎么规划比较好，毕竟你说的这个肯定是个长期的用户运营
——2015/12/11 9:38:08
说明一下：
对于反馈的产品异常，如果是直接导致用户流程走不通的，或者其他比如“不断送礼给用户”这些造成很大影响的，算是比较严重的Bug，所以技术部这边会尽快抽时间处理；
而如果虽然是异常，但是并没有影响主要流程的，会先将此问题列入到待修改点列表中，再安排时间再尽快处理（处理完后会通知的）。这样整个工作安排会比较有序。
PS：技术同学一般是按照正常项目规划的安排在开发，是一个连续的过程，尽量不中断一个项目而弄其他的内容，这样工作推进效果更好。
——2015/12/1 16:30:23
嗯，可能我多说一点建议。
外部用户反馈回来的异常情况，应该由接洽的同学先按照他们反馈的情况，自己做一次，如果确实像他们说的那样出现异常了，然后再反馈技术部门这边，而不是一旦用户他们反馈了异常直接就找技术部门了；有些情况，确实只是用户自己那边的问题。
再一个，处理问题反馈沟通，及时告知相关部门同学自己在着手处理了，不管好不好解决，别让其他人干等着，其他人也好及时和用户协调。
——15.11.26
后面再反馈公司产品出现的可能异常，就按照下面这个格式来说吧，这样沟通清楚一些。 麻烦其他同学也这样处理，感谢�/抱拳：
【哪个项目】【什么用户】【在做什么业务】【是在哪个页面】【发生什么问题】，+ 起码1张当时出现问题的全屏界面截图
举个假设的例子，比如：在XX产品中，我（超级管理员）去创建XX活动，在新建活动页面，在所有信息栏里输入完信息之后，点击提交，系统弹窗出现一段乱码。截图如下……（全屏的截图）
——15.11.25
当初我做编程开发时的沟通记录，这时虽然我本职是写代码，但开发团队很多事都要负责跟进去推进。
今天说道的几个问题，除了那个打印的奇葩，其他的，
其实都和整个项目组织方面有关，
1、功能点需求说明，不明确也不够全面。一开始不够全面也正常，但是应该逐渐补充。不过此项目里，没有及时更新维护，甚至没有需求，所以到现在，想要回头再确认一下某个功能，多半只能靠脑力，相关留档文件基本没有可用；
2、开发或者说业务设计的辅助方面，相关文档制作不到位，就比如那个’库存‘是什么玩意，系统里的词汇对照表，从开始建立系统，到最后，这个表格是应该保持更新的，任何时候不明确一个词的含义，都可以通过这个表格里的定义，得到确认和统一。可惜的是，算是最开始有，后面没有继续补充和维护；
3、开发本身，客户端，服务器端，以及两者之间，特别是如何合作，没有约束，没有规则，没人能掌控整体进行调节，所以，过于自由随意。这个项目里基本无解。。。
上面只是根据此项目进程里明显经历的，作点小结，前车之鉴，如今后的类似的项目，必须引以为戒。
这里的经验意识，或者说，实际项目知识储备，得来不易 Orz
——2015-05-07 14:46:49
请注意，
今后处理“软件客户”反馈的问题，
首先从‘正确的业务流规范检查“，然后检查”操作是否正确’，
如果这些前提都是正确的，
最后，再反馈给开发人员检查。
‘正确的业务流规范检查“: 一个业务是什么，在什么前置条件下进行，在什么后置条件下完成，这些原则问题。
（根据“软件客户”反馈的问题所在业务，“我方人员”，判断此业务是什么以及其规范，确认其是否进行的‘正确的业务流规范’。比如，只有‘待结算’的才能进行结算，而‘已发货’的还不能进行结算这些规则）
检查”操作是否正确’：在上面这些原则的基础上，进行的与软件的交互操作上，是否是正确的操作。比如应该点A按钮，那就不是点B按钮能进行的操作。
（根据“软件客户”反馈的问题所在业务，“我方人员”，向其确认此业务的各个具体操作，是否是正确在进行操作。如果到最后“软件客户”说是全部按照‘正确操作’，“我方人员”，最后在自己做一次，确认是按正确操作进行）
——2015-04-12 11:37:22
团队工作推进，如何能使得这个推进能较为顺畅有质量的前进下去，其中有很多关键的要素，而团队成员的工作能力工作质量如何就是其中非常重要的一环。
在小团队里，或者说是相关规范制度很不完善的环境里，各成员的个人能力，更具体来说，是对工作的应变以及综合处理能力，且不说要多高，当然能高肯定
更好，但是，底线就是，成员的工作能力在成长，特别是在其他成员的帮助下，以前犯过的错不再犯，以前的缺点能改正，被指导过要遵循的工作规范要能
严格保证执行下来，积极并且主动进行工作。
在一般大团体里，由于存在较为完善的规章制度，不是着眼于那些“八股”，而是指的那些能为实际工作带来指导性，规范性，能将一个普通的不知道这些规范的人
被指导了这些规范后，做的的工作的质量是有显著提高的，这样的较为优化的工作流。
主要还是关注小团队里，实际的发展中肯定会出现不满足上面说的要求的，甚至更甚者，表现更严重，那么应该的处理方式是什么？
一旦发现存在这样的成员，必须，一定，绝对要尽可能快的将其从团队“移除”，不然很可能带来严重的隐患。
如果实在是实在暂时就“不能”移除，或者说是观察期，那么对这种成员的工作安排，应该是负责“非节点”性工作内容，否则很可能会
影响其他人的工作甚至整个团队的工作。
——2015-03-12 18:34:16
#工作流##测试用例#
如果测试用例表一直在保持更新，并且根据它在推进测试以及bug处理，那么，这次再出现的这个问题，其实一早就可以发现原因。
但是开发人员这边只是凭人脑大概记得这个以前出现过也修改过，但是具体原因不确定了。
如果测试用例表用的好，第一次出现这个问题，那么测试用例里面肯定会加上这个用例，并且备注里或者其他栏目标记“异常原因‘，
这次这个问题一出现，马上就可以到测试用例表里查看，很快就可以确认问题，解决起来更快。
当然，之前很长一段时间测试用例没有用起来，所以，上面说的只是用起来的情况，是规范工作流之后才会有的。
还有负责测试用例更新维护的人员，也需要在开发人员修改完bug提交的反馈里提取出原因，添加到这个用例里。
以上说的是测试用例部分实际有价值使用的工作流的一部分，请注意
——2015-03-05 16:58:13
#工作流##测试用例#
同样的，其实后面在维护这个项目的时，有些时候明明感觉这个问题以前处理过，可是无从查起。
而如果测试用例表保持维护在更新，上面的那个测试记录里，是可以
很清楚看到这个bug以前出现过没或者出现过几次，
这样去用测试用例表，才是将之前设计的”开启关闭值“的价值利用上了。
这个说的也是测试用例表工作流的一部分，
请注意
——2015-03-05 17:02:55
规范的发布流程里，确实应该包含一个更新版本的说明，
以提供本次版本更新的细节问题
——2015-03-05 18:06:36
需求文档，各个部分，单独的点表示的功能写清楚了，
再把这些点“串起来”，把流程性的控制说明，默认页，如何切换，保留刷新等等
——2015-02-28 16:31:50
还有，我刚才看了一下你用的测试数据，以前已经说过，每次起码是2-3条数据，不要只有一条，仅仅1条数据的情况只可能是极少数，常规测试都是2-3条数据，这是起码的
——2015-02-28 15:02:29
让你去输入试试，我是想告诉你，这里的这个功能是后来加的，可能测试用例没有，如果有的话，一旦我修改了这里的功能，那么，你应该将这里的测试用例找出来，整体走一边，以确认是否这里的一系列功能正常
——2015-02-28 15:02:42
之前写过这里的测试用例，找出来看看，里面的测试用例，的粒度，到了这个程度么？
当然了，不是说你写的不到这个粒度就是有问题的，这个粒度是可能随着功能设计的细化，逐渐更新和细化测试用例文档，进一步整理出来的，
最开始的需求文档说明，很多也不会达到这个地步，
而真正实际要用的，随着项目的准备工作的推进，会达到这个粒度
——2015-02-28 15:06:22
其实需求文档和测试用例基本一致的，只是一个为了表述有哪些功能以及怎么用，另一个是为了检查有哪些功能，并且是否正常，
原则上是分为2个不同的文档的，
你把需求文档写完，按照测试用例那个“粒度”，
然后，再稍微排个版，加个测试结果部分的，就是测试用例文档了
这样，按照上面说的，你先写完一个模块的我看看
——2015-02-11 14:31:47
我看了你写的入库测试用例
1、你这个写的是入库流程的，其实我是想看你写的‘仓管模块里入库部分的’，可能我当时没有直接指着仓管模块说；
2、那看了这个入库流程的测试用例，作为流程级别的测试，目标是确认，这个流程是否能走通，而且是前后正常能对得上的（数据），流程里主要的操作正常，在这个目标的标准下，编写对应的用例说明，你这个文档里应该是包含到了所有的主流程，而最大的问题是，“操作步骤细节”和“预期结果”里面写的内容，杂糅的，’细节‘里包含了结果，’结果‘里包含了’操作细节‘，如果你觉得某个流程需要对一步一步的结果是边有操作然后要有结果说明，那就拆细点；
3、而回到说，如果做的是’仓管模块里入库部分的测试用例‘，那么目标就是什么？你先想想
——2015-02-08 14:22:55
是的，粒度上要比写‘流程’的更加具体
——2015-02-08 14:32:42
’仓管模块里入库部分的测试用例‘，目标就是
要尽可能的在这部分里，对它提供了的所有功能，每个细节功能都测试到位，比如同样都是从A到B，可能提供了A到C到D再到B，也提供了从A到D再到B，还有A到E再到B的，这些同样都是属于“A到B”这个提供的功能里的，但是具体操作上会分为这么多情况，那你的测试用例里就必须穷尽所有的情况，以达到这个测试的目标
——2015-02-08 14:28:04
你后面在写测试用例的时候，要明确当时写的内容，是按照上面哪个目标去做的，那样才会让写出来的测试用例有保障
——2015-02-08 14:29:46
待补充……