SE企画与上线记录
2019年08月10日に投稿

最近半年终于上线了一个公司内部的startup项目,领队专家能力很强,我个人也学到了很多,特此记录。

首先强调一下,我这里的startup并不是外部风投的创业项目,而是大型公司的内部IT立项。它立足于公司平台,面向内部客户提供企业向的SAAS服务。但是也不要觉得它好做,大公司内部更聪明的竞争与模仿者很多,同样需要找到方向、组建团队,交付项目。假如项目失败,不管你级别多么高,都将被淘汰掉。

本文面向读者:自己有3~5年技术经验,写够了CURD,希望自己能够设计落地方案的读者。本文关注点在实施流程,入门工程师与高级管理者可能收获不多。

快速结论

如果不想读完本文,可以先看结论

  • 方向与愿景:已经完成了从零到一的规划,找准位置,方向要大致正确
  • 需求:要明确语境,长/短期诉求,明确SAAS中产品/需求的定制界限
  • 落地技术方案:要用拿来主义思维来节约时间,成熟度从40(POC)到60(MVP),再到100进行延展,不要开始就深入源码与高并发来证明你的技术
  • 过程效率:要有高度成熟的DevOps/Agile/Meeting等方法论来管理过程
  • 团队组建与招聘:找比自己优秀的,有主动能力的(同样的成本,要1.5 * 1人 而不是 1 * 2人),详见更多

上面每个决策失误都将消耗珍贵的起步时间作为学费

背景

本文不涉及的内容

下面这些难度超纲,我就不瞎写了,本文假设下面均已经搞定

  • 本部门与客户们通过各种方式磋商(ROI价值分析/竞品/受益群体),达成了要到预算(人力/时间/采购/投资)并立项的诉求与决策
  • 部门级、公司级、平台级的宏观战略比较清晰
  • 团队基本组建成型(Sponsor的客户也要有人全职跟踪与验收),组织有活力与执行力

你所拥有的

  • 上层提出的一个宏观的,需要3到5年才能完成的目标
  • 上层初步与客户对出的业务流程
  • 运气好有几个人给你带,运气不好需要自己面试挖人组建团队,运气最差是连HC都没有

你需要做的

以下为项目开始只做一次的

  • 验证上层战略是否可行
  • 在上层讨论的基础上完善业务流程细节,画出包含细节的Workflow
  • 制定技术方案选型、初步做出POC与MVP并演示汇报

以下为项目稳定后每个迭代的搬砖工作,只要有方法论与良好的招聘流程就可以转为人天,可以看我以前的文章

  • 与客户讨论每个月内交付什么功能
  • 设计需技术方案细节,堆人上,并盯着编码人员不要走偏或瞎搞
  • 招聘与学习型组织建设、处理求助、开会、AAR、DevOps、WIKI、JIRA等等…

愿景与实施

愿景大致正确

格鲁夫曾经说过,在一个组织中,某管理层的战略/愿景,通常即是高他一层的经理人考虑的战术,而你作为执行者是负责实施上级战略的。

大前研一也曾经说过,做任何事情,都要以顾客的顾客为中心,所以你的技能不能只满足于编码与当包工头,而是让所有人都满意,因此你个人就算是纯写代码也要高看一层。

此外还有创造性张力, 格物致知等类似术语,我这里就不掉书袋了,这些属于都强调了最高方向的重要性。

以某企业向IT项目为例

战略战术关键事项
客户提高过程管理效率30%,降低浪费XX%找IT部门来实施定下时间,出钱、出需求与验收,防止钱白花了
领导打造一个全部门/公司/甚至超越IBM的XXX系统愿景制定3年规划对齐上游,防止我瞎搞
对抽象的工作流程进行分析,进行Demo演示,设计技术方案,参与核心编码设计方案、管理搬砖过程对齐需求,实施进度,防止下面瞎搞
编码通过编码完成分下来的需求搬砖干活量化/流水线化招聘标准,确保质量

通过这种分析方法,可以把所有人的思路给连接起来,有了最高战略,我们才有共同目标,这样就可以引入方法论进行实施。上述过程在H公司叫做【对齐(Aligenment)】,一旦方向大致正确,就用超高的执行力实施。

如果你与其他人的理念不合适,那么要尽快得出结论。如果你自己都不认可,我觉得还是换个方向搞吧。

方向错误会发生什么

假如客户无法自己想要什么,那么可能会把IT团队给累死,部门名声差了,后面就没人敢接这个部门的活了。

假如领导挖掘需求能力较弱/二传手,脑子里是浆糊,或者天天开会效率低,那么就算是CURD的业务,你也要996搬砖,万一项目搞砸了,你和领导都升不上去了,然后34被淘汰。

假如我对上游的需求方案细节补全不合理,软件架构能力差,那么要么996,要么走人。

当然这些话题扯远了,我这里主要还是想强调先方向、后战术、再实施。假如你是技术设计者,切忌上来就陷入代码细节、高可用与源码分析,这样你就把下面的实施人力给浪费了。

其他必要条件

除了方向正确外,还需要有强执行力与技术视野确保成功开头,执行过程中需要有方法论支持,有了流程才能先固化后减法,否则还是瞎搞,导致下面996加班/跑路。

需求的实现与验证

领导与客户交流是高纬度的战略,因此这种方案一般是需要2~3年才能彻底完成的项目,而下面干活的肯定不止你一个,因此你要把属于你的活给抽出来,自己搞一个思维树。

收集术语,对齐语境,建立项目知识树

举个例子,我做的X项目中有大量的领域术语缩写,甚至连中文资料都很少,你需要如下操作

  • 通过搜索引擎了解术语含义,甚至去参考术语相关的IT产品、商业产品是什么样
  • 去图书馆等专门的知识渠道去过一遍知识,你不用完全读懂书,只要知道这个流程需要哪些步骤就可以了
  • 将上述过程整理为Wiki/Gitbook,与客户再对齐一遍,补充备注。

将Wiki发布给上级与客户,这就是你这段时间的成果,你在这个阶段是顾问的角色。

补全场景细节(enrichment)

找客户要人,1~2个人开会讨论,不要拉一堆人。

打开会议室的投影,打开一个你喜欢的绘图工具,然后采用问答的方式画业务总体流程图,举个例子

  • 这一步从哪里开始,后面到哪,角色是X吗?如果失败将交给谁?
  • 这里的交付件是什么,储存在什么地方?交付件是否纳入版本管理?
  • 这一步分出的4小步是什么,它们输出了什么?第三步挂了是否还接着走,如果挂了怎么定位?

这种会议将非常高效,因为你是主持人,如果有人讨论离题,你要及时委婉地纠正过来“这个细节下来再讨论”
场景补全后,将这些流程图共享,这就是第二阶段的成果。

我个人比较喜欢的两个场景工具(可以看我写的PlantUML插件),一个解决粗细粒度,一个精确到时间与人员

  • Work Breakdown Structure: 工作分解图
  • Timeline Diagram: 找出流程中所有的关系人,类似于BPM流程

设计产品Feature的WBS

设计一个超大的菜单,并将上述场景承载录入到菜单层次中。此处暂时可以不用原型图,偷懒可以用Excel等工具画一个即可,不要上来就用UX工具或者UML进行DB建模。

  • 明确各个菜单中业务的一对多,多对多的关系
  • 细化界面结构到可以给前端派活的水平,这样前端就可以开始写壳了

设计POC(可行性验证)技术方案

(此操作可以与上一个任务并行执行)

技术方案可谓拿来主义,可以网上查商业与开源方案,买Cookbook,甚至花钱找顾问的经验/招聘比你强的人。至于说如何设计好的架构,由于需要视野积累与业务场景,本文不多讲,但是最终交付件至少如下(以Web为例)

  • 背景与ROI,业界ABCD公司的方案
  • 高阶应用方案:需要有Portal层,业务层(承载了什么业务)与技术基座
  • 规划下次会议需要演示的交付件与开发计划,赶紧把搬砖的活给分下去

这些搞定了,再与领导对一遍,然后再搞,架构方案是可以调整的,但是主要方向不能改。

源码分析/技术视野应该在轻松业余时间完成,上班时很难集中精力去搞,如果你的代码读的少,那么设计架构明显会很吃力,看源码逆向固然快,但是你的一天时间就被耗没了。

POC演示与验证(Try Run)

这里你真的就要开始编码了,还是先不要急着看源码,建议先看各个框架官方的架构文档。

  • 按照技术方案,从入门到精通搭起来跑一下
  • 哪些场景痛点解决了,哪些没解决,需要怎么改?
  • 尝试编写部分代码,但是不要整个时间耗进去

把Demo报上去给客户看看,根据客户的意见补充改进,直到最终客户拍版同意实施正式开发。

此处用户会提出很多诉求,但是你本人当前时间非常珍贵,不要耗到细节中,也不要这么早当用户的客服,否则其它的就没法做了,进而影响总体功能。
另外,只用找几个客户补充验证场景即可,不要盲目扩展多个客户,否则你的人力也会被耗完
最后,要明确“诉求”与“诉求的实现”的区别,你做的是产品,而不是外包

演示过程中,用户也会提出一些需求,但是作为SE,一定要平衡长期与短期诉求,定制与通用诉求,它们的投入产出是不一样的。任何情况下,都要考虑SAAS化。比如用户短期想马上用,你可以给一个简陋的版本,但是还是不要耗进去了。

落地方案与折衷(Gap)

当可行性ok后,也就是已经上一版本后,那么就要进行真正的设计了

PAAS层

  • 预估出计算资源、网络(时延/带宽)、存储
  • 系统部署架构图,明确好region/datacenter层次的方案,是否需要跨WAN的强一致性
  • 弹性伸缩,运维/监控/日志可视化

技术承载层: 指SpringBoot/Rails等开源框架的选型

  • 内网是否需要强一致性?哪些地方有锁?哪些地方持久化?
  • 哪些地方调用了第三方服务,对方是否阻塞本侧业务?
  • 开源软件后期如何维护升级?

SAAS层

  • 分片与多租户方案
  • 用户/群组等RBAC方案,SSO等鉴权方案

业务层

  • 数据库UML设计
  • BPM流程设计
  • 自测用例

技术架构主要难点是在于挖掘问题(The Challenge, the solution),并提前克服墨菲定律进行分解,而不是多个问题混在一起,也不要被短期诉求/条件所限制(你先出方案,再找上级解决限制问题)。

梳理清楚后,把任务按照1~2天的颗粒放到总backlog里面,然后与领导讨论哪些功能先上,最终整理出一个MVP迭代计划。

这时可以使用专业的DevOps工具导入项目,比如Azure Devops就可以从持续集成到需求管理全部帮你搞定。

启动MVP(minimum viable product)项目

此处是最小可行版本,也就是短期诉求,我们可以先搞两个月,然后用较少的用户去试点业务流程

  • 开始找更多用户进行推广(自上而下/自下而上)
  • 功能与壳优先,技术尽可能是拿来主义,先只考虑少量并发/单DC的方案
  • 就算是第一版也要要有运营方案
  • 通过技术/运营手段控制总人数,但是业务流程的覆盖面要广

无论你是对内IT,还是天使轮项目,都有竞争者,MVP的目标始终是通过最快试运行的运营结果获得决策者的认可,要求始终是快速出产品,而不是高并发微服务等技术细节。

我在这个位置就再次陷入源码分析与高可用细节了,导致投入浪费了一周

正式工作流程

后续工作主要就是一个迭代一个迭代的做,按照敏捷(不管是真假敏捷,反正就是要搞定)等流程拆解与完成。拆解一定要按照功能-技术-实施的维度进行拆解,而不是用技术-功能-实施来拆解,否则项目会遗漏。

自己不能控制的,优先推动做

参考流程

附录

时间管理

有一个优秀领导带你工作,的确可以帮助你少走很多弯路,节省很多时间。优秀的领导每天的工作时间分配的很棒,列举如下

  • 借助公司流程获取资源
  • 与领域客户讨论需求,与高端顾问讨论技术方案,撰写方案
  • 指引执行层,防止“瞎搞”,比如我以前做原型验证时很容易陷入细节与源码中,领导会及时纠偏

这样可以放大自己时间的效率,基本上不会有浪费

不足

上述方案讲得基本是就是西方理论的生搬硬套,目前来说还是有作用的,但是缺点也很明显

  • 上述时间只要有压缩,你的技术深度就会降低
  • 做任何事情都很保守,按照模版搞,拆解的很细,很容易陷入细节
  • 比较依赖上层判断,限制了自己的思维,当然也很难出错
  • 万一没有Plan B,心里就会慌
  • 同事间缺少“被关注感”,所有人都陷在流程中如同机械一般

总的来说,这套方法在大型组织作为中高级螺丝钉是足够的,但是在小型组织中是不够灵活的,希望后期能够先固化后改进,打破框架实现更佳的方法。