@WildFactor
There are several misconceptions here.
First, since you are clearly coming from a developer background, let me state that I come from a production background with management experience in three major studios. I can't say that my reasoning applies to all studios, but everything I've seen applied to all 3, I tend to generalize as something that happens everywhere (there is a bias here, but I have to assume as much given the 3/3 so far on these).
Other employee risk to loose their job if estimation are not good. If I take too much time to make a task I risk to loose MY job. So you shouldn't give you an under evaluate estimation!
(read the paper Muz give as ref if you want)
I disagree. Firing someone for making a bad estimate is malpractice. The best way to make sure developers become better at estimating is to allow them to fail. Like everything else, its something you must train yourself to try and do the right thing (give the right number instead of buffing it up or making it willingly smaller than it should). It is bound to fail often, but over time, the results of developers that have been given the chance tend to close on the gap.
You are not making a commercial proposition to a client, you are not competing with your cowroker by offering the lowest price (for the lower quality). If your manager work well he won't push the competition between team and force them to lie on estimation.
Except you are. Just because you don't get to be part of the Sale process or management layer doesn't mean your work isn't directly impacting sales. The manager isn't pushing competition, reality is. I agree that the developers shouldn't feel that pressure unecessarily, but they need to be counscious about it regardless. I actually think it's one of the strengths of the indies, because, businesses like Spketrum Media (boasting 5M$ contracts in 6 months using a single dev) give developers complete information regarding the sales process and what the competition is bidding.
I've been a lead programmer Smiley I've made estimation and control other estimation for many years! I've been friend with all my managers (and I'm still with some few years later) You can listen to experience (me, book, blog post...) or make the same mistakes like everybody and learn by yourself.
I've been a manager for many years. I've steered estimates for various projects. I'm friend with all of my employees because I'm able to adjust to different personalities. You can listen to experience (me, book, blog post, Forbes mag, CEOs, Dice Keynotes) or make mistakes like everybody and learn by yourself.
Well your example has some problem. If a manager has to choose between 2 teams, well people will get fired anyway. Manager usually has to decide between two projects not two teams. This never happen to me, and I don't see why it will. If your manager ask you some estimations, he will probably already worked with you for some months and trusted you and he has calculate the factor estimation/duration accuretly for you. So no problem for him to take the best descision.
If one of the team lie on estimation to get the job, it puts the entire company in danger!
My example states that the manager has the choice between doing the two projects or doing just one (possibly salvaging a few resources from team B to reinforce team A should only one project kickoff). It is true that a lot of studios have 3 or less development teams (cells) they use and have very few projects to work with simultaneously. I, however, have worked at 2 studios where this wasn't the case (teams where 5+). It depends largely on the scope and nature of the projects a studio chooses to undertake (largely related to specialties and demand).In a servicing environment, (I'm not talking about IPs here), it's possible to do the two projects if they are both profitable, but if the estimate for one of them (wrongfully) assumes that it is not a profitable venture, that's when the employees get the axe. If both projects' estimates reveal they are profitable (client offers to pay enough for the work it would actually take) then more people get to stay aboard. It wasn't clear from my example that I was referring to a servicing scenario however (apologies).
Most of the time a manager ask the same person to make the estimation of both projects. Managers are not stupid you know ?
Unless you work with cells. Let's assume the two projects use very different techs. Then, you are likely to run the estimates by whoever is the most proficient with that specific tech. In many instances, you'll be running the estimates by different leads for example.
(and I don't consider myself stupid, thanks for underlining it!).
You can also not give yourself a buffer and be late like 3/4 of the video game production. Ask of a budget extension for the third time, not having it and close your studio doors even when your game is 95% finished.
That's actually part of the manager's job. Assessing scope, following key metrics (namely, burndown charts). It shouldn't have to fall back onto the lead dev to tell the manager they are running late and that he should take action. There are various ways to take action and release the game 100% on-time and on-budget (by assessing scope).
In real life: you ask for 18 months (without doing overtime). The boss couldn't get the money for 18 months and asked you to do it in 12 months. You make what we call a retro-planning. At the end of the 12 months the boss see that you worked hard, extra hours/days, and you still need 4 more months. He get the money for 4 more months or close the studio. (16 months with overtime)
Everybody knows it but:
- The boss can't close a deal for 18 months (competition) right away. He can always ask for a budget increase later. Or he can deliver a bad game.
- He keeps a pressure on you so you work extra hours.
In real-life (with actual management involved), you ask for 18 months. Client won't give you that much. You settle for 12 months, but remove a bunch of features. At the end of the 12 months, you're approx 110% budget because the client asked for a few more things here and there, and because you felt bad you had to axe features, you gave in. Then you present your final product, and you offer them the 4 extra months for the missing features. They likely say no, unless the game goes well, and offer to send a "patch" or "dlc" with it.
As a general rule of thumb, I refrain from asking for overtime. It generally comes from the team-members themselves when they feel they are running behind, and I rarely encourage it tbh. I also make a point to give back 1:1 hour, as should be. In the last 2 years, I haven't allowed a single employee register more than 50h in a single week, or 90 in two.
Another solution: be an indie and eat noddle if your game is not enough good.
As "funny" as it might sound, you're actually assessing scope (quality of what you ear) in regards to your budget. That's good management
@Muz
For one thing, good software developers are pretty damn rare and rarely get fired if they can get hired in the first place. Even if they do get fired, it's probably not too hard to find another job that pays as well, and severance pay makes for a nice bonus.
Depends how the business gets away with hiring undergrads. My area is known for having more studios than its developer pool should allow. Hiring from the outside or through unconventional means is commonplace (we're the 2nd largest game development area in north america).
It's easy to find another job for a dev, but not necessarily one that pays well. It is well known that HRs in this area actually dine together every week and perform a form of Oligarchy for salaries (otherwise, competition would be so rampant that people would keep moving). With a current avg bounce rate under 1 year, it's very hard for businesses to thrive without this form of agreement (whether it is ethical or not).
Chances are that the people on project B will get reassigned to project A. If you gave a target that you couldn't do, then neither project gets completed properly, and everyone loses.
A portion would, but the business would take advantage of this time to trim the best from the herd.
As for giving a target that couldn't be done, remember that the assumption is that these two projects COULD both get done (but that an overly buffed estimate would reveal that it doesn't). I'm basically demonstrating the effects or over-estimating here.
Show Posts
