开发产品学到的一些事(上)

收藏:581

开发产品学到的一些事(上)

这几年都在 start-up 打滚,跟着做了一些产品,也有一些小小心得,就纪录下来跟各位分享讨论。

不要一开始就写程式

你想到了一个好点子,这时你要做的第一件事是什幺?马上捲起袖子把点子实作出来吗?千万不是!你们要做的第一件事是 确认真的有客户需要这个点子 ,而不是草率投入大量时间、人力、金钱成本,最后做出来的东西却可能没人要。

或许你会想说东西都还没做出个雏形来,怎幺知道有没有客户呢?方法有很多种,例如你们可以把点子解释给陌生人听,看看对方的反应如何。或是先快速开发一个 landing page 来介绍你们的点子,并收集使用者的回馈。

确定真的有人需要这个点子,并且确定这个点子真的需要写程式之后,再开始动手写。

写好 User Story

你可以不写 Spec,但千万不能没写 User Story。User Story 的写法很简单,长得大概就像这样:「为了解决什幺问题,身为一个使用者,我希望在某种情况下,能够做某件事」。

写 User Story 有几个好处:

  1. 可以让所有人都看得懂因为 User Story 就是用大家都明白的语言,把想要做的事写出来,所以无论是不是技术背景的人,都可以看懂「为何需要这个功能、这个功能是为了解决什幺问题」。
  2. 可以帮助整理思路因为你得把你在什幺情境底下想要完成什幺功能写出来,在写的过程当中就可以整理自己的思路,检查这样的需求是否合理。然后因为大家都能看懂,所以无论是否有技术背景的人,都可以一起来讨论,这样就可以帮忙找出盲点,并且完善整个需求。
  3. 可以让开发者用最适合的解法解决问题为什幺我会觉得不需要写 Spec 呢,因为写 Spec 的人不一定是要开发的人,所以很容易就写出很莫名其妙的 Spec。更糟糕的是,有可能一开始就写 Spec,少了互相讨论完善的阶段,结果最后整个歪掉。所以我会说不要写 Spec,写 User Story 就好,然后把 User Story 写完整。有经验的开发者看到 User Story 自然就会找出最适合的方式去解决问题。千万不要外行领导内行,乱下指导棋。
  4. 方便验收既然 User Story 都写得那幺完善了,要验收的时候只要一一对照 User Story 就可以知道是否完成所有需求。对验收人员来说,看 User Story 就会知道这个功能到底是什幺,也就代表很容易就能理解要验收什幺。
一定要使用版本控制系统

版本控制系统的好处我就不多说了,无论是单打独斗或是团队合作都应该要用版本控制系统。我个人最推荐的当然是 Git,虽然它的入门门槛颇高,但熟悉它之后所带来的好处真是让人无法抗拒的。

近年来 Git 有越来越多好用的 GUI,已经大大降低初学者上手的难度,SourceTree、Tower、GitUp 都是不错的选择。至于要如何将版本控制系统整合到你的开发流程,可以先参考 Git Flow 跟 GitHub Flow,再逐步调整成适合你们团队的作法。

有了版本控制,当然就得记得要下版本号,如果不知道该怎幺决定版本号,可以参考 语意化版本号 的作法。

不必一开始就写测试

可能有些人觉得这是邪魔歪道,不过我真心这幺觉得:「你应该写测试,但你不应该一开始就写测试。」

身处在 start-up,无论前期的思虑有多幺周到,产品的需求还是很容易就会变更。如果採用「测试先行」的话,最后你会发现绝大多数开发的时间都拿去写测试了,而且因为需求在前期很容易变更,所以你的测试也很容易一改再改因而难以重複使用。

所以我会建议,等产品到达一定的稳定度之后,再来补上测试。到时可以特地安排一段时间专心来写测试,或是在需要重构程式的时候边重构边补上测试。

欢迎加入"Inside" Line 官方帐号,关注最新创业、科技、网路、工作讯息
开发产品学到的一些事(上)
开发产品学到的一些事(上)