私はずっと頑張って、しかしどうしてやはりこのようにしますか。自分で問題を探します！

 ――　私はずっと頑張って、しかしどうしてやはりこのようにしますか。自分で問題を探します！

         随着教授的到来，手上的活也暂告一阶段了。今天我们和教授交流了一天，解决了我们大部分的困惑。最让我感动的是在下午会议结束前，教授说要把这两天的工作分一部分给他，他要帮我们整理数据。他大老远来到济南，今天一整天都没有休息，晚上回宾馆后还要做自己大可不必做的工作。切勿他论，仅就这种认真的态度就已经深深的触动了我。

         我还是要抓紧提高日语水平啊，昨天在晚餐的时候也只是大概能听懂点教授的话，而且语速还不是很快。最丢人的是当时问我了问题，我一紧张怎么也不知道说什么合适了。还是自己口语没有练好，平时想着问答，自己可以对上句子来，但是一对话就完蛋了。不过今天讨论项目的时候听懂了很多，当然有些细节也是理解得很模糊。感觉教授应该有些大阪口音，和标日发音有些出入（完全是感觉）。嗬嗬

        通过今天的会议，在技术上基本没有什么疑问了。遗留的问题：这个项目如何作为产品去分析、开发、销售。这个问题实在是太难搞了。原因：这个项目是拿着预期目标产品往现有的算法、程序上靠，这可能会因为要迁就现有的算法、程序，而改变（误导）预期目标产品的功能。最后可能就成了四不像，该有的功能没有做完善、不需要的功能一大堆、使用了不恰当的表现形式等等。所以我认为还是应该重新作一边需求分析。首先针对于本公司来做，然后再根据行业的不同，提取共同点。这方面的（整合）工作应该非常重要。程序方面肯定要重新开发，工数也是要考虑的一个方面。

        从这个项目上我也感觉到了社内项目的尴尬地位。在公司项目不多、人手充足的时候，会调拨所有的空闲力量来做社内项目，项目多的时候再把这批人（甚至Team）调走做外包项目开发。这样做，当然可以让公司员工接触新技术、得到锻炼、提高水平。但是对于社内项目来说是存在很大隐患的，现在社内OA系统（暂且这么称呼吧）就已经开始暴露出种问题了。大部分都是由于变更开发团队造成的，每个开发者（Team）在接受项目后就直接开始写需求、设计、开发，并没有遵照上一期的开发规约。而且新加入的开发者（Team）水平也是参差不齐，新接手的项目组一般都不会开会讲解一下基本框架和共通一览，现在的系统里同样功能的模块写了很多，可以公用的功能却没有提取共通。也没有什么命名规约了，数据库中表名因为没有加前缀也很混杂。以上原因导致项目的可维护性变差了，也会出现很多隐藏的Bug。现在看来这个项目就像个火药桶，现在是在我手上，不知道传到谁的手上时就会爆炸。嗬嗬

        这些社内项目公司如果要做就应该认真去做，至少要做的专业些，至少要找点专业些的人做。有些社内项目不仅仅是程序开发好了，就一定会有前途。当然也不是懂运营，就一定可以把不专业的网站做起来的。

运营网络服务和经营公司、管理项目、做开发还是有很大区别的。（个人观点）