Aug 23

如何做一个项目 不指定

djangowang , 11:24 , 工作相关 » Docker , 评论(2) , 引用(0) , 阅读(493) , Via 本站原创 | |
开篇

这篇文章是对之前几篇文章的一个续,主要介绍项目开发过程中发生的问题并以案例的方式介绍。

前两篇文章
Docker2.0 项目过程总结  http://blog.puppeter.com/read.php?52
Docker3.0 项目过程总结 http://blog.puppeter.com/read.php?56

你真的了解你的用户么?
一个项目能够成功需要看是否了解用户的真实的需求,但很多时候与用户沟通发现用户是不知道自己想要什么的,所以这里就要收集很多数据帮用户来排序与选择并最终给他一个选择题。以下是一个未了解用户真实需求的案例。
年中公司团建内部小鲜肉(kanesong)组织了一个泰国团,我个人是非常想去泰国的因为确实没有去过也很感兴趣泰国的美食,但从以往经历上看这团并不好组织所以也协助小鲜肉在拉人。 这里我提前设想了一下尽量的让泰国团能够真的筹集到人数成团的方法。
首先私下问了一些比较熟悉的朋友筹集首批用户而首批用户以女生为重点用户,因为女的多了男的才会有去的心思即便不去也可能会帮我们吆喝。人数很快筹到了13个人差2个人就可以成团了,但心里知道很多已经入团的人仍然处于犹豫期的未必会去,所以要了解大家真实的需求是什么好趁热打铁,我们收集了大家的想法与需求后经过汇总分类后如下:
1. 我想去泰国,但之前去过所以只想去指定的地点与路线,譬如芭提雅;
2. 我想去泰国,但是需要了解最终的团费是多少。而最终的团费和出团时间出团人数都是有关系的没有最终成团前这问题很难回答;
3. 我想去泰国,但只在6月中旬有时间;
4. 我想去泰国,去哪无所谓,主要是能吃到地道泰国美食,看到真正的泰国人妖;
5. 只要泰国能在短时间成团我就去;
6. 没说肯定去,也没说肯定不去。
从需求看上去真的是众口难调,但仔细思考问题也不大我想如果能满足这类人群中的大多数的需求那少数部分也就不成为问题了。我们边收集想法边推广,以以上需求的角度,以团内都是美女的角度,通过秘书与大家口口相传希望能筹集到最后的最少两个人,不过随着时间的渡过发现很多已经入团的同学没有了耐心已经有开始有退群的打算了,我都是先说等有新人进来再退但很无奈人就是凑不齐。 一天同组同学老司机(brinkmai)组织了一个休闲的广东省内团(http://blog.puppeter.com/read.php?59)开始我并不太看好,因为我觉得大家都是年轻人年轻的时候就应该能走多远就走多远多看一下外面的世界, 而吃惊的是两周后听说人数已经筹够达到出团的要求。 brinkmai也在邀请我来这团,其实我本想的是如果泰国不成团我就参加数据组同事组的台湾团,不过发现很多组内的同学都参与了,从更多与组内同学沟通的机会上看最终我还是选择了这个团,当我进入这团的RTX群后人数慢慢攀升到了30人这也给我了很大的触动,为什么泰国团组建就这么难而广东省内肇庆团就这样容易,分析后发现团内老员工占比比较多,大家主要还是借此机会能够得到充分的休息,所以用户最真是的需求是实惠休闲,当能聚类出这类用户的需求的情况下组织一个团成功率就会高很多,虽然不能满足每一位团友的需求但已经抓住了主体用户的需求组织起来也就没那么了。




Docker3.0的过去、现在和将来
开篇中提到的是一个生活的案例,可以看到在组团前我们是有意识通过历史经验来提升组团的成功概率的,工作中做项目也一样如何让做的项目能够成功? 这就需要考虑的维度更多一些。下面来介绍一下Docker3.0项目(Docker3.0是我们开发的一个内部系统版本代号)我主要通过时间维度来介绍一下此项目的过去、现在和将来,并介绍在每个环节中遇到的问题与思考。

“过去”
1. SNG运维场景;
2. 容器在场景下的需求分析。

1. SNG运维场景:
我个人觉得我们运维了业界最复杂的系统,复杂的原因产品线多、产品历史悠久譬如qq、qzone,腾讯成立于1998.11.11到2018.11.11日正好20周年,qq也从花季雨季步入小青年,qq和qzone是我们业务的主干为了不断满足用户的需求我们在主干上也不断迭代新的产品特性,但也有很多产品特性随着时间被主流的用户遗忘而变为了长尾业务,而这些业务都在我们的服务范畴内复杂程度可想而知。我们在运维这样复杂的系统同时也需要与时俱进不断跟上技术的革新,譬如Docker容器很火在公司内部其他BG如游戏王者荣耀都在应用,容器在技术上实现了弹性伸缩节约我们的成本也统一了“交付物”,在业务层面助力了王者荣耀的快速发展,所以我们有理由相信我们SNG也是可以用的。经过与同事的讨论与之前的运维经验,我们分析出玩容器在SNG可以分为4个场景,以下是4个场景的优缺点:
点击在新窗口中浏览此图片      

2. 容器在场景下的需求分析
容器应用场景已经分析出来了,如果站在我的角度出发,我可能先做离线再做在线业务与离线的混部,同时在开发系统过程中我们肯定会发现很多问题通过发现的问题在来迭代下一版本的需求,但主线依然是以上所提的SNG运维场景,所以假如我对SNG运维场景做一个排序的话,我的优先级排序是 1 3 2 4 这样做的方式优点是风险比较低相对容易出成果。但实际执行过程并没有想象的这样简单要综合很多人的意见权衡利弊,以下是前期与中期收集了大家的想法。
大老板: 我们要做容器、 不追求上量但能力一定要达到,希望我们做的不要比其他BG差;
中老板: 支持容器机器,底线是稳定与易用可推广,建议与织云体验融合可以无感知的推广与上量;
小老板: 系统一定要做出亮点。通过实现弹性伸缩,解决效率问题的同时也解决了我们成本问题。
经过各种权衡最终我们选择了在线业务的弹性伸缩(4)是四个场景中最难的一个场景,有时老板思路占比重会大一些。
确认应用场景后内部对开发形式又有一些争论:
开发同学1(t3): 建议使用lighthouse(内部开发系统代号),因为lxc(全称Linux Container)通过lighthouse管理对它做简单的改造就可以支持Docker的管理,无需重复照轮子。
开发同学2(t2): 是否使用lighthouse无所谓,但没有使用过python心里没底,希望开发同学1更多支持与帮助, 不过经过最终的权衡选择了重新开发。
我个人观点: 开发1与2的同学观点都对我们在做系统的时候要尽量避免的重复造轮子,但也要尊重每个人的选择让每个人在项目中得到收获与成长,而后者的权重通常要高于前者。

“现在”
时间到了年中,现状我们已经开发出了弹性扩容的系统灰度了很少一部分业务但并没有上量,从技术角度看此系统是成功的达到了预期效果,但从上量角度看还短期达不到还需要很多细节打磨。 一天坐公交偶遇一个老同事目前已经是一家创业公司的技术骨干,我们聊起了我做的Docker3.0项目,他其中一句话印象令我十分深刻,他说在腾讯内部开发的系统没有规模上量是有问题的。实际上从KPI角度看在年中没有上量也是有问题的,我复盘了一下整个过程个人总结有以下几点:

1. 缺少对用户需求的理解:
从“过去”这环节中大家可以看到我们前期分析了SNG的容器应用场景,在分析的过程中也与负责业务与开发天天打交道的业务运维进行了沟通分析了痛点这里要说一下强调一下“痛点“这词,在聊得过程中我个人感觉有时确实用户是不知道自己想要什么的,只能描述出业务特性比较复杂开发与运维“交付物”不明确等,如果可以通过镜像来实现开发与运维的“交付物”,通过容器来实现弹性伸缩是可以解决我们的效率问题降低运营的成本。而我们忽略了最真实的使用用户是开发,同时也没有一套简易的UI来描述开发后的用户体验而开始开工建设系统,最后导致系统建设出来但最终的使用用户反馈新系统学习成本比较高推动困难。 所以最开始如果我们做的是离线系统,通过此目标建设系统在后续做在线与离线系统混部的环节能给开发提前演示效果,有可能会比当前状态推动会更容易一些。

2. 没有遵循目标最小化原则:
其中目标最小化原则是以最小的代价来满足用户需求,再通过用户的反馈不断的迭代新的需求;以下这张截图很形象的说明了目标或产品最小化原则,这思路也是来自《精益创业》 一书中提出了“精益创业”(Lean Startup)的理念。

点击在新窗口中浏览此图片

而现状是(如截图no like this)确实初期定的目标有些高,短时间推动上量很多细节需要打磨,譬如页面的用户体验、对用户无感知和与旧运营系统融合等等。而目标较高在KPI的背景下短期没有过多收益会有很多流言蜚语影响大家的心态;

3. 没有推动上量的手段:
通常在内部开发的系统推动上量有几种方式:
1. 确实解决用户痛点,对整体(成本、质量、效率和安全)有明显受益;
2. 至高向下推,由leader或者更高职位的领导帮推动。 举个例子譬如安全,如果服务器不做安全加固短期可能没事,但万一出现安全漏洞服务器又没有加固就会导致数据泄露风险。而在没有安全漏洞的情况下,推动别人去做一些安全加固没有至高向下推是比较难推进的;
3. 通过其他手段譬如卡资源来推动本项目。 这里我们也没有做到,虽然我们组名叫计算资源组,但资源并不归我们负责用户上下线也不走计算资源组。2015年是节约成本年,很多产品业务快速发展拿不到资源,通过资源来卡业务是一个没有办法的办法,因为当时运营系统效率达不到弹性伸缩。但目前是17年业务手中不缺少资源,所以很难推动。
而目前1-3情况都不具备,没有一个很好的推动上量手段。

“将来”
0.  邮件记录每一个环节:
前期的需求分析、规划、里程碑、短期目标、中长期目标、参与人员和每次例会的内容都要记录邮件并定期输出,防止沟通不清楚和信息不对称导致项目出现的风险。

1. 不断的复盘与总结过程中发现的问题:
在“现在”这环节中,我们对项目的过往进行分析与总结,做项目还是要充分了解用户的需求,如果在用户说不清楚需求的情况下要拆分场景用产品最小化原则来建设系统,通过建设系统是否解决用户的痛点或是系统运营中的过程数据发现的细节问题来不断迭代下一版本,并在之前拆分的主线上慢慢前行同时还要不断的复盘过程中发现的问题并一一解决才做出一个好的系统。

2. 别迷信权威:
在项目开发很多思路来源于书本上的方法论,但书本上的知识方法论在项目过程中应用并落地还真不容易,所以不能不学这些方法论但又不能过于相信所有的方法论。

3. 尽量发现每个人的长处:
在项目过程中确实发现每个人性格是不一样的,所以在做项目的过程中根据性格特征每个人也有着自己的长处,有的同学不善于沟通但写代码很强,有的同学文档写的不错,有的同学推动能力很强,在做相同项目过程中发现每个人的长处可以让大家有成就感的同时推动最终项目的成功。



总结
本文标题是如何做一个项目,从本文第一个案例与第二个案例中看做的项目都不是十分的完美,大家看完可能觉得有些标题党的感觉所以这里介绍的并不是如何做一个成功的项目,而是在做项目过程中通过案例方式如如何将风险降到最低同时又能权衡利弊让大家受益最大化。当然在做项目过程中也有很多拿不准的东西以下留了一些过程中遇到的问题,如果是你应该如何应对也欢迎与我沟通讨论邮箱:8851970@qq.com 。 最后,引用爱迪生的一句话  "天才都是百分之九十九的汗水加百分之一的灵感。后面是那百分之一要比百分之九十九重要的多" 。

讨论的问题
0. 如果根据自己历史的项目经验觉得当前的方案是对的而老板又不这样认为应该怎么处理?
1. 项目开发过程中肯定会遇到很多细节的问题,当遇到细节问题争执不下时(在方案没有最终落地前,两方争执结论都是无懈可击的)这时找leader又两面为难不给最终建议,这时你应该怎么做?
2. 项目过程一但版本封板不准许增加需求,而产品为应对市场需求又怎需要增加一些需求导致版本期限延期,应该怎么处理?

ThreeStones
2018/03/10 13:06
你好,有的日志加密了还允许看吗
大梁
2017/08/25 10:51
同事路过,帮顶。
建议blog的排版建议优化下,看得费劲。
分页: 1/1 第一页 1 最后页
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]