**Think of the development process as a single work day...
想一想一个工作日的开发流畅吧**
Serious things you hear about, before lunch, will get fixed before the day is done. For sure.
Then you might work on something else, with lower priority, for a while.
午休前你听到的严重的事情你在当天就一定会去解决。之后你可能就去做一会儿低优先级的事情
Until the next big problem pops up.
直到下一个严重的问题出现
But, by then, you can’t start on it. Because you can’t get it all the way done, before you have to go home. It’ll have to wait until the next day.
**但是，到那个时候你不可能再去解决他的，因为已经到下班时间了啊！！回家了啊！！！只能明天在搞了啊！！！**(说的这么理直气壮好意思吗。。。)
So, in order to not waste precious time, you squeeze in something else that will fit.
因此，为了不浪费宝贵的时间，你会把另外的事情放在今天完成而不是更高优先级的事情。
This is how our development cycles work. Sometimes we simply can’t start on something and get it fixed, or improved, before the expansion has to ship.
这就是我们的日常开发工作流程。有些时候我们只是不能在扩展包发行前挖新的坑。
(This also illustrates how sometimes things with lower priority get done when some higher prio stuff are left for later.)
这也就是为什么有些低优先级的事情做了，而高优先级的事情反而没做的原因。
**Difficult judgement calls**
**难以判断的建议**
Other bugs or suggestions are more up for debate.
另外的一些bug或是建议都是比较有争议的
Doing something that will make one group of people leap for joy - might seriously anger another group. We have to stay on top of that.
有些事情做了回让一部分玩家欢呼雀跃，同时也会伤害另一部分玩家的感情。那我们只能保持不动。
**The big time-stealers**
**耗时任务**
Not to mention that some requests, like improving AI, is a perpetual job that can’t be rushed.
更不用说有些比如对AI优化的要求是一个不是一朝一夕能完成的长久工程。
As obvious as it is that an area needs work; some things are like hatching an egg. It takes the time it takes. No matter how many bodies you throw on the problem.
很明显这必然是一个需要加工的方面。有些问题就像孵鸡蛋一样，他就是要这么多时间，跟你在这个问题上分配多少人根本没有关系(这点还是同意的，人月神话中讲的也是这个道理)
(Btw, this is how I imagine a Steam Summer Sale going. If Steam was a physical store.)
顺便，如果steam是一个实体商店的话，那么夏季促销差不多就是图中的景象了。。。
**The Breakdown & Estimation process**
**任务细分和预估阶段**
Moving on: Once the design doc is complete… The team takes the design and breaks it down into bite-size tasks for coders, content designers, art, UX-design, sound etc.
继续说吧，当设计文档完成之后，团队会把这个文档分成一个个最小的任务后分配给程序团队，内容设计团队，美术团队，UI设计团队以及音效音乐团队
When we have everything broken down into a list of tasks; we sit down together and “estimate” each task. Giving us an idea of how long the full feature will take to develop, once you add it all together.
当我们把所有任务都分成一个原子任务的清单后，我们一起坐下来"预估"一下每个任务的消耗。这就能给我们一个大概整个扩展需要多久能完成的概念。
**How are deadlines and release-dates determined?**
**死线和预估的发售日期是怎么确定的？**
Paradox has a plan for how many expansions/DLCs we should release per year.
P社队旗下每个游戏都有一个每年发行多少扩展/DLC的计划
HOI4 release dates are determined based on: 1. that plan, 2. how quickly we can reach the desired sell-value of the release, and lastly 3. coordinated with specific dates that our marketing team have selected.
钢4的发行日期取决于
1. 这个计划
2. 我们多久能做足够一个扩展包的内容
3. 和营销组协调发行日期
(More on this subject in next week’s Dev Diary.)
这个部分会在下周的日志中展开讨论
**Can we make the expansion-design happen within the deadline?**
**我们能在死线前做完吗？**
After all features have been estimated; I can figure out if what we want to do is possible within the deadline. With the people at our disposal.
所有的需要做的功能都被预估完之后，我们才能确定这些是不是能够在死线前完成。
If yes: Huzzah!
如果可以的话，万岁！
If not: This is where I have to crush the designer’s hopes and dreams.
如果不能的话，我就不得不让设计师失望了
Splat!
啪！
We need to cut something in order to be able to finish on time.
我们必须砍掉一些内容来在死线前完成！
This is something we discuss and agree on, together. While I gently pat their backs and hand them tissues.
这是我们一起共同决定的，我只是站在团队的背后支持他们，并处理这些问题。
**What gets cut?**
**哪些内容会被砍掉**
When cutting something I have to consider, for example:
当需要砍掉内容的时候，我会考虑比如
- The desirability and priority of the feature.
- 这个功能的需求度以及优先级
- What people we have available.
- 我们手底下的员工
- How much, and what, each person can work on.
- 每个人的工作能力
- While not being blocked, or blocking, someone else.
- 有没有遇到什么问题
- What features tie into other features.
- 哪些功能和其他功能更相通
(If there is anything independent enough to cut cleanly.)
有些与其他功能无交互的被砍掉也不会有什么影响
Sometimes laying this complex puzzle, trying to fit high priority pieces together, is trickier than trying to nail jello to a wall. Things slip and change constantly. This is the very essence and nature of development work.
有时候在这些复杂的条件下，把高优先级的事项写入清单列表比在墙上钉一个果冻还难。计划赶不上变化，这是工作中再正常不过的事情了
## In closing (结语)
Speaking of the nature of development work… While the example above mostly serves illustrate problems with communication, which is always a factor when people with different perspectives discuss something… I think it says something about how frequent certain development problems are; that a site exists where you can create your own project cartoon, like this one.
说到开发工作的本质，之前提到的几个极端的例子都是讲述了在交流中的问题。不过这些问题也是不同背景的人探讨在过程中无法回避的问题。我认为这也说明了这些问题发生的有多频繁。有一张很经典的图片就阐述了这一切。
The issues that Paradox and HOI4 struggle with are the same problems that all IT projects, everywhere, grind their teeth over. It’s terribly complex work. Which is why, although the problems and risks are well known and can be anticipated and planned around, to a degree… they remain.
之前说的问题，在所有的IT项目，包括P社和钢4所要面对的都是一样的。这在工作中是极端的复杂。这也就是为什么有些你们发现的问题已经广为人知并且也在某种程度上写入了计划。。。但是他们还是没有被修正的原因。
The silver lining, I think, is that while our problems are the same… we at Paradox have a hell of a lot of fun while working on them.
不过希望还是有的，毕竟这些问题都是一样的。我们在P社内解决这些问题还是比较开心的。
Next week, our Brand Manager will write a Dev Diary. Before handing the baton back to podcat.
下周是我们的品牌经理来写开发日志了。之后开发日志会回到Podcat的受伤
Don't forget to tune into World War Wednesday today at 16:00CEST on
https://www.twitch.tv/paradoxinteractive! To see podcat run Germany in massive co-op, with the other devs as generals.
别忘了本周的周三世界大战哦。
![[汗]](/static/emoticons/u6c57.png)
![[泪]](/static/emoticons/u6cea.png)
![[阴险]](/static/emoticons/u9634u9669.png)