|
就裂缝的理想攀岩指南问题,我也来说两句
其实说白了,大家在讨论一个Web软件项目,现在还停留在可行性和需求分析阶段。
理性的分析方法是从用例(Use Case)开始。 定义出可能的参与人(Actor)和情况(Scenario),列出较常见的用例,然后根据优先级排序,计划当前版本要支持的用例,或以后几个版本要逐渐支持的用例。
下一步才会到具体的技术讨论,比如wiki或是blog,pdf还是flash.
比如说总结你们的需求,我可以看到
Actor: 1.开发岩场者,
2.前往攀登者,
3.轮椅攀登者?
Case:
1.小河开了新的project,需要方便的公布线路信息,同时希望别的岩痞能自由的反馈补充(如照片,beta)
2. wei要去爬白河,但是只有sport器材,于是在网站上通过地区=白河,类型=sport,难度=[5.8-5.11]搜索出相关的线路信息,网站自动整合并表现以方便打印成册。
3. wei爬完了,有一条线路需要70m绳子,网上没有提到,于是登录网站,添加信息到此线路
4, wei爬完了,拍了几张线路的照片,于是登录网站,添加照片到此线路
5, 裂缝看到wei贴的照片,评论了一下wei萎缩的攀登姿势
6, mh发现某条线路FA信息有误,提交更改信息,等待原贴者或管理员审批。
7, wei象在自己的blog里些trip report,中间直接插入网站中自己发布的照片
8,.. ?
我不知道大家认为哪些用例比较重要,个人认为1,2,3,4是最常见的,应给做的尽量好,而现在已有的网站都还不能完全实现这几个用例。这也让我们这里的讨论有些意义。
希望大家积极补充用例和actor,并评价各自的重要性。
有一个结论以后,我们可以分析具体要使用的技术。和显然,普通的wiki不能支持2, 因为1无法定义相关的metadata(climbingtype, grade, comparator of grade, etc). 也不支持整合不同的页面打印。比较理想的方案是类似于mountainproject.com的系统。但是好像市面上还没有现成的opensource项目。所以结论是如果要较好的支持1,2,需要独立或在wiki的基础上开发。
接下去就是考虑资源(resource),时间(time)和质量(feature, quality)的平衡了。好像我们时间是有,但没啥资源,所以估计结果是降低质量,砍feature,除非有谁技术很强,可以利用已有的wiki系统迅速改处一套来,不过根据我个人的经验,这个也很难(特别是考虑后期维护和升级)。.
总之,大家都有着美好的愿望,但一个软件或是网站从无到有不便宜的,我们应该分析什么功能是现在别家还没有的但确实必须的,并用最便宜的方法来实现。 |
|