不同驱动型公司协同开发工作流
公司开发驱动类型
️⚠️注意：在每一个公司都赴互联网化的道路上，首先要明确自己属于哪一种驱动模式。现列出以下几类，后续可作补充。
-
如果是转型中的传统公司，或者创始人为传统公司背景，那么公司的开发流程便偏向于业务驱动型；
-
一些常见的如“我有一个点子，有大笔的钱/能拿到可观的风投”就开始创业的公司，大部分都属于产品驱动型公司，基于这个点子会发散出一系列的业务流。（顺便一提，每个创业项目都应该想清楚盈利点在哪。这个关乎到能否拿到风投以及能撑多长时间，钱烧完就死，那这样的创业没有任何意义）
-
如果创始人为技术背景或者整个团队都很geek，那么公司的开发流程便偏向于技术驱动型；
那么以上几种不同驱动模式的公司需要分别注重以下几点内容：
-
业务驱动型完全依赖于当前的业务线，比如传统零售业/办公软件销售/工业转型等。这样的公司已经有比较完备的资金周转方式，而资金的来源主要以销售为主，那么业务员或者整条业务线在公司的话语权会比较大，技术部门是对整条业务线的支持，那么这时候技术团队涉及到的开发内容以OA办公为主。在这种类型的公司，一定要注意对需求和进度的把控，因为涉及到专有业务线的内容，业务员的需求是特有且多样的，这需要有一个强力的产品经理和项目经理对整个需求及开发流程进行整理，防止出现需求堆积如山，开发慢如老狗，效果展现不符业务员预期等情况，并且在产品设计及技术开发的时候要预料到基于当前业务线可能添加的功能扩展。
-
产品驱动型公司依赖于一个优秀的点子，大部分一拍脑门想到点子之后便拉到几个技术合伙人创业的公司都黄了😂。在这样的公司，产品部门的话语权可能会更大一点，技术部门按照已经出好的产品设计进行开发，产品上线之后会再根据线上数据进行一定的迭代微调。技术部门都是指哪打哪，并很有可能是弱点部门，对优秀的产品设计实现起来力有未逮（大神不好招）。在这种类型的公司一定要有一个好的产品经理跟一堆优秀的程序猿。对产品数据进行汇总分析，并预留几种产品备选方案方便试错。技术部门除按照开发进度做好自己的本职工作之外，还需要跟产品确认后续思路以进行合理的架构设计加速迭代开发。
-
技术驱动型公司与其他则不同，整个团队都在追求技术至上的理念，我的业务代码要牛逼，界面展现要酷，技术体系要是最新潮的等等… 这样的团队有可能每位开发人员技术实力过硬，不担心技术方面的压力，但是需要考虑的是时间成本。用新的技术框架很geek，但是是否考虑到整个技术环境后期维护及人员离职之后新员工的上手难易程度，必然会拖慢开发进度。另一个痛点则是不知道用户想要的到底是什么（有点程序猿式不解风情的反差萌呢）。那么这种团队一定要有一个好的架构师/项目经理对技术方向进行把控，并有一套行之有效的产品反馈机制以及时优化用户体验。
以上分析了一堆，都强调了产品经理在开发流程中的重要性，那么大家会问，这该不会是一篇产品经理自吹的文章吧😂，其实不是，本文在强调的其实是流程管理在整个开发过程中的重要性。一个井然有序每个人都知道整个开发流程及对接的团队，永远要强于一个乱七八糟各自为政不知道其他人在干嘛的团队。市面上有很多流程管理及协同平台，而真正搞清楚自己当前团队的问题在哪，才能更有效并针对性地去进行协作。
多部门协同流程
以下时序图对常见开发场景下的沟通流程进行细分分析。
整个需求的实现
|
|
以上时序图中需求提出方可能有很多中，具体驱动类型的公司有不同的场景。 需求评审阶段需要需求提出方/产品/技术/美术等共同讨论可行性并评估开发时长，这个讨论是非常有必要的，以发现一些逻辑问题，当场进行调整，各部门在实行的过程中也会心中有数。
设计评审阶段是设计部主导，做出产品设计图之后与产品/技术部门进行讨论，确认开发难度，评估开发周期。如果有当前技术部难以实现或者不合理的交互效果，可进行适当调整。
开发阶段需要项目经理的全程协调。前端、后端、数据收集反馈等按照功能排出优先级依此实现，并保证能在交付日期之前完成开发并进行一定程度的自测。设计部及产品经理在这个过程中起到监督作用，以确认即将产出的内容是达到自己预期的，以随时进行调整（微调可以，可不要随意加需求，不然会被愤怒的程序猿群殴的）。
测试阶段需要整个开发参与部门共同进行（不只是专门的测试部门啊），最后捉完虫子做完回归测试之后，可以考虑进行灰度发布，以确认改动效果及影响程度，数据无反常之后，可以进行渠道的全部更新发布。
以上流程全部走完之后，产品就正式交付，可以根据数据确定下个周期的开发任务了😊。
以下是整个流程中具体部门的一些沟通协作流程。
产品展现的确定
|
|
此部分内容为与设计部沟通模式，此处的产品可以是其他要求设计部进行设计的其他部门（因为设计部有时候需要对接推广部门等）。在进行设计的过程中可能会跟需求方进行反复的确认，以确保设计出的产品是预期中的展现效果。
bug的提出
|
|
捉虫阶段是比较痛苦的，因为有些bug总是在极端情况下才会出现，要覆盖测试到各种情况，如果测试没法根据正常流程复现，可以要求技术或者自己模拟一个极端环境。直到反复确认修复完成之后，可以根据bug覆盖率提交修复上线计划。如果bug涉及到产品流程的问题，也需要产品部门的参与。
线上数据的观测与迭代
|
|
根据时序图可以看到一个线上产品发布之后需要对真实数据进行持续的关注。产品自身会去关注一些转化指标，推广运营部门/产品使用者也会基于一些指标关注对应的数据。一定周期内这些数据汇总到产品之后，产品可对当前内容展现进行一定的调整，并重新安排设计开发任务。这部分的开发任务可以参考上文整个需求的实现部分内容。
总结
以上是作者参与互联网工作三年多以来的总结，从小初创型公司到中型公司的道路上踩了不少坑，对整个流程的执行及优化特别考验管理者的能力。当然，如何建立行之有效的管理制度及奖励措施我们后续再进行分析。不管是小中大哪种类型的公司，只要涉及到产品开发的内容，总逃不开这个流程，不过每个公司根据其性质都会有更加具体和细分的部分。如有问题，欢迎讨论批评指正。