用了多少时间吗？”

我坚持自己的观点：“但我们是站在巨人的肩膀上，有很多东西可以直接参考和借鉴，所以我认为基础框架应该能够更快地搭建完成。如果有经验的程序员，他们甚至可以直接参照现有的产品开始编写代码。而不是所有人的眼睛一直盯着产品部门何时能给你们提供产品原型。”

这位同事听我这么说，愤怒地拂袖而去，直接走向老板的办公室。我们的会议也因此不欢而散，其他同事也对我投来了不满的目光。但我依然坚持自己的观点，认为如果由我接手这个项目，凭借几个熟练的开发人员，最多只需要三个月的时间就可以让系统上线。这大概就是我长期在小公司工作所形成的快节奏思维方式，与大公司的节奏存在明显的差异。

回到产品部门后，我感受到了同事们异样的目光。他们既好奇我的身份和背景，又对我的做事风格感到不解。一位同事好奇地询问我平时做产品设计时使用的软件。我尴尬地发现，自己对于产品经理的专用软件一无所知。于是，我虚心地向他请教，并很快学会了使用他们推荐的axure软件。这款软件对我来说并不复杂，半天的时间就让我掌握了基本的操作。

然而，当我打开离职同事的设计文件时，我发现整体的设计思路存在问题。作为一个有多年开发经验的程序员，我深知这样的设计会给开发部门带来很大的困扰。同时，我也发现了公司在产品开发过程中存在的一些问题。例如，产品经理们普遍缺乏编程和项目经验，这使得他们在与开发和美术部门沟通时显得力不从心。这种情况导致了开发部门和美术部门对产品部门的轻视和不满。

通过更深入的观察和交流，我逐渐揭开了产品部门神秘的面纱。令我吃惊的是，这个部门的产品经理们，几乎都是刚毕业不久的大学生。他们虽然充满朝气和热情，但对于系统设计和软件开发流程的了解却近乎为零。更令我意外的是，其中还有几位是从建筑行业转行过来的，对于it行业的认知完全是一片空白。

这样的团队构成，无疑给产品部门的工作带来了巨大的挑战。他们在面对复杂的系统设计和软件开发任务时，往往感到手足无措，不知从何下手。这也解释了为什么开发部门一直等待产品原型，却始终未能如愿。这些产品经理们由于缺乏经验和专业知识，难以在短时间内交出令人满意的设计方案。

同时，我也明白了为什么之前的那位产品经理会选择离职。面对一个看似简单的系统设计任务，他却因为缺乏经验和技能而无法完成，这无疑给他带来了巨大的压力和挫败感。他的离职，并不是因为任务本身有多难，而是因为他无法胜任这项工作。

在我看来，产品部门应该是一个项目的核心和引领者，而不是一个附属品。然而，由于目前产品经理们的经验和能力不足，导致了这个角色的错位。这让我感到非常矛盾和困惑。同时，我也意识到自己在融入这个新环境的过程中还需要付出更多的努力和时间。