枫叶「零碎记录」

项目中的思考

字数统计: 1.9k阅读时长: 6 min
2019/04/06 Share

当初成为火排队的Owner的时候就不再以一个纯粹的的开发人员的职责来要求自己,或多或少会接触一些开发外的杂事,跟客户了解需求、跟其他开发兄弟协调任务、自己研究餐厅业务相关的知识、开始关注团队成长和氛围、用户体验、关注架构、关注未来可能的需求,尽可能保证一点前瞻性吧.

在做管理学习上我觉得有个简单的方法叫对标学习。在其位谋其政,不在其位预谋其政。看你现在的项目经理、技术总监、CTO的工作日常,有机会分担责任时,哪怕是协调人员、组织会议、跟踪任务。

一个项目的开发时间是固定的,甚至在大多数互联网公司来说时间是紧迫的 不够的。一个项目从开始到结束,参与的人除了客户端,还有测试和服务端,以及产品。每个人是否能够完成自己手头的任务? 需求的频繁变更,以及前期未料到的技术难点等等,这些都是不可控因素,任何一点没做好都有可能导致项目失控,最后的结果就是逾期。

  1. 很重要的一点就是任务分配。要充分了解小组内所有成员的特点,把任务分派到合适的人员头上。同时注意,一个模块的开发,如果资源允许的情况下最好安排给2个人协同开发,而不是一个模块一个人(里面有各种各样的情况大家想想可能就会懂了)。
  2. 任务细分。包括任务时间划定和任务描述,这是很有挑战性的操作,怎么在开发前准确理清任务的脉络,并在描述中写出来让相关人员避免踩坑,这是任务进度可控的关键所在。任务粒度要足够细才能在后面的周会和禅道上精准把控每个人的完成情况。
  3. 任务优先级。技术选型一定要提前展开,方案没出就可以开始。基础性任务,这个版本的重要需求任务,也要排到前面,原则就是先重后轻。
  4. 每周一次的例会是少不了的,不同开发阶段会议侧重点不一样。开发中期侧重就是了解每个开发人员的进度情况(包括服务端),沟通一些技术问题,作为组长要及时提醒一些逾期的任务。开发后期,则主要是明确变更的需求调整,对于大的改动应该再三商榷。另外,把握相关的测试进度,督促测试人员加大测试力度。
  5. 要实时关注开发进度,对于技术难点可以协助介入,如果长时间未能解决要及时停止,进行后面的开发。在后期在对这个难点灵活处理:比如暂时用特殊方法规避,或者和产品商议放到下个版本处理。
  6. 两个关键节点一定要守住:功能封板和0bug。功能封板是指客户端完成所有开发任务,能够全程无障碍交付测试,0bug则是发版的最后一道防线。

事情做到前面

要比别人花更多的精力,提前预判一些未知的问题:比如需求的不合理性,方案没有描述的地方,能够在开发前及时指出。服务端接口定义是够满足开发需求,也要提前审查。还有就是客户端开发的障碍扫平包括复杂模块的程序方案,一些技术研究,一些坑点等等。

你至少要比正常进度提前1-2天,把准备工作做好,一直保持最坏的打算的心态。

每天早上要了解组内成员和服务端的任务进度,必须时要运行并过一遍两端的app各模块。从我的经验来看,很多时候禅道上的任务进度有水分,明明功能没有完成,他要说自己已经完成了,这时候如果你不及时指出会直接导致后面0 bug节点失守!不要过分相信数据,要相信自己的眼睛(自己多做一会测试工作、不是不相信测试哥们,而是多一个『小白』测试也是一个测试想法要千奇百怪的测,毕竟一千个人心中有一千个哈姆雷特)。

还有就是ui这一块的工作安排,要提前和UI同时沟通确定任务时间,不要到客户端本地开发快完成了,才想起来还有ui切图没有给全。ui切图的按完成时间至少要比客户端本地开发截止日期提前1-2天,这样才能顺利完成所有的本地开发。

引导项目向前推动

每个人都是做自己的一亩三分地,服务端和产品可能还要负责其他的业务,大家很难做到100%的精力都投入到这个项目中。遇到一些冲突的地方就有可能是项目停滞不前,应该主动站出来组织一个短会让大家参与讨论,解决问题。

结果导向

大家应该没少听说 过程导向和结果导向这两个词,有时面试中也会被问起,两者的区别我不再赘述。我只想说,管理一个项目是绝对的结果导向。我不关心中间发生了什么,只要告诉我结果,以及你是否能够守住自己的承诺。 这同样也是小组长对自己的要求,老大既然愿意把这份责任交给你,那么一切以结果说话。0 bug时间节点到了,结果是android 和ios还有几十个bug。你可以找出十几个原因,但是毫无意义。如果你能在任务细分上做的更好,如果你在开发前期关注进度更多一点,是不可能导致现在的局面。多从自己身上找原因吧,我相信一句话:任何坏的结果不是在于过程中发生了什么,而是在于我们做了什么。

一些挑战

比较大的挑战主要是下面两个方面: 一是开发任务的细分。需要足够的开发经验积累,以及对需求的透彻理解,这个还是很难把控,毕竟在开发前就要把一个任务的来龙去脉,各种路径全部理清并不是一件容易事。但这个事情是很重要的,以我的经验来看任务细分的质量直接关系到功能开发的进度能否按时完成。

二是发版前期的进度把控,包括需求的变更和取舍,无法解决的技术难点处理。这里的准则就是:版本稳定为主,后期不应该引入较大的需求变更!比如3天后要发版了,那么接下来的3天的代码提交你要亲自审查,需求变更基本是拒绝的。如果现在还有谋和技术难点没有攻克,建议采取特殊处理办法暂时规避,后面再还这个技术债.

CATALOG
  1. 1. 事情做到前面
  2. 2. 引导项目向前推动
  3. 3. 结果导向
  4. 4. 一些挑战