标签：构建 自己 引导 str 特色 方案 最大的 cal 简单
后悔没有早点读完这章，回想团队项目刚开始时做的需求分析，深深感到我们实在太天真、太理想。毕竟没有理论指导，按习惯做调研是容易碰钉子的，不过现在项目还未正式启动，亡羊补牢，为时未晚。
我们踩中了哪些坑？
①未能充分引导用户表达需求
我们采用了问卷调查的方式，但没有做进一步的深入调研。问卷调查有其好处——简单方便、调查速度快、数据易统计，但也有固有的弊端，那就是容易形式化，不易让受调查者充分表达自己的观点、问题或是诉求。出于节约受调查者时间的目的，题目基本设定为多项选择，这会有什么后果呢？填问卷的人看完题目便根据自己的第一反应或最近（最近多久也无法确定）的状况作出选择；同时，我们并未进一步的询问情况，答者也就不会花更多的时间给我们建议或说明实际情况。做完这些后，我们看似获得了不少数据，作出了一些立即的结论，但这些都是肤浅的。反之，我们损失的是更深入的用户体验，而这往往决定着软件的生死。总而言之，我们把“人”想象的太简单了，只从片面去考虑问题，得到的结论也将是不完全的。
②理想化思考，调研不够严格
在调研之前，我们确实可以提出自己的想法，畅所欲言，不过，有些决定做得太早却不是好事。结合之前的讨论，我们有不少“我觉得……，所以我们就要/不要……”的言论，可能我们是将要开发的软件的目标人群，但充其量只是其中一个渺小的子集，不能代表广大用户群体的需求，除非是一些普遍达成共识的结论，不然都需要经过充分调研才可得出，这也是需求分析的意义所在。过多的“我认为”会带来先入为主的错误，从而降低了软件功能与用户需求的覆盖率，如果因此恰巧错过了“杀手功能”那就真是追悔莫及了！
③功能分类不明确，缺乏主次
之前我们设想了一大筐可以添加的功能/模块，仿佛吃火锅一样，食材怕少不怕多，感觉什么都能往里加，然后沉浸在头脑中建好的罗马城里，自我感觉很棒，要是真的做出来了，必定大受欢迎。不知不觉中，我们又犯了理想与乐观主义的错误，试问，这些功能全部做完需要多长时间？这些功能都能真正吸引到用户吗？我们的技术（考虑学习新技术的时间及预计的掌握程度）能完成所有模块的开发工作吗？那么，我们要怎样做？进行功能和需求的分类！书中提到的做法我觉得是可取的和行之有效的。按功能分为“杀手功能”和“外围功能”，按需求分为“必要需求”和“辅助需求”，而这些当然是要根据细致的调研结果得出的。
当然，这些“坑”只是我们前期存在的比较严重的问题，还有其他一些细小的问题就不在此一一列举了。
我们该怎么办？
对于问题①和②，我觉得可以重新开展调查，至少应该抓住重点对象进行进一步调查。毕竟，我们的软件可能不是大众必需品，所以我们要提高对使用者的粘性。在设计问题是，我们需要充分引导答者，让他们说出心里话，表达出自己的需求，这样我们才能充分判定哪些功能是适合开发（有人会用）的。这还不够，我们还需要看出哪些用户对这款软件特别期待或感兴趣，再对他们进一步调研，要结合他们的想法来规划一个模块具体怎样设计才是令人满意的。前者，相当于在一块地上建东西，到底是建公园还是建大楼？后者，则是具体落实要怎样建，如果建公园，公园里该有什么？如果建大楼，大楼几层比较好？建成什么形状？这都是要通过调研来确定的。
对于问题③，我认为书中提出的解决方案是比较实用的，即按功能分为“杀手功能”和“外围功能”，按需求分为“必要需求”和“辅助需求”。必要的杀手功能要投入最大的力量去开发，争取做成自己的特色，与类似软件拉开差距。必要的外围功能则可参考其他同类软件，做到差不多即可。辅助功能则抱完成就好的态度，甚至可以在时间不够时放弃，之后再陆续添加并改进。
标签：构建 自己 引导 str 特色 方案 最大的 cal 简单
原文地址：https://www.cnblogs.com/Laplace-s-Trap/p/8886146.html
