Are they strictly referred back to? Are they used at all? If so, what terminology do you use? Would love to hear about that.
For further actions, you may consider blocking this person and/or reporting abuse
Are they strictly referred back to? Are they used at all? If so, what terminology do you use? Would love to hear about that.
For further actions, you may consider blocking this person and/or reporting abuse
Dani Passos -
Gervin Guevarra -
Muhammad Asadullah (Asad) -
Omari -
Top comments (8)
I'm sure there will be varying responses here. It depends on a number of factors: industry, application, corporate culture, etc. My current company really emphasizes work-life balance, so overtime is generally frowned upon. When I worked in finance, there were mandatory overtime hours to meet customer deadlines. The gaming industry is another example; you work around the clock to ensure that you meet the release dates. And if you're Elon Musk, you're going to work more than you sleep and eat combined.
So do you define release dates and then be understanding when you don't hit them? Do you not really define them at all? Does it vary?
At my current position, release dates are somewhat loose, mainly because things change a lot (read: Agile). But we have daily standups, so we understand the urgency and adjust as necessary. Again, overtime is not expected.
Pretty accurate depiction here for me:
Today I gave an unrealistic deadline for a project I'm working on and I said to the PM, about the second part of that project something like: "the release date you asked me about is science fiction"
Nothing to see here :-D
Usually we just follow what Agile principles suggest. We reduce scope in order to meet deadlines. But if it's some sort of revamp of a certain feature or product, we'll review it in order to have mvp working as desired instead of pushing something half baked to users.
I'll start by clarifying, I work for an outsourcing company.
On my current project, we have release cycles. There's a requirements phase, a development phase and a stabilization phase.
We have a code freeze at the end of the dev phase, before stabilization, after which no new functionality should be worked on. Requirements, gathering, for the next cycle, should happen at the same time as stabilization, though it's normally continuous. Dev is self explanatory and stabilization is for bug fixing.
After stabilization we release the completed functionality to the client. They're supposed to do additional testing, normally don't, and a few other thing to prep for deploy to prod and that can sometimes take our whole cycle.
This is done less formally than I'm making it out, but here's the rough process we use:
We first characterized the project and get some rough milestones that we can reason about. We make a WAG for each milestone (a month, 6 months, whatever)
We we then go to the real drop dead deadline, the "We will be sued if it isn't done by now deadline". We work backwards from there and see how much slack we have if we start now. We figure out a start date, and a red/green zone for a couple milestones out. We meet periodically, and have a couple meetings right before and during our milestone targets.
If it looks like we are going to miss a milestone, we check the overall timeline and see if it looks like we might miss the deadline. If the deadline looks imperiled, we either chop scope, add devs, authorize overtime or investigate what it would take to push back the deadline.