架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的。产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解、评估、碰撞、优化、把控、验证等等。当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处。在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦。所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构。

当然架构师的懂产品,是懂产品的生命周期,产品发展的客观规律,产品的评估及验证。其实架构师承担的是一个美食家的角色,美食家并不需要去做菜,但是要知道如何评价菜的味道,懂得菜是如何做出来的。你不需要去养猪,只管吃肉就行了,听上去很美好,非常美好!

  1. 产品提出初步思路,这时候你就需要参与进来,用客观的角度去评价思路的正确性,而不是觉得这个做产品的人跟我很熟,我觉得产品思路就不错。这个非常重要,目标错了,200%的努力去实现,只会更糟。如何用客观的眼光去评价呢,我有一个诀窍,就是代入法,假设这个产品是你的竞争对手做的,你如何干掉他。
  2. 产品需求调研,你要亲自参加,使用精益创业的手段来进行理性的验证。

后面不写了,再写可以专门写一本了,反正就是你要懂产品,不是让你去做原型,而是让你去品这个产品!

时间: 2024-09-25 22:46:45

架构师速成8.2-架构师要懂产品的相关文章

架构师速成8.3-架构师必须要了解的规则

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务

架构师速成-目录

天地会总舵,陈近南给了韦小宝一本武功秘笈,韦小宝说:"嗯?这么大一本我看要练个把月啊!" 陈近南说:"这本只不过是绝世武功的目录,那边才是绝世武功的秘笈!" 这就是架构速成的秘笈目录 架构师速成1-前言 架构师速成2-概述 架构师速成2.1-论成功 架构师速成2.2-论成功 架构师速成3-开发者境界 架构师速成4-幼儿园 架构师速成4.1-幼儿园要学会如何学习 架构师速成4.2-幼儿园要学会如何学习 架构师速成4.3-幼儿园要学会查找资料 架构师速成5-小学 架构师

架构师速成2-概述

成为一名合格的架构师,需要经历菜鸟.码农.资深码农.项目经理.技术经理.架构师等一系列的过程.为了让大家通俗易懂,我把整个过程按照大家熟知的上学的顺序排了一下,从幼儿园-小学-中学--一直到博士,至于博士后需要大家自己去实践和想象了.每个过程我都会进行统一的描述: 阶段:例如 幼儿园 需要做的事情:例如 学会一门编程语言 完成任务耗时:例如 2-5个月 升级标准:例如:能写出简单的计算器,接受用户输入的+-x/运算 风险:例如 有人打断 当然在正式开始之前,我还是要提示一下相关的风险: 任何行业

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

一个架构师谈什么是架构以及怎么成为一个架构师

新年新事,来点轻松的话题.我们调剂一下后再继续讲CAS SSO单点登录吧因为后面的内容全部和代码有关,大家会觉得枯燥.所以今天我们先来点"番外篇",讲讲什么是架构师,什么是架构这个永恒的话题吧.此篇源出自我在公司内部写的一个PPT,它是用于在公司内部向广大技术人员做普及用的一个资料,而CSDN这边的编辑不支持图文混排的效果,因此一些章节我就直接截取自我的PPT里的内容了,这样可能对大家在阅读上会显得更加生动和活泼一些吧. 架构的定义 先来看看软件架构的普遍定义吧. 一个程序和计算系统软

10年感触:架构是什么?——消灭架构!

架构是什么?昨天下午我坐飞机从西安到太原的路上,不禁在思考这个问题.我做C#开发已经11年了,做过很多项目,经历了很多项目开发过程中的折磨,在小企业兼职过不靠谱的"技术总监",在大公司也当过码工,见识过很多牛人,分析过牛人的代码,并且也和团队设计了OSGi.NET框架和iOpenWorks插件仓库平台.回想这么多年的软件开发经验,我发现自己一直在追逐如何使软件开发做的更好,如何让一个团队开发出一个像样的软件产品,而不是像大多数的国人生产的丑陋不堪.经常出现各种古怪问题的企业软件. 目前

架构漫谈:如何做好架构之架构切分

原文:架构漫谈:如何做好架构之架构切分 架构漫谈是由资深架构师王概凯Kevin执笔的系列专栏,专栏将会以Kevin的架构经验为基础,逐步讨论什么是架构.怎样做好架构.软件架构如何落地.如何写好程序等问题. 本文是漫谈架构专栏的第四篇,作者将会介绍架构的切分,并直戳切分的本质其实就是利益的调整.文中作者将会讨论为什么需要切分.切分的原则.切分与建模.切分的输出和组织架构等问题.欢迎阅读和反馈. 前一篇(点击文末阅读原文链接查看)已经讲了如何识别问题.在识别出是谁的问题之后,会发现,在大部分情况下,

《架构真经:互联网技术架构的设计》分而治之

本节书摘来自华章出版社<架构真经:互联网技术架构的设计>一书中的第1章,第2节,作者 小象学院 杨 磊,更多章节内容可以访问"华章计算机"公众号查看. 分而治之 2004年,ServiceNow的创始团队(最初称为Glidesoft)构建了一个称为"滑翔"(Glide)的通用工作流平台.在寻找可以应用该平台的行业时,团队发现建立在信息技术基础设施库(ITIL)上的信息技术服务管理(ITSM)领域有机会可以通过PaaS服务(平台即服务)一展身手.在这个领域

《架构真经:互联网技术架构的设计》水平扩展

本节书摘来自华章出版社<架构真经:互联网技术架构的设计>一书中的第1章,第3节,作者 小象学院 杨 磊,更多章节内容可以访问"华章计算机"公众号查看. 水平扩展 在实践中,我们经常告诉客户,"向上扩展注定会失败".这是因为在超高速增长的环境里,公司计划以水平方式扩展(又称之为向外扩展)至关重要.大多数情况下,这是通过对跨越多个系统工作负荷的拆分或者复制完成的.数据拆分的实施,类似我们在第2章中描述的众多方法中的一种,当超高速增长的公司无法扩展时,他们唯一