引言

2017 年 7 月 3 号我以技术总监的身份正式加入一家创业公司，公司大概是 5 月份成立了，时至今日我的工作已有半年之久，今天这篇文章我打算总结一下这半年发生的一些事情。

基本情况

做技术已经有 5 年多的经验了，虽谈不上技术有多厉害，在这几年也一直处于 SaaS 领域，对于一个小公司来说我的技术积累确实是足够了。

先讲一下整个公司的人员分布情况，我来的时候整个公司不到 30 人，但是技术部门足足占有一半以上的人，对于一个还没有推出任何产品的公司来说，技术部占这么多似乎是可以理解的。但以现在的角度来审视过去的话，我觉得对于一个创业团队来说个个都必须是精英才行。

刚来的时候人员分配是这样的：4 个 UI、6 个前端、3 个后端，一个产品助理、一个兼职产品经理，加上我一起是 15.5 个人，从这你可以看得出来老板完全不懂技术。入职的第一天，我做的第一件事就是通过一对一会议简单的了解他们的基本履历。后来我裁掉了 2 个 UI，再陆续进来两个测试。

身份的转变

做技术比较在行，但是做管理确实是没有经验。说实话入职之后并没有很快找到自己的定位，只是把自己当做一个技术上比较好的开发。

后端组还是让我比较放心，但是在前端组我一直在扮演着『救护员』的角色，这些都是我管理经验不足的体现。

产品架构选型

我进公司的时候，由 2 个人正在负责小程序，一个简陋版的官网。我参与的第一个产品是一个给私募公司使用的管理后台，出于以下几点原因我让新项目采取了前后端分离的架构：

  • 这种架构就是后端提供 API，前端控制路由，前端调用 API。这几年前端发展繁荣，这种架构可以说既解放了后端也解放了前端。
  • 前端可以话更多的精力去调整一些细节，交互方面也不受后端约束。
  • 我们公司前端人员偏多，后端技术偏少，而这种架构恰巧会把部分后端的工作转移到前端，所以在不裁员的情况下这种架构符合当时的情况。
  • 后期性能扩展更加灵活（我甚至到考虑到后端 API 如果 PHP 性能不够可以直接换语言）。

而现在回顾起来的话，有以下几点值得怀疑的地方：

  • 公司前端人员当时真的有能力做到这个架构的开发吗？
  • 如果当时不考虑这种架构的话，项目是不是更早的发布？

招聘 && 裁员

进公司之后我只负责招了第一个测试工程师。另外再说说裁员的事情，终于体会到了『裁员』比招聘要难的多了。

公司之前招聘的人没有严格把关，虽说我来之后技术部的『生杀大权』交由我负责，但是坦率的讲到现在为止我都不太会处理裁员的情况，我总是犹豫不决，想给年轻人一些机会。但正式我的『仁慈』有可能会公司损失更加惨重。

第一次裁员是裁掉了两个 UI，因为确实是活不多，而且他们还在试用期，最重要的是那个时候我刚来公司不久还未她们还没有建立起情感，裁员还算顺利。

第二次裁员是公司给我下的决策，前端整体技术偏弱，输出太少，公司不得不决定裁掉 2、3 个技术经验较少的人，宁愿多花点钱招高手。现在看来这个决策还是来得有点晚了，员工转正之后裁员就变得一件非常麻烦的事情。

第三次裁员是公司出现了财务危机，再次做了不得不做的人员上的调整。

关于招聘的时候，我觉得除了考虑技术扎实之外，第一要考虑的是这个人的自我学习能力和做事情的责任心，以及是与公司的团队文化一致。入职之后半个月作为观察期，如果达不到预期，要果断的下决策，正所谓『慈不掌兵』。

敏捷开发？

并没有太多时间去好好研究敏捷开发，目前做了以下点：

  • 使用 TAPD 管理项目进度。
  • 每天的早上的站立会议。
  • 周报

以前我也讨厌写周报和站立会议，但是现在换了一个角度，在大家都还没有非常高的自我驱动能力的时候，我只能用这种方式来督促大家。

团队文化的建设

团队的氛围是我一直非常在意的东西，但是我确不知道如何营造氛围，或者说我营造氛围失败了。

想来想去，我只做了以下几点：

  • 营造『自动化』的氛围：刚进公司我就推荐公司使用钉钉办公（这里不是给钉钉打广告，其实我很想推荐公司用 Slack 办公，但是在国内使用 Slack 网络太不稳定了，而且全英文的界面门槛确实有点高），事实证明确实要比使用 QQ 办公要好的多。钉钉支持在群内添加聊天机器人非常好用，结合 GitLab，我让每次的 Git pull 都自动发送到钉钉群内，每天 10 点自动提醒大家去会议室开早会，每周五下班之前提醒大家写周报。GitLab 也配置了 CI，自动编译发布版本，一键发布测试版。就结果来说，这些东西基本是我在做，并没有带动其他人。
  • 营造『分享会』的氛围：每周五下午有分享会。以报名的方式成为主讲人，给他们机会分享自己的观点。但是目前来看大家都在分享比较基础的技术，非技术的话题还没有出现，而且大家分享的积极性不太高。
  • 营造『学习』的氛围：为此为特意跟公司申请了一笔资费，一口气买了十几本书。但实际大家看书的并不多。

我想去营造的氛围：

  • 技术讨论的氛围。
  • 团结的氛围。

关于项目进度的把控

以前没做项目经理之前，不知道项目进度有这么难把控。由于公司的产品是从 0 到 1，所以每次迭代基本上都花了一个月时间。延期次数多了很容易让大家都失去信心，所以按时保质保量的完成项目进度非常重要，这个我还在学习中。就这半年总的来说有三次的延期：

  • 第一次是我错误的高估了大家的能力，而且忽视了测试环境。
  • 第二次是支付环境，大家都没有预料到的是申请个第三方支付有那么多的事情要做，而且流程有那么长。
  • 第三次有坑在支付事情的事情上了。

现在回顾起来的话，有以下几点值得以后注意：

  • 做任何版本迭代只要涉及到支付或者第三方服务有关的东西，我们第一要做的事情就是足够重视起来，因为这些东西有太多不可控的因素在这里面了。能尽快出 Demo 的就赶紧，不然的话就要每天跟进此事。
  • 只有负责写代码的程序员本人才能准确预估时间，这点应该没错，但同时我心里应该给他们有保留时间，作为突发事件的准备。
  • 前期合理的规划时间非常重要。延期的人往往都有点拖延症，不到最后一天总认为后面的时间还很多。所以宁愿前期的路辛苦点，后期越走越轻松。

产品方向

现在回顾这半年的情况我们产品确实是没什么拿得出手的东西。我试着找找原因，这半年公司这十几个人我们到底做了些啥：

  • 我们的第一个产品，私募荟的小程序，花了技术部接近一半的人力和 2 个月左右的时间，最后以资质不够不能上架为由，被『搁浅』了。
  • 围绕着微信公众号开发的一套私募管理后台包括一套微信 HTML5，花了整个技术部的 1 个多月时间（两次版本迭代），上线后没有人使用。
  • 公司产品转型，我们开发了一套围绕着私募基公司交易服务的平台，再加上一个为了吸引流量的云课堂。两次界面的大改版以及更新，差不多花了 3 个月。实际上线之后交给市场部得到的反馈是，不好推，做一个平台级别的东西，要让市场接受的确是一个漫长的过程。
  • 公司着急盈利，于是再次转型，也就是现在还在做的一个小项目。我不确定这个项目是否能成功，我只是给大家做，我们尽自己最大的努力去做，至于能不能成功就看我们的运气了。

创业公司存在很多的不确定性，我们在不断的试错。好处就是成功的几率大，坏处就是比较折腾。大家的精力被分散了，输出的结果不明显。创业公司产品经理的职位是非常关键的，因为公司的资源全部由他来调控。互联网行业讲究的就是快，慢了一步有可能真的就错过了。

总结

以上就是我以技术总监视角回顾了今年下半年的创业情况，主要提到了个人职业身份的转变、营造团队的氛围、项目把控的情况以及公司产品的转型。创业确实很累，但还是感谢公司能给我这次机会让我学会了很多东西。关于管理方面的经验，以后我会再边学边实践和总结。