初入公司，如何面对一个全新的项目？

最新推荐文章于 2022-06-18 17:13:10 发布

黔家仔

最新推荐文章于 2022-06-18 17:13:10 发布

阅读量863

点赞数 1

分类专栏：小朋友故事

本文链接：https://blog.csdn.net/sjdjjd6466446/article/details/110879720

版权

小朋友故事专栏收录该内容

4 篇文章 0 订阅

订阅专栏

案例项目背景: XXX智慧安全服务系统项目
当拿到一个于我自己而言全新的项目定制，我并没有捉急着前往代码大军的营地走马观花,也没有采取向天下散布英雄集结令求援救助。相反，第一时间，我只身打马，通过沟通和搜索找到了项目所必需的东西(定制需求单，源代码, 和其它相关信息)

头阵：新建唯一可识别一个目录，把搜集到的相关文件和资料进行存放。

我大体分为以下三类资料（不同公司对于流程中的名称不一，但里子含义都是一样的哈）：

1.需求单

我对这个单子的理解就是：根源。

怎么说呢？简单说，就是有了需求之后才有后来的一切呗。只有用户需要了，那么我们才能和客户“发生关系”嘛。天下熙熙皆为利来，天下攘攘皆为利往。只有同时涉及了客户和我们的利益了，那么我们做的东西才存在意义，衍生的各种关系也才能由于利益交织在一起。
在这里插入图片描述
单子里我们能够查看到用户最原始的需求，追踪到最初的起点，就像宇宙大爆炸的奇点一样。而且，更有幸的是, 这个单子里还有项目经理对其的评估理解，最为重要的是还给你提供了需求问题的解决方案 (一旦你能够达到站在项目评估人的角度，真正理解他所给出的解决方案，那么基本上所有问题就已经解决一半了。如此可谓知其所以然了，接下来就是实操了。)

2.源代码

这是每个项目定制提上流程开发单的时候就一定有的, 需要拿到项目定制源代码的svn路径（或者git路径）, 然后拉取分支, 随后解决问题的真实战场就在其内了。
在这里插入图片描述
由于这才是落实具体想法和问题解决的载体, 所以一定要确保自己所获取到的代码完整, 还有自己所选择的代码的模块(版本信息)万无一失。（一些细节问题，在一开始就要将其遏制，否则必将蚁穴溃堤。只有经历过雪崩的人，才真正明白每一片雪花的分量都是不能低估的）

3.其它相关信息

一开始, 我拿到项目需求单，通过了解，明确是在我的工作范畴内，能较好解决它，所以，我接下来就开始了我的寻宝之路。
在这里插入图片描述
我打开了公司的wiki，直接搜索查询我项目定制所在大背景相关的信息（解决问题我喜欢采取Top-Down的方式进行, 先在体系概念的层面对高层次的抽象和概念进行熟悉，先知其然，然后再知其所以然。）先采取宏观上对整个“战略”进行理解,然后再逐步进入到具体的战术战斗。如果不理解战略，那无论战术再怎么完美，也不过只是重蹈 ”南辕北辙” 的历史旧辄罢了。

对于查到的项目所处大背景信息，我进行通篇详略适合的阅读。（过程艰辛，你们知道的，眼干舌燥，但我做到了，嘿嘿，真棒~。）

4. 突然的自我

最好的工具，并不是无所不能的适用于方方面面，而应该是在属于它自己的领域能够一枝独秀。于72行，人工又何尝不是如此。
如果把项目定制喻作修炼打磨一件适应于用户环境需求的工具，那么我们必须应该知道的，就是用户究竟是在什么样的环境和情景下使用该工具。（突然间想要自我表达一下，也还是和以下谈到的话题有关的哈，懂得懂了）

我在需求单中了解到用户所处的真实环境之后，我用自己寻找到的资源进行最大努力地向用户真实环境靠近，真实场景模拟，体会用户的需求。(我拿到了XXX对内的测试平台, 而且该平台上也有关于ZZZ的服务组件-YYY) 拿着这个平台，我对照着wiki上和自己向同事沟通得到的有关ZZZ的资料，进一步进行操作理解。

期间, 我多次怀疑这项定制自己无法完成, 而且这个工作似乎已经超出我的工作范畴。我还固执地认为是项目经理在评估时候就做出了错误的判断, 并给出了错误的解决方案。我一度地想要和项目经理进行沟通，但我总觉得好像什么地方不对劲（那就是我过于自信，仅仅基于一小点的理解就局限地否定了他人，我意识到问题所在，然后我决定再多给自己一定时间，哪怕我是对的，我也应该做到有理有据，而不是所谓的我以为。）