技术团队内部工具的选型与评估

不管技术团队规模如何,总要在内部用一些工具来支撑日常工作。这些工具的选择会影响整个团队的效率,不可不慎重。如何做这类产品的评估与选型?每个人都会有自己的方式,这里说说我在丁香园技术团队遇到类似场景的时候,一般会参考的几个维度和评估方法。

活跃分析

目前来看,Google Trends 是个不错的分析产品活跃度的工具,只是有些关键词选择需要注意一下,不要迷惑于表面的数据。

产品特性

一般来说,WikiPedia 的对同类产品的功能比较是非常详尽的。如果是一个相对陌生的产品,无论如何要看一下。真的佩服这些编辑者的水磨功夫,相比之下,国内的有些类似网站,没办法看。

主观评价

通过 Twitter 进行提问,可以收集到很多技术同行的反馈与评价。另外,如果没有候选产品,通过 Twitter 也可以征集产品列表,前提是平时要有不错的互动。

通过搜索引擎可能会找到一些评测文章,一定要注意各自的场景和团队规模以及技术风格,一般来说,此类文章参考价值不是很大。

国外技术人员接受程度

参考一些问答网站,比如 Stack Overflow 的讨论,一些产品的优缺点,几乎都会涉及到。

国内技术人员接受程度

通过新浪微博进行关键词搜索可以基本获知国内技术人员对某技术或者产品的使用与接受程度。比如,搜索一下 “Trac” 这个话题看看。

多方面沟通

尊重内部同事意见与建议,咨询一下更大规模的团队负责人的经验。有句话说得好,”听多数人的意见,和少数人商量,自己做决定”,对于这个场景,也是适合的。

我吸取的一个教训是要让相关的同事有”知情权”,避免黑箱操作。

选择与风险

团队负责人做最后的抉择,并且承担后续风险。如果经过一段时间,证实判断有问题,别硬着头皮往死胡同走,承认错误,尽快调整。

工具用不好或是不好用,团队效率可能会骤降许多,不得不重视。类似的惨痛教训还是不少的。

没错,我说的没有什么新奇的内容,都是常识。有时间我再改改。

EOF

此文作者:, 位于 Startup 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

7 thoughts on “技术团队内部工具的选型与评估

  1. Jeremy

    在内部协作,如文档共享、知识点积累、难点讨论等上有什么好的工具呢?感谢!

    Reply
  2. joe

    是应该再改改,例如没有写如何评估
    选取xxx工具作为团队内部工具,听取wiki、twitter、Stack Overflow、google group是外部评价,内部认知度和评价也是一方面(员工并不总是白纸一张,同样类似的工具可能都用过)。
    最怕的是选了但没有执行力。例如使用eclipse还是ultraedit作为主IDE可以下放到个人,但是缩进规范如果定死是1Tab而不是4空格,那么就请自己在自己的IDE里配置。或者每次都identity工具格式一下才准提交代码。
    代码跟踪工具,更加需要有执行力,否则工具配置搭建在那里了没有人用,每个人都在自己的calendar或blog上写自己今天发现或者fix了什么什么怪问题,那就悲剧了呀

    Reply
  3. 白开水

    不清楚为什么弄这么复杂
    项目的BUG提交或者开发的新特性,直接在用SVN commit代码的时候,加到log上不就完事了吗?早上过来的时候,up一下代码,然后看些别人的FIX,和feature就可以了啊
    项目的协同,找几个牛人,每个人分一大块。
    然后一些工作的安排和感想,用google docs,写一块,然后大家分开编辑不就完事了?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *