说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

传统开发过程
传统开发过程

由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

为什么会失败呢?后来思考了这些问题:

1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

敏捷开发的主旨

一:个体及交互比流程与工具更具价值
二:可用的软件比冗长的文档更有价值
三:与客户的协作比合同谈判更有价值
四:对变化的响应比遵循计划更有价值

而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

创业公司敏捷开发敏捷流程化
创业公司敏捷开发敏捷流程化

敏捷开发简单流程

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

  • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
    a、测试要验收功能,必须理解业务需求。
    b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
    c、团队大部分是男生,女生推广更有亲和力一些。
  • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

  • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
  • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
  • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
  • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
  • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。
创业公司敏捷开发任务墙
创业公司敏捷开发任务墙
  • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
  • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
  • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。
创业公司敏捷开发结对编程
创业公司敏捷开发结对编程
  • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

另曝光一下项目1参与成员:

项目1敏捷团队
项目1敏捷团队

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 创业公司如何实施敏捷开发

      好的团队是创业公司成功的必要因素之一。差劲的团队会导致整个团队没有战斗力,互相算计,只看到自己的利益,永远做不成一个好的产品。优秀的团队整个团体非常有凝聚力,以公司的事业为自己的事业,各自发挥自己的特长并互相帮助对方,不计较个人短暂的得失努力把公司推向一个又一个高点。我想没有一个创业者不想建立这样的团队,但很多人想法是好的,为什么最终却达不到理想团队的效果呢?

      要知道人的问题永远是最复杂、最难处理的,因为人是可变化的实体,而作为技术创业者的我们对于电脑、程序处理的得心应手,但对于人来说就不是那么容易了。和团队、和客户等等相关处理,需要很好的情商,只要人对了,成功也就理所当然了。不过这里有很多问题,如何组建最开始的合伙人团队? 最开始没钱没资源怎么找到好的人才?人才找到了,怎么打造一个团结互助、士气高涨的团队?团队成员参差不齐,如何保证有潜力暂时能力不足的人才不掉队也不影响公司的产品研发?如何保证公司辛苦培养的人才不会流失?这么多问题怎么创业?是的,本身创业就是一个挑战自我的机会,就算很多产品刚开始只有一个人后续也会发展团队来完成产品的扩展,本篇文章主要讲的也是需要多人协助才能达到目标的创业方式。

     1、如何组建合伙人团队?参考前面  技术人员如何创业《二》- 合伙人的模式、 技术人员如何创业《三》- 合伙人的分工

  •  建立行政、产品、技术、销售互补型合伙人团队。
  • 合伙人团队难免会有意见冲突,有了冲突可以有很好的解决矛盾的机制,比如投票。
  •  要利益目标一致,公司重大事项透明化,减少猜忌和沟通误区。
  •  把合伙人当成创始人对待,建立起责任机制并发挥主人翁精神,把公司的事情当成自身必成的事业来对待。

     2、最开始没钱没资源怎么找到好的人才?

      这确实不好办,好的人才一般要求待遇也很高。那不是没钱的创业者就吸引不到优秀的创业人才了吗?其实看看我们成功的企业,比如腾讯、阿里巴巴等。马化腾他们一伙人在当时也不算特别出类拔萃,因为整个团队能力互补并且有很好的合作信任机制使他们走向成功。马云更不用说了,小学读了7年,高考考了三次,和他一起创业的十八罗汉大部分都是他的学生和以前创业公司的下属。看到这里也许大家就明白了,其实刚开始创业我们不需要特别出类拔尖的人才,只要这些人能够互补并且有好的潜力就可以了。当然如果有很强能力的人愿意放弃高工资收入浑浑噩噩的加入到创业公司并且愿意长久创业下去,那就说明踩了狗屎运了,这类人也要看情况管理,管理不好就像没有紧箍咒的孙悟空。说了这么多,需要关注这几点:

  • 寻找有潜力,有创业欲望的人。没有钱首先打消要找很强的人的念头,但是要找有那种不甘于现状,想在这个社会有所作为的人。
  • 建立大公司不能具备的学习成长环境。现在在大公司都是一个萝卜一个坑,人才比较多,发展机会也不是那么多。这也是我们吸引人才的一个优势,大家来了创业型公司可以一边学习一边做,不会像大公司论资排辈,只要做得好看结果论功行赏。
  • 目标导向和阶段性奖励的措施。   这个要做好,得让大家感觉到公司在不断发展,虽然目前收入不比大公司强,但是我们在成长,未来超过设置更大的空间也是有希望的。
  • 工作的多样性。这个也是大公司不具备的,在大公司换一个岗位很难,在小公司就不存在,哪里需要就在哪里革命,当然这个也会考虑大家的兴趣。只要能够创造出价值就行,以前在大公司只能做某一方面的技术,在创业型公司不只接触的技术面很多,还可以学习销售、营销、客户管理、财务等方面的知识。
  • 逐步扩大公司品牌影响力、技术专业影响力。这些东西搞好了,很多优秀的人才就会被公司形象、专业技术产生兴趣继而加入公司。因为人是群居动物,别说生活圈,我们在社交网络上也是找到自己感兴趣的人交流。

     3、怎么打造一个团结互助、士气高涨的团队。

      刚开始创业合伙人团队打造好了还不够。因为事情一多了就需要扩展整个团队,不可能所有事情创始人都能够搞定,团队的战斗力直接影响了整个公司的战斗力。我觉得一个团队最基本的就是要互相信赖,不只是合伙人需要信赖,整体团队也需要。合伙人都不信任就别开公司了,团队不信任合作会举步维艰,推动不了任何事情。信任包括同事对同事、上级对下级、下级对上级,任何一个环节都很重要。作为领导人怎么处理?

  • 认真思考每个人的性格和能力并根据能力安排好他们的位置和作用。这个很重要,如果把一个只会纸上谈兵的人安排在重要岗位,这种人在领导面前谈的头头是道,但是做起事来却屡屡受挫。如果他们还带领团队,那底下的员工更加不服管理导致团队战斗力下降。所以需要根据不同人的能力、性格和他们的兴趣安排工作,比如唐僧和四个徒弟分工就很不错,唐僧是项目经理负责团队管理和指导方向,孙悟空能力最强也担当了打怪的第一人,猪八戒能力还可以并且还会活跃团队气氛,沙僧做一些脏活累活并且无怨无恨,白龙马作为座驾非常称职并在合适的时候也会露两手。
  • 奖惩措施要公开公平透明。公司不管有没有发展,都需要有一套公开透明的奖惩措施,保证大家不会觉得不平衡。所谓论功行赏也是这样,奖励是摆在这里的,谁的能力强就能够得到。谁影响了整体公司的利益,谁就应该收到惩罚。我相信只要是为了创业一起来的兄弟都愿意接受这样的条件,通过这样的机制把想创业的更好的聚集在一起,把不好的人排除掉。
  • 阶段目标和进度要明确,并且每个人都知道整体目标和进度。作为领导者一定要掌控整个公司和项目的状况,不只是自己需要知道,团队也需要知道。大家需要知道我们目前做的东西处于整个公司的哪个部分,在整个项目中的哪个位置,现在进度怎么样。有了这些,团队了解到公司的经营状况和项目状况,使大家感觉自己的工作就是自己的事业,努力工作实现公司和项目目标也是为了我们自己。阶段完成目标后需要小小庆祝一下,有一种成就感。
  • 充分信任每一个团队成员,对于合适的人和合适的任务充分授权。充分信任你找到的每一个员工,相信他们能在自己的岗位发挥自己的最大作用。对于合适的人还需要再指定岗位充分授权。如果领导自己不信任员工,不授权员工做事,自己什么都要管是非常累,技术型领导更加容易这样。与其去管理团队还不如多花时间写几个函数来的实际。授权就是教人做事的方法,充分信任他能做好,并且知道和鼓励他不要怕错。授权后并不是不管了,还需要去跟踪进度保证他们执行到位。
  • 建立积极正面、坚持、负责到底的文化态度。领导是一面镜子,在遇到困难时大家都不愿意上的时候,自己得顶上。在收获任何一项果实,都需要坚持努力。因为你是焦点,必须要身先力行冲到最前面,好比古时候打仗一样,将军始终都是出头兵,如果将军到了打仗时使劲逃那谁还愿意去冲锋陷阵。

     4、如何保证有潜力暂时能力不足的人才不掉队也不影响公司的产品研发。

      公司刚成立,不可能全部找到各方面能力很强的人,还需要补充一些目前能力不足但是很有潜力的员工。他们虽然短时间内承担不了太多的事情,未来肯定会发展起来的。但是又有个很矛盾的东西,小公司不可能花大量时间去培养一个员工,当然招进去也是希望他马上干活的这种。那怎么取舍呢?

  • 建立学习型的团队。活到老学到老,技术团队需要不断加强学习。新人不能直接投入工作所以需要先学习一段时间才能正式工作。前期的学习可以采取导师指导的过程,在普及好规范、制度等后就可以在项目中锻炼了。刚开始做事情时,可以把一些简单的分配给他们做。有了一定成就感和分析能力后,可以在导师的指导下参与稍微复杂点的项目。每一个项目都必须要把设计文档写出来,并且开发后的东西刚开始必须要审核,审核通过后才能发布。这样团队成员在这样的发展中逐步成长起来,也完成了公司的产品。不过作为导师和技术总监也需要给每一个新员工制定好学习方向和路线。
  • 良好的团队沟通氛围,能力高的员工不歧视低能力员工。团结互助,这是一个强调团体的时代。大数据大数据,就是一堆人在一起才叫大数据。当然对于团队也是这样,不管团队内部什么成员,只要完成了团体目标才是好的团队。很多时候我们创业公司一个项目里有三分之一的新人比例,但是并不是因为新人的原因我们就完不成团队目标。所以以团队利益为导向的团队,在实现了团队梦想的同时自己的梦想也达成了。

     5、如何保证公司辛苦培养的人才不会流失。

      辛辛苦苦招的人,工作年限满了就开始跑路,离开的原因很多,可能领导不好、可能对方工资高点,可能对方技术和团队比较好。有潜力的人刚过来是不在乎工资,随着工作经验增多加上猎头也多,他们可能就受不了诱惑或者其他原因就跑到其他公司了。那我们如何才能做到大家会陪伴公司生存的每一天,不死不放弃的心得呢?

  • 好的领导。说到做到要有诚信。做不到的就先别承诺,承诺的不管有什么原因一定要达到。这个要做好不然下属经常也会为了自己的事情找借口。作为领导不比每件事情小事都自己做,充分调动大家的能力才是他的能力。好的领导尽量不要摆着一副暴发户的样子,要足够平和,让大家觉得你是大家的朋友而不是老板,多去和大家沟通,这样才能很好的融入大家的工作中。好的领导要有一些阅历,在大家都没有办法的时候你能想到办法。这里要说一点,技术型领导很怕别人比他强了,其实领导不可能什么都会,比如马云,他技术什么都不会,但是他能领导几万人的企业,能管理很多能人并且为他卖命。这才是一个好领导应该具备的特质。领导不是和下属比技术、比能力,而是比谁在遇到困难问题时谁还能想到办法,领导能够把一群比自己强的人管理起来已经就是很了不起了。领导必须是一个大方,懂得吃小亏占大便宜的人,如果随时在处理事情都表现得很小气,员工也不会觉得跟着这个领导以后公司成功了自己能得到什么利益。
  • 好的文化。任何一个公司都必须要有好的文化。好的文化可以使大家凝聚在一起,朝着一个目标奋斗。比如腾讯的文化:  正直、尽责、合作、创新。阿里巴巴的文化是:客户第一、团队合作、拥抱变化、诚信、激情、敬业。他们都突出了尽职、合作等文化,正是这些文化使他们的员工觉得作为公司一员很骄傲,正是这样阿里巴巴和腾讯才有这么多的员工和好雇主称号。有了这样的团队,他们不成功也难。关心员工的生活(安排休息区,有条件的还可以准备一些水果,桌面乒乓之类)。
  • 好的制度。领导一句话容易变成皇帝一句话封建主义社会。没有了制度就像没有了军规,没有了法律,完全靠人的本能和行为约束是不现实的。有了好的制度,不管是领导还是员工都应该一视同仁保证规矩方圆得当。好的制度并不是领导一个人说了算,最好是这个制度是从现有团队从目前状况中抽离开来,团队中成员一致认同或者选票得出。得到大家支持的制度才是好的制度。比如可以建立灵活的考勤制度,合理的奖惩制度,透明的成长职业规划和发展机制等。
  • 好的职业规划。其实并等于创业没有成功就不需要给大家做职业规划了,反而在创业的时候更应该做。毕竟大部分员工进来不像创始人对自己做的事情这么了解,也不一定有那么多的激情,他们可能更多的考虑个人和自身的发展,当然如果能够搭上一艘创业的好船,公司成功了他们也成功了当然非常好,我想这也是他们愿意来创业公司的一方面原因。我觉得作为公司的领导需要给每一个加入的人规划好未来,将来如何发展,对大家负责。因为这伙兄弟为了这个共同的梦想跟着当前的带头人放弃安逸的生活一起奋斗是多么的不容易啊。说到底,就算创业失败了,大家也是在创业的过程中学习到了非常多的经验和知识。
      说到底,每个公司创业的方式可能会有些不同,大家根据情况参考一下。后续再说一下,小型创业公司实施敏捷开发实战。

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 技术人员如何创业《四》- 打造超强执行力团队

“中国梦”我们习主席上台后就大大倡导。国家领导人有他们的中国梦,创业者也怀揣着创业的梦想。我们张罗好产品就要准备风风火火的大干一番了。合伙人很重要啊,就比如结婚一样,一定要找个好的对象。得有不同兴趣互补、又要有共同爱好、互相可以接受对方的缺点,也有很好的处理分歧的方式。找谁合伙可以看之前一篇 《技术人员如何创业《二》- 合伙人的模式》,这次主要说说我们公司创业的时候怎么去分工。

记得公司刚开始成立时,团队有一个技术型boss、一个行政、两三个技术。这个时候主要是为了一个ideal、满腔热血就开始开发。分工是这样的,boss指导方向、行政打点生活和后勤、技术作为先锋开发软件。这里就有个问题了,很多时候一个想法并不能变成一个产品。比如,我要研发一个记录笔记的软件,可以支持本地和在线,还支持交流分享。一句话需求如何去实现呢?在boss的眼里,这些都是他根据自己平时的生活工作发现的机会,技术实现人员就应该把这句话变成一个他满意的东西。我ca,一般技术型老板都认为这个很好实现,然后自我夸奖自己之前开发过什么很大的项目之类,不过这个是产品设计,并不是一个技术难题。怎么说呢?
首先,这不是一个好的产品定义,技术实现人员尝试着去理解开发最后不是boss要的。boss可能也只是了解产品的基本面,知道有这个市场空缺,具体怎么操作、怎么交互他也不清楚。
第二,没有细化,计划无法执行,可能导致项目时间把控不住。很多时候boss也会参与开发,导致产品进度没有人跟进。
第三,技术定义产品,可能会不自觉的添加很多非功能的潜在需求。比如要建立一个业务系统,先要引入一堆新技术。

所以之前这个项目就因为这样的模式很快就暂停了,做了2个月最终还是拿不出手。后来大家总结并改善了合作分工。由boss把握产品方向,建立公司级别的管理制度,定期收集和整理用户的需求和反馈;行政辅助建立督促公司的制度执行,负责部分用户的客服工作;技术负责把boss提的和用户提的需求实现,并先写个需求文档交给需求方开会总结,确认没有问题就变身码农实现系统。没有把这个产品具体定义出来是不能开发的,不是说很完美的一个产品,至少是能够体现得出最核心的功能。因为我们做的是一个针对企业的产品,光靠技术在家里蒙着头发明轮子是不行的,还必须定期了解用户的需求,反馈给我们进行反复迭代。这时一个小的产品研发团队初见规模,在这个阶段最需要的是产品设计、团队管理、技术研发。相当于我们的boss承担了产品设计和整体团队管理的工作,作为公司的负责人必须这么做也只有这么做。因为公司是boss搭建起来的,公司未来怎么走,员工积极性高不高直接影响了项目的结果。公司刚成立企业文化管理、团队管理就要建立起来,不能因为是创业公司生存压力大就不考虑。这些东西就像技术框架一样,没有这些东西也可以开发系统,但是如果不建立,后续开发的模块越多就越乱。导致到了最后添加一个简单的新需求都会寸步难行,制度也一样,一开始没有良好的企业文化和制度,这样建立的团队也是散的、没有战斗力。

产品设计
这个是很重要的,没有好的产品或者好的服务公司是赚不到钱的。是不是每个公司都必须要boss去设计产品,这个不一定,但是boss必须要把握公司的产品战略,或另找一个产品方面比较牛的人来专做这样的事情。特别是我们技术型的人才(不是复合式的),要转型到有产品思维的理念需要有个过程。我觉得就算有专业的产品合伙人,技术型的ceo也要多从业务角度、消费者、商业链条的角度去思考产品和战略。这个刚开始很难,做起来不是特别有感觉,除了课余时间恶补各方面知识外,还需要多从用户角度去收集意见。我记得之前腾讯发布一个版本时,先开发一个基础版本(80%的内部人员满意,不是说自我觉得全部ok)就发布给部分vip用户使用,美其名曰vip用户优先体验新版本,其实这个时候是充分调动了vip用户的积极性来收集这个产品的用户意见,在全面发布版本的时候提前改掉不合理的设计。技术人员是很固执的,一但决定要做一个功能,很难说服他不做这个。通过用户的角度来思考,更有说服力。经过几次迭代,个人和团队的工作方式也好转了,大家在产品的捏拿也更有感觉,不只是ceo。参与这个过程的行政、技术人员都会通过用户反馈吸取到意见。不过技术人才要创业,要当ceo就必须要华丽的变身,后续会越来越少的参与技术,最终可能转变为总体产品经理。常见的技术型ceo有马化腾、李彦宏。

团队管理
这个也很重要,没有好的团队做不了太多的事情。在大公司工作是这样吧,很多时候大家不朝一个方向努力,互相排挤对方,也就是很多大公司难以产出好的产品。小公司的人员管理也很重要,因为每个人承担的东西更加多,一个人相当于多个人用,如果大家不朝一个地方使劲,怎么可以做出非常好的产品。在这个时候有些事情就很重要了,确定企业文化、建立奖惩措施、建立好的工作环境、良好的工作氛围、目标明确的前景规划、看得到的计划里程碑。刚开始创业时最重要的可能是一个想法或者一个产品,但是随着公司的发展人才才是最重要的。有了好的人才可以让公司基业长青。怎么突出优秀的人才?先要好的选拔机制把有突出表现的人选拔出来,如果确实能力很强、态度很好,并且和公司利益一致,可以吸纳为小股东。让每个优秀的人都能有归属感,使他们感觉到自己是企业里的一份子。团队的建设其实在这个时候是很难的,因为公司小、资金紧张、又想找好的人才。很多公司开始有风投的,人才吸引方面问题不大。我们公司开始时没有,靠的是自己积蓄和亲朋好友天使投资。那这个人才问题怎么解决?我们找了一两个核心开发人员,再找一些有潜力工作不太久的开发人员,通过技术总监带核心开发、核心开发给普通开发当导师的模式共同构造一个学习型的团队,鼓励实战中学习。既能把工作做好,也使大家在学习中获利,双赢收效还不错!

技术研发
这个非常重要,技术不给力,就实现不了好的系统。所以互联网技术型创业的公司都有个什么都懂一点技术总监,负责攻克所有的技术难题。其实从刚开始来说他主要负责是需求分析、组建技术团队、系统设计,随着公司的发展,后续可能还需要承担一些产品设计、团队管理,甚至是一些销售的工作。虽然做的事情很多,技术人员也还是从多方面发展和锻炼了。从我的经验里,我觉得目前解决业务的技术都不是难题,所有的技术问题都可以解决。难题就在于在有限的成本下如何构建满足业务高性能需求架构(因为小公司不像大公司预算那么多买高性能服务器)、如何在有限的成本下构建超强执行力的团队、如何实现一个用户喜爱的产品。 关于技术如何做需求、构建超强执行力团队等具体怎么实施后面可以讨论一下,我们采用的自己特有的敏捷开发。

光有了产品还不够,就算再好的产品,用户看不到就谈不上购买了。隆重介绍一下销售。

销售
这个太重要了!怎么让我们的目标用户看到我们的产品,需要一个好的销售总监。在技术型公司,很多时候是看不上销售的,他们认为自己很牛的技术产品客户就自动找上门来。一开始只是研发产品,往往不具备销售人才,这也是刚开始创业公司的一个短板。产品快出来了的时候,可能也有点不是那么完美,不需要等到产品100%完美。要尽早提前预热的预热、准备的准备,其实也是这么回事,产品销售炒作才能体现出他的价值。有时候2块钱卖不出去的苹果,100块钱反而卖出去了。不管任何时代,营销广告都是非常重要的。站外的销售操作也是越早做越好,包括熟人群、qq群、邮件群、seo、sem、微博、微信等等。通过关系网把自己的产品推销出去,适当做些营销造势增加曝光度,树立行业领先地位品牌。而销售型的ceo可能模式就有点不同,他们可能更多的关注业务价值,怎么把核心的商业理念通过简单的技术手段实现来解决客户的问题。所以很多销售型ceo之前积累了很多客户和行业经验创业更容易成功。比如刘强东、马云之类。

其实这些都是一些角色定位,在创业初期可能一个人就兼职了多个角色,怎么去平衡,还看自己的人员配置!

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 技术人员如何创业《三》- 合伙人的分工