如果从技术层面而言，要想快速构建个性灵活的业务管理系统（包括但不限于敏捷项目管理软件），那基于可视化低代码平台的开发模式应该成为主流，像广州社科院、广州建筑设计院等单位都选择基于myapps低代码平台构建适合自身业务模式的项目管理系统，系统不仅满足项目管理需求，还融合了项目知识管理、项目费用管控，对于互联网项目型、科研设计院等单位都是非常适配的；
从两种不同的选型方向来看，前者对项目管理业务的理解更加到位，功能模块也非常的齐全，但是它是按照乙方厂商自己的理解去构建的，你如果要试用就得按他那一套管理模式来，后者则强调对个性化的快速适应，从工具层面强调你想要什么样的项目管理软件我快速给你定制，特别的这种定制不是传统的底层编码模式，而是把常用功能控件都已经封装好，把常用业务场景模板化，在此基础上用可视化拖拉拽的方式进行，开发周期更短，开发成本更低，后续业务调整更加灵活。
产品经理可以从以下渠道来调研需求：
1.从产品定位出发
对产品有足够认知和把控。产品是为了满足哪些人的哪些需求而做的。其核心价值是什么？，深挖核心需求，放弃价值不大的需求。
2.用户反馈
用户直接提出需求，交流论坛提出的建议和需求。用户访谈、调查问卷等方式搜集用户需求。用户行为习惯（如习惯、偏好、使用流程等）的分析来获取用户的需求信息。
3.竞争对手情况
竞争对手的产品优势及不足也是产品经理需求来源的重要渠道。竞争对手好的功能我们如何借鉴优化，不足如何规避，在反复探讨中也能获得好的灵感。
4.相关人反馈
包括任何对产品需求有贡献的人，主要有运营人员、客服人员、市场人员和开发人员的反馈。
最后需要注意：尽量保证需求的精准性，一是用户意图的准确，一是语言描述的精炼，否则接下来的需求整理工作必然变得非常吃力。通常的格式为：作为一个<角色>，我想要<功能>，以便于<商业价值>。这也是产品研发的标准。推荐：
workless可量化的任务协作软件，通过积分来衡量每个任务的任务量、难度和完成质量，最终合理量化每个协作创造的价值是workless的核心思想，诠释了精准协作创造价值的理念，适合中小企业或者成长型企业使用。
功能如下：
一、任务管理
1、任务分为四个优先级，其中A优先级的任务有时效性考核要求，如超时会根据扣分配置产生连带（连带上级）扣分；
2、一个任务的角色包括发布人、执行人、验收人，其中执行人可以是多人，也可以在任务执行过程中指派新的执行人协作
3、预估任务量是最终验收获得积分的重要依据，发布任务时需要客观评估该任务的任务量，并尽可能精准。
4、任务执行获得的积分=日基础分*难度系数*完成质量*任务量，其中难度系数、完成质量由验收人根据沟通和经验主观评定
二、任务的量化评分
1、执行人需要对A类任务特别关注，A类任务超时扣分=扣分日基础分*超时天数，并产生连带扣分，扣分日基础分和连带层级可设置；
2、执行人交付任务时提交执行任务的耗时，耗时是单独做该任务所花费的时间，不是时间流逝的长度。耗时是验收人最终核准任务量的参考；
3、验收人主观评定难度系数和完成质量，并根据执行人提交的耗时和发布人填写的预估任务量最终评定核准任务量，核准任务量应倾向预估任务量，适当参考执行人耗时，此后分数将自动计算出。
三、项目全局管理
1、项目进度的全局管控，清晰显示项目包含的任务、动态、文档、文件和进展；
2、在线创建项目文档，多人协作编辑查看；
3、共享项目文档，并进行动态管理
4、关键的项目讨论留痕，提升参与者对项目的信息对称程度
四、通过积分量化任务
积分是执行任务产生成果的量化体现，workless提供积分管理工具，对任务、汇报等成果进行统计，形成积分排名，为团队管理者提供数据依据。
workless适应不同的行业，30+行业在使用workless解决工作中的团队协作问题、任务管理问题、项目协作问题。
Worktile 团队对于开发和Scrum的一些理解，希望有所帮助：
关于开发，我们已经有了太多的方法论和工具，这之间其实很难说哪个方法论是正确的，哪个工具是最好用的；
其实开发是“任性的”，它没有定律，如人饮水冷暖自知，其过程是否高效，除了团队的内功实力这个决定性因素之外，还取决于整个流程是否是清晰的。
高效总是伴随着清晰而来，清晰的目标，清晰的计划，清晰的职责……而这也是Worktile采用看板的原因，直观可视的结构将原本错综复杂的流程变得清晰；而高度模块化的特性，又可以让一个个项目不再僵化，变成可以流动拼接的系统。
我们下面就以Worktile本身的开发作为例要介绍一下怎样apply Worktile in development 。
流动的系统
我们的开发流程是利用六个项目构成的一套开发系统，这六个项目分别是：路线图Roadmap，灵感Ideas，计划Planning，缺陷Bugs，设计Design，开发Development。这六个项目中，以开发项目为核心，其他的项目中的任务通过筛选汇总，最重构成可执行的开发计划。这个系统的构造为：
而让该系统得以运转起来的，就是其中各个项目的任务卡。每个任务卡代表了一个单一的功能、优化点乃至bug。以任务为驱动的Worktile，赋予了任务诸多的特性和功能，这可以让一个任务所携带的信息变得十分的精确，并且表现力丰富：
标题可以简要概括某个功能点；
描述可以作为详细的解释；
子任务可以分拆一个比较大的功能，或者用于标记开发中的注意事项；
负责人让任务责任到人，功能由哪个工程师负责开发一目了然；
参与人可以让PM或者team leader跟进开发进度；
开始/结束时间可以敦促工程师应该在什么时间完成；
标签/自定义字段将开发的优先级和问题醒目的标示出来；
附件可以用于添加辅助资料或者图片；
如果需要沟通，使用任务评论会非常便捷。
而通过任务（或者整个任务列表）的跨项目复制或者移动，这些任务就可以犹如血液一般在这个系统内流动起来，让整个系统焕发出活力。
管中窥豹
【开发Development】是开发过程中最主要的项目，也是落实计划的最前端。通过重点介绍这个代表性的项目，也可以一窥整个开发系统的运作模式。
该项目由技术负责人负责，新的任务来源于系统其它五个项目的汇总，其中的任务分为以下几个列表：
要做：每周的例会上确定新一周的开发计划，然后将【计划Planning】【缺陷Bugs】【设计Design】中的相应任务添加到该列表中，并对新添加的任务按照优先级排序，但在这个阶段并不进行任务的分配；
进行中：一个功能进行设计或开发的时候，将其从要做当中拖拽到当前列表，然后分配给相应的工程师进行开发，并指定任务截止日期；
待测试：开发完成的任务会进行到待测试列表，由测试人员负责质量保证；如果测试有问题，则退回到进行中，由工程师去处理；没有问题的话，就可以推进到下一阶段；
待发布：测试人员检查没有问题的任务会移动到当前列，等待部署发布；
已发布：对于已经发布的特性会进入到当前列，一般会把已发布任务在当前项目保留1个月左右，确保没有问题后，归档已发布的任务。
需要注意的是，如果产品是对应多平台的，可以将开发分为多个项目，这样可以让开发更为清晰，比如【Web端开发】、【iOS端开发】和【Android端开发】。
一些经验
这套系统内的项目要尽量采用统一的优先级标准，换言之，就是这六个项目要用一套【任务标签定义】。只有这样，不同项目内的任务在几个项目间流动的时候才会非常顺畅，不会因为标准不一造成什么问题。
每周在开发的【要做】中，仅添加一次任务，不要让工程师们觉得工作总是一望无际的，让他们看到一个个可以完成有限目标，最终，这自然会汇集成为一个Big Dream！
完成的任务别急着归档。对于已经完成的开发内容，都不要急着在路线图、计划或者开发中去归档，可以保留一段时间，比如一周或者一个月，这样可以便于我们回溯过去一段时间的工作成果。
无论你想把这套开发系统弄的多么的精简（比如一个项目）或者多么复杂（三层以上的项目），首先要明确的一点是——这套系统是不是让你的开发变得更加清晰了？为了确定这一点，你要检视一下，在这套系统之下，你的团队目标是不是清晰了，让你的开发计划是不是清晰了，并且让你的团队职责是不是清晰了。如果没有，你就需要作出调整。
