基于商业目的而开发的管理软件，从基因组合上就决定了她应是销售，客服，技术，产品等多血统结晶。以上授体任一缺失或不作为，都将导致所开发的管理软件先天不足，即便面世，后面也极难快速成长。
以下仅就软件开发需求环节分享自身感受
技术研发以产品PRD为指引，而产品PRD是应以用户需求为根本的。
用户需求的明确，目前个人理解应至少划分为以下两个层面。
第一层面是市场需求， 即用户需求的提炼与判断
销售，客服作为用户的代言人 产品部作为用户需求的判断，尤其是将用户需求按“需”分级，这里的“需”既应兼顾到市场需求的急迫与重要性，也要考虑到公司研发团队的匹配性，呈现的结果就是通过产品PRD的版次来将这些需求进行梯级分配 考虑到产品的研发一定要有超前性，因而技术研发不建议直接参与到这一层次，应该允许产品部按需求去制定产品PRD,这样的PRD才能有前瞻性并对技术研发形成挑战，而不会因为现阶段技术而受限，失去创新性;而产品PRD在此阶段可以更多地考虑用户的适用性与偏爱，销售与客服可以加大发言权。只有客户喜欢，研发出的产品在上市时才更有竞争力。 销售，客服与产品对待开发的产品PRD或产品原型进行小组确认。。。 产品的超前性要适度，是相对的，即兼顾开发资源与开发成果间的对应关系，如国外市场上已有类似，国内尚空白，或界面优化，或改善用户操作友好性。。。
第二层面是产品需求，即产品PRD需求的沟通与明确 已确认的产品PRD, 在实际交付技术研发时，是否需要配合讲解与培训，是否要有“确认”， 只有在保证技术完全理解并认可产品PRD的前提下，才能发挥产品PRD的价值，否则，同样的PRD下开发的结果与最初设想不符，或中途因研发不利而修改产品PRD,会造成信息错乱，失去管控。 研发过程中，产品PRD的修正难以避免，尤其是细节或界面优化等，但修正的程序，一定要产品PRD引导研发过程，即保证一定的提前性。 产品与技术研发互动，产品PRD的交付是非常关键的，是应该被足够重视的，有疑问，尤其是与技术能力，与资源配置，与开发时限关联的，应该在交付时就考虑并及时反馈。因为一旦产品PRD被认可，技术方面就可以提供开发里程碑设定。。。方便后续追踪与跟进
这里特别强调一个步骤，即在软件产品开发前，真的有必要对参与软件开发的技术人员进行或确认与所开发软件相关联的知识普及。虽然软件开发人员的确不排除“堆代码”的工作性质，但如果开发人员自己都不十分清楚所开发的模块实际使用应该是什么样子，要用来做什么，与上一步骤如何衔接，将如何影响下一步骤的操作，那么这块产品的开发前景真心让人忧虑。。。如果技术团队实力超强，即凡是产品经理能想到的，技术团队都有能力实现，这种情况还好。而如果技术无法支撑产品天马行空的各种远景，在实际研发中，产品不断地向技术妥协，那么这款产品既无法体现出设计的创新，更不可能使用户需求得到完美解决，那么最终出来的产品一定不是精品，而是平庸的集合，上市时出现一堆问题也是意料之中的事。
网友评论