机房合作（二）：我怎样做组长（编码本身不重要）

导读：我成为了组长，真正的感到了压力。好不容易才把图画完，然后文档初步整理完毕。然后，就在SVN上，上传了资料，设置好了每个人的权限。那时候，我以为编码，是整个项目中，最为重要的。但，其实不是。

一、编码的时机是？

之前，一直没有注意这个问题。在我看来，当我把文档写好，代码框架弄好，把一些其他的文档整理好，就可以写代码。但经过实践，这些是远远不够的。

三军未动，粮草先行。行军打仗，第一步绝不会是什么确立阵法，安排攻打哪里。肯定是粮草的问题，粮草保障是将士，尤其是将军，最为重视的。那么，在一个项目的完成中，什么又是项目系统的保障呢？作为一个组长，我又该关心重视什么呢？

1，编码规范

那天，我向九期一个师哥请教问题，我说，作为一个组长，什么时候，我可以让我的组员写代码。我把文档整理好了，图也画好了，上传了一份编码规范，这样可以开始了吗？其实，我真的以为，我做的很完善了，在这个时候开始，真的就可以了。但是师哥说：在你的小组没有确立好编码规范，组员没有阅读或者掌握组内编码规范时，谁都不可以动代码。注释，=左右有无空格，变量作用域等的限制，命名规范等，都得全部确立好。只要组员没有看过编码规范，代码就不能给他。

而且，师哥还特别指出一个问题，组长上传了代码规范，而再没有做出任何说明，组员是很有可能不会去阅读的。还有可能因为文档太多太长，根本不愿意或者无法确认小组内必须规范的东西。

这些，我开始都做得不好。后来，及时的发邮件，进行了补救。

2，编码工具

这个是我问师哥另一个问题的时候，反应出来的。就是我上传的代码框架，我都是先在我的电脑上，先测试成功生成才上传的，解决方案，DLL文件，全都能生成。但我就是不明白，为什么组员下载后，就会爆出一些问题。师哥先给我说了一下，直接引用和间接引用的问题。那时候突然明白了，为什么要将D层的东西保存到U层下去。然后，就给我说了，还有可能是编码工具不统一导致的。

从设计模式开始，大家都装上了VS，那时候，我根本没有考虑到编码工具统一的问题。写代码前，除了编码规范，还有一个也得确认统一。那就是编码工具。尽管大家都是用的VS，但很有可能因为版本不一样，而报出一些问题。编码工具的版本，.net framework 的版本，以及编码工具中需要的一些基本配置设置，都得先统一。

3，管理工具

机房合作用到的工具，需要特别说明的，就属于SVN了。作为组长先得上传代码框架及相应文档。在SVN上建立好相应的文件夹，然后给组员分配好各自的权限。我以为只要自己弄好就可以了。后来师哥告诉我，我还得确认组员也知道关于这个软件的应用。他们写好的代码怎样上传，怎样下载等等。项目的管理工具，也得统一，然后，还得会用。

二、组长能做什么？

师哥、师姐都说我有点软弱，我也承认，真的。就只是编码任务分配的问题，我就请教了3个师姐。我一直游移不定，最后一个师姐问我为什么的时候，我说：我怕他们不愿意写，对这个分配有意见。然后他们就说我：你是组长，你可以考虑实际情况协调分配，但最后，还是你说了算。那要是你去工作，老板就分给你那个任务，你能不干吗？

我狠不下心，或者说我拿不出组长的气势来，还反应在另一个方面。

由于各种原因，项目的进度一直跟不上。我又拉不下脸去催，然后，在分享苦恼的时候，我又被说了 这个问题。说：合作项目，不是一个人的事儿，不能因为哪一个人的情绪、进度，就让整个团队的效率降下来。你身为组长，就是宏观把控的，你上面不着急不紧跟，你还能指着下面的人怎么样呢？然后，我又不怕死的说了一句：可能别人真的是有事儿耽搁了呢？我这样会不会催的太急。然后的然后，师姐就。。。。。。。。。。。。后来说了一句：就怕组员找借口，我就不懂，你这个组长怎么也为他们找借口呢！

三、组长应该做什么？

1，统一编码环境

这样做的好处是：环境统一，那么，小组成员开发的东西，在融合中，错误会少很多。如果有报错，需要考虑的因素，也能减少很多。其实，我后来在想，会不会有时候，为了小组合作开发一个东西，连系统、连电脑都得统一呢？确立编码规范，会让代码看起来很整洁干净。调错的时候，也能很好的修改。

2，把握工时

作为一个组长，一定得紧跟项目进度。后来想想，师姐说的也真对。项目已经建立了，那么就得保证这个项目的完成效率。组长就是一个宏观把握的人，如果组长就特别懒散，那下面的人也就不会太勤快。俗话说的好：跟着好人学好人，跟着。。。。。。。。。

3，分析工时

我觉得这个也很重要，如果进度慢了，那么到底是什么原因导致的，可以从哪些方面去改善。如果进度快了，那么，到底是什么原因促使的，项目是不是按原型实施的？这些都得考虑。我觉得考虑这些因素，可以在下一次的组建中，更好的去实现去完成项目。

4，分析项目

这个是重点，项目的建立，首先得对它进行分析。这个在文档那里，反应出来的是可行性分析。这里我要说的是：确立工时的分析。工时的确立，得分析项目的大小，技术要点、难点。攻克难点需要多久，构建需要多久，实现需要多久，成员的能力大小等，都得分析。

这个体会，是在项目需要延期的时候，我不知道要延多久，那时候师傅帮助分析的。后来想想，这个真的很重要。一个项目应该为时多长，绝不是凭哪一个人的意愿而定的，取决于客观事实。

四、个人感受

真的感到很受挫，但我会继续努力。小组的合作走到今天，在这个过程中出现的一些问题，身为组长的我当负全责。进度的问题，代码报错的问题等等，作为组长都有逃不开的责任。

组长应该总揽大局全局，这一点，我也没有做好。我总想着好好说说，好好做就可以了。但有时候真的觉得，自己很天真。我终于明白，当一个组长，或者说是作为一个管理者、领导者，和作为一个下面的人，她所需要考虑的事，她所需要承担的责任，真的不一样。

在最下面的人，或者说管理的人比较少的时候，可以偷懒，可以仁慈，可以照顾每一个的感受。但当你的位置比较高，下面有很多人，依靠你的决定去做事的时候。那就必须得慎重，必须不能仁慈，必须照顾大多数人，必须把握全局。

尽管，我现在做的不够好；尽管，我现在走的很艰辛。但，我不会放弃，我要做管理者，我要做领导。我渴望被需要，是的，我从没有这么强烈的渴望过，我渴望被需要，我渴望被很多很多人需要。加油，何下下同学！