Trello + 1

除了好用外，使用Trello的唯一原因：所有的数据都在AWS上面！

@FinalAir
没合同的话，挺麻烦的... 另外，我看你的朋友貌似也不太懂技术，这样“更加危险”。
关于合同周期，除非你做过类似的项目，或者你非常能清晰估算时间，否则再没有合同的基础上谈两个月的项目周期，延期的概率很高。

PS：我吃过这样的亏，初做SOHO的时候，有个哥们找我做个简单的项目，预计周期1个月，也怪我“接包经验不足”，结果项目（断断续续）拖了半年多。最后，赔钱肯定没有了，哥们那边也不好交代。

我不是你，我的哥们也不是你的哥们，所以我说的事情不代表也发生在你的身上，只是一个忠告，经验和建议。 :)

--
说一下我现在定价的策略：
- 肯定是我做过的（类似）项目和熟悉的技术方案，我绝不接不熟悉的项目。（宁可不挣这个钱）
- 需求必须要明确。
- 甲方对UI的要求必须明确。
- 后期是否要长期维护。
- 对于著作权（代码、文档的归属）甲方是否有特殊要求。（比如：甲方需要代码有明确的文档，是否方便其他团队二次开发等）
- 签委派开发合同 和 项目/代码保密合同。
- 编码前敲定需求。（编码中可以细调，但要要让甲方有个节制。）

然后根据上面的要点给甲方做个精细预算（精细到每人/每天 or 每人月等）。
貌似可能会觉得啰嗦点，但这样能保证甲乙双方的利益/职责最大化。

报价原则：你赚了，他不陪。
另外，还要看甲方是什么“身家”。如果身家厚，自然价高。

如果你不是专门接外包的话，这个项目对你有非金钱上的帮助，价格差不多就行，反正你也不指它糊口。
反之，价格一定不要被压低，这样很贬身价，对你以后的接包有影响。

最后，熟人外包存在一定的风险，毕竟我们是人情社会，不是信用社会，很多东西前期看很简单，大家说两句就行，但后期一旦出现问题，就会各种推诿。（经验看一般倒霉的都是乙方）

所以，在熟悉甲方脾气秉性的前提下，尽量事前合同化。先君子，再哥们！

@horizon
后者...

额，同为New Tab for Chrome extension 的开发者，刚刚试用了一下，UI很棒，功能丰富，特来共勉一下，加油，希望能长期坚持下去！

只是Effect在老机器下较慢，新机器完全木有问题。（希望可以照顾到老机器）
尤其是能为这个产品设定一个独立域名，其它不说，至少非常有诚意！

Infinity与我开发的New Tab，在思路上完全是相反的，前者全面，后者简约。很有意思 :)
PS：在这里就不提我做的New Tab的名字了，避免广告嫌疑。 ^_^

Cool，俺也是东北地，算半个老乡~
在哈尔滨还没见到这么酷的公司，发现没有人回复，支持一下老乡！

建议在招聘的时候，写点不同的东西，如：
我们是谁？我们在干什么？薪资，我们的优势，加班情况，年假周期。（晒福利，晒妹子，晒工作装备啥的 ^_^ ）
PS：虽然在你们的网站写了，但还是意见写到招聘里面...

补充下...
- 价格只要是甲方能接受，就从了吧...毕竟还要让乙方挣钱 (￣▽￣")
- 一次性短期外包是个良心活，如果双方不认识的话，价格的高低绝对会影响代码的质量！（甚至沟通时的心情...）
- 最好口头跟乙方明确下，是否有二次外包的情况。（尤其是设计，很多外包都有可能把这块再二次外包出去... 要知道，好的Designer要更难找！:-o ）
- 建议签保密合同。（鉴于国内的知识产权意识，这种合同只防君子，但聊胜于无）
- 代码归属要明确。（很多不良乙方，会找这方面的漏洞，甚至发生一套代码卖N家的情况，游戏行业尤慎）

好吧…… 如果能有匿名评论就好了 ╮(╯-╰)╭

作为一个长期做SOHO的人来看『甲方需求』，大概有这几个问题：

- 不要用任何语焉不详的词，如『简单』，前面已经有V友说了，任何简单都意味着『很麻烦』。
- 作为甲方需求，这也忒不详细了，一旦涉及到了不详细，三周的工作时间如何评估？
- 作为乙方，一旦遇到了语焉不详的需求，这就是坑啊！（一入深坑悔3年...）所以，从我的角度看，乙方对三周无任何异议是很危险的『信号』。
- 甲方没有UI和UE的具体要求，这也是坑。（这里很容易产生分歧，功能是『死』的，但设计是『活』的，如何量化？）
- 甲乙双方是否在一个城市？编码前的沟通和需求的明确，需要花费大量时间，这点作为甲乙双方的话，都应该清楚。（尤其是编码前的一切时间都不应该计算在三周内...）
- 后期维护包括什么？Update？Debug？还是？后期维护这块也很麻烦，甲方应该清晰描述。

LZ发到这里公开讨论报价的问题，不怕乙方知道么？ :-)

PS：如果我是乙方，我不敢贸然报价、预估时间。（当然，前提是以LZ发的内容为标准，如果有我不知道的情况，另当别论！）仅此建议~

@Gauin
啊，Sorry，貌似混乱了... 请无视PS的回复...

@Gauin
呃，因为我也做SOHO，恰好用过『番茄土豆』，所以对你们的产品很感兴趣。
看到这个招聘，以及『九零后』的限制，所以来说说 :)

假设因为工资低而招『九零后』的话，大可不必。
你们的工作时间很灵活，相对比较少，这就是优势，尤其对SOHO，其实没必要『底气不足』。


PS：你们的招聘方向与我不太对口。不过，可以微博私信聊聊啥的 :)

本来很感兴趣，拉到最后发现 - 『九零后』...
为啥要加上标签呢？
PS：虽然工资不高，但工作时间也相对较少... 万一有合适的非九零后呢...

代码都是给人（Developer）看的吧，所以肯定要以看懂为目的性，所以才有那么多的编码规约。

- 如果你写的代码只是少数人看的话，只要这几个人达成了默契，那么就算是写成天书也没问题。（即便写的不好，大不了，另外的人，吼一嗓子，然后你可以过去帮他解答...）

- 如果你写的代码需要持久、多人反复的迭代和更新。如果你写成天书，完全有可能会造成，其它人无法读懂，最糟的情况是需要重写；最好的情况也只能不理会这块逻辑，编写另外的代码来维护这块无法看到的代码。（出来混，迟早要还技术债务的...）

一个良性，条理/逻辑清晰、易读的代码，其实是衡量一个人编程水平的标准。（我尤其讨厌，卖弄自己『本事』，把代码写的超复杂的人...）

LZ，我也是这类工具的爱好者。发现没人回复，我来回复 :)
试用了一下，发现有些像高级版的Workflowy。

使用的过程中，感谢有些卡顿。（只是感觉上...）
比如：『光标停留在某一Item上，延时几秒后自动高亮』这个动作，给人的感觉就是卡了一下，所以这里可以设置为Fade In效果比较好些。

还可以加入Import功能，毕竟这类的工具对用户都有粘性，迁移成本越小越好。

另外，不知道LZ使用过Moo.do么？从我的体验感觉比Workflowy好些，虽然我已经使用Workflowy有一段时间了。

PS：Tutorial的方式很赞！！！

作为一个已经SOHO很多年的人，必须要鼓励一下！
PS：主页 > 设置 > 头像 也忒大了点...

@hoogle
看成 “考虑路飞 当 上海贼王 在买。。”...