原帖
@LikeCode
你既然未工作, 说实话你的体会可能就是错的. 代码很多时候就已经是最好的设计. 纸面工作, 最大的作用是交流,
只有你在相当大的一个组织里, 如果不做适当的文档, 交流成本远远大于设计+编码的成本的时候, 文档才有相当大的重要性.
程序员半兼职设计不是什么了不起的事, 大多数设计和具体工作挂钩也比较紧密, 程序员完全没有自主权才成问题. 编码和民工的工作还是有区别的.
你
在课程上学到的那些说法, 和所谓的体会, 其实往往和实际工作差别很大的. 这和环境有关. 如果在现实中的一个团队,
大多数人和你课程设计上的同学水平相仿的话, 你说的情况是必然的结果, 那么考虑到团队的这种水平, 那个当头儿的就要做更多的工作.
但是如果是一个都有相当经验的团队, 找准设计的层次就很重要; 往往头儿只要做一个适当粒度的划分, 确保划分结果之间的交互的合理性, 就足够了.
@金色海洋（jyk）
我
觉得主要是个度的问题. 感觉老兄你以前挺灵活的啊, 不是让大家的博客影响了吧. 你说的8/2, 不见得8就是你一个人包办的,
更多的这个原则是说代码在全部设计+编码人员的全部工作量里所占的比例, 而上层有上层的设计, 具体到某一划分, 内部也应自有其设计,
这个设计让具体工作的人来把握, 往往有更好的效果. 我觉得你可以试试将更多的工作下放下去, 如果做编码工作的人已经有一定经验,
还算靠的住的话. 你只要告诉他, 你要的结果是什么就可以了.
@jillzhang
嗯, 你说的这是一个关键问题, 在我去年的团队中深受其苦.
这里面有一个深切的矛盾:
齐全的文档和制度, 整体成本会大大上升, 由于自顶而下, 对文档中无法明确要求从而下面编码人员可以做决定的事情, 肮脏的角落就容易被忽略.
所谓的敏捷开发(其实我不喜欢这类的忽悠), 对团队人员的主动性要求就高. 其实真的不是水平的问题, 就是团队里每个人愿意下多大功夫的问题.
我觉得这才是真正考较设计人员或者是负责人的角色(往往是同一人)的地方: 应该找到一个停止的地方, 程序员的工作是可以量化和考核的, 同时避免过分加大设计人员身上分配的事情而导致的各种各样的额外消耗和隐藏的漏洞.
其
实一说到团队, 就是人的工作, 人事就是首要问题. 所以我更赞成的一个方式是: 放权是一个过程. 毕竟大多数编码人员都可以逐渐变得富有经验,
至少在某一个范围内, 你可以逐渐的对他放心, 而这个范围也会不断加大. 但这有一个前提条件: 你有正确的人, 你能以正确的方法对待这些人.
最后这个问题, 往往是被忽略的, 我过去也做得糟糕的要命, 而且有曲折.
最
早的时候我因为水平不够, 带的程序员面试进来, 为了让他们能尽量分担工作, 实际上选择的做法是让他们的工作相对的独立. 我要求什么呢?
我让人把界面做好, 把每个界面上的元素的交互定好, 你做出的东西就必须是这样, 而且我会事先提醒一下可能的变化;
对于不直观的部分也尽量按*需求和业务*(而不是设计的合理性)划分的完整, 模块的大体思路给出来, 较为严格的告诉他们需要输入什么,
输出什么定好, 剩下的你爱怎么做怎么做. 你要是碰见问题需要花费时间, 那你来找我, 我把这个问题给粗略的解决一下, 剩下的你去完善.
这属于一个垂直的划分, 最不容易出问题.
是的, 这里头有风险, 如果他的这一块做烂了, 也许整个项目就完蛋了.
可是这个风险是要冒的, 因为是公司选择了他们. 这在招人的时候就定了, 我们这些技术负责人不可能人为的消除这个风险, 而不花费大量的代价.
我发现招来的程序员, 只要待遇恰当, 这样较为的垂直划分, 会增强他们自己的责任感, 因为决定是他自己作出的;
相反如果是某个细致分配的小模块, 即使依仗测试, 也不是个愉快的过程: 应付过测试, 每个人都认为工作结束了. 当新的变化产生时,
问题可能一下子暴露很多, 这时候每个人都有借口: 对于设计人员来说, 认为编码人员不能快速的适应新变化是技巧不足(比如原来的实现过于死板);
对于编码人员来说, 你设计人员朝三暮四(无论是不是来自于合理需求), 我代码又不是变出来的, 多花时间您就等着吧.
后来我水平高了, 可以划分的比较细致, 把一些工作变成纯粹的体力工作, 把程序员当作代码生成器, 也舒服过一阵子. 这阶段的项目出现的失败, 主要是我自己创业以后选择的项目不靠谱导致的失败.
但
是在创业以后这半边, 我自己自食其果了: 因为我的新项目整体设计是核心, 而部分的设计也很重要, 设计又根据我的想法不断变化,
我根本没法稳定接口让别人完成接口下面的工作. 同时, 把设计的工作变为较大粒度, 然后把小粒度的设计分配出去也是不合适的:
我的合作者没有得到成长的机会, 根本没法快速理解我的思路并分担或者配合我的工作, 这样要么是给他们担子, 进度就没法保证,
要么就是我一人完成工作, 他们根本没事可做.
这里头有一个可以思考的地方, 很多人都和我一样, 个人水平提高了,
带领的团队质量反而变差了. 但是很多人的认识方法是, 那是因为我还做的不够好. 其实不是这样的, 我觉得我们要反思过去快乐的日子的合理性,
并且承认它. 现在我体会到, 其实我现在做的这种框架式的, 创新型的工作, 如果想提高效率, 必须所有人都具有相当的水平, 并且愿意下力气.
任何一种过程方法, 都解决不了我的难题. 我觉得作为技术组织, 总有一天会进行更高层次的提升才能活, 而不被淘汰. 那时候, 你的团队,
如果都是人肉代码生成器的话, 他们跟的上吗?
不是说更高级的设计知识和方式, 是大而无用的屠龙术,
如果我没有这些方面的认识, 我都不可能有构思现在框架和产品的水平. 而是说, 培养人, 不断提升整个链条上每个环节能发挥的价值,
才是最重要的事情. 如果我坚持我最初的做法, 在详细观察每个人的特点和担当的基础上,
有意识的通过逐渐加大新团队中伙伴的工作范围(从编码->设计)和职责, 让每个人可以调整到他们能够达到的比较高的一个水平,
那么我的团队就照样可以写出漂亮的程序, 获得在我只将程序员当作编码员时的一切好处, 同时不必承受自顶而下的更高成本和一切其它恶果.
那么这样我拿什么去交换呢? 我会付出了更多的精力, 去提升别人的价值. 我认为这是值得的: 因为我不是IBM或者华为, 铁打的营盘流水的兵; 我身边的每一个人都对彼此很重要, 不是吗?
@金色海洋（jyk）
不是说什么都是你的责任, 其实主要是几点:
1. 你们公司没有拿出应该拿出的成本, 比如付更多的工资雇佣更好的配合人员.
2. 咱们不要说什么设计人员或者项目负责人这些词, 也许你还不适合当一个头儿, 或者你们公司虽然让你做设计, 却没有给你这个"头儿"的角色, 从而你无法认识或实行到一个"头儿"该做的.
3.
思路特别在很多情况下就是乱, 这一点是你自己的问题. 代码大全等很多书里讽刺了代码灵活富于机巧的写程序方式.
但是标准的面向对象思想的程序也不见得更好一些, 因为你的思路如果是有益的, 面向对象只是把它们整理的更好, 而不是说你就不能用这些思路了,
这时候别人能不能看懂, 思路的复杂性还会照样存在, 这时别人无法跟进, 参照1.
4. 水平高低不同是客观存在的, 这需要你和公司共同的付出, 这即使是一个困难, 也是要你们去解决的, 参照2.
@金色海洋（jyk）
不是说当头儿就不能写代码, 关键是你的工作内容往往决定了你可能的角色. 比如咱们是一个游戏的主程序师, 再带2~3个配合的程序员, 咱们肯定要写代码, 不然咱们在过去实践中积攒的经验全都浪费掉?(没干过什么活, 就因为做人和运气就当头儿的那种人例外, 不过不是说这种人就一定对项目无益) 主要是看核心的难度在哪里. 有时候核心难度比较少的分布在具体实现上, 那么当头儿的就未必要亲自动手了.
但是人的问题是负责人必须要关注的, 只要我们需要别人, 我们就必须正视这个问题.