第一个关键词：复盘
在商业战略上复盘有两个好处。第一个是找到亮点，对于可行的一些试点项目投入更多资源扩大规模。第二个是我们犯过什么错，犯过的错误能不能写下来不再犯。今天就来盘点一下去年我们范下的那些严重错误：
1. 低估问题的难度
如果去看上一篇文章大概还可以看到我对于能从一堆乱麻中找到所有问题，排好优先级一个一个来理顺解决这件事情是抱着痴迷的态度的。
但是由于认知的问题，包括对于个人本身能力的认知以及对于问题的认知都决定了“外来人员” 是很难在短期内从根本上解决问题的。举个栗子:
由于我本人是技术管理出身，又都是偏大公司的背景。所以自然而然，我最先看到的都是关于技术和流程的问题，并且我过去解决这两类问题所用的思路、资源跟现在都不一样，所以我过去的经验就未必那么有用了。没有正确客观的分析自己的优势与所处环境, 以及与原来同事的沟通不充份。这是一开始就埋下的一个坑。
问题总比想象的要复杂的多
资源的能力以及可控的范围远比想象的要小
2. 错误地跟随
和大家一起参与重构是我踩下的另一个坑。当时我们由原来的网站模式开发向纯前后端分离的开发模式。而原先的前端负责人在完成一个小项目之后离职了，留下了一个重度的react框架和一个我们刚刚从后端转过去跟他学习的前端。
在选择react去留的问题上，我发挥了一个“优秀”技术人员的特性。喜欢新技术，相信自己能搞定这一切。于是我们花了一个月才把原来留下来一个没有重构完成的项目拖上线。
千万不要用不熟悉的技术
你可能没有时间学习
3. 错误地评估/加码
过程虽然艰辛，但是最后完成了，我们欢欣鼓舞，准备大干一场！
大家都很期待， 我们找了系统中的一个重要模块决定开始服务化。前端还用react！ 投入2个后端，1个前端。后端api在2周左右基本完成，但前端花了1个多月功能还是不能正常运行。后端api也因为缺少设计和框架层面的支持有一些缺陷。最后全盘放弃，时间从我加入已经过去5个月了。
第2和第3个坑可以说是有连续性的，之前那个前端负责人走的时候，我们已经有一部份线上项目用react实现，并且也有一个后端一起参与。为了不让这些变成沉没成本，我们选择继续投入。
中间那个项目上线之后，其实我们依旧没有对react+redux等这套框架掌握的非常熟练，包括对于那个模块的业务，也不是特别的了解，可以说是技术与业务与人员3重危险的基础上做重构，胜算非常的低。
学会坚决放弃
4. 带着团队冲向了炮火
在以上的5个月的时间里，虽然没有在技术和产品上取得进展，但是却在团队和开发流程上取得了一些小成绩。那时候前端团队扩充到3个，后端扩充到6个，并增加了一位测试，技术团队扩充到14个。 正好到了11月底，大家想着要在年底做点真正对用户有意义的事情！
于是我们开展了一个叫“磨刀”的行动。
在一个月之内，前端3个人+后端4个人+测试1人。修复所有现有UI、数据上的bug。新开发了5个模块。发版7次。
有人说，这怎么也算坑了？
你们想想，如果一个公司开始出现疯狂加功能的时候，基本离死掉也不远了。
事实也证明，除了bug以外，到现在为止还没有证明我们做的事情从增长、营收以及留存上有特别大的价值。这可能是最致命的，因为你最不忍心看到的就是那些满腔热血、艰辛付出的人最终不能赢得荣耀。
敏捷开发的软胁是：工程师愿意根据不断改变的业务要求调试产品，但是对这些商业决策的质量不负责
第二个关键字：反思
所有的坑，都只能坑踩一次。
以上所踩的坑可以说是具体的现象，相信所有的创业公司都会遇到，只是以另一种现象展现出来而且。由于篇符的原因，以上几个问题我将结合我们去年一年的实践分为下面的5个主题在接下来的一一分享
-
人才引进与培养——找对人才，帮助其发挥
-
产品开发流程实践 ——优化效率，指导方向
-
我们的架构演进实践 —— 什么时候该做升级，如何来升级
-
解决问题之道 —— 识别与迭代改进
-
企业发展战略如何实践 —— 战略是打出来的，团队如何跟进
生意专家是一家专注于实体店铺开店管理的saas软件服务商，目前服务于全国40W家b端商户且在继续快速增长。想和我们一起见证从1到100000吗？
你也可以在我的公众号上看到这篇文章。（我会在公众号上直播这段创业的经历，包括我们技术架构以及团队的升级）
