Philip Becerra · Producer

I'm actually quite passionate about this, because I review all the game design documents that the lead designer puts in front of me. Like if they say this is the amount of work, I'll try and question that, right? Because they may feel very optimistic that we can achieve something with X amount of weeks or months available to us. But I, as a producer, have the responsibility to push back on that and look into those numbers and look into that scope that they're trying to achieve and ask difficult questions like, are you actually able to do this on your own? There's so many things you have to keep in mind, right? Some of our leads have more than just development work that they have to do. They have their own people, they have a lot of meetings to attend, right? Everyone, I think, that I've met in this company is very optimistic about what they can achieve, because it's an exciting project. But humans are incredibly bad at estimating. I think there's entire papers written on it, right? So what we do as producers is question and push back, and wherever we feel like we're not really 100% confident, we can build in buffer, right? Extra time in the development of a feature schedule so that we can account for unknown unknowns. There's always something that goes wrong. There's a tool that's breaking, or there's some priority that has to be addressed immediately, right? So that is something that we have to deal with. It's a very big company with so many developers, with so many people checking in. You've talked about game dev before. It's difficult to get it in a stable enough state very quickly, and so sometimes we just have to make a push, and that can affect a feature's development time, right? So we as producers try to always push back, ask questions, try to understand what's the reality of a feature's development timeline, and then build in that extra safety net of buffer.

Jake Ross · Lead Producer

Yeah, and then I'd say that you can't always look at just an estimate on its own, right? Sometimes a developer will say this will take me three weeks to do. Okay, cool. You're not working 100%, eight hours a day, whatever it is, for that amount of time. There's meetings that crop up. People get sick or they take time off. You can't just look at an estimate somebody gives and say, okay, cool, I'm just going to take that and plop it into my schedule, and that's that. We do track and ask teams to account for time for unknowns, which is the things you don't know that you don't know, because it always happens. Things come up that we just could not foresee. And so we don't max out our team schedules. If they give us an estimate of three weeks, we might actually put it in the schedule for something like four, four and a half weeks, because we know that there are real things that crop up. Bugs will come in that need fixing. So there's an element of that as well, of trying to keep in mind the whole context of things, whereas the developer's scope of what they know about is the stuff they've been asked to do. Producers have to be mindful of everything that's going on in the project, so that we can be like, well, I know that there is a release happening around that time and that likely we will have to monitor the bugs that are coming in. This team is often supporting the releases and fixing bugs. So I'm going to take your three-week estimate and I'm going to add a little bit of time there, because I know that you will likely have to get pulled off and reprioritized to help support the release or something like that.