微信客服
微信公众号实施工程师创业项目（工程类创业）
大家好，关于实施工程师创业项目很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于工程类创业的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
1本文目录一览
- 1、网络工程师如何创业
- 2、技术人员应该如何创业
- 3、创业项目该如何选择技术?
2网络工程师如何创业
在互联网的浪潮下，产品在快速地推陈出新，技术在不停地推陈出新，在这种大环境下，人心趋于浮躁，往往很难静下心专心做技术，唯有耐得住寂寞，才守得住繁华。以下是我为大家搜集的网络工程师如何创业相关 文章 ，希望对你有所帮助。
网络工程师如何创业：工程师的自我突破
态度决定一切
有句老话叫作：态度决定一切，你的态度如何，在一定程度上已决定你是失败还是成功。我觉得这点在做技术时体现得淋漓尽致，就以Openstack项目为例，在其中发现一个bug，其实不是难事。那么在发现某个Openstack服务的bug时，不同的工程师有着不同的态度：有的人随意Google一下找到解决 方法 然后接着干活，有的人尝试阅读源码后去自行修复bug，有的人会把写好的bugfix尝试推送到社区的upstream去。我们都会以工作太忙为理由，只以问题的解决作为目的驱动，从不去细究问题的源头。因此，这就导致了若干年后，有的工程师还只在原地踏步，有的已经不仅深入掌握源码，还能快速地做二次开发，还有的人不仅养成了良好的代码风格，还能积极地参与到upstream的开发中去。
记得在刚进入Sina云计算部门的时候，团队协作平台的副标题是28号加粗的一行文字：Develop is not easy。虽然不知道是哪位大牛写的，直到现在我仍然记忆犹新。Develop不光狭义地指开发，而是囊括了所有的技术岗位，我们要时刻清晰地认识到把事情做好并非易事。这里不仅指技术本身，还涉及许多相关的细节，这些细节常常被多数工程师忽略，而正是这些细节才能体现出一个工程师的闪光点。
我常使用业务素质一词来评论工程师：这个工程师的业务素质很高，指的是他不仅在***技能上出类拔萃，更重要的是在做事上非常认真，事无巨细，小到代码格式，注释，变量名称，代码提交信息，文档等每个细节都能体现出认真两字有多么难得可贵。凡是做过技术的朋友应该都会有所共鸣，并且从脑海中立马浮现出那些闪闪发光的人名来。
保持努力
我不想在努力这一点上举例来说明努力是多重要的因素，因为我们从小就开始灌输努力的重要性。我只想强调在正确技术突破的道路上，你必须不停地更新自己的知识和技能，才能越走越远。
我认识的另一位朋友，社区核心开发者，我询问他 圣诞节 打算去哪里过，他给我的回答是：I'm not going anywhere, just writing codes at home. 所以，那些外国工程师之所以如此牛逼，并非他们生来如此，而是他们的不懈努力。
所以请一定要做到保持这份干劲，并且时不时买些心灵鸡汤激励一下自己，或者按老罗所说：恶心一下自己，保持大脑亢奋。现在我脑子里只要一想到Emilien的那句“I write puppet codes except eating and sleeping“，就开始失眠，这鸡血的剂量使得我的生物钟又延时了一个小时。
充满热情
在我认识的技术人中，做得出色的人大都有一个相同特点：富有激情，他们总以一种积极主动的态度去对待生活和工作。我相信所有刚入IT行业的同学们都是满怀对于未来的憧憬，只是这种弥足珍贵的热量很容易被许多外界的负面因素慢慢磨灭：工作单调乏味，生活压力太大…但不要因此就把你的热情埋藏起来，一旦你习惯了埋藏，你将是一个了无生气的人。如果你失去了对于追逐技术的热枕，那么很难在技术的道路上有所突破。激情，在很多时候，往往能点燃我们创新的本能。有了激情就有了不竭的动力，你的内心同时也会变化，越发有信心，别人也会逐渐认识到你与众不同的价值。
善于沟通
工程师们常常把精力放在编码上，而很少去关注自己沟通能力的培养。我曾遇到过一些大牛，有的不屑写文档，有的不会用git等团队协作工具，还有的连话都说不清。不能否认他们在自己各自的领域中耕耘得很深，但是在分工如此细化的时代，大多数项目都需要团队协作才能完成，因此沟通是无法避免的：产品经理和设计师之间的沟通，后端组和前端组之间的沟通，研发部和运维部之间的沟通…为什么有时候对方听不明白我们想表达的意思，导致跨部门的工作寸步难行。
TED上有个有趣的演讲题目叫作：怎么说话人们才听，声音学专家朱利安给我们上了生动的一课，列举了为什么没人愿意听我们说话。因此，我们在与别人打交道的时候，我们必须明白对方在想什么，也要让对方明白我们想表达什么。
除此之外，对于工程师而言，沟通能力并不局限在语言沟通上，还有在协同开发时的沟通，例如对于使用git做版本控制的项目，若是没有掌握好git工作流，沟通将异常困难。代码审查系统上的交互，也是沟通方式的一种，你需要理解他人给你的意见，你能够向他人表达清楚你的意思。
全面 vs. 专精
以部署系统为例，早先的部署系统完全为公有云打造，要求做到细粒度控制，但操作起来比较繁琐;而现在要求同时管理公有云和数量庞大的托管云集群，并且每家在架构上都会有所差异，这就要求部署逻辑解耦，灵活可变，支持不同环境，不同拓扑，不同软件栈，还要解放实施人员，减少部署时间。
但由于每个人的精力都被分散到多个领域，因此很难集中精力把部署系统做好，于是我们开始从多面手向专一转变。也正是因为这两年我们什么都做，猛然一回头大家有些迷茫：自己什么都懂，但又什么都做不精。那么问题来了，学技术到底是…到底是精通一种还是全面发展好?
Take it easy，在技术的道路上看似会有两种截然不同的方向：横向扩展和纵向深入。横向的犹如瑞士军刀，十八般武艺样样精通;纵向的是削铁如泥的倚天剑，倚天不出，谁与争锋。横向扩展可以拓宽你的视野，让你不再局限在某一种技术中，并也给你的未来多了一种可能;而纵向扩展，可以使用你深刻理解一项技术的细节，让你静下来思考问题的本质，你可能会惊讶地发现某些原理都是相通的。这两个方向都没有对与错，发展到一定程度都会相互溶合，就好比中国佛家禅修的南顿北渐，其实到了最后，渐悟与顿悟是一样的，顿由渐中来。
不过哪个在前，哪个在后，我个人认为还是先做到对某一个领域有较深的理解和掌握后，进而去学习其他方向，这个道理就如同精通一门语言的程序员再去学习其他语言时就能驾轻熟路。
关于这两点的结合，我有很深的印象，如上面提到的情况，刚开始的时候，运维相关的事情繁杂，每个人都得是多面手，要去cover多个领域，也因为此只能把每件事情做好而无法做精。在集群规模不断扩大和业务量的增长后，原先不是问题的地方开始暴露出来，这就有精通该领域的工程师来独挡一面。这是一个自我学习，自我改变的过程，也是自我突破的关键。
了解自己，把握方向
在大学课堂里，工作 面试 和 入职 培训时常常能听到一个词： 职业规划 ，就是对职业生涯乃至人生进行持续的系统的计划过程，它包括职业定位、目标设定、通道设计三部分内容。职业定位主要是指：一是确定你是谁，你适合做什么工作;二是告诉别人你是谁，你擅长做什么工作。人生是应该有一个规划，这样可以对于未来设立一个期望，明白前进的方向。但这类职业规范往往过犹不及，觊觎通过把自己的人生画在纸上，然后按图施工的想法是不切实际的。仔细想想你真的能在刚踏入社会时就能真正了解你擅长做什么工作，适合做什么工作?
乔帮主说过一句话：“如果你了解自己，能够明白地做自己，职业规划如同虚设”。所以，你只要清楚自己想要什么，然后朝着这个目标去做自己想做的事，就可以了，为什么要给人生设限?何不尝试一下跨界?
前文中我谈到了一个网络工程师的华丽转身，接着聊一聊我们运维团队从UnitedStack成立伊始到现在发生的 故事 。
从理想国际大厦走出来开始创业的第一天，一个现实摆在了我们面前：采购服务器和交换机，选择IDC。在新浪，服务器选型有专门的部门做，采购硬件有专门的部门做，交换机配置有相应的部门做，服务器上架有相应的部门去做，我们只有基础运维和业务运维的 经验 ，原先所擅长的只是一个狭小的领域…
看来唯有自己动手，才能丰衣足食，我们着手开始调研服务器的选型，交换机的配置，IDC的选择。通过不断的摸索，现在我们制定了一套成熟的机制去根据不同业务来选型服务器，形成了一套完善的网络拓扑去连接分布在全国多个机房的公有云和托管云集群，也有了稳定的IDC合作伙伴。
许多朋友可能还记得UnitedStack去年发布的UOS 1.0发行版，其后端代码完全由运维组编写。当时，我们转身从运维变成研发，调研了主流的StackOps, Fuel Web，根据产品设计的需求，开发了一套由Python+Puppet编写的后端代码，实现了Openstack集群的自动化部署;内部的持续集成持续发布系统也全由运维组负责，我们根据研发工程师的实际需求对持续集成工具链做了多次整合以匹配整个研发体系的日常工作;14年初公司业务开始涉足公有云和托管云，我们和研发部门共同设计了公有云，托管云的整体架构。由于业务量的急剧上升，我们着手开发了资产管理，节点管理等多套运维平台。同时，和一般的运维团队不同，我们还负责虚拟服务器的镜像自动化制作和维护，参与Openstack最庞大的计算项目Nova的定制开发并一直保持与社区upstream同步，参与puppet-openstack社区的开发，一直在向社区贡献源码。
因为我们清楚所做的一切都是为了能把“事”做成，因此做什么并不重要。而且通过这两年的磨练，我们在技术上最大的收获在于大家的视野不再局限于各自的一亩三分地里，在面对新问题时，可以站在不同的角度去思考，这种在大公司里无法获得的经验就显得弥足珍贵。因此了解你自己，明白你自己想要什么，然后把握好方向。
3技术人员应该如何创业
技术人员应该如何创业
***技术人员 指依照***人才法律法规，经过***人事部门全国统考合格，并经***主管部委注册备案，颁发注册执业证书，在企业或事业单位从事***技术工作的技术人员及具有前述执业证书并从事***技术管理工作，在1983年以前评定了***技术职称或在1984年以后考取了***执行资格并具有***技术执业证书的人员。下面我为大家讲解技术人员如何创业。
技术人员应该如何创业1
不得不说这是个浮躁的社会，人人在这个社会都想暴富或者成名。在这些引诱的驱使下很多人都脱离了原来的稳定工作创业。前几天看了《中国合伙 人》，故事讲到了几个大学生从校园到工作、再到创办了一个伟大的企业，这个故事更加激励了创业大军的壮大。大家都想创业，那我们技术人员怎么创业?也就个人的经验分享一下：
a.好的想法、产品构思。
b.好的合伙人。三板斧，管理、销售、技术。
c.构建强大执行力的团队。
产品及想法：
什么是好的产品?一个朋友之前问到，这个问题要系统的回答还真有点不好说。看一下比较理论的解释，产品指一个能够满足用户的需求，我们能够使用 可行的技术手段实现并且通过销售给用户给公司带来利润。好的产品指具有很好的用户体验，能够满足用户的刚性需求，受众用户市场空间很大，产品具有核心竞争 力，具有不可复制性，有收益并且具备很好的产业链和利益平衡点。
我们技术人员设计产品会是什么样子?这点在创业中遇到了很多问题。有一些技术人员拿到一个产品就开始想象自己的产品未来如何的好，将来会赚多少 钱，结果研发到最后往往不是这样的。为什么呢?因为技术人员平时自己总是在搞定一个又一个的问题，做完了一个别人提给自己的需求就觉得自己信心暴涨，认为 这么简单的产品自己也可以很轻松就做出来了。看看自己搞的程序，这么复杂的工程，多有成就感。可是，自信心爆满的工程师如果不自我总结，研究用户需求、研 究产品，只是自己一个人关门造车的话很难开发一个大众都喜欢的产品。
现在我们处于一个信息量大、优秀产品非常多的时代。要在这个时代获得成功必须得迎合用户的需求甚至超出期望才行。技术人员怎么操作呢?
1、做市场调研、多和客户沟通、认真做好需求分析。
这个看似简单，对于技术人员确实难度很大。因为毕竟大家习惯了面对电脑，喜欢了在电脑面前攻克难题，让我们去做这些事情总觉得时间花的不值得。 有时候可能会想，我花这个时间去做个计划、去和客户沟通、写个需求文档还不如多学一点技术或者多写一些代码。技术相关的事情才是看得到摸得着的东西。这样 就错了!大错特错!
很多创业公司开始没有产品经理，像facbook的ceo扎克伯格。或者只有技术一个人，这个时候公司的创始人就承担了产品经理的角色，如果 创始人就把自己的点子抛出来给大家或者稍微分解一下就给到大家。然后大家分别去实现，自己也不管了，忙着开发自己的功能模块。以我们的经验，最后肯定是个 四不像的产品。那意思就是不开发产品了吗?看看电影《社交网络》就知道，扎克伯克其实不仅仅是技术很牛，网站搞瘫了整个哈佛的网络，他的商业敏锐度和用户 需求也拿捏得很好。在设计第一个长相匹配的网站时他知道整合爱德华的算法。在设计facbook时知道怎么利用其他学校都想和哈佛名牌学校的学生交友、 如何通过熟人关系网络邮件营销、添加用户是否单身的标示(最后这个功能大获成功)。
看到这里其实大家会想到，其实facbook的成功并不是因为他本身产品的技术多么牛，而是他把握好了产品用户的心理、选择了合适的营销方 式、整合自身独有的资源优势(哈佛)。其实他这个php网站我想现在很多学过web编程的都可以制造出来，有几个能做成facbook呢?
在《中国合伙人》中也有个场景，成东青因为在外面开小班被大学辞退了。最后一堂课时改变了原有的讲课风格，原来上课小心谨慎的照着课本讲，课上 的同学都在睡觉(因为那个时候风气比较严谨)，因为他在乎这份工作所以特别小心注意。最后一堂课给大家调侃自己的感情经历，已经释然反正都已经被学校辞退 了，结果讲课的风格大受同学欢迎。这个就是市场，有时候自己觉得对的不一定是对的，而是要和用户交流，充分尊重用户。他最后把同学当成朋友，也为他后面赢 得了新梦想。
这些在技术人员看起来的没有技术含量的脏活、累活反而是一个产品成功的关键。
2、适当的抛开技术，避免影响到产品设计和开发
技术人员设计产品时，总会把系统搞得特别是复杂。因为做技术框架时会想到重用、接口定义时要很灵活。一但这些技术方面的原因占据了产品的主导地 位，那这个产品最终会超级复杂。不过有一点，除非你的客户是专有的或者是面向技术型客户。不过面向大部分社会上的产品一般都比较傻瓜化、尽量简化，不让用 户思考，一看这个系统就知道怎么使用。
facbook曾经为了诸多技术原因选择了通用平台化的Html5作为技术实现。最终却因为用户的抱怨不得不重新使用ios、andriod开发原有应用。
很多技术在设计系统时，总想把很多新技术带入项目中来，让自己觉得特别牛。殊不知这样的技术自己能否掌控，如果掌控不了到时候出了问题影响的就是产品的口碑。并且引入新技术，带来了学习成本，如果团队中还有其他成员，未来他们如何学习和开发。
技术人员还有个弊病。觉得自己的技术非常牛，人家不可能超越我的技术(也就是未来我的产品肯定是市场占有率最高的，通俗讲我的产品是最赚钱 的)。研发几个月后发现竞争产品推出来了，会觉得他的技术多么弱，不削一顾。再过几个月，发现对方产品已经占据很多客户，并且推出了好几个新产品，还是觉 得他的核心竞争力没有，技术能力弱，我的技术毫无压力的压倒他。再过几个月，tnnd，我这么好的产品怎么没有市场呢，赶紧换一个产品...结果可想而 知。就算是自己最开始研发这种类型的产品，结果到后面反而没有赚到钱。这就是盲目的技术自信，而不是商业自信，开公司是要赚钱的，赚钱才能养活公司。
技术人员设计产品时，一定要有市场眼光、简单化功能、适当摈弃技术。刚开始要做到这些可能很难，需要大家强迫自己不往技术方面思考，不过我觉得 只要多发现、总结自己的问题，并想到解决方案终会创造一款好的产品。如果大家尝试了无数次，还是技术影响整个产品的设计，推荐几个选择：
a、找到互补的合伙人，弥补你的短板。
b、开发技术类产品。
b、回到公司工作继续做技术。
现在大概总结了产品设计的一些经验，后面再总结下我们怎么把这个想法变成可运行的东西。
技术人员应该如何创业2
“合伙人”其实从古到今都有，指一帮人聚集在一起干一件大事情，这个事情必须要借助大家的力量一起完成。比如水浒里的一百单八将、西游记里的五 人组合。技术创业者刚出来创业一般也都会找合伙人，毕竟一个人搞定不了太多的事情，除非自己做的东西一个人可以搞定，比如开个小店之内的。是不是只要研发 出软件产品就可以赚大钱了?那是不可能的，必须要有好的产品。个人觉得好的产品需要整个公司特别是管理人紧密配合才能创造出来的。怎么选择合伙人，我总结 一下我的个人经验吧。
有了好的产品想法或者拉到了投资就要开始张罗组建团队了。这也是最开始的核心部门，而作为技术人员的我们怎么组建团队?看现在的创业公司一般有下面几种模式：
a.几个同学或者朋友凑在一起组建团队。类似于腾讯、新东方的创始人。
b.一个创始人找项目找人凑在一起做一项事业。类似马云、史玉柱这样的创业公司。
c.家族式，比如当当网、四川希望集团等。
其实还有很多模式，哪种模式好，只有适合自己的模式才是最好的。这几个模式是我身边出现最多的几种。
第一种模式个人觉得很好，不过也是很有争议的一种模式，因为一起创业的都是朋友但是创业的过程少不了斗嘴，不少很好的朋友同学最后反目。电 影《中国合伙人》中因为成东青和孟晓峻的矛盾，王y说了一句挺有意思的话：“千万别跟丈母娘打麻将,千万别跟想法比你多的女人上床,千万别跟好朋友合伙开 公司” 。说是这样说，是因为中途出了矛盾，大家没有办法调和。王y和孟晓骏离开了新梦想。不过当最后成东青理解孟晓骏当年在美国的遭遇，并且悄悄把之前孟晓骏待 过的实验室以他的名字冠名，我当时就很羡慕这种共赴患难最后一起成功的兄弟是幸运和幸福的。说一下腾讯，他们几个合伙人从创办到2007年都是一直保持5 个人的阵型，很难得。他们是怎么做到的呢?从最开始分配股份时，马化腾让其他的股份合起来比他多一点，这样大家在做决定时就不会因为他一个人一家独大。另 外后来的利益分配也是按照贡献分配，几个合伙人在一起商量决定。这种模式最怕的就是大股东是个固执的人，不愿意投票决定，所以一开始就要确定要公司未来的 制度和利益分配制度。以后大家不会为了这种事情扯皮，最后要离开也就像陈一丹他们是为了实现自己其他人生价值(听说做慈善)而退休的离开。
第二种模式需要领导有很强的人格魅力聚集一帮能人。马云就是典型这种模式，当时阿里巴巴十八罗汉被马云召集 在他家创业，每个人每月500元工资，工作15个小时以上，吃住都在一起。这样的一个团队最后却大获成功，这中间和马云找到一些关键性人物和风投有很大关 系。所以这个带头人需要很强的忽悠能力、管理能力、超前的商业敏锐度。你说马云他刚开始能保证就要做一个阿里巴巴吗?我想他也不清楚，路走一走就清晰了， 就怕没有先前冲的勇气。这种模式怎么合伙呢?我觉得领导人需要找到合适的人做合适的事。因为毕竟大家不是朋友、同学，对彼此都不是很了解，怎么做到信任。 创始人需要建立行之有效的管理制度，保证有能力的人得到利益，不行的人淘汰，建立自己的核心团队。建立核心团队后，这个团队就要保持信息透明，让大家觉得 团队有归属感。就像以前毛爷爷带领共产党一样，其实前期创业是很苦的，但是大家还是愿意跟着他做，甚至付出自己的生命。这个很重要，很多领导人觉得公司还没赚钱谈这些都是空的，但是如果不谈谁 来给你拼命。特别是技术性的创始人更加容易这么认为，需要把股份分红白纸黑纸写出来让核心人员静下心来努力干活。上次马云退出阿里时，看到十八罗汉重聚台 上，还是蛮感动的，当时那一批没能力的草根搞出来现在日交易额几百亿的公司。
第三种模式家族企业，个人觉得处理好也是比较容易成功的。有个亲戚他们夫妻现在成都创办一个火锅品牌，开设 的分店有30多家。想当时他们刚起家时，家里有好几个小孩还有双方老人需要赡养，没有存款只有欠债，在这种环境下还是创业成功了。总结了他们的经验，最开 始男方在上海学习火锅厨师一套、女方做会计和大堂经理学习店面管理和财务。后来学习差不多了，他们回到三级城市，抓住了当时那里没有比较大点规模的火锅店 这个机遇。借了一些钱和几个人合伙开了一个火锅店，加上外面学的一些营销知识，打锣敲鼓巡街宣传。这样慢慢就发展起来了，不过之前他们还开过好几个店都失 败过。后来发现县城做这个的人慢慢跟风多了起来，竞争压力大，就开始向外部发展。到了成都刚开始也不知道怎么做，就加盟别人的店，后来知道加盟这种模式非 常好，马上就准备筹备开公司做品牌，逐步发展到现在这个程度。其实男方比较有商业敏锐度，喜欢交友，不计较得失;女方懂得财务，管理。光是扩展肯定不行 的，赚的钱守不住，这样一张一紧就把公司做起来了。
不管哪种模式搭建的合伙人团队都需要保持一个目标，朝着共同目标奋斗。看到这么多成功的模式，大家可能都想创业了。不过创业说容易也不容易，像 我们公司现在创业四年也只能做到刚刚盈利一点。我们是技术型公司，老板最开始工作也是做技术的。我们这种技术型创业型公司怎么建立起来的?下篇继续聊聊个 人经历。
技术人员应该如何创业3
“中国梦”我们主席上台后就大大倡导。***有他们的中国梦，创业者也怀揣着创业的梦想。我们张罗好产品就要准备风风火火的大干一番了。 合伙人很重要啊，就比如结婚一样，一定要找个好的对象。得有不同兴趣互补、又要有共同爱好、互相可以接受对方的缺点，也有很好的处理分歧的方式。这次主要 说说我们公司创业的时候怎么去分工。
记得公司刚开始成立时，团队有一个技术型boss、一个行政、两三个技术。这个时候主要是为了一个idea、满腔热血就开始开发。分工是这样 的，boss指导方向、行政打点生活和后勤、技术作为先锋开发软件。这里就有个问题了，很多时候一个想法并不能变成一个产品。比如，我要研发一个记录笔记 的软件，可以支持本地和在线，还支持交流分享。一句话需求如何去实现呢?在boss的眼里，这些都是他根据自己平时的生活工作发现的机会，技术实现人员就 应该把这句话变成一个他满意的东西。我ca，一般技术型老板都认为这个很好实现，然后自我夸奖自己之前开发过什么很大的项目之类，不过这个是产品设计，并 不是一个技术难题。怎么说呢?
首先，这不是一个好的产品定义，技术实现人员尝试着去理解开发最后不是boss要的。boss可能也只是了解产品的基本面，知道有这个市场空缺，具体怎么操作、怎么交互他也不清楚。
第二，没有细化，计划无法执行，可能导致项目时间把控不住。很多时候boss也会参与开发，导致产品进度没有人跟进。
第三，技术定义产品，可能会不自觉的添加很多非功能的潜在需求。比如要建立一个业务系统，先要引入一堆新技术。
没有把这个产品具体定义出来是不能开发的，不是说很完美的一个产品，至少是能够体现得出最核心的功能。因为我们做的是一个针对企业的产品，光靠技术在家里蒙着头发明轮子是不行的，还必须定期了解用户的需求，反馈给我们进行反复迭代。
这时一个小的产品研发团队初见规模，在这个阶段最需要的是产品设计、团队管理、技术研发。相当于我们的boss承担了产品设计和整体团队管理的 工作，作为公司的负责人必须这么做也只有这么做。因为公司是boss搭建起来的，公司未来怎么走，员工积极性高不高直接影响了项目的结果。
公司刚成立企业文化管理、团队管理就要建立起来，不能因为是创业公司生存压力大就不考虑。这些东西就像技术框架一样，没有这些东西也可以开发系 统，但是如果不建立，后续开发的模块越多就越乱。导致到了最后添加一个简单的新需求都会寸步难行，制度也一样，一开始没有良好的企业文化和制度，这样建立 的团队也是散的、没有战斗力。
产品设计
这个是很重要的，没有好的产品或者好的服务公司是赚不到钱的。是不是每个公司都必须要boss去设计产品，这个不一定，但是boss必须要把握 公司的产品战略，或另找一个产品方面比较牛的人来专做这样的事情。特别是我们技术型的人才(不是复合式的)，要转型到有产品思维的理念需要有个过程。
我觉得就算有***的产品合伙人，技术型的ceo也要多从业务角度、消费者、商业链条的角度去思考产品和战略。这个刚开始很难，做起来不是特别有 感觉，除了课余时间恶补各方面知识外，还需要多从用户角度去收集意见。我记得之前腾讯发布一个版本时，先开发一个基础版本(80%的内部人员满意，不是说 自我觉得全部ok)就发布给部分vip用户使用，美其名曰vip用户优先体验新版本，其实这个时候是充分调动了vip用户的积极性来收集这个产品的用户意 见，在全面发布版本的时候提前改掉不合理的'设计。
技术人员是很固执的，一但决定要做一个功能，很难说服他不做这个。通过用户的角度来思考，更有说服力。经过几次迭代，个人和团队的工作方式也好 转了，大家在产品的捏拿也更有感觉，不只是ceo。参与这个过程的行政、技术人员都会通过用户反馈吸取到意见。不过技术人才要创业，要当ceo就必须要华 丽的变身，后续会越来越少的参与技术，最终可能转变为总体产品经理。常见的技术型ceo有马化腾、李彦宏。
团队管理
这个也很重要，没有好的团队做不了太多的事情。
在大公司工作是这样吧，很多时候大家不朝一个方向努力，互相排挤对方，也就是很多大公司难以产出好的产品。小公司的人员管理也很重要，因为每个 人承担的东西更加多，一个人相当于多个人用，如果大家不朝一个地方使劲，怎么可以做出非常好的产品。在这个时候有些事情就很重要了，确定企业文化、建立奖 惩措施、建立好的工作环境、良好的工作氛围、目标明确的前景规划、看得到的计划里程碑。
刚开始创业时最重要的可能是一个想法或者一个产品，但是随着公司的发展人才才是最重要的。有了好的人才可以让公司基业长青。怎么突出优秀的人 才?先要好的选拔机制把有突出表现的人选拔出来，如果确实能力很强、态度很好，并且和公司利益一致，可以吸纳为小股东。让每个优秀的人都能有归属感，使他 们感觉到自己是企业里的一份子。团队的建设其实在这个时候是很难的，因为公司小、资金紧张、又想找好的人才。很多公司开始有风投的，人才吸引方面问题不 大。我们公司开始时没有，靠的是自己积蓄和亲朋好友天使投资。
那这个人才问题怎么解决?我们找了一两个核心开发人员，再找一些有潜力工作不太久的开发人员，通过技术总监带核心开发、核心开发给普通开发当导师的模式共同构造一个学习型的团队，鼓励实战中学习。既能把工作做好，也使大家在学习中获利，双赢收效还不错!
技术人员应该如何创业4
在人社部支持和鼓励事业单位***技术人员创新创业的指导意见出台3个多月后，昨日，北京市人社局发布《关于支持和鼓励高校、科研机构等事业单位***技术人员创新创业的实施意见》，对市属高校、科研机构的***技术人员“六种模式”下的创新创业，集中出台组合式支持政策。
6种模式鼓励当“创客”
3月22日，人社部公布《关于支持和鼓励事业单位***技术人员创新创业的指导意见》，明确了4项支持政策。未来高校、科研院所***技术人员离岗创新创业，可在3年内保留人事关系，离岗创业期间保留基本待遇。
此次北京出台的实施意见指出，实施支持政策旨在破除事业单位人员流动壁垒，启动***技术人才“共享”新机制，进一步激发人才创新创业活力，实现“出得去、回得来、用得活、管得好”，助力北京全国科技创新中心建设，着力打造北京发展新高地。
北京本次集中出台的组合式创新创业支持政策，明确了支持和鼓励高校、科研机构***技术人员创新创业的“六种模式”，即：兼职、在职创办企业，在岗创业，到企业挂职，参与项目合作，离岗创业。
创业内容须与本***相关
实施意见对可以享受支持政策的人群进行了划定，创新创业的人员范围，是以高校、科研机构为主的事业单位***技术人员。
有***技术职务的领导人员辞去领导职务的，从事科技管理工作、具有科技成果推广转化能力的管理人员，都可以离岗创业，充分发挥高校、科研机构人才和科技资源优势，加快科技创新。
北京市人社局相关负责人表示，公立医院所属的科研机构中拥有科研成果的***技术人员，以及高职院校、中专技校等职业教育机构的***技术人员也适用于该政策。
这位负责人强调，创新创业内容必须与自身的科研成果相关，必须以科研成果转化为目的，否则不适用该实施意见。
北京市人社局副局长陈蓓说，该实施意见制定的目的，就是要提高高校和科研机构科研成果转化效率。“以前从事科研转化人员，往往是业余工作者，在私底下搞成果转化，今后要支持他们搞，并且建立成果转化收益分配的制度体系。”陈蓓表示。
持续跟踪防止“吃空饷”
新政为事业单位创新创业人员创造了几乎“无门槛”的便利条件，但是否会增加用人单位的财政负担呢？
陈蓓告诉记者，新政的实施确实可能增加用人单位人力成本，但是鼓励创新就要义无反顾，创造最好的环境。而且，一旦有科技成果通过创新创业转化成功，收益中的一部分会反哺原单位，带来收益。“用人单位要把目光放远，支持力度越大，科技成果转化成功的可能性越大。”
陈蓓同时提醒，为防止“吃空饷”，对每一个创业人员都要采取严格规范的管理，例如规范程序、完善协议、持续跟踪等。“在这种新形势下，更难的问题留给了人事管理人员，要建立***有序的、符合创新创业管理需求的新型管理模式，避免因管理不善、跟踪不及时，造成人员失联和吃空饷，导致一活就乱、一活就散。”
对于事业单位人才流动制度，陈蓓认为，人才流动一直以来都不是很通畅，柔性流动并不频繁，人才作用发挥并不充分，从事***技术人才的岗位成果转化工作，也存在诸多不足。
陈蓓表示，新政就是要“变暗为明，变堵为畅，变单一为多元”，事业单位要怀有大格局，对人才流动持***态度，激发和激活***技术人员的创新活力。
中国劳动学会副会长苏海南表示，支持和鼓励事业单位***技术人员创新创业的一系列新政策，是对过去管得过多、过死的旧有人事管理制度的一个改革。“改革就是破旧立新，下一步，应该针对新情况相应完善相关制度，在鼓励支持这些人创新创业的过程中规范其与事业单位人事制度管理的关系。”苏海南说。
;
4创业项目该如何选择技术?
这些年，许多人问过我下面相同的问题： 我开始了一个新项目，你认为我该使用什么技术呢？ 通常，这些人属于下面两类中的一类： 已经做出决定的技术人员 需要鼓励支持的非技术人员 在一天结束的时候，我怀疑这些人是否真正关心我的答案。或许他们只是想知道我们是否面对相同的问题或只是需要鼓励支持。 坦白的说，作为一名工程师，我信奉这个说法：伟大的想法可由几乎任何技术构建。它们都有自己的优点和缺点。无论你选择什么技术，你都要为它带来的风险买单。但真的，你项目的成功与否更多的取决于愿景、领导团队、执行和市场，而并非技术的选择。 现在，我是一个负责人，我每天做技术上的决断。当我选择了一个特定技术时，我要能够证明这个决定，向我自己、我的合合伙人/员工和潜在的投资者。我根据项目及公司愿景做技术选择。 项目要成功你必须有一个坚定的愿景。如果你能将你的愿景转化成一组衡量你每个决定的值，你的前进道路会更清晰，也更容易找到合适的加入你的人。 除了愿景，许多初创公司专注于文化。人们都说文化是由创始人、最初的几个员工及产品本身确立的，然而，技术抉择对公司文化有直接影响这个说法却没怎么被提到。 你的项目初创可能基于J2EE、Oracle、Perl、PHP、Rails、Node.js或.NET，随之而来你的团队工程师将有不同的期望，不同的价值观，和不同的关注点。这些技术没有本质上是坏的。伟大的事情都有各自不凡的所在。它们伴随而来的是一种文化。 几年前，我遇到一位负责人选择使用Node.js来搭建自己的应用。出于好奇，我问他为什么选择Node。他的回答很简单：基础的工程师对Node.js很兴奋，所以我可以更容易招募到愿意免费贡献的人，因为他们希望积累相关经验。 这个决定显式地定义了工程师文化和团队成员——那些能够在这个项目中工作或感兴趣这个项目上工作的人。 问一个不一样的问题 那么我们不应该问什么技术是我们需要使用的， 我们应该问我们自己： 这个技术符合我们公司的核心价值观吗？ 这显然是个更为之困然的问题，因为你需要切切实实地了解你公司的核心价值观。这将是创建一个成功项目的关键。 你不能盲目地套用技术就像你不用套用别人的商业计划那样。这是公司身份的一部分，你的核心价值观，你的目标，你的团队，你的期望都是跟别人不一样的。 关于“这技术在某某公司用得适合啊”这样的论据是很少有效的。例如Facebook使用PHP，它“在Facebook公司用得很适合”，但是这意味着我们选都应该使用PHP吗？ 技术文化联盟 要具体描述这些技术社区的特性是很困难的,但我会个你分享我在不同选择上的观点与看法。请自由在评论里分享自己的看法，也可以包括关于其他技术社区的。 古典学校： 这里有些是“经典“的语言：他们已经被使用很长的一段时间，并且被证明他们的价值。他们的使用范围已经很广泛，但却引不起别人更大的激情。 注意：我在这没有提及Perl，因为我并不知道有哪个创业项目是以Perl作为核心技术来创建的（6？）。 PHP 理念: 功能都实现出来，这非常重要 就像互联网的基础一般 只要有一个方法去实现它，那么就不会被破坏 只要它运行起来并且速度很快，那么其他东西都是没有意义的 不要太理论化了，我们的语言是非常通熟易懂的，任何人一眨眼的功夫就能上手了。你可以用Java做同样的事情看看！ 面向对象是种落后的想法 常见的使用例子: (在2013年中期) 你的第一个web app Wordpress/Drupal的扩展 个人观点: PHP拥有它光荣的日子。它真的让web开发更加简单，容易上手. 但是, 大概因为大量新的程序员开始使用PHP并且它拥有个不是那么地坚持自己观点的社区，所以只有少数人能写出漂亮的PHP代码。 良好的拥有规范的代码例子是很难找到的，并且我甚至不敢肯定PHP拥有自身的规范。这导致了PHP社区以糟糕的代码质量，缺乏测试，安全问题如同梦魇和像在2000年代初期般的落后品味而著名。 拥有良好规范约定，开发流程和指南的强大的PHP团队，是可以完成伟大的事情的，但这样团队很稀少。 Java 理念: 可移植性 像C/C++般的能力和表现，但却能够自动管理内存 更多地关注面向对象 IDE是必须有得 我们要消耗所有的内存，因为它们是一文不值的 线程处理是个好方法！ 不要提起Java applets 看看我可爱的JVM！ 开源（但拥有者为Oracle） 缓慢但更为安全的开发流程 个人观点： Java是非常有趣的。在几年前很多开发者已经厌倦了Java，他们找到了其他新大陆。他们开始转向一些脚本语言，像PHP，Pyhton，Ruby或者一些更加难懂小众的语言像Erlang。 尽管如此，Google通过Android展示了Java并不像我们脑海里的那么糟糕（只要你并不是使用J2EE或者Swing）。现在有一种”赶时髦“的趋势视乎暗示着Java再次变得酷起来了。这些大多建立在两件事情上: JVM 让人难以置信高质量的代码库 即便如此，对于我们来说，花一整天来编写Java程序看起来并不是一件吸引人的事。如果你打算依靠Java的堆栈，那么有一系列的其他JVM语言供你选择，他们成熟而且兼容Java扩展的库（例如：Scala, Groovy, JRuby, Clojure），你总是可以混搭使用它们。 自从大量毕业生学习Java后，聘请Java程序员并非一件难事，但是要找那些前期创业公司，高水准的工程师并且对写Java程序感兴趣是一件极具挑战性的事情。 另外注意：如果你的目标是Android，那么不用想得太复杂，即使你认为其他JVM语言更好，你也要坚持使用官方的堆栈。 我们仍然有许多的原因在你的创业项目里使用Java技术，但你可能会想同时使用一些的”更快，更灵活“的解决方案（Ruby, Python, Node…）。对于公司跟工程师来说，一个多语言环境带来了大量的价值，这就是为什么Java社区看起来节奏很慢，但却肯定是活跃的。 Java绝大部分是吸引了那些受到了传统的训练的工程师，他们向往舒适，有重复性，总所周知的编程模式。他们习惯关于使用这种语言，这种工具，这种自然的节奏。或许他们并不是最具有求知欲的开发者，但是他们却是很可靠的（当然，你要挑选了正确的人）。 C#/.NET 理念: 是更加好的Java 最初是为了桌面与嵌入式软件设计的 我们比开发Java的小伙伴们拥有更好的IDE 虽然是企业级般的重量了，但是我们提供了大部分Rails很酷的特性 我们有矛盾的开源版本 缓慢但更为安全的开发流程 个人观点: 当我回顾C#在发布C#5的时候，我不得不惊叹，我真的对该语言新的特性留下了深刻的印象。单从纯粹的语言设计角度来看，C#是有一丁点的领先于Java。在Visual Studio里写Javascript时的欣悦感让我感到很惊喜（自从我用VS主要为了C++后，我真的再也没有期待过什么了）。 另一件让我印象很深的是：C#可利用的文档的质量非常显著！但是C#并不是开源的，和Visual Studio + MSDN 非常昂贵，并且整个环境都因为licenses跟内存损耗而变得很糟糕，这些事实多少让这个好印象打折扣了。 微软正在慢慢地往开源发展，所以有了更多像Azure的开源方案。但是作为一个社区，.NET仍然是微软开发的中心。作为创业者，你应该考虑下你对开源与拥有企业支持的文化之间对比的看法。 C#大部分吸引了Java群体中的变向者：这些工程师们寻求稳定性和有保障的合同远胜于追求开源。还有他们可以容忍IIS！ 明确的可替代品 在过去的这些年，有两个动态语言对于新的创业项目来说变得十分受宠：Python and Ruby。这两个语言实际上有非常多相似的地方。现在Python因为后台apps而著名（因为NLP, biotech, APIs, SOA的因素 ）而另一方方面，Ruby因为面向用户的apps而著名。尽管这两个语言都受到了一样的限制（主要是性能跟并发性），但是他们的核心价值和社区有着不一样的专注点。 Python 理念: 只有一种显而易见的做事方法 代码要漂亮简洁和明确 文档是关键 有较强的语言设计引导 个人观点: 作为一个更喜欢ruby的人来说，我常常嫉妒python项目文档的质量。同时python设计的初衷——给你一个正确的编程方式却又让我又爱又恨。通常这一初衷对于团队来说很好，但某些时候可能令人抓狂。 在某些领域python有很多优秀的库，并且这些库和你想解决的问题有关，这种情况下python可能是最好的选择。python开发者知道怎样去讨论交流他们的代码。他们用文档记录所做的事情并且用面向过程来描述他们务实的方法。 但是python在互联网流行前就已经存在，如果你关注的是并发和高吞吐量，那么这个并发性很差的动态解释语言可能不是一个很好的选择。 python主要吸引的是那些想要一个现代但通过充分验证的语言的更加务实和经验丰富的全栈开发者。 Ruby/Ruby on Rails 理念: 为人而不是机器而设计的Designed for humans, not machines 极端的灵活性：如果陷入困境的话，是你的原因，那是你 一切力求简单、优雅并充满乐趣 DSL至上，尽DSL 测试非常重要 事情变化很快，保持学习 激情活力的社区 个人意见: 就我而言，Ruby是我几年来的首选语言。你会发现令人难以置信的、大量的Ruby开源代码。Rails实在是一个了不起的Web框架，如果你知道如何使用工具的话它让使大多数的Web项目容易实现。 但灵活性和过快的开发周期也有缺点。随时准备在你的代码上投入大量时间以保持其更新以及分离废弃老的库。如果不能依靠缓存，一个成功应用的吞吐量往往被缺乏良好的并发支持限制。 Ruby开发者主要是用Rails开发，所以与框架特性相比基本不会去深入核心语言本身的特性。他们往往是充满好奇心且机会主义的（以一个很好的方式），有些实用主义，关心代码质量/结构和测试覆盖率。Rails开发者早期采用它的典型原因是由于该框架本身默认使用的一些新技术（coffeescript、turbolinks、CSS预处理器……）。 Ruby和Rails主要吸引了那些想把事情做得快而优雅的开发者。相比于底层计算细节，这些开发者往往是以产品导向的，他们更关心的目的和客户价值的实现。 新成员 这是些让人们兴奋的语言/技术。他们代表了运行在“云端”的编程语言的设计新浪潮。 Node.js (Javascript) Node.js不是一门编程语言，但它是使JS在服务器端运行最流行的方法。和我对Ruby的大部分评论是关于Rails一样，相比JS我更关注Node。 理念: 为实时驱动的应用程序而设计，高吞吐量、低延迟 DIY 小的内核，剩余的内容由社区维护 低耦合 借鉴Ruby/Python 个人意见: 我觉得Node.js很有趣。在技术上Node没有太多新内容。Python有Tornado/Twisted，Ruby有EventMachine，C有 libevent。 事件驱动的框架已经使用了一段时间，但Node具有两大优势：*大多数JS库是非阻塞*大多数Web开发者不管怎样都要写一些JS。 在前端和后端使用相同编程语言的想法吸引了不少人，但值得与否还有待验证。 Node提供了巨大的吞吐量（只要你坚持IO操作），它很容易上手，而且写起来很有趣。 由于其本身具有事件驱动性，调试及测试面临挑战，回调处理是可维护性的地狱。我希望Node能够提供一种官方的今后或承诺的解决方案。略显凌乱的文档使在现有项目里跳转时有些困难。 Node的开发者大都是它的早期的接受者，他们更喜欢自定义而不是按惯例创建结构/模式，这样使他们觉得更舒服。它吸引开发者使用已知的语言（JS）去处理高层的并发。Node作为一个框架处理的水平比经典的MVC更底层一些。Node开发者们也真的喜欢这个在服务器和客户端使用相同语言的想法。 Clojure 理念: 实用且符合现代人使用的Lisp 一切皆是数据 并发性，并发性，并发性 让那该死的可变状态见鬼吧 能够很好地与Java协作 稍微靠近科研路线，但并不影响他的实用性 个人观点: 我最喜欢Clojure的一点是它的lisp精神。一旦你攻克了它的圆括号和操作符/参数顺序，那么Clojure将很可能让你重新思考你构建代码的方式。对于处理数据跟强迫你保持代码简短这两方面来说，它真的很棒并且高效。 让我头疼的是我并非拥有足够的聪明去更多地编写Clojure。当我尝试去追踪那些数据时，我的大脑会出现栈溢出。对于该语言来说异常通常是没意义的，假如你尝试解决别人代码的bug，这将会是机具挑战的事情因为Clojure本身是复杂的语言，并且可以用宏来拓展。最后，Clojure社区并不是真的面向web开发，Clojure完成的大多数作品都是以数据作为中心的。 Clojure主要吸引了那些处于边缘，对编程语言有求知欲，面相数据的程序员。如果你寻找有编程语言怪癖的数据处理专家，那么Clojure将会是吸引他们的好方法。 Scala 哲学: 同时具有面向对象与函数编程世界的最佳优点 让编译器为你做一些工作 并发事务 比Java少一些规范，但是目标在于相同或更好的性能 与Java生态系统和谐共存 个人意见: 当目标是JVM时，Scala目前是我所选择的语言。它的学习曲线陡峭。 知道何时使用 FP 与 OOP是非常复杂的，而且在应对该语言语法本身时也是如此。 那就是说，获得使用FP的好处，同时又在需要的时候仍然保持OOP，是非常有用的。一旦你“掌握”了该语言的风格，写Scala实际上是令人愉快的，而且它的社区也非常友好。 Play框架确实很好，它提供了一个很好的替代Rails的选择，特别是对API开发来说。Twitter的工程师团队为此提供了许多资源与开源代码。 目前使用Scala是一个非常安全的选择。Java开发者会有舒适感并会尝试这种更加“现代的”语言。动态语言开发者不会感觉太陌生，并且获得了Java生态环境，性能提升，并发性和永恒性。如果编译时间不会使你感到沮丧的话，现有工具以及惯例使得在一个成长的团队中使用Scala非常不错。 不过就像Ruby，Scala社区的文档不是很丰富。我真的希望 API文档 可以重新编写得更直观，总的说来就是更有用。但是公平的说，已经有许多非常好的资源了，比如Martin Odersky (Scala的创造者)提供的Twitter的 Scala学校和Coursera的Scala 课堂之 FP 。 Scala主要是吸引了好奇的Java开发者，他们想要一些更现代的东西，就像Ruby/Python开发者想要他们语言的一个更具伸缩性的版本。对于吸引那些想拓展它们现存开发环境的伟大的开发者，以及那些可以充分利用该语言二元性的开发者来说，Scala是一个好方法。 Go 更强大的C 你可以自己管理内存，前提是你不能粗心大意 直观的代码更好 丰富的代码库 效率很快..对于任何一个部分来说（从编译到执行） 存在并行编程模式，并且简单使用 文档很关键 个人观点: 我真的很喜欢Go（亦称Golang）。在我使用它几年之后，我选择使用它来开发我自己新项目的API。Go或许对于一些人来说有些无聊，但它的简洁与效率是真材实料的。 Go强迫你更多地去思考你的代码的结构，你的数据/代码行为，因为你不能总是坚持面向对象的编程模式。我发现我的代码总算变得容易调试，结构更简洁，但有时会重复性比较大（例如：错误处理）。 没有比Go更加方便地开发并发业务的语言了。一旦需要编译，你的代码编译加上运行的时间会比Rails服务器启动的时间还快。Go支持一些鸭子类型（duck typing,动态类型的一种风格），这造就了从Ruby（举个例子）转换过来显得颇为简单。对比起一些脚本语言，它所编写产品的性能实在让人觉得惊叹，并且它占用的内存很小。 Go被设计为一个人或是一个大团队都可以为同一代码库工作的语言，而且它的身旁有很多很棒的工具值得你使用。 然而，它不是完美的语言。有时第三方依赖库很让人头疼。当你在高水平编程中运用了Go会让你觉得它的水平太低了。有些语言设计时的决策有时会引起困惑(例子：交互式接口和结构化设计)。 初创公司里，Go看起来在性能和并发事务方面变得越来越流行。我见过很多初创公司用Go替代了Node，而且另一些公司添加了Go应用作为扩展程序。 Go社区里看起来混合了一些老的C/C++学校***和一些喜欢低水平语言的年轻人。Go语言和社区的领导者固执的相信让人们理解他们的想法是很容易的。同时他们也允许你能快速的评估你接受他们哲学后是有多么的舒适，而且可以发现是否能达到你的预期效果。 Go主要吸引着面向性能和结构体系的开发者。他们想要轻易的实现并发，要达到C的执行速度，也要达到Python/Ruby的开发速度。他们不想在找一个新的有趣的语言，他们需要一个坚定的妥协。 技术驱动理念 技术的选择会受到理念的影响。你需要清楚而谨慎地权衡你选用的技术是否与企业的价值观一致。做出正确的决定有助于你从技术细节的纠缠中摆脱出来，拥有更多投入商务运作的时间。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！