设为首页收藏本站
查看: 75|回复: 0

[PHP] 做一个有产品思维的程序员

[复制链接]

论坛元老

Rank: 6Rank: 6

积分
34274
主题
17031
UID
1347
M币
67
贡献
17176

  • 发表于 2014-5-21 01:51:00 | 显示全部楼层 |阅读模式
    针对这些年旁观和经历过的技术产品场景,做一些个人的总结和判定,尽量不涉及争议性话题,比如对一个互联网公司而言,技术重要还是产品重要之类的,这种话题一扯开,各有道理,谁也别指望说服谁。
    此外,加一个前缀,主要针对非技术领导者所面临的技术管理困境,在很多从传统企业转型或个人站转型的互联网企业里,这个问题较为突出。
    以下一些产品经理 or Boss 面临的场景,不知道读者是否熟悉。
    这么简单的需求?为什么开发告诉我要做那么久?
    同行 or 竞争对手都做出来了,为什么我的开发说这个无法实现?
    我明明说清楚了,开发也确认了,给我的产品怎么是这么奇怪的一坨?和我想要的完全不是一回事。
    线下测试都ok,一上线就各种崩溃,诡异现象,弄得我们什么运营活动都搞不了.
    请了个大公司出来的,工资巨高的,结果也没看出比便宜程序员好在哪里?
    天哪,又给我说要重构!又是好几个月啥需求都做不了!
    看上去,有没有同感?且慢,程序员也有话说。
    你需求三天一改,两天一变,你以为我代码会72变,我多少工作打水漂了你知道不?
    你说这个简单,你前面系统数据结构各种不支持,我不大改我根本支撑不了这需求,我跟你说数据结构你听么你?
    你告诉我做A,B,C,D,E,我都按你说的做了,做完了你说不是你要的,鬼知道你要什么。
    你就给我这点开发时间,我已经加班给你把事干了,我反正实现了,测试也通过了,线上出问题,你业务场景各种诡异,我哪里知道,又没早跟我说。
    天天有事没事就拉我开会,你知道我思路多难集中么?完全没效率,你尊重过我的时间么?你以为写代码随时抽五分钟就能写一坨么?
    这代码补丁打得,找一个小问题要一个下午,不重构你后续功能没一个可以顺利快速搞起来的,我替你考虑,你还埋怨我?
    哎哎哎,上面的那位童鞋不要乱讲,我设计架构的时候,也没想到现在业务这么变态啊,当时我可是按照标准的流行业务模式设计的。你没理解我架构精髓,就知道重构,你有问题哦你。
    好了,打住打住,架构这话题太大,程序员自己都会pk起来,不和谐。
    下面说一下我的理解和相应的对策。
    问题1:信息不对称
    产品人员往往认为,描述了功能需求,甚至简单的给一个竞争对手的范例,工程师就能完美的实现所有业务需求;但是,工程师对业务的理解往往是欠缺的,因此在产品的塑造上,很可能因为个人理解偏差,带来极大的随意性;即便是产品经理具有超强的控制力和投入,保证技术在功能实现上与使用场景吻合,但往往因忽略了业务的性能诉求,导致线下ok的东西,线上各种问题。
    个人认为,让技术充分了解业务诉求,并参与业务讨论,是有必要的,只有这样,才能深刻理解产品的设计目标和设计要点,这样才能减少产品跑偏,与需求不符的现象。
    问题2:尊重技术人员的时间观
    工程师什么时候开发效率最高?我相信不止我一个人会有这样的感觉,凌晨1点-2点这段是时间,夜深人静,无人打扰,开发效率最高。应尽可能营造无打扰,无中断的开发环境;从设计代码到编程到测试,开发需要整段的时间来思考和实现,比如下午4点有个会,哪怕只有10分钟,等于一个下午没有效率。至少以我个人而言,是做不到可以随时中断,随时继续的开发水准。我几年前比较多的编程都是在半夜完成的。
    所以,产品人员应当与技术人员勤沟通不错,但是请尽量将完整时间给工程师,比如早上上班后开沟通会,保证后续的完整性,下午午饭后立即开沟通会,或者用午餐会的形式,留给完整的下午时间给工程师,都是值得建议的方案。
    问题3:理想主义情绪
    开发人员往往有理想主义情节,希望所设计的架构可以支撑更广泛更持续的应用诉求;有时候产品人员也会有这样的想法,过于追求远大的宏伟目标;理想主义往往导致投入太多的无用功到无谓的兼容性设计上,而实际上,随着业务的发展和市场的变换,往往大部分提前准备的或者按照高端目标准备的设计,都是浪费的;其实,最重要的是把握当下的市场,互联网产品淘汰更新频率太快,未来是怎样,很多不确定的因素。
    一个典型的架构悖论是,为了支撑更多更复杂的业务诉求,而设计了一个非常宏伟庞大的架构,但是新的诉求出现的时候,很抱歉,互联网发展太快,新的诉求超出了最初的预期,然后,因为架构太复杂太庞大,所以无法实现。
    这事在著名的互联网上市公司是经常出现的。
    轻架构,着重当下,代码做好低耦合就可以了,不用把架构弄得太复杂,而且,个人认为,最好的设计是,让后续的程序员(中等水平),不读文档,只看代码就能接手。
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    在我站开通SVIP可同时获得17个站点VIP资源 立即登录 立即注册
    快速回复 返回顶部 返回列表