分类 管理 下的文章

管理心得,不间断记录

兼职管理

1、响应时间 微信响应时间 超过5分钟 2次 中止合作
2、培养能力 经验、工具
3、收益高于预期
4、工程师和质量

关于裁员

裁员名单是根据个人在公司工作期间对代码的贡献来制定和排名的。

高效工作总结:

0、必胜信心
1、结果导向
2、完成时间
3、物理专注

公司管理思路:

互相投资、互相信任,非传统主雇关系
1、培养人,把能力传授给下面的人
2、放权
3、分享机制

小团队项目组基本管理:

1、放手,新问题主动处理、老问题交给下属处理,借此制定标准处理问题流程化;
2、榜样,有困难主动承担、有问题主动冲锋;
3、让功让利,向上让功、向下让利;

温和派领导人管理思路:

1、立功,对公司有贡献;
2、握权,能够影响员工收入组成40%、考核评分、项目奖金;
3、守信,不轻易承诺、一旦承诺必须兑现;
4、立标杆,培养典型员工进步并树立标杆;

团队凝聚力

1、身先士卒,带动员工积极性;
2、知人善任,用人长处;
3、勇于背锅;
4、尊重、感谢,公约机制;

提高员工工作效率

1、责任到人;
2、限定时间;
3、确定标准;
4、重复一次;
5、检查机制;
6、验收考核;

老版轻松

X成就感
V想明白,布置下去
1、会算账,不算公司赚多少钱、算员工能赚多少钱;
2、会画饼,公司壮大时候做到位置、发展前景;
3、会激发,你是专家我不行、顶梁柱;

7大迹象,表明你的DevOps 做对了!

据预测,未来 10 年中,企业或组织的数字化转型会达到高峰,将比过去几十年的总和还要多。而这一进程,开发工程师必须找到更加有效的开发方式,才能实现。

在这一层面来说,DevOps 是数字业务转型计划的核心。目前,企业越来越重视DevOps,并开始向这种开发方式转型。但是,如此多声称专注于 DevOps 的企业或组织,真的都做对了吗?

在大多数的 DevOps 实践中,仅仅涉及到了特定工具的使用,企业非常松散地遵循着某些 DevOps 原则。然而,要想真正成为一个以 DevOps 为中心的组织,这些远远不够。参照以下 7 点,或许能够帮助你及时纠偏:

一、部署是完全自动化的

每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分,要想将这些部分有效组装、最终形成最后的应用结果,往往需要借助构建工具或策略。

构建过程如果仅仅依赖人工,就会十分繁琐。于是,自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现,将大大提升工作效率。

在 DevOps 实践中,是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间,更多是避免问题的出现,手动部署更常出现因为人为错误引起的问题,而自动部署可以在问题出现时迅速恢复到以前的版本。

二、有频繁且快速的发布周期

天下武功唯快不破。想要获得更强大的竞争力,只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD(持续集成/持续交付),寻找更有效的自动化和部署更新迭代的方法,让开发人员提高生产效率、并快速地发布到生产环境中。

CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于:

1)通过频繁的代码库提交、自动化构建等来提高生产力;2)通过集成自动化测试以及开发期间的测试,增加在开发早期发现错误的机会;3)得益于频繁的测试和自动化部署系统,可以更快地发布版本。

三、注重可观察性

国外的一份报告显示,可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中,可观察性有非常重要的意义。

New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现,90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉,才能作出明智的决策,越来越多的团队开始从整个企业应用程序环境中收集数据,来提高整个开发过程的可观察性,可观察性也在生产前和生产后的环境中扮演越来越重要的角色。

四、有持续的反馈循环

请输入图片描述

初期,DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现,有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环,如上图所示。

其中,蓝色气泡代表技术,黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环(黑色箭头反馈环);开发-运维反馈环(绿色箭头反馈环);业务-运维反馈环(红色箭头反馈环);业务-用户反馈环(紫色箭头反馈环)。

在现在的 DevOps 理念中,出现错误并不可怕,可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知,从而使问题得到更快地解决。

很多时候,我们遇到问题仅仅是简单地解决了它,并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上,如果你设置了一个系统来识别问题、修复问题和改进问题,还需要认真分析,才意味着你在正确地实践 DevOps。

具体来说,一个监控系统需要观察并记录系统状态变化和数据的流程:1)状态的变化:可以通过状态的直接度量或者更新日志来表示;2)数据:可以通过记录内部组件和外部系统之间的请求和响应来记录。

五、开发和运营团队一起工作

Dev(开发) 和 Ops(运维) 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出,并以“Cooperation”作为整个演讲的核心,讲述了他们解决这个矛盾的实践经验。

在一个组织中,如果相关利益者的利益不一致,在既定流程的进行中一定会碰到诸多阻力。而在这一点上,首先做的就是把 Dev 和 Ops 的利益一致化,从而减少 Ops 对软件交付的阻力。

在传统观念中,开发的工作是增添新的功能,而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中,Ops 的工作目标应该是激活业务(enable the business ),与 Dev 是一致的。

至此,DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上,DevOps 的解释也着重于一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。因此,开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。

六、目标明确

虽然不同团队之间的沟通至关重要,但明确定义每个人都在努力实现的目标同样重要。归根结底,所有团队都有同一个目标:让组织更有效率。

但是,他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求,而不是做出假设或任其发展。

七、使用正确的工具和平台

DevOps 不仅仅是一种文化转变——它需要强大的工具才能实现。在实践过程中,如果你发现往往需要花费大量时间来解决出现的问题,那么很可能是因为你没有选择正确的 DevOps 工具。

幸运的是,目前的市场上有大量且广泛的 DevOps 工具可以选择,以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分,但是要记住,真正使改变发生的是实践。

请输入图片描述

在众多 DevOps 工具中,近两年来被业内广泛关注的飞算SoFlu因其对软件开发流程的变革而被大量企业应用于DevOps落地,飞算SoFlu是一款管理加开发工具,通过可视化编程的方式满足开发需求。使用平台的一个ID相当于一个10人科技团队,从而使用户有更多精力可以更多关注自身业务。飞算SoFlu中包含的三大核心技术,全都是 DevOps 实践中所要关注的重点:

1)可视化开发

改变传统开发方法,业务逻辑可视化展示,降低开发门槛,无需编写代码,在设计业务逻辑时就形成微服务应用。

2)平台组件

可视化平台组件是一类通用的技术功能模块,平台支持循环条件判断,函数调用,通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑,有别于通过组件排列组合。

3)管理方式

主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期,经验沉淀、知识积累,将管理制度真正的落地。

截至目前,飞算SoFlu已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务,助力其落地DevOps,提升研发效率。

一个典型的案例是,飞算SoFlu在某大型国有银行的应用。该银行原本需要3天才能开发完成的接口,使用飞算SoFlu,仅用了5个小时。其IT负责人表示,使用飞算SoFlu后,银行软件中心的整体研发效率获得了大幅提升。

飞算SoFlu的DevOps功能正是在不断的实践中完善升级,从实际业务出发,真正让企业实现降本增效。

一人公司方法论

作者和授权信息
本文由 Easy 撰写。

Weibo: https://weibo.com/easy
Twitter: https://twitter.com/easychen
Youtube: https://www.youtube.com/c/Easychen
(欢迎大家关注和订阅,等 Youtube 订阅过 1000 ,我会试试制作本方法论的视频版)

本文在 cc-by-nc-sa 协议发布。

您可以复制、发行、展览、表演、放映、广播或通过信息网络传播本作品,但必须署名作者并添加链接到本文。
不得为商业目的而使用本作品。
仅在遵守与本作品相同的许可条款下,您才能散布由本作品产生的派生作品
为什么有这篇文章
不管是独立开发还是IT课程,一个人做业务也好几年了,最近开始回过头整理通过实践获得的认知,并尝试将其梳理为一个方法论。

当然这个体系还不完善,但一直没有找到同一个方向又更为完善的。所以不如自己来整理和维护,对自己而言可以定期回顾修正,读过的大家也可以来参与补充。

什么是一人公司
这个方法论,我把它叫做「一人公司方法论」。那首先什么是「一人公司」呢?

字面的理解就是一个人运营的公司,但实际上它指代的是比较少的人运营的小公司,一般来说1~3个人运营的公司,也可以把它放到一人公司的范围以内。其他一些形式,比如说一个人再加上很多的兼职一块运营的公司,其实也可以看成一人公司。

所以从人数上来定义一个公司,实际上并不是很准确。我更喜欢另外一个层面的定义:

「 一人公司就是建立在个人品牌之上的公司。」

这个定义更为准确,它是说整个公司的业务和品牌影响力都主要源于基于一个人。它周围可能有一些辅助运营的团队,有一些外包、有一些兼职,甚至全职助理的角色,那也是一人公司。

为什么要单独来观察这一类公司呢?因为我觉得它是以个体创造财富的典型。之前我翻译过一篇趋势报告,叫做「百万美金的一人公司」。说的就是越来越多的一人公司,可以做到百万美金的价值。当然,直接盈利达到百万美金的不多,但是以 100 万美金估值卖掉的却不少,而且正变得越来越多。

一人公司的特点
优点
下面我们来看看一人公司的特点。先看优点。

第一个显而易见的优点就是成本低。因为整个公司只有一个人,所以无需办公场所等硬性成本;也没有长期雇员,所以它没有固定人工成本。

这里需要注意,固定人工成本,实际上是一个会引入风险的成本。很多程序员创业副业喜欢做外包,但是如果你做一家外包公司,就会纠结于固定人工成本。比如在你规模小的时候,接到几个大单子,就需要扩展人员来完成开发。但是如果做完这些项目以后,接不到同样数量的活,你还却依然需要支付同样的薪资来维持团队。这就成为了一个很高的风险。

你又不能把员工开掉,下次需要时再招。先不说这样干下次还能不能招到人,每次团队磨合和培养的成本就非常高。

回到低成本上来,因为你只有一个人,你不需要协同,所以没有沟通成本,很多事情可以保质保量的快速完成。

再一个,因为你没有团队,个人的话,想在哪个城市就可以在哪个城市。现在一些新一线和二线城市的生活成本非常低,生活环境也非常舒适,如果可以把业务放在一线城市,然后生活在其他城市的话,不但生活成本低,而且生活品质反而会得到提高,这也是一个非常划算的地方。

因为成本低,相应的对收入的压力就小。一个每月只能挣 10 万的业务,对大公司来讲可能成本都收不回来,但对于一人公司来讲,去掉成本和税都是自己的,很可能可以活得挺滋润。也正是因为存在这些结构性的市场空白,才让一人公司可以存在并得到发展。

缺点
一个人的精力是有限的
说完优点,下面我们来说一下缺点。

首先就是一个人的时间和精力是非常有限的。因为如果我们一天工作10个小时,一周工作5天,那一周其实就50个小时的工作时间。如果把这50个小时的工作时间均摊到各种要做的事情上边,就会发现其实每一件事都分不了太多时间,这会造成整体业务进展慢。

同时,因为就一个人,所以必须在多种业务之间来回切换,这会带来一些额外成本。

比如说我们正在编程、正在做架构设计的时候,是在进行深度思考,如果这时候有一些紧急但不重要的事情插入进来,就会把我们从深度思考中拉出来,之后需要再花很多时间才能重新进入到这个状态里边去,甚至可能再也回不到当时的状态,从而丢失掉一些很好的想法。尤其是对一些创造性高的工作来讲,这是非常可惜的。

一个人需要做全部事
第二个缺点就是,一人公司往往要求我们一个人把整个链条上的所有事情都做了。原因很简单,因为整个公司就你一个人,你不做就没有人做。

这样带来的一个非常明显的问题,就是工作量的大额增加。即使很多没有难度的事情,处理细节也会消耗大量的时间。

另外还有一个更严重的问题,「麻雀虽小、五脏俱全」。它不但要求工作量,还对技能有要求。如果你缺乏特定的技能,就需要投入上百个小时的学习时间,而且还不一定能学得好。

更有一些大型公司具有的资源,一人公司可能是不具备的,比如像做运营和销售时候的人脉资源。如果持续解决不了,就只能调整策略去绕开。

矛盾和解决
这里就出现了一个非常明显的矛盾:一方面是我们个人的时间精力非常有限(一周就50~60个小时);另外一方面,我们又有非常大量的事情要做,因为公司就我们一个人,所有的事情都是要有人来做的。

这个矛盾不解决,一人公司就运转不好。怎么解决呢?还是从矛盾的双方分别入手。

提升效率

第一个方向,一个人的时间和精力是有限的,那我们能不能提升效率。

这个对于其他的行业来讲,可能会比较难,但是对于程序员来讲,可以考虑自动化和人工智能。如果在这两个方向上有突破的话,我们就可以把个人的时间和精力从重复劳动里面解放出来,让机器高效率的去处理重复的事情,把我们仅有的精力放到创造性的、开创性的业务上面来。

对于通用业务而言,这个难度可能很大,但如果针对某些特定的业务,还是有可能构造出一人+机器人的效率放大结构的。这个结构一旦完成,就可以极大的提升效率。

选择要做的市场

另一个方面,我们还可以从选择要做的市场入手。虽然每个公司都有各种业务,但对于不同的市场,每一种业务的工作量是完全不同的。如果我们对进入的市场进行取舍,就可以把精力集中到那些工作量小的细分市场或者小众市场。比如我们只针对一个小众人群去做一个功能简单的软件,产品和开发的工作量就会小很多。

但小众市场往往伴随获客问题。

通用渠道
首先是通用渠道的相对获客成本变高。比如同样是花一百万买开屏广告,面向大众的快消类产品,100 万人看,其中有 80 万都是潜在目标用户,最后点击可能是 20 万。但小众产品如果以同样价格去投放,100 万人中很可能只有 10 万人是目标用户,这样点击和转化就非常低了。相对而已,小众人群的获客成本反而高很多。

定向投放
除了通用渠道,我们还可以考虑做定向投放。所谓定向投放是说,对这个小众市场的行业网站和社区投放广告,或者向这个小众市场相关的意见领袖(KOL)做营销推广,再或者购买搜索关键字来导流。这部分的效果会好一些,但成本就要看这个行业竞争如何了,竞争激烈的比通用渠道投放还要贵。

自制内容
以上两种方式都是需要相当的市场预算的,对于一个刚刚启动还没有盈利的产品,更多的是没有什么预算的情况。这时候我们更多的会考虑自己来做内容、自媒体、成为 KOL。

但做内容是需要持续不断投入的事情,在精力上的投入比较大。如果我们是一个人的公司,那一周50个小时的时间,花在视频录制剪辑加字幕发布上的时间,很可能高达20个小时。40%的时间花在做视频上,而这个视频它还不是立竿见影的,需要很长的时间去积累用户。

这也是为什么你会看到很多的程序员,不是靠写软件挣钱,而是靠公众号卖广告挣钱。因为做内容就很费时间了,如果还要去开发一个软件,精力上很难支持住。

自传播
除了做内容,我们还可以在产品设计上发力。如果我们能让产品做到自传播 —— 就是让用户能不断地邀请来新用户,我们就不用花自己的精力在上边了。

有网络效应类的产品比较适合做自传播相关功能,因为用户的收益和用户数量成正比的。有的产品不一定适合传播,比如定位是一个非常私密的个人数据类产品,就不一定适合通过分享内容来拉新。

当然除了直接整合在产品中,我们也可以通过积分、物质回报来激励。比如现在已经很常用的分销返利或者邀请用户送付费会员等。

小结
对比以上方案,自传播应该是最好的渠道。需要付出的成本低,效果相对的也好。但它的问题在于如何优化产品,实现持续不断的自传播。这个是非常考验产品能力的。

选择成为平台或生态的一部分
除了选择市场以外,我们也可以选择成为平台或者生态的一部分。因为有平台在,我们就可以少做很多事情,甚至只需要关心业务逻辑。

对于早年的苹果市场来讲,只要会开发应用可能就OK了。苹果商店会帮你进行销售,其他的事情都不用管。

但这其实是理想状态,随着市场慢慢的从蓝海变成一个红海,我们会发现即使应用写完了,在市场里已经有很多同样的应用。我们又只能想办法去做营销相关的优化,在其他渠道去做一些推广。最后之前要做的事情,又回来了。因为对于每一个产品来讲,平台能提供的入口大家都能拿到,只能在这个基础上再竞争。用现在的词就是「内卷」,市场「卷」起来以后,我们就必须去做更多的事情。

当然我们也可以不做海,选择去做一个小池塘 —— 就是说这个市场非常小,不太可能变成红海,因为没有那么多的人看得上它。但相应的,这种市场一是很难发现,二是往往随着趋势的发展,它可能会消失掉。可能短期内还能挣点钱,但最后这个市场可能就没了,你又不得不从头来重新寻找新市场,这也是非常痛苦的。

苹果商店已经很成熟,所以比较卷。我们也可以去找一些新的平台和生态。比如 toB 的 SaaS 的话,国内可以看看企业微信和钉钉,国外的话可以看看 Airtable 这种新兴生态。如果进入的时间点合适,就能分到很多流量。

当然,还是想之前说的,一旦市场竞争变激烈后,红利就会消失,剩下的就是大家真刀真枪的竞争,要做的事情又会变多,如此往复。

分离非核心业务
确定了市场以后,我们还可以对自己的业务进行取舍。比如,我们把非核心业务给分离出来。这些业务,我们可以外包、可以兼职。对于一些基础设施,我们可以「以租代建」。

所谓「以租代建」,就是说以前我们需要什么系统都要自己开发,但是现在有各种各样的云平台、行业SaaS、以及不少按量付费的商业服务。比如商品代发,就已经有平台可以帮你来做。只要付一点钱,就可以让他们帮发货,自己就不用再搞个仓库或者店面来做中转。

基础设施和制造业也正在逐渐的成熟和开放,比如3d打印、周边印制。最后它们都会抽象成一些API接口,我们在网上去调用它,付费,剩下的事情就自动完成了。这样的话,很多非核心的业务都可以被分离出来。当然这个是一个过程。不同国家和地区的市场、不同的行业成熟度都不同,需要自己去考察。

强调「以租代建」对于程序员有特殊意义,因为对我们来讲写程序是很容易的事情,自己建一套系统也很方便的,而租用别人的还要花钱。以租代建的核心是节省时间和精力,如果我们只是通过不断开发各种系统来省钱,那这样跟我们去接外包挣钱不会有太大的区别。

(这也是我自己经常犯的错误,需要时刻提醒自己)

这里还有一个概念要明确,前面我们有提到说要分离非核心业务,那什么样的业务是核心业务呢。

这里有一个简单的判断标准。在我们做的这个业务中,最稀缺的资源应该成为我们的核心业务。比如对网课平台来讲,能持续不断生产优势课程的讲师就是稀缺资源,如何聚集和维护这个群体就是核心业务。只要保证这点,其他资源都会慢慢聚集过来。而其他的部分,比如课程平台的开发,就是非核心业务,可以通过租用或者购买的方式来解决。

增强优势
除了降低工作量,我们更需要想办法来增强优势。因为降低工作量只是保证我们能把产品完成,但如果产品和其他竞品一样的话,并不会具有优势。

从用户的角度来讲,大部分的用户并不关心产品背后的开发者是个人还是大企业,更看重付出的成本和得到的收益。所以我们最终还是要回到产品价值上来,为用户提供不可或缺的价值。

从标准品到独立品类
我们可以给一些标准化的产品去添加独有的特色功能,从而把它变成一个独立的品类。比如我之前做过一个软件叫做福利单词,它是一个背单词的软件。在任何一个市场上,这类软件都是一大堆。但福利单词有一个额外的功能,就是在输入单词正确时,会给你显示一张高清的萌妹子福利图。这就带来了完全不同的体验,在它和那些千篇一律的背单词软件中划出了界限,成为了一个同时融合叫教育和娱乐功能的独立品类。

如果你觉得这点小功能还不足使其以成为一个独立品类的话,可能我之前做的学前端 RPG 游戏 更明显一些。

副产品优势
另外一点就是,我之前在「从精益开发到精益副业」的视频 中提到的「副产品优势」。

虽然是在运营一人公司,但不一定非要全职来做这件事情。也可以一边上班,一边把一人公司作为副业来做。

在这种情况下,我们就会多出来一个优势,我叫它「副产品优势」。核心是说,因为有主业,所以可以保证基本收入和生活品质;在主业工作里边产生的副产品,可以进一步加工为商品,作为副业来销售。这样既没有生活压力,又降低了副业的制作成本。虽然刚开始可能收益的绝对值不大,但可以慢慢把它做大,直到有了充足的现金流,再把它当成主业来做。

营销优先还是开发优先
除了上边提到的这些,在实际运营中,我们还经常会遇到很多其他需要选择的地方。比如,在优先度上,到底是应该营销优先还是开发优先。

对于大一点的公司,有足够的人力,营销和开发都是不同的部门去做,所以可能不存在这个问题。但是对于一人公司来讲,其实很难一边做营销,一边不停的去给产品开发新功能。因为营销和运营不是一个短时间的事情,需要持续不断的进行。如果你不去做,很可能流量就没有了,没有流量就没有转化、也就没有收益。

另一方面,如果我们不断的开发新功能,时间长了就会有一堆项目需要维护,维护成本累加起来会很大。假设有 50 个项目,平均每个项目一年升级维护一次,每次两天,那么就会花掉我们工作时间的 40%。如果这些项目是免费的还好,可以随时关闭。但如果每个项目都有那么几十个付费用户,既不挣钱就要不断的提供维护和客服,是非常麻烦的。

这之间的取舍,会对我们的一人公司的运营产生很大的影响。

营销优先
营销优先模式是说,我们只开发一个很简单的产品,维持一个很小的功能集。然后不断的去为这个产品寻找新用户。

这个模式的优点是,我们开发的功能很少,维护成本比较低,不用不停地开发。

而它的缺点就在于,我们需要持续不断的进行营销,不断的获取新的用户。最后可能会发现,越来越多的精力都用到了营销上,用到了拉新上。最后完全变成了做内容或者做业务的竞争。

即使这样,如果能做好营销,那其实也不错。但大部分程序员并不喜欢和擅长做营销,而且在没有市场预算的情况下,要成为影响力不错的营销号是需要花很多的时间和精力,甚至还有运气的。

关于营销的难度,很多同学没有基本的概念。我这里有一个自己常用的参考转化率,是在以微博为主要流量入口的环境下测试得到的。从信息流展示次数到有效付费购买之间,转化率略为 1~5‰ 。当然,具体的数据会因为营销材料、产品需求有很大的不同(这其实是优化得不错的数据了),当你自己测试过后,可以得到自己的转化率数据。

如果你没有自己的数据,那么不妨以 1‰ 为基础简单评估营销难度。也就是说,如果想要获得 100 个购买,大概需要十万次的有效阅读,那么首先以 10 万的触达为基础思考如何达到。

开发优先
另一种模式叫做开发优先。是说我的营销能力可能不够,那我就面向同一群用户,不做营销了;改为针对已有的这些用户,不断的为他们开发付费产品。

这其实就是凯文·凯利那篇《1000个铁杆粉丝》的文章中的逻辑。文章中说,如果你有1000个铁杆粉丝,无论你卖什么东西他们都会买的那种,那你只需要面向他们不断推出产品,就可以维持不错的生活。

这种模式的优点是,我们不用到处去做营销,不用过多的去做我们(可能)不擅长的领域。而缺点就是,开发很累,维护也很累。如果不能形成规模效应,就要不断的开发付费应用,每一个产品可能就会做得很浅。

你可能要问,为啥我要不断的开发应用,我只开发一个应用,然后不断的收钱不行么?答案当然是可以,但难度有点高。

为什么要这么说呢,我们来计算下。假设我们期望每个月的毛收入在 5 万(除去成本和税以后大概在 3 万),如果以 1000 个铁杆粉丝来算,那每一个用户,就需要每个月消费50块钱。

这其实是一个很高的费用。从开发者的角度来讲,你可能觉得这个费用不高,但从用户的角度来讲,是很高的。如果你收集下自己和周围的人在软件和互联网服务上的实际开销,就会明白。

我之前在微博上发过一个提问,从评论来看,即使一年花销达到200左右的产品和服务都不太多,而且基本是资源导向的,比如视频音乐会员、电商外卖会员。很少有工具类软件能达到这个数的。所以,to C 的工具软件和 SaaS 里边,要找到每年能持续挣600块钱的需求,难度相当高。

to B 的服务在价格上相对容易上去,但是在获客成本和开发工作量上又相对较高。如果能在其中找到一个好的需求,倒是很不错。

总之,如果我们找不到这样的需求,就只能退而求其次,用多个付费服务来提升客单价。

实际操作
前面说了这么多的分析,但离落地还有一点点距离。在最后一部分里,我们就来思考下怎么落地。

发现一个趋势
寻找一个小市场
针对这个市场
面向 1000 个用户,提供一个每月 50 元定价的产品
或者面向 10000 个用户,提供一个每月 5 元的产品
开发产品并持续运营
发现趋势
首先,我们应该集中精力在发现趋势上。以前创业的时候,我经常思考一个问题。凭什么一个创业公司可以以很小的团队,在很短的时间,用很少的资源崛起。以前的人都没这些人聪明吗?显然不是。后来在阅读一些创业方法论的时候才明白,这是因为创业公司发现了趋势,找到了变化。因为这些变化是新出来的,所以以前的商业虽然有能力,有资源,但难以未卜先知。新的趋势就像山脉的崛起,将原来严丝合缝的商业逻辑撑开,出现了新的商业路径。

发现趋势,就是要看到变化。个人的努力虽然重要,但也要考虑时代的进程。尤其对于一人公司来讲,跟上大趋势,才能放大自己有限的精力投入。

关于趋势发现,简单粗暴的方式是读研究报告。比如艾瑞网会定期更新一些简版报告,从里边的数据可以发现很多有意思的趋势。不过这些报告更多的是面向创业投资领域,未必适合一人公司。像我经常在微博上提到的 Trends.vc 这种专门为独立开发者和一人公司准备的分析报告,就更有针对性一些。

寻找一个小市场
正在高速增长的赛道里往往有大量的巨头和创业公司,从资源上来讲,一人公司在这些领域很难占据优势。

但在这些赛道周边,通常都存在一些年收入最高几千万人民币的小市场,这些市场大厂和资本是看不上的,反而是一人公司很好的切入点。如果能结合趋势,选择到一个现在看起来很小,但是会随着趋势慢慢变大的市场,就能进一步保证将来的收益。早期进入,持续深耕,当这个市场成长起来时,即使是一人公司,也会具备很强的竞争力。

设计产品
然后就是针对这个市场设计产品了。根据自己的能力,可以有两个选择:

面向 1000 个用户,提供一个每月 50 元定价的产品
或者面向 10000 个用户,提供一个每月 5 元的产品
当然,其实你还可以进一步调节用户数和月定价,只要乘起来是 5 万就可以。而且 5 万也只是一个参考值,做不到还可以调低。如果一个产品做不到,可以把一个改成两个。这里量化数据的意义在于,给出一个清晰的模式,用来做前期的参考。

参考依据
在设计的过程中,我们可以准备很多备选方向和产品,通过比较选出最适合自己的。以下是我觉得有用的参考依据:

市场安全性:发展趋势(是否快要没了)、竞争情况(是否红海)
客户价值:MRR(每月经常收入预期)、LTV(客户生命期价值)
获客渠道和成本:是否能够自传播,传播系数
工作量:MVP(最简可行产品)所需工时、迭代和升级维护成本
资源匹配度:是否有自己难以掌控的资源
开发和持续运营
接下来就是 MVP(最简可行产品) 的开发,PMF(产品市场契合) 的寻找以及后续的持续运营(或者转型)了。这一部分的内容可以参考精益创业系列方法论。

一人公司的基础设施
无公司运营
虽然写的是「一人公司」,但其实我们并不需要一开始就注册一家公司。因为会带来办公地址和记账的固定成本。一般来讲,最理想的方式是以个人身份运营业务,在有了稳定的现金流以后,再注册公司。

在国内,很多平台对个人主体并不友好,需要自行寻找替代方案。以 Web 业务为例,我们需要和平台对接的部分通常包括:

第三方用户登入(比如微信登入)
支付(没有这个就没法收钱)
消息触达(群发通知)
其中,① 和 ③ 算是加分项,② 则是付费业务不可绕过的。

个人支付解决方案
就我了解,在目前个人主题可用的支付方案中,唯一安全而且稳定的是「小微商户」及类似方案。这种方案其实是支付平台(比如微信、支付宝)在提供底层能力,只是通常为了防止被滥用,不开放直接申请,而改用服务商代理的形式。

正因如此,它可以做到资金完全走支付平台(而不是你的支付服务商),保证了资金的安全而且没有二次清算问题。

国内提供基于小微商户支付方案的有好几家,通过搜索可以发现有 xorpay 、payjs 等服务商。但不少服务商不太厚道的自己搞了一个审核流程来收取审核费或者叫开通费。

我自己使用的是面包多推出的支付平台:面包多Pay。

官网注明的特点如下:

没有开通费,交易时才付费,非常适合启动期的项目,费率为每笔交易 0.1 + 2%
支付完成以后可以显示文字、图片或者跳转到网址,一些简单场景就不用写代码来接入了
不过对我而言,最主要的考量还是平台稳定性,现在面包多每月结算数百万,这个支付平台其实就是其业务核心「闪电结算」平台的扩展,属于主业副产品,因此不挣钱应该也会维护下去。

一个 Tips:面包多Pay(其他平台我并未交费试用,因此不做评价)的支付接口里边,有一个获取 openid 的接口。它其实可以用来做微信体系下的用户登入。换句话说,无需认证公众号就可以实现微信用户的登入和支付。这就非常适合个人。

消息触达
常规操作是,在登入时要求用户补全邮箱、手机号并将其作为消息触达主通道。但邮箱时效性差、短信被拦截可能性高,且费钱。因此微信成为了发送通知实时性和到达率最高的通道。但是未认证公众号只能被动回复消息,均不能主动发送消息。即使认证公众号,模板消息权限正在收回。

经过比较,我认为目前适合个人的消息触达方式是微信机器人/QQ机器人。通过关注机器人,发送 token 实现账号关联,之后就可以通过机器人推送消息给用户了。我知道的方案如下:

微信机器人方案: wechaty (网页版协议免费,其他协议收费)
QQ机器人方案:mirai (未亲测)
机器人方案除了可以用作消息推送,还可以用作登入。比起通过支付接口的 openid api 登入而言,没有因 openid 改变导致用户无法登入的风险。

公司注册
如果你不能找到满意的个人主体解决方案,那么就只能考虑注册公司了。需要留意的是,即使注册公司资质,其实也有个体工商户和公司两个选项。

个体工商户的申请流程虽然简单,但其背后是无限责任。而有限责任公司则以注册资金作为上限,更容易规避风险。

公司注册不是本文的内容范围,在此就不做展开了。

软件外包思考 二 验收

交付物

  • 软件

100%实现需求明细列表所有功能,即100%满足业务需求的软件。

  • 文档

5k0RououxvvEVPjH7fWp.png
2HTGkDE3AI1YFw0JSqDm.png

项目验收

  • 验收方式

1、将要交付的软件安装于指定服务器,并完成调试和上线;
2、完成培训后,业务验收人员根据需求明细列表实现情况进行验收评价,研发验收人员根据以下内容进行验收评价。

  • 文档验收

1、文档齐全(参考如上文档清单);
2、文档内容描述准确, 没有歧义和错误的表达;
3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达;
4、文档对主要功能和关键操作尽量提供应用实例。

  • 界面验收

1、界面设计符合自己公司的设计规范;
2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单;
3、各界面需要做好PC、手机、PAD等UI兼容与机器适配;
4、原则上,浏览器至少需适配Chrome、Safari、火狐、IE8以上;
5、原则上,手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。

  • 功能验收

1、功能验收范围覆盖(接口、数据库存取、页面功能);
2、提供单元测试用例、集成测试用例和系统测试用例;
3、提供BUG管理跟踪记录表;
4、提供质量分析报告。

  • 性能验收

1、提供性能测试报告;
2、相关重要指标达到以下要求:
LflV5vh3vvXE5jRYzegE.png

  • 安全验收

1、软件中的敏感数据需以密文方式存储;
2、软件需有留痕功能,即保存用户的操作日志、系统异常日志、接口调用数据日志等;
3、软件中各种用户的权限分配合理;
4、扫描出的安全漏洞(包含但不限于:越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等)外包团队需修复完毕。

  • 用户验收

1、外包团队需提供稳定的用户验收环境和联调环境;
2、业务场景功能测试不通过数的比例<1.5%;
3、不存在严重等级为1的错误;
4、不存在严重等级为2的错误;
5、严重等级为3的错误数量≤5;
6、所有提交的问题都已得到修复;
7、以上功能,用户验收测试通过后,由用户负责人签署验收通过确认书。
sOILv5Xlr5n2OevyiEnl.png

源码交接

如涉及到源码交接,按下列规范进行验收和交接。

  • 交接前提条件

1、需提供用户验收通过确认书;
2、涉及交接的软件,原则上建议接受交接软件所有功能,不建议交接软件部分功能模块;
3、跟薪资类无关的软件或功能,所有功能需在线上稳定运行不少于3个月;跟薪资类相关的软件或功能,所有功能需在线上稳定运行不少于6个月;
4、线上稳定运行既线上可用率,需满足:最近3至6个月内,线上没有出现影响20人以上或数据错误的严重bug,且每月线上bug数不超过3个。

  • 源码验收

1、代码应只保留跟本项目相关的代码,无效代码应一律去除;
2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等,无效内容应一律去除;
3、特别注意合理做好数据表结构设计,适当冗余提升性能;
4、代码结构清晰无冗余,注释完整有效,避免硬编码;
5、但凡不符合源码验收规范的,外包团队需修复完毕。

  • 其他注意点

1、对于外包团队的软硬件选型,建议业务部门邀请本公司IT团队一起参与决策;
2、与外包团队商签署的商务合同和补充协议等,建议业务部门邀请本公司IT团队一起参与制定;
3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可;
4、如外包项目不符合或无法满足上述验收规范的,建议商务层面延长付款周期、扣除相应款项或终止合同;
5、每一笔合同款在支付给外包团队之前,除了需获得用户验收通过确认书之外,还应通过IT团队验收;
6、以上内容建议附加进商务合同,成为其中一部分。

软件外包思考 一

软件外包存在风险,外包人员技术、态度、交付能力,如果想通过合同或者诉讼降低风险,由于太多的未知因素和太多的主观性,不现实。因此唯一的外包原则应该是:如果外包人员做得不好,有能力随时终止合作且可控费用损失和项目交付。

可以尝试渐进式方法,首先废除传统开发外包大瀑布方式(例如签订需求URS、项目总金额、进度款支付)(不过目前大部分外包会坚持使用瀑布法,并签订大额的预付合同),尝试新方案,项目按照功能或者阶段划分为多个子合同,做小项分包,或者改为签订人力外包合同。

  • 针对我们想要构建的功能,拟定一个顺序列表。
  • 找几名开发人员,最好是独立的自由职业者,但如果同意以下流程,开发工作室也没问题。
  • 对于每名开发人员,挑选列表中最重要的功能,与他们讨论功能需求、预算和成本。
  • 让他们实现那个特性并测试。
  • 让一名内部人员审核他们的 PR,测试升级后的 App,并标出有问题的地方。
  • 符合要求后,合并并部署该特性,这样,所有创始人/用户就可以继续审核该 App,并提供反馈或者根据需要调整。
  • 如果我们对他们所做的工作感到满意,就挑选下一个我们希望他们实现的功能,然后再次重复这个过程。
  • 如果我们对他们的工作不满意,就解雇他们,并寻找替代者。

当前需要做的工作,整理敏捷开发平台或者公共开发平台,并且参照以下原则:

  • 客户合作胜于合同谈判
  • 个体和互动胜于流程
  • 可运行的软件胜于详细的文档
  • 响应变化胜于遵循计划

参考文章:
Experiences working with an Outsourced Dev Shop

/* * @Author: your name * @Date: 2016-09-06 00:00:00 * @LastEditTime: 2020-03-17 18:29:35 * @LastEditors: Please set LastEditors * @Description: In User Settings Edit * @FilePath: \htdocs\usr\themes\default\footer.php */