项目与咨询==产品与技术要相互尊重对方==win-win

从我最近的工作来看，乐于做为business的thinker，作为乙方从甲方的mission/vision/strategy/brand去思考问题，因为真实而言，我们没有发现能够把自己表述非常清晰地客户。坐下来和客户一起谈，一起聊，也许没有钱，也许没有项目，但最后有收获了，感激与快乐同在。

surround and thinking closely, but be focus。。。

从市场竞争分析，从我们共同的目标分析，从可行性分析--这个往往是技术最无力了，从来或者很少听说因为这个平台技术很牛，我靠大家多来购买，Business Model和执行力才是生意成功的重要因数。

“

这个业务还是很深的，有问题请教

我们也在想整个流程，如何顺畅，减少歧义

我们的目标客户是不是。。

我们的策略是不是。。，当前领域最先进的是。。。

我参考了这个行业的xxx公司。。。

”

作为系统开发者，于我们有更多的义务去了解系统，于用户，甲方有基础的IT知识会更好。但是认真滴和用户沟通他们的需求，他们的pain.解决pain，而不是解决写在纸条上的函数。

 

“产品”=“需求提供方”，也就是提需求的人。其时还是那句话，产品和技术之间要相互理解，团结合作，最终把产品做好，赢得更多的口碑，挣更多的钱。而互相理解的前提就是要对别人的工作先要理解，甚至插手（这里不是为了显摆或干涉，而是真诚的参与）。

所以我总是建议开发人员 多从用户，领域，行业人员出发，亲自体验一下，甚至于自己去亲自实践一下。而架构者更要从更高的高度来思考问题，但是be focus，be rely on expert。

 

当需求（方）发生变动，甚至是天翻地覆的变化时，就意味着我们要修改甚至推倒重来已有的设计架构方案了。而这无疑是很痛苦的。即使我们使用了不少“手段”（比如：
模式，架构等等）来响应需求的变化，但遇到了需求发生根本变化（需求分析出现重大人为失误）时，同样会显得那么被动或无用。

我宁可花时间，自己，公司花时间帮助甲方理清思路，其实有个基本原则如果我们就原则办事，按某种需求去做，最后出来的东西是符合合同，但用户不满意，甚至用户最后发现当时的设计根本不符合现实应用。然后lose one，那实施方呢，拿钱很困难，毕竟甲方想TMD这个没用啊，少给点钱，搞不好还破坏双方关系，最后lose-lose。

结尾，我宁可补贴时间，或则再谈判，加钱，互相谅解，往一个目标去。预期后期贴钱，贴时间，不如前期想清楚，从文档管理项目，到楼，无不我们贡献了主意。。。当然有些心不甘情不愿的/

以后要改变这个心态，成功实践多了，这个咨询费用完全可以加入到项目来谈啊。not only programing, but also designer/ designer of business model.refiner of process.

越早投入编码，代码死的越快。而越来提出需求，需求变更的也会越快。这需求的变更一方面是市场的变化，一方面是人为因素。前者我
们无法准确预知，而后者却可以通过一些方法部分加以控制。比如专业的咨询分析，科学的汇总，充分的调研论证，而这都是对人自身能力，行业背景，工作经验的考量。现
在公司招的人五花八门，经常是专业不专业都招进来，然后通过短期培训就上岗了。如
果这些人之前就有相关行业的工作背景那还好说，如果是新手，并且恰恰是新手来给你
提需求，要求你这样那样的话，那就真把我们当手他们的“练手工具”了。

 

个人感觉是技术选型什么可以上，但全编码最好放到后期上，一个开发过程会经历如此几个阶段会比较舒服：

1。这个什么系统，想着不合理-〉差不多了-〉还是不对-〉文档什么全出来了-〉忽然开朗

2。这个xx技术，不好搞-〉差不多了-〉用不上-〉基本可以

3。没架子啊-〉上架子-〉补代码-〉不行啊

4。重构！幸好架子还可以，幸好技术问题之前搞定了--〉整理整理发布了