这是一个创建于 3473 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们是程序员客栈 http://proginn.com 团队的。现在网站第一步做的是程序员展示。后一步我们要为程序员增加收入而努力，直接带来利益。实践探索了这么久，觉得远程工作是值得做的一件事情。即能效率高于招聘快速完成开发者与项目的对接。又给程序员增加收入多了一种可能性，甚至是生活选择、话语权。
当然我们深知远程工作这件事情是非常艰难的探索。
之前，由于政府的鼓吹，创业进入了类似“上山下乡”的癫狂状态，满大街都是想要改变世界的创业者，贩卖创业的咖啡厅、孵化器也越来越多。CEO一多，干具体活的人自然不够了，于是外包一片红火。传统行业创业者的加入，更把创业外包的需求推向空前。看到这种大环境，所以头脑发热，程序员客栈的第一版我们做的就是“外包”。
之后才慢慢发现“外包根本不是个方向”，加上猪八戒类似这样平台一直的扰乱混淆。外包基本已经变成了一个甲方无理要求、乙方坑蒙拐骗、双方相互扯皮、市场没有赢家的局面。
于是收手做了程序员展示，再寻求机会。经过这么多个的项目经验沉淀和市场摸底预估。我们认为“远程工作”是可行的。所以后一步，我们会做程序员的远程工作（远程协作）。现在产品论证和原型已经基本完成。
我们认为远程工作有三个重点：
1. 快速补齐紧缺技能。建议核心开发自己做，远程工作第一步就是把个人开发者对接到一个团队，补齐紧缺的技能。这样才能保证质量。
2. MVP（最小可行产品），逐步开放分类，加强过程管理。当前只开放“前端”、“iOS”、“Android”、“设计”几个分类的需求。争取做到线下验证一个，线上开放一个。
3. 平台优质的服务：交易担保、黑名单、签约机制。谁不靠谱就永远拉黑谁，谁优先专业我们推荐谁。
所有的制度规则，都是为了让正确的人到来，让合适的人留下。
还有三个亮点：
1、不用担心技能不全，你只做你最擅长最优秀的部分，加入到一个远程团队，享受团队开发的氛围和乐趣。
2、再也不用压价竞标，我们会学习Uber的模式直接派单。
3、平台估计，成立“报价专业委员会” 价格按工资、能力在基准价基础之下浮动，我们努力做到收益高于你的工资。
最终目的，对于靠谱的开发者我们希望你只管开开心心写代码，我们会为你做开发之外的其他一切工作，当好程序员的经济人。
现在需要做的工作之一是成立“报价专业委员会”，逐步确定价格，定价是一个过程，希望大家加入帮助讨论：
1. 对开放的“设计”、“前端”、“iOS”、“Android”几个分类做好定价（基准价）
设计
需求文档（原型设计） -> 静态设计
Android端
静态设计 + 后端接口齐全 -> Android开发
iOS端
静态设计 + 后端接口齐全 -> iOS开发
web前端
静态设计 + 后端齐全 -> web前端开发
2. 确定不同水平开发者的价格（调价因子）
3. 确定其他调价因子
微信群求加入
其他探讨请联系：
[email protected]
当然我们深知远程工作这件事情是非常艰难的探索。
之前，由于政府的鼓吹，创业进入了类似“上山下乡”的癫狂状态，满大街都是想要改变世界的创业者，贩卖创业的咖啡厅、孵化器也越来越多。CEO一多，干具体活的人自然不够了，于是外包一片红火。传统行业创业者的加入，更把创业外包的需求推向空前。看到这种大环境，所以头脑发热，程序员客栈的第一版我们做的就是“外包”。
之后才慢慢发现“外包根本不是个方向”，加上猪八戒类似这样平台一直的扰乱混淆。外包基本已经变成了一个甲方无理要求、乙方坑蒙拐骗、双方相互扯皮、市场没有赢家的局面。
于是收手做了程序员展示，再寻求机会。经过这么多个的项目经验沉淀和市场摸底预估。我们认为“远程工作”是可行的。所以后一步，我们会做程序员的远程工作（远程协作）。现在产品论证和原型已经基本完成。
我们认为远程工作有三个重点：
1. 快速补齐紧缺技能。建议核心开发自己做，远程工作第一步就是把个人开发者对接到一个团队，补齐紧缺的技能。这样才能保证质量。
2. MVP（最小可行产品），逐步开放分类，加强过程管理。当前只开放“前端”、“iOS”、“Android”、“设计”几个分类的需求。争取做到线下验证一个，线上开放一个。
3. 平台优质的服务：交易担保、黑名单、签约机制。谁不靠谱就永远拉黑谁，谁优先专业我们推荐谁。
所有的制度规则，都是为了让正确的人到来，让合适的人留下。
还有三个亮点：
1、不用担心技能不全，你只做你最擅长最优秀的部分，加入到一个远程团队，享受团队开发的氛围和乐趣。
2、再也不用压价竞标，我们会学习Uber的模式直接派单。
3、平台估计，成立“报价专业委员会” 价格按工资、能力在基准价基础之下浮动，我们努力做到收益高于你的工资。
最终目的，对于靠谱的开发者我们希望你只管开开心心写代码，我们会为你做开发之外的其他一切工作，当好程序员的经济人。
现在需要做的工作之一是成立“报价专业委员会”，逐步确定价格，定价是一个过程，希望大家加入帮助讨论：
1. 对开放的“设计”、“前端”、“iOS”、“Android”几个分类做好定价（基准价）
设计
需求文档（原型设计） -> 静态设计
Android端
静态设计 + 后端接口齐全 -> Android开发
iOS端
静态设计 + 后端接口齐全 -> iOS开发
web前端
静态设计 + 后端齐全 -> web前端开发
2. 确定不同水平开发者的价格（调价因子）
3. 确定其他调价因子
微信群求加入
其他探讨请联系：
[email protected]
 |
1
jukka 2015-06-27 15:37:54 +08:00
有游戏开发的么。。T_T
|
|
2
jukka 2015-06-27 15:38:09 +08:00
Full stack game developer求加入。
|
 |
3
cho OP @jukka 游戏开发怎么标准化是个问题？希望和你讨论下，游戏里面的策划 原画等环节都是独有的。 现在我们“后端”都不敢开放，因为线下实践失败了，代码质量不过关。
|
 |
4
xionghengheng 2015-06-27 16:31:32 +08:00
感觉掉。。。。
|
 |
5
nonesuccess 2015-06-27 19:07:02 +08:00 via iPhone
有没有javaee相关的。。。
二维码显示已失效 |
 |
6
lijianying10 2015-06-27 19:24:20 +08:00
已经注册，期待有人联系我。
|
|
7
jukka 2015-06-28 06:29:42 +08:00  1
@cho
的确是个问题。对整个游戏产品的外包，国内能做的公司并不多。整个游戏外包行业并不成熟，这也和国内游戏产品互相抄袭可能有一定关系。本人目前在手游行业，就说下手游行业如果要外包，需要哪些工作吧。 先说游戏策划吧，关键在于需求表达清楚（这不是废话吗）。根据游戏类型，游戏策划的文档基本可以套模版写。问题在于就算有模版，也很难只用文字去表达清楚需求，不会写代码的美术不是好策划，要图文并茂才行。说了那么多，其实没什么用。国内游戏基本就是，原创一点点核心玩法，其他成长点抄一套过来，没节操的甚至数值也直接抄，再没节操一点直接反编译，我这里并没有在含沙射影的在说HC。这种前提下，不会有太多创新，所以需求还是明确的（外包给一个团队，抄一个XXX这种多数吧）。先声明并不是说策划没用，no offence，准确的说是国内游戏，对游戏系统策划的要求并不是那么高。扯远了扯远了，说外包，说文档。以前做过索尼的对日外包，文档基本上都是程序员写的，细到astah制作流程图，时序图，类图都有。国内策划虽然有计算机专业出身的，但是并不能写的一手好文档（拿来就能直接写代码的那种文档）。并不是说要求策划文档写到如此专业的程度，但是至少游戏内出现过的“所有名词”都统一这种基本要求，很多策划并不能做到（今天这个东西叫coin，明天叫 gem，后天叫 gold，这种文档你能看懂？今天叫spell，明天叫skill，后天叫skull，当然这是瞎扯） 结论：能有一个原型最好，没有原型文档必须要标准化。 再说美术，可以说美术是游戏开发里面“最稳定”的因素了。除了UI（一会儿单独说），因为一旦游戏风格定了，人设定了。根据质量的要求，原画动作的价格市场上都比较稳定，所以美术外包并不难。 先科普下，一般认为，如果制作人员按照游戏的内容来分类，一部分是做的核心玩法（战斗系统，一般这个系统由主程来写，由于现在大部分手游是短链接，这个功能基本没后端什么事儿，也是比较好外包的部分。所以只要核心玩法定了，这个系统基本不会怎么去改，也不敢去改。PS：个人认为做一个手游最有趣的部分也在这里）。还有一部分就是各种成长点（升级装备，强化装备，培养培养宠物等等，一般工作1年经验的程序员就能胜任了）。 前面也说了，因为策划在产品初期，并不能想好所有的成长点，经常出现这种情况：“国产游戏的一般节奏，XXX游戏上线啦，标杆级产品，有1，2，3，4这些成长点，看起来都能在我现在的游戏里用呢，一拍脑门，程序，美术开会啦，我们0.8版本加1，2，3，4这些功能”。 所以经常出现，“界面推倒了重做，UI风格各种换的尴尬局面。” 而且根据开发的情况，经常会有 UI 各种变的情况。所以并不适合外包 UI（成长点部分的功能。） 结论：除了游戏核心玩法，游戏成长点这里是变化最多的部分，非常不适合外包。 最后来说程序部分。 先说游戏的后端吧，本人在公司里的职位主要是客户端，不过后端也能做一点，讲的不对的地方轻喷。还是先科普，因为网络的原因，端游的长连接并不适合手游，所以大多数手游的服务端基本是一个webapp。技术方案大多是 NGINX + php, OpenResty, apache + php, 数据部分redis/memcached + MySQL，再加一个长连接的聊天服务器，这个选择就更多了，有三方的解决方案，也有自己做的，比如直接用pomelo(Node.js)什么的。服务端做的大多数事情是验证客户端传过来的运算结果和玩家存档。除开三方支付，登陆，聊天这些通用功能。服务端其他的业务逻辑相关的代码，基本都是成长点相关，所以也是属于“需求不稳定”的那一部分。另外根据运营策略（国内一般滚服，海外一般一个大服务器），经常需要做活动，这些外包起来也非常麻烦。 结论：游戏服务端并不适合外包。 再说客户端吧，这个更复杂一点。也是先科普下吧，和做web前端差不多，手游客户端也非常复杂，总结起来就是：1. 开发环境和运行环境很多种（对应web前端就是各种framework和各种浏览器） 2. 开发语言非常多（主流Lua，C++，C#((主要是U3D))，Javascript((算半个主流吧，毕竟H5)) ）3. 再者兼容性和性能，iOS相对简单一点，主要是Android设备类型太多了，各种系统对OpenGL的标准兼容不一样，另外Android设备虽然配置高，但是app运行时的“可用内存”非常不稳定，然而游戏不像一般的app，又对内存（最少还是需要200M+的内存）和性能（至少30fps）非常敏感。所以 “游戏引擎的选择就至关重要！”。市面上主流跨平台U3D, cocos2d-x。还有市场占有并没那么大的libgdx， corona（这个严格说是做app的，做游戏性能并不特别好，简单的游戏可以用）。 好像又扯远了，我为什么要说又呢。说下客户端外包。 先说U3D吧，以U3D为核心开发的游戏，工作流更适合外包。因为U3D制作精良的跨平台编辑器，稍有经验的策划就能做出一个差不多的原型，以此为基础给程序开发，更快的反馈问题和修改，另外U3D的UI部分很稳定，基本都用的NGUI（不像cocos2d-x一个引擎竟然有3套UI框架）？所以对于标准化相对较容易。不足之处在于包稍微偏大（如果是做海外平台，这都不是事儿）。 再说cocos2d-x。cocos2d-x引擎的渲染部分还是很优秀的，除了粒子系统性能糟糕一点，核心渲染系统问题不大。因为借着手游的东风，cocos的发展很快，可能确实是因为太快了，周边工具非常不完善。2D 项目基本还是首选了，因为会的人多，招人方便。然而维护成本并不低，好像又扯远了，继续说外包。个人建议cocos2d-x项目客户端外包最好整包。因为本身引擎是类为单位构建的，并不能以插件的形式改引擎，然而大多数项目有自定义引擎的需求，所以最多引擎和产品不分开，一起改。 结论：游戏的程序外包的确很难，因为是长期维护的事情，并不是一锤子买卖，所以除非是外包对象签订合同的长期合作，不然还是别外包了。 这其实是一篇软文，你们都没看出来吧，233333。 以下是此软文硬广告： -------------------------------------------------- 我们的游戏，www.armorblade.com 现在需要一位有海外经验的运营 ：）。 联系方式：tangyy#armorblade`dot`com |
 |
9
MOsky 2015-06-28 12:23:11 +08:00
扫了加了，我做 iOS 的。
|
 |
10
mianju 2015-06-28 12:25:31 +08:00
网页前端对Safari没优化好> <
|
|
11
MOsky 2015-06-28 12:37:40 +08:00
呃，程序员客栈绑定 GitHub 居然对私有数据要求 Full access 的权限。别啊，这样我只能不绑定了。
|
Select Language