创业故事之 失之仓促

                                                                           激情创业  失之仓促

                                                                                                      刘晨 / 文
 
编者按:
我们之前报道了很多成功或正在走向成功的创业案例。然而,现实是残酷的,事实上,更多的创业最终以失败收场。本期我们就收到一份创业失败的案例,而且在程序员创业中非常有代表性。尽管最终的结果并不令人满意,但作者却将整个过程和感想都讲述了出来。或许这样的案例对更多的后来者会更具意义,我们也衷心感谢这位勇敢者。
投资50万创业,一切似乎水到渠成
2003年创业时,我们是四个人:一个有足够的资金,一个借助私人关系能够联系到项目,包括我在内的另外两个人,对开发很感兴趣,主要投入技术、精力和时间。
我们一直是很好的朋友,又都希望能在软件行业里找到自己的位置。临近毕业时,我们决定申报一个软件公司,做完全属于自己的事业。7月份开始商议此事,10月份拿到了合法商业运作许可。公司注册资金50万元,其中有45万元是一个人独自出资,另外5万元是剩下三个人共同投入的。
接下来的一个月我们奔忙于寻找办公地点,招聘技术人员,完善开发队伍。最后,我们拉拢了四个在读的技术人员,其中包括两个博士和两个研究生,在租到华清家园的一套房间并购买了一些办公用品和电脑后,一家公司就这样正式成立了。
第一个项目启动,系统不大但是几经挫折
不过,由于整个公司的运作不当,我们在做第一个项目时就出现了种种问题。
这是一项某市教育局的教学资源管理系统。在与对方交流了四天,汇集了当地各学校校长、书记等人的需求之后,我们整理出一个两百多页的需求文档,回到北京,正式启动项目,投入到了紧张的开发工作中。
项目用到的技术是Struts的三层体系结构MIS资源管理系统,涉及Eclipse、Tomcat、数据库、Hibernate等。预计到2004年3月份完成项目,至少完成整个流程。
从2003年11月5号正式启动项目到11月底是初期系统架构、功能划分阶段。
12月初基本上进入功能模块的详细编码阶段。项目初期就分配好了每个编码人员负责的需求功能模块范围,由项目经理整合这些功能模块代码,测试会出现什么样的问题,再反馈给我们。
项目的时间进度、完成度和可能出现的一些Bug都在我们的预料之中。但代码不规范却是我们开始没有重视的。比如说命名的不统一,导致系统集中运行时出现很多报错。当一个编程人员需要调用其它编程人员负责的某些功能时,不是根据项目文档来写程序,而是直接跑来问:你这个功能接口是怎么定义的?我们几乎每个人都是在编码过程中才慢慢完善了自己的代码规范。
事实上,项目经理考虑到了有关规范代码的问题,但是编程人员对其都不够重视,最终陷入了非常复杂的情形,浪费了大家很多精力和时间。现在回想起来,如果最初的项目需求文档做得更规范和详尽,我们应该还能再提前30%的时间完成这个项目。
沟通方面我也遇到了很多问题。团队成员之间意见不统一,一旦出现大量的Bug,就相互埋怨对方为什么最初时不和自己沟通。由于公司当时对员工并没有合约的约束,有时争吵后,员工就赌气不到岗,直接影响项目的进度。
2004年2月份我们完成了整个系统,时间比预计早了40天。然而,在和用户沟通的时候,他们认为系统不是十分符合需求。好在不是技术上的问题,我们花了两三天时间再次沟通后回到北京进入二次开发,3月20号正式部署了我们的系统。
总结一下这个项目,也算成功,因为系统到现在还在使用,也没有出现什么问题。但实际上它并没有太多的技术创新,只是很单纯地实现了客户大概95%的需求,最后部署时还有些需求上的小分歧,好在有私人关系也没有再深究。
作坊式的运作
由于我对公司的运作和项目的技术创新都不太看好,第一个项目完成后不久,恰好有了一个更值得去学习的机会,我离开了创业团队。
现在仔细分析,其实那时不能算一个公司,整个运作就是作坊式的,很不正规。
回忆第一个项目的运作,技术方面基本还可以,但管理方面绝对是不及格的。由于部分人员是在读学生,基本上游离在公司外部。而且整个公司没有清晰的分工,职责不明,甚至没有做收支预算,项目运作下来只收益了几千元。
同时,公司没有核心技术和方向。开始仅仅明确了短期目标(接手某个项目),不想长远的目标。这样,对客户资源和市场没有考虑太多,但靠私人关系寻求项目,没有正常的赢利模式,所以时刻面临缺少后续项目的困境。
四个技术人员是雇佣的。完成第一个项目之后,四个人一起要求加薪。这个凭借短期项目成立的公司没有更多的项目,基本上所有花费都在员工工资上。最终,在没有亏掉50万元注册资金的情况下,我们不赚不赔地解散了。
我在公司待了不到一年,大家那时一起生活,吃、睡都在一起,挺苦挺累。团队有开心的时候,也有很多难过的事情,可惜的是没有累积下很好的资源。当初曾希望在开发中累积一个组件库,把很多可以反复利用的代码整理出来,但因精力分不开没有实现。
不放弃创业的机会,但不能单凭着一腔热血
这一次创业基本上是“群情激愤、血气方刚”下的产物。经历这次创业,我觉得有一个保证公司健康运营的管理人才确实非常重要,同时还要有一定资源的客户,而且要十分明确自己的赢利模式是什么。而我们当时完全是学生的心态,像完成作业似地工作。
创业还要有很好的心态,要明白自己是在创业而不是在任职,需要考虑的很长远。创业确实需要很高的热情,如果你在创业之初还犹豫就不要去做了,必须是义无反顾。面对团队,要能很好地调节关系,所以必须宽容和忍耐,团队成员之间有时候需要有人妥协,成员之间也要相互信任。
我们四个人当初决定分开的时候就约定,虽然这次失败,但我们始终相信总有机会一起做点什么。其实这个社会机会很多,等待当然是一种方式,需要沉着、忍耐和自信。我们永远不会放弃创业的机会,但是如果再来一次,我们明白不能单凭着一腔热血就开始了。
最后我想说,非常感谢我的父母,他们给了我最直接的鼓励。他们一直对我说:你如果要做,我们就尽力支持;但是,只要你决定做,就一定要认认真真,不管最后成功或是失败都是一种收获。
 
嘉宾评点
王征
北京网络易联信息技术有限公司CEO,曾任北京朗川软件可以有限公司COO和北京联众电脑技术有限公司产品总监。

 
创业成功的企业有很多类似的经验,而失败的企业也同样有相似的教训,通过分析本案的经过,我认为除非撞上大运拣到钱,这样的企业最终失败是难免的。
首先创业的定位和目标不明确。作为技术型的软件开发公司,可以分为通用软件产品型、解决方案型和定制开发型三种类型,各自的组织结构,管理模式与运作体系有很大差别。每类企业应按照定位不同进行技术人员与市场人员的组合,同时制定内部的开发与管理流程。简单地说,通用产品型的企业更注重产品的研发和渠道建设,解决方案型的企业更注重在特定行业或领域形成优势并和相关企业联盟,而定制开发型的企业则应着重在客户的发展维护和定单的获取。本案应归类于第三种模式,按照客户需求做定制开发,也就是大多以单一项目开发的模式进行管理。这种企业生存所依赖的是广泛的客户关系群,源源不断地获得定单,并且快速高效地完成开发交付使用。从这点来看,本案的企业定位不清,在软件研发与管理与客户发展维护上缺乏重点,没有针对性地拓展客户,也没有充足的客户关系基础,而是仅靠一两个关系定单支撑,致使难以为继。在这样的情形下,软件开发规范、公司管理也难以获得有效的保障。而项目开发型的企业很容易由于客户的支付问题造成资金短缺,占用资金较长,在这方面本案也体现了对现金流的计划没有足够的重视。
本案的第二个问题在于市场组织和销售。公司从创建伊始,就没有明确的市场对象,更没有制定有效的市场拓展计划,很多技术型的企业热衷于技术研发与管理,却忽略了市场才是企业的生存之本,没有客户群、没有强有力的销售政策,企业就不可能生存和发展。本案中的企业成员几乎全部是技术人员,缺乏市场的拓展与客户挖掘的能力,坐吃山空定然会在发展过程中遇到挫折。
管理团队意见不合无法形成共识是第三个大问题。作为一个团队,必须有共同的目标和具有领导力的Leader,本案的企业在没有明确目标和各自职责的情况下草率创建,最终由于管理团队意见不同而分道扬镳,这个结果本是可以预见的,虽然说鸟无头不飞,然而头太多就变成五马分尸。本案的创业团队在企业管理的经验与个人阅历方面都尚稚嫩,没有建立可行的管理与激励制度,缺乏基本的财务知识,在管理过程中更多的是依靠激情和想象,所幸及时止血,经过仔细分析与反省倒是一次宝贵的历练。
每天都有无数的企业创建,也有无数的企业解散,衷心希望他们在磨练之后能得的更远飞得更高。
 
怀千江
清华大学毕业,1999即开始创业,为时3年,担任技术负责人,建立技术团队,规划产品线,并取得两轮海外融资;于2001年离开团队加入一多媒体芯片设计公司,先后担任通信技术总监和算法部经理。

 
创业成功对于刚出校门的学生来说,应该是有不一样的定义。这里不是歧视或偏见,自己也是从这条道路走过来,所以额外能体会其中的辛酸和遗憾。如果要讲创业失败的细节几天几夜都说不完,只是结合这个故事说说自己的体会。
创业首先要有激情,更重要是要有很好的团队。团队的好坏不在于技术,而是人员配置合理,有市场,有技术,有管理。没有经验不要紧,团队就是一个动态的词,是需要不断调整、磨合,每个人能互相促进,能不断学习,甚至调整方向。这期间,每个人都要找到合适的位置,找不到的人就要被淘汰掉。
对没有经历过工作洗礼的人来说,要能认识到市场往往不会比技术这两个字更好理解。市场不只是关系,更是企业商业价值所在,是
存在的基础。要找到正确的适合的市场,要能在价值链上创造额外的价值,企业才能生存下来。创业初期的激情要转化为产品原型,经过实际市场的磨练,要不断调整方向以找到自己的市场。
创业失败,大家都会自我检讨,没有经验,职责不明,缺乏管理……总是有很多很多缺点,然而这些其实都不是关键,每个公司从小到大都是要经历这些过程。我们要检讨的是为什么团队没有很好的组织起来不断学习,为什么不能很快适应变化的市场和客户,自己在团队的角色是不是相应发挥了,能影响其他人。回到最初谈的创业成功,成功只是偶然,能拥有市场的意识,又有技术的优势,这样的创业失败仍将是职业生涯中一个很高的起点。

资源下载链接为: https://pan.quark.cn/s/5c50e6120579 在Android移动应用开发中,定位功能扮演着极为关键的角色,尤其是在提供导航、本地搜索等服务时,它能够帮助应用获取用户的位置信息。以“baiduGPS.rar”为例,这是一个基于百度地图API实现定位功能的示例项目,旨在展示如何在Android应用中集成百度地图的GPS定位服务。以下是对该技术的详细阐述。 百度地图API简介 百度地图API是由百度提供的一系列开放接口,开发者可以利用这些接口将百度地图的功能集成到自己的应用中,涵盖地图展示、定位、路径规划等多个方面。借助它,开发者能够开发出满足不同业务需求的定制化地图应用。 Android定位方式 Android系统支持多种定位方式,包括GPS(全球定位系统)和网络定位(通过Wi-Fi及移动网络)。开发者可以根据应用的具体需求选择合适的定位方法。在本示例中,主要采用GPS实现高精度定位。 权限声明 在Android应用中使用定位功能前,必须在Manifest.xml文件中声明相关权限。例如,添加<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />,以获取用户的精确位置信息。 百度地图SDK初始化 集成百度地图API时,需要在应用启动时初始化地图SDK。通常在Application类或Activity的onCreate()方法中调用BMapManager.init(),并设置回调监听器以处理初始化结果。 MapView的创建 在布局文件中添加MapView组件,它是地图显示的基础。通过设置其属性(如mapType、zoomLevel等),可以控制地图的显示效果。 定位服务的管理 使用百度地图API的LocationClient类来管理定位服务
<think>嗯,用户让我深度解释一下Python之禅。首先,我需要回忆一下Python之禅的具体内容。Python之禅是Tim Peters写的,包含19条指导原则,对吧?用户可能已经知道一些基本概念,但想深入理解每条原则的含义和应用场景。 首先,用户可能是一个有一定Python编程经验的开发者,或者正在学习Python,希望更好地理解其设计哲学。他们可能在实际编码中遇到了问题,比如代码结构混乱、可读性差,或者想提高代码的可维护性,所以想通过Python之禅找到指导。 接下来,我要考虑如何组织这些原则。可能需要将19条分成几个类别,比如代码可读性、简洁性、错误处理、设计哲学等,这样解释起来更有条理。例如,“优美胜于丑陋”和“明了胜于晦涩”属于可读性方面;“简单胜于复杂”和“复杂胜于凌乱”涉及简洁与复杂的关系。 然后,需要结合实际例子,让用户更容易理解。比如,解释“显式胜于隐式”时,可以对比隐式类型转换带来的问题,或者Python中如何通过显式的方法调用提高代码清晰度。此外,用户可能对某些原则感到困惑,比如“除非你确定需要,否则不要使用嵌套”这样的建议,需要具体说明如何避免过度嵌套,比如使用函数拆分或提前返回。 还要注意用户可能的深层需求。他们可能希望不仅了解每条原则的字面意思,还要知道如何在团队协作、项目维护中应用这些原则。例如,“可读性很重要”在团队开发中的重要性,或者“拒绝诱惑猜测”如何减少维护时的认知负担。 另外,需要提到Python之禅的局限性,比如有些原则可能相互冲突,这时候如何权衡。比如,在追求简洁的同时,如何保持代码的可扩展性。这能帮助用户更全面地理解,避免教条化应用这些原则。 最后,总结部分要强调Python之禅的核心思想,即编写清晰、优雅、易于维护的代码,并鼓励用户在实际中灵活运用这些原则,而不是死板遵循。可能还需要提醒用户,虽然这些原则很有帮助,但具体情况具体分析,实际开发中需要结合项目需求和团队规范。</think>Python之禅(The Zen of Python)是Python语言的核心设计哲学,由Tim Peters编写,隐藏在Python的`this`模块中。它通过19条简洁的格言,指导开发者编写优雅、清晰、可维护的代码。以下是深度解读: --- ### **核心理念分类解析** 1. **可读性与简洁性** - **优美胜于丑陋** 代码不仅是功能实现,更是艺术表达。Python鼓励用自然、直观的语法(如列表推导式)替代冗长实现。 - **明了胜于晦涩** 避免过度炫技,例如用`for`循环明确遍历,而非复杂的递归或魔法方法。 - **简单胜于复杂** 优先选择直白方案:用`in`判断成员存在,而非手动遍历列表。 - **复杂胜于凌乱** 若复杂逻辑不可避免(如算法优化),需保持代码结构整洁,通过注释和函数分块提高可读性。 2. **代码组织与结构** - **扁平胜于嵌套** 减少嵌套层级:用`guard clause`(提前返回)替代多层`if-else`。 - **稀疏胜于密集** 单行代码不宜过度复杂。例如,拆解复合表达式: ```python # 不推荐 result = [x**2 for x in data if x % 2 == 0] # 更清晰的拆分 even_numbers = [x for x in data if x % 2 == 0] squares = [x**2 for x in even_numbers] ``` 3. **稳健性与容错** - **显式胜于隐式** 避免隐式行为:函数应明确接收参数,而非依赖全局变量;用`is None`而非`if not x`判断空值。 - **错误不应被静默传递** 善用异常处理:捕获特定异常并记录日志,而非空`except`块掩盖问题。 - **面对歧义,拒绝猜测** 拒绝歧义设计:如Python中`==`和`is`的严格区分,避免像JavaScript的`==`隐式转换。 4. **工程化与协作** - **可读性很重要** 团队协作中,代码被阅读的次数远多于编写。遵循PEP8命名规范(如`snake_case`变量名)。 - **实用性胜过纯粹性** 必要时可妥协:若性能关键模块需牺牲可读性(如用Cython优化),需添加详细文档说明。 5. **设计哲学** - **现在胜过从未,尽管从未胜过现在仓促** 平衡开发节奏:快速原型验证(MVP)后逐步优化,而非过度设计。 - **命名空间是个绝妙理念** 利用模块化组织代码,避免命名冲突。例如通过`import numpy as np`管理作用域。 --- ### **辩证思考** - **原则的权衡** 如“简单”与“复杂”的冲突:面对高频查询场景,选择哈希表(`dict`)虽增加内存复杂度,但显著优化时间效率。 - **反对教条主义** 在追求“显式”时,合理使用上下文管理器(`with`)或装饰器隐式处理资源,反而能提升代码安全性。 --- ### **实践建议** 1. 通过`import this`随时重温Python之禅。 2. 使用`pylint`或`flake8`工具自动检查代码风格。 3. 在代码评审中,以之禅原则作为讨论框架。 Python之禅不仅是语法规范,更是对开发者思维方式的引导——它倡导在工程实践中寻找简洁与灵活、效率与可维护性的动态平衡。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值