在创业公司做架构师，你需要解决哪些问题？

本文中，作者将分享他在创业公司遇到的一些挑战以及解决方案，主要包括以下七个方面：

1、项目管理的问题；

2、业务代码的问题；

3、产品需求的问题；

4、组织协调的问题；

5、技术选型的问题；

6、运维方面的问题；

7、人的问题。

突然想到一句话，人生若只如初见，找对象如此，在公司干活也是一样。

在你加盟一家初创公司的时候，总是豪情万丈，自信心满满，但是问题的出现总是那么的突然，没有一丝丝防备，创业公司甚至没有大公司的蜜月期，你就会面临很多问题。

首当其冲就是项目管理的问题。

创业团队为了追求小快灵的模式，很多时候牺牲了项目本身的科学管理部分，例如项目计划倒排，任意变更需求，随意封闭开发加班加点，甚至压缩测试工期等。

当然，我们并不是来抱怨问题的，而是想如何更好的解决它，我觉得作为一个技术人员合格素养的一条就是敢 say no。很多问题都是因为畏惧权威，过度承诺导致的。

另外，也需要尊重科学，重视项目里程碑，杜绝人月神话这类事情的发生。

我觉得，不管加班也好，砍需求也好，一定要遵守一个原则，就是不能伤害客户的利益，很多时候我们一味追求糙快猛的工作方式，看起来做了很多事情，其实结果却是漏洞百出，应付不过来，最终伤害的还是客户，倒霉的还是你自己！

推荐大家都好好读读 bob 大叔的《程序员的职业修养》这本书，特别是前面几章。在这里介绍下 bob 大叔。robert c. martin，世界级软件开发大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，c++ report 前主编，被后辈程序员尊称为 “bob 大叔”。20 世纪 70年代初成为职业程序员，后创办 object mentor 公司并任总裁。martin 还是一名多产的作家，至今已发表数百篇文章、论文和博客，除本书外，还著有《代码整洁之道》、《敏捷软件开发：原则、模式和实践》、《uml：java 程序员指南》等。他最近创办了 cleancoders.com 网站，专为软件开发人员提供教育视频。

接下来就是深入业务代码的问题。

由于创业公司发展迅速，所以往往会忽略代码构建的科学性，甚至牺牲和忽略设计的过程，完全需求片段导向，系统可以说是功能点的不停叠加，到最后就算是经验丰富的超级救火队员都没法解救了。

这时候，很多人就会说，这还不简单吗？赶紧重构啊，拆分模块埃说实话，画个几个框，搞几个箭头标注一下数据流向这谁都会，但是具体业务如何建模？

任何互联网的业务平台无非逃不过：会员，账户，订单，支付，营销，计费等几大模块。

但是重构不是说画几个框框搞定的，而是在不脱离你业务显示情况下的合理设计，例如做营销，你不能只是简单构建一个营销的规则引擎就完事了，也不是做一个抽奖或者优惠券的系统就是把营销的事情做完了，而是需要去分析：

从上帝视角(系统整体视角)你的营销系统摆在什么样的位置。从整体上走通营销的规则和流程。
套用目前和未来一段时间内有可能会出现的需求，是否可以在这套模型下可以走通的。
设计营销系统本身，站在营销系统的视角进行建模。
在设计完营销系统核心部分后，安排开发工程师进入营销系统的细节功能点开发，以及周边系统的接入。

再例如会员系统，有些有主子账号的概念，这样又会影响订单系统是否需要体现主子账号的关系，甚至又得影响营销，我买一送一这样的活动如何搞，账单如何体现等等？

所以，建模和重构没那么简单，也不是画几个框框就能解决你的问题的，你得深入业务，围绕业务，并且建模绝对不是技术人员的职责，而是运营，产品，市场，技术等大家都需要达成一致甚至深入理解的。

推荐大家阅读下，eric evans 写的《领域驱动设计：软件核心复杂性应对之道》一书

接着是产品需求上遇到的问题。

你会发现产品经理有时候也不能很好的从产品的整体角度去产品，仅仅只是把业务方的需求过滤和理解了一遍就交给了开发，这样，你就会遇到很多自相矛盾的业务逻辑，甚至影响到用户体验。那么，这个时候你会怎么办呢？是选择做鸵鸟把头埋到沙子吗？还是选择帮助产品经理一起来分析呢？

很多时候，产品经理会抱怨，自己只是个传声筒，老板找他，运营找他，市场找他，那么多事情，根本没法系统性的去梳理产品需求，结果导致需求总是零星的提给开发，结果上线之后漏洞百出。最后背黑锅的不但是产品经理本人，还有开发和测试，客户会说，这是什么垃圾技术开发的。另外，老板不了解情况，也会说，花那么多钱，养一个技术团队，结果开发出了什么鬼？

我想，在创业公司产品技术部工作，最难的就是产品经理和架构师，架构师需要从产品的角度去审视，去把住命脉，因为这已经是最后一道工序了，不系统性的梳理，那么进入开发就会导致前面的悲剧。

产品经理也得好好思考，虽然前期会很累，确实事情很多，但是累一次总比你无穷无尽受虐最后导致团队和老板还有客户信心丧尽的好。

另外，难道产品设计真的很难吗？除了整个业务模式的玩法你跟别人不一样外，整个产品的形态，其实大多数同类的厂商设计的都是可以互相对标的，比如抽奖怎么玩，你大可以对标一下京东，天猫等产品的玩法，然后结合你自己的特色进行改善。其实我的意思不是叫你去抄袭，而是你要去梳理思路，形成体系化的结构，当你不知道自己怎么弄的时候，可以去借鉴别人，就像读书，读的多了自然就会明白些。我想，大多数重运营的 app，其实还都是相似的。

再接着是组织协调的问题。

大公司的好处就是各司其职，只要有合理的制度和流程，只要你按照规范操作，傻子都能把任务完成(当然这不是说大公司的员工都是傻子。我这里是说流程和规范的重要性，当然傻子虽然能完成工作，但却不能成为大牛，同样，大牛不管在大公司还是小公司，他一样能成为大牛)。但是，在创业公司却不是这样，流程和制度的缺失，导致你会觉得什么都很乱，什么都会有问题，但是你得反过来思考一下，假如什么都好了，还需要你干什么？另外，你加盟创业团队的初心是什么呢？为什么开头我要说，人生若只如初见呢？

其实，乱就是体现你的价值，把你的经验和优势发挥出来，梳理清楚流程，该自动化就自动化，不合理的就及早提出改善。其实，管理管理，管理的不仅仅是你的员工，也不只是你自己，你还得需要如何向上管理你的老板，如何跨部门管理其他同事等等。拥有一颗大心脏吧，为什么麦迪成为不了科比这样的人呢？

当然，我觉得在协调合作的时候，千万不能把自己的成就感建立在别人的痛苦之上，一个创业团队，大家为什么跟你合作，为什么大家要在这个公司，都是和你一样心存梦想，奉献自己，不是只有你一个人是最伟大的。是人总会犯错，你要理解别人，严于律己，宽以待人。我觉得华为价值观里有一条非常好，赢则举杯相庆，败则拼死相救。而不是你赢了还黑队友，你败了在责怪队友。时刻心存感恩，感恩你的同事，感恩你的下属，感恩你的伙伴。只有这样，你的事业才有可能长久，否则就算事业成功了，你失去了一群帮助过你的人，你觉得这真的是你想要的吗？

再谈谈技术选型约束的问题。

很多创业项目为了图快和省事，在开发过程中甚至没想清楚为什么，就随意从网上下载别人的代码和组件，然后写出来的代码五花八门，比如一个 web 工程，有 vo、do、dao、dto、ao、bo、pojo…这么多的概念不把开发给搞成脑残才怪呢。

再比如 json 输出，有手工拼装的，有 fastjson 的，有 jackson 的，总之市面上有什么同类技术，就会在你的代码里一一出现。

当然，我这里不是讲你要选择什么技术，选择什么框架，选择什么软件，而是想说，这种规范和约束性的工作，越早做越好，否则后面重构代价非常大。比如说我们之前的 action 居然都是 servlet 手工输入的，连自动注入都没法做，后面新人进来就说，你们公司怎么那么垃圾等等，为了解决这个问题，我跟一个哥们合作，光光迁移 1000 多个 servlet，并且完成测试，就花了 2 个礼拜，另外，主干代码人家还得提交，后面还得发布前增量 merge 一次。代价非常大。

架构，还是需要持续的控制，持续的优化，而不只是等到重构的那个点，否则你会很累，团队会很累，老板也不满意，他们会觉得，不是刚刚重构过吗？为什么你们的系统又不行了？为什么又要停下来让业务需求停止呢？

当然，这个事情不是技术驱动那么简单就可以完善的，还是需要得到你的老板，产品业务方的理解和支持才行。其实架构不是牙膏，挤挤也不一定会有，技术和业务好比公司前进的两条腿，缺一条都不行。其实再怎么业务导向的公司，技术其实还是很重要的，比如很多重运营的公司，假如没有牛逼的运营支持系统来提高运营生产效率的话，人力成本是很庞大的。而且都是完成手工点击装备的低价值工作，还看不到运营的效果是什么样子的。

架构，其实有时候还是和权利有那么点关系的，你既要让架构师干活，而且要出规范，让系统工作的更好，却不给架构师明确的权利和约束的职责，有些事情屁股决定脑袋，业务，需求，老板，随时都可以否决你的建议，屁股决定脑袋，很多时候真的是一条铁律。

再接着是运维方面的问题。

现在很多公司都上了云，比如阿里云，腾讯云，所以，很多同学都会觉得运维省事了，没什么挑战了。但是恰恰相反，这是墨菲定律的反定律，越是你觉得没问题的地方，越会出现问题。因为人家可以帮助你维护硬件，维护机器，甚至维护中间件，数据库。但是没法帮助你维护你的业务，也没法帮你优化性能的瓶颈。

另外，现在有很多第三方的公司和服务，做了很多运维支撑监控，错误排查等服务和工具，假如你的业务发展速度飞快，运维跟不上，你也可以先期使用这些服务来快速定位线上问题，等后期业务发展壮大了，再慢慢发展你的运维团队，招人永远是个大问题，但是我们不能因为这个问题就面露难色，天助自助者呀！

同时，一定要提倡人人都是运维的理念。试想，你自己写的代码，你居然都不知道哪里出了问题，线上到底是什么情况引发的问题，这是多么可怕的事情呀。

不是说上了云，你的系统就不出问题高枕无忧了＼多中间件，甚至一些基础组件，因为贴合你的业务，还是你自己开发的，它们的运维成本并不比维护机器更低。

最后，再谈谈人的问题。

其实，前面讲的这些最终都可以归结为人的问题，或者说不管大公司还是小公司，人的问题才是最本质的问题，天下熙熙皆为利来，天下攘攘皆为利往！

首先你得解决内部沟通的问题，如何沟通，如何平等沟通，特别是创业团队，大家为什么会选择加盟你，为什么又会选择离开你？这是很科学严肃的问题。很多创业团队就会犯类似错误，把人当做工具使，不行就换，再不行继续招聘。

他们从来不想如何培养内部人员，如何让内部人员的效能最大化。天助自助者，假如你自己都没法救你，还指望别人来救你？

其次是招聘的问题，很多公司都缺人，都缺牛人，但是他们缺从来没有认真科学的理性分析，我为什么要招人？我要找什么样的人。我可以负责人的说，很多公司都是在凭感觉招人，盯着简历凭感觉撞大运！

最近遇到好几个创业公司的 ceo，都说缺人，需要架构师，但是他们自己却说不清楚招聘进来架构师能解决他们什么问题，是技术问题？还是业务问题？太可怕了。其实这不仅是对自己不负责，也是对别人不负责。人进来不仅仅是短期能否解决你的问题，还得长期关注别人在你这里获得什么，找到合适的人是双赢，否则就是双输。

你真的得想清楚，你是想要找的这个人能做成什么事情，还是看重这个人看起来曾经做过什么事情，这可是有本质的区别的，因为这恰恰决定了你招聘的态度，这是个严肃的话题，而不是你撞大运的行为！

另外，很多时候，你第一个招进来的技术负责人会决定后面人员的素质，屁股决定脑袋，牛人跳槽也不希望找个二逼管着自己，就像蔡振华管中国足球，就是个笑话，所以，当你和一个大牛把酒言欢，畅谈一番觉得这个人板上钉钉能加盟你的时候，却在关键时刻放你鸽子，你就该反省，为什么你的团队没法让大牛加盟了。

也许大公司招人只是为了垄断人才市场，形成人才资源的行业壁垒，但是创业团队不能这么干，否则，迟早你会身败名裂，找不到任何一个人。

在创业公司做架构师，你需要解决哪些问题？

接下来就是人才培养的问题了，一个人进来之后，人家为什么选择在你创业的阶段加入你？你是否对这个员工具有感恩的心，人家帮你成长了，你是否愿意帮助人家呢？每个人都会在一家公司遇到阶段性的瓶颈，在这个时候，你是一脚把人踢了，还是乐意抱着感恩的心，来给人家成长的机会呢？因为任何一个人，在一段时间内，总有被榨干的时候。感恩的心，不只是对别人，也是对你自己！

最后，就是成就感的问题了，假如工作天天都是上面指派，每天都是机械的处理指令，我想，任何有想法的人干不上几个月就得离职。当然这个也得看你的团队是否足够精英，假如是组建精英团队的思路，就不会出现这样的情况，但是假如你的团队只是局部精英，你就得考虑如何保证精英人才的成就感问题，而不只是机械的向他们传递指令，否则…..

讲了那么多，我是想说，当你豪情万丈打算加盟一家创业公司的时候，今日长缨在手，何时缚住苍龙？却在进入一家创业公司之后，发现这样那样的问题，请你耐心，细心，爱心的去解决。而不只是抱怨。

创业不简单，加盟一家创业公司也不简单，请你认真对待你的人生和你的家人。并不是每一个人都适合在创业公司工作的！

本文作者资深架构师陈科，36 氪经授权转载自微信公众号聊聊结构 (id:archtime)。

本文地址: https://www.xiongge.club/sb/hw/167.html

转载请注明：熊哥club → 在创业公司做架构师，你需要解决哪些问题？