论产品需求的理解在开发过程中的重要性——一场技术讨论的反思

    昨天产品发了新的交互说明书，其中主要增加了运动过程中“配速” 信息的记录和展示。大部分人可能对“配速”一词不是很熟悉，百度百科上是这样的：

     也就是说，配速表示的是每公里用时。在新的交互中，需要在一个列表中顺序展示某一次跑步过程中每公里的配速。这一信息在之前的运动轨迹文件（GPX文件）中是没有保存的，也没有其他地方有关于配速的展示。在用户运动时，我们已经可以记录采集到的每个GPS点当时的经纬度、速度、距离和GPS时间。这些信息为了能够在安卓客户端与iOS客户端向服务器进行数据同步时保持一致，使用了一同定义的GPX格式，大致像这样：

     其中的type表示的是骑行模式，是跑步还是骑行。对于如何在运动过程中获取配速信息我们没有异议，比较相邻轨迹点的向下取整和向上取整就可以得到运动距离达到整数公里的轨迹点。但是对于如何保存在GPX文件中，我们有了不同的想法。对于公共使用的数据文件的制定，可以参照公共数据库格式的要求：

    1、在满足需求的条件下尽量减少对公共数据文件的格式更改；

    2、在兼容新旧数据文件的同时，尽量少的产生冗余数据。

    对此，安卓组的同事建议在trkpt 节点下增加<duration>0</duration> 节点，这个节点存储该轨迹点距离第一个轨迹点的秒数，最终像是这样：

<trkpt lat="31.828234815111482" lon="117.18830751582587"><ele>49.6828332826443</ele><dis>0.008209216</dis><sp>7.497872</sp><time>2016-02-24 14:12:49</time><type>0</type><duration>42</duration></trkpt>

    这样做的依据是GPX文件存储的都是比较原始的信息，而且有这些信息后，客户端可以根据这些点方便的得到每公里的配速表。但是这样需要所有的点都记录 duration，就需求来说会产生很多的无用数据。因此我的意见是在轨迹点的数据区之前，单独开辟出存储配速表的信息，就像这样：

<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.2" creator="Cycling">
	<trk>
		<name>1918_0_track</name>
		<paceseg>
			<pace value=“320” ><pace>
			<pace value=“345” ><pace>
			<pace value=“325” ><pace>
		</paceseg>
		<trkseg>
			<trkpt lat="31.828524" lon="117.189110">
				<dis>0.018462</dis>
				<sp>7.008073</sp>
				<ele>73.000000</ele>
				<time>2015-11-12T13:37:40Z</time>
				<type>0</type>
			</trkpt>

     这样定义的优点是可以在处理GPX文件时直接读取出配速表，不用处理所有的轨迹点。但是缺点也比较明显，就是扩充了单独的数据区，同时还是存在一定程度上的数据冗余。在讨论了一番后，我们最终确定第二种方式更好一些。

    但是，没错，就是但是，就在这时，我突然想到了百度百科上关于配速的定义，就是文章开头的东西。配速，是跑步时每公里的所花的时间。这个时间好像有问题，因为我们的运动模式——骑行和跑步，在暂停时都是不计入时间的，就是说当速度低于某个阈值时，我们的计时是停止的。这也是为什么我们要计算配速并存储到GPX文件中，而不是使用GPX文件中轨迹点的GPS时间的直接原因。但是，配速的时间是怎样计算的呢？是应当将暂停时间考虑在内，还是按照骑行时的时间一样不计算在内呢。按照百度百科的定义，恐怕应该按照前者。

    于是，本文回到了标题所说的产品需求的理解在开发过程中的重要性。我们在与产品的同事确认配速的定时，证实了配速计算应该是从运动开始起，不论运动速度为何，如果结束都应计入时间。举个极端的例子，如果我开始跑步，但是跑的很慢，花了15分钟跑了500m，睡了半小时，再花了15分钟跑了500m，那么我第一公里的配速就是60分钟。以这种情况来考虑，那么我们之前讨论的关于GPX文件的扩展都是无用的！因为现有的数据已经包含了完整的信息，根据轨迹点的GPS时间我们就可以得到每公里配速表。

    所以，总结来说，由于我们开发对配速这一概念的理解并不很深刻，没有意识到与之前骑行时间记录时的不同（一定程度上也因为是产品需求说明不够详细），使我们花费了一番功夫在一个本来没有必要讨论的技术问题上。这样的问题我想很多开发者都遇到过，因此，在我们拿到新的需求时，在想当然的理解之前，不妨对于自己比较陌生的领域知识和产品人员做深入的沟通，加深对细节的理解，也好发现需求输入时产品人员没有考虑到的问题。