剑客
关注科技互联网

一次被咨询后的感触

上周末陪着朋友去谈项目,刚好派单方是我以前的同事(好吧,其实我就是传说中的介绍人~)。一进办公室,对方的程序员就开始直奔主题,让我感到些许的不舒服。别误会,我十分喜欢开门见山直奔主题,但项目背景肯定是不能省的,直接进入具体功能细节真的让我感觉不适应。不过考虑到我只是个旁听,所以也就耐着性子听了一会~不一会老板来了,我就被拉出来私聊了。

和老板的一番交谈,刚好弥补了项目一些背景信息。原来之所以打算外包出去部分功能,是因为这个项目出现了不小的问题。这刚好解答了我本来的疑问:为什么明明自己有程序员,却还要找外包?

梳理了一下,在这个老板的眼里,主要就一个问题:项目迟迟不能上线,他感觉被拖住了。这种感觉其实我的领导也有,我也因此被叫过去谈话好几次~~工作了七八年,凭借经验我第一直觉就是:需求变化问题。果不其然,这个项目的需求一直在不停的变化,大到需求小到界面,都随着老板日复一日的新想法而发生在或大或小的变动。当然,另一方面也和程序员有关,例如经验问题,能力问题,心态问题等。这部分我不想深谈,并非是因为我也是程序员而不想找程序员的问题,仅仅是因为我对他们的那个程序员不了解(后面通过和那个程序员接触我确实也发现了一些问题,后面再说~)。

我们先从需求本身来分析,问题如下:

  1. 需求变动太频繁
  2. 需求假设太严重
  3. 产品胜过使用者

很多我去过或见过的小公司的it项目都这样,老板突然有了个想法,自己其实也没想太透,更没有去验证和评估自己的设想,反正公司有开发人员,做呗。今天一个新想法,明天一个新创意,后天就能出来一个颠覆整个项目的大构想。身处这样领导的部门下面写代码,真TM的命苦啊!

那该怎么办? 严格控制单次迭代的需求变更次数,尽量做到不对当前迭代进行任何需求变更
。说起来简单,但很难做到,毕竟这个世界是在时刻变化的。但,至少我们应该时刻记住这个约束,尽最大努力保证它的有效性,而不是无视它。无视它的后果就是项目的无限期延迟。(我所负责的项目,某个模块前后足足做了3个月,而最初预估用时是1个月,多出来的2个月都是因为需求不停的改动花费的~)

我这么提到这点后,老板则是这么回答的:那明明知道不改的话等于白做,也不提么?是个好问题,但这个情况值得深思~尽管我承认随着时间需求会产生变化,但是否每周都会有?是否每次变更都是颠覆性质的?我很好奇。

为什么会这样呢?我个人觉得,是因为成本预估没有有效的量化方法。身为老板,他决定是否启动一个项目时,首先要考虑的应该是资源的投入问题:时间成本,人力成本。当然,他需要一个程序员老司机(其实就是项目经理)来反馈一些数据来辅助他做决策。其实多数情况下,老板并不是最终的系统用户,他只是系统的间接受益方。而实际上呢,老板可能并不这么认为,所以他才会武断的提出所谓的创新和想法,他也固执的以为自己的这种想法真的可以有效的帮助到系统的真实用户。所以,在交谈时我有意无意的问他:这些设计是不是真的和用户确认过了?而他的答案呢,则莫能两可~~我内心只能呵呵。那应该怎么样呢?大公司往往这部分工作是有专门的产品经理来负责的,产品的定位,功能,甚至界面交互他们都会琢磨和思考。而且,职位的使命感和责任感会让他们不自觉的思考更多的维度,毕竟如果项目失败了,他们有可能面临被砍掉的风险。而这种无形的压力和约束力是老板不会有的(老板的压力来自于其他方向,我并不否认老板存在更大的多的压力)。

我私下和他们公司的一个部门经理聊(也是我的朋友),得到的数据确实证实了我的猜测,关于这个项目的很多想法真实的使用者并不买账,除了感觉复杂以外并无其它。我后来给他们提到了一个产品哲学问题: 到底是人用产品,还是产品用人
。听起来这是一个很搞笑的是选择题,对吧?!但我认为真的应该认真思考一下这个问题。

他们公司的产品,涉及到一个自定义订单处理流程的模块,他们参考一些现有OA系统的设计,弄出来一套非常灵活(有点bt)的工作流自定义方案。乍一听非常合理,也很强大,但我总觉得怪怪的~

奇怪的地方在于,他们公司的规模:一个不超过100人的公司(包括保洁员),业务范围也相对专一(互联网营销),每年的订单量大概只有四位数(包括作废订单),办公场所不超过300平米(大厅,会议室,总经理办公室玻璃墙隔开)。这个项目他们一开始是自用,未来考虑卖给其他公司。通过询问,老板说这个项目的目标客户也都是此规模的小型公司为主。

ok,那么问题来了,公司真的需要这么灵活复杂的产品么?我们来仔细思考一下:订单处理流程。按照他们的需求,可以为指定类型的订单来设计每一个处理流程,每个流程对应系统里的部门及其中的负责人,包含处理所需时间,包含其它一些业务选项。流程也涉及到异常处理,状态提醒等(我也只听了这么多)。

这样的功能其实并不罕见,也很合理,经得起推敲。不过我的关注点则在于:考虑过使用者的感受么?其实订单处理流程一直都存在,我的意思是,即便是没有软件系统来定制,公司的规章制度也无时无刻在发挥作用。即便规章制度存在死角,但人是会变通的,公司没有倒闭就证明这不是问题。人类是社会性动物,意味着无时无刻都活在规则里,不存在绝对自由。同时,人又是自私的,怕担风险的。这一切的事实,就证明了,即便是系统不提供这样的明确要求,一个订单从开始到结束都会遵循合理的流程。

我给他们举了个例子:新员工小明有一个订单需要提交,他会怎么做?他一定会去问经理,经理一定会知道提交给谁,即便是这两个“一定”出现了错误,小明错误的把订单提交给了小美,但小美自己知道处理不了会怎么做?

那按照我的逻辑,工作流就没有意义了么?当然不是,如果是跨国公司,或者公司人数上万,办公场所不在一起,业务范围繁多,都会需要一个相对明确的工作流程。但注意,即便如此,我依然不认为固化工作流程太细是好事儿(例如上面提到的“指定处理时间”或“指定处理人”)。

就拿“在工作流程安排中指定处理人”来说,人是可以请假的,对吧?所以,我的意思是,不要把软件设计成一座用户的监狱。是的,没错,我不太同意把用户当成傻瓜的设计哲学,这有悖于人的自我认知,毕竟没有人觉得自己真傻。

另一个层面,我们需要设计一套完善的数据分析逻辑,来让使用者查看系统中错误订单的错误原因,尤其是甄别出恶意操作行为。系统收集这些数据的方案很多,尽量保证不要影响用户的使用成本。这样似乎才能更好的打造一款产品吧(我似乎不确定一定可以!)。

上面我们一口气说了那么多,解释了我对那三个问题的看法。接下来花些时间来说说这个公司的程序员。

可能是作为旁观者更容易发现问题吧,我觉得这个程序员(或者说大多数程序员)有一个问题:不懂得化繁为简。更可怕的是,很多程序员还总化简为繁来寻找成就感(几年前我就这么干)。

当然,这和工种有关,这也证明一个稍微大一点的项目,都需要一个项目经理。直接交给程序员来分析功能只会加速这个项目的崩塌,因为他们思考问题容易陷入细节,没有大局观。因为他们的成就感来自于解决某个特定的技术问题,只有这样他们才会感觉幸福。如果让他们思考技术之外,人的问题,他们的思维就会变得慵懒,拖延症。但,正如之前我说的,产品是辅助人使用的。你可以不认可这个观点,但你总不能推翻“产品是人用的”这个论点吧,既然如此,你怎能忽略“人”呢?

我不否认我推崇“技术至上”的价值观,但多年的工作经验让我明白:解决方案总比问题多。我也喜欢刨根问底,多年的刨底经验告诉我,如果一个业务问题复杂度超过预期,那一定是人的问题。这个时候,通常需要冷静,跳出来思考,另辟蹊径总能达到更好的效果。

说了这么多,你一定以为我成功的影响到了对方,辅助他们做出了更合适的选择,对吧?!其实,这次咨询经历是很失败的,至少对于他们来说,因为我并没有提供任何被采纳的建议,哇哈哈哈~他们的需求还是一如既往的复杂~如果让我分析原因,我只能归结于:

  1. 我并没有足够的权威来辅助我的观点
  2. 我并没有强大表达能力
  3. 对方并没有足够的失败经验来辅助消化我的建议

其实,尴尬的是,我自己负责的项目,依然存在上面说的所有问题。我连自己的客户都搞不定,还怎能奢望去搞定他人呢?哇哈哈哈~~

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址