Godziny pracy i oczekiwania produktywności dla twórców gier i programistów


30

Mam startup z ograniczonym budżetem, a ostatnio zatrudniłem programistę i artystę. Zanim rozpoczęli projekt, opracowałem mapę drogową projektu z dużą ilością dobrej dokumentacji dotyczącej tego, co należy zrobić i jakie są terminy.

Obaj zostali poproszeni o przedstawienie harmonogramu, w jaki sposób zostaną dotrzymane te terminy. Dla artysty wspomniałem, że jeśli obciążenie pracą byłoby zbyt duże, może być możliwe zatrudnienie dodatkowego wykonawcy na miesiąc lub dwa, podczas gdy oni potrzebują pomocy.

Zacząłem już słyszeć takie rzeczy, jak: „no cóż, może potrzebuję dodatkowej pomocy” i „Nie jestem do końca pewien, jak długo to teraz zajmie, więc te ramy czasowe są bardzo przybliżone”. Rozumiem, starają się nie wystawiać na porażkę, ale jako menedżer muszę także wiedzieć, co się dzieje.

Mamy więc dwa pytania:

  • Często widzę obu moich pracowników, którzy używają Slacka spoza firmy, odbierają wiadomości telefoniczne i robią życie administratora na zegarku. Pojawili się późno więcej niż raz w pierwszym tygodniu, kiedy mam politykę firmy dotyczącą bycia w wieku 9 lat. Może to niekonwencjonalne, ale pracujemy nad dużym projektem, a ostatnią rzeczą, jakiej chcę, to odwrócenie się wokół i oskarżając mnie o niedoszacowanie zakresu projektu. Z drugiej strony zdaję sobie sprawę, że w większych firmach może to być normą. Czego ogólnie można oczekiwać od artystów / programistów pod względem stylu pracy i wydajności? Jaka jest różnica między elastycznością a lenistwem?

  • Mój artysta już zaczął odmawiać innej pracy (pracy na rzecz marketingu, itp.), Ponieważ ma już dużo pracy na głowie i musi sprostać oczekiwaniom. Mógłbym sobie z tym poradzić, gdybym ich nie spóźniał, odpowiadał na wiadomości na Slacku i generalnie robił rzeczy niezwiązane z pracą. Z drugiej strony nie wiem, czy jest to normalne / konieczne w przypadku kreacji. Czy to jest


Jeśli to może pomóc:

  • Studio znajduje się w Europie.
  • Nie mam pisemnej polisy, ale godziny pracy są zobowiązaniami umownymi.
  • Używamy zwinnego zarządzania projektami.
  • Nad projektem pracują 3 osoby. Oba są „potencjalnymi klientami”, więc podejmują decyzje związane z własnymi dziedzinami - sztuką i kodem

46
Ustalenie harmonogramu projektu z wyprzedzeniem terminów jest dokładnym przeciwieństwem zarządzania projektami Agile.
Jörg W Mittag

5
@lucasgcb: Ale te terminy są krótkie (zwykle jeden lub dwa tygodnie), poddawane ponownej ocenie co sprint i ustalane przez zespół. Tak nie jest w tym przypadku, jak napisał PO, przedstawił całą mapę drogową i terminy przed rozpoczęciem projektu. Zwinność polega na ciągłym sprzężeniu zwrotnym i dostosowywaniu procesu na podstawie tego sprzężenia zwrotnego.
Jörg W Mittag

2
Jeśli PO stworzył mapę drogową z terminami dla każdego punktu, to tak, to nic zwinnego. Czy tak naprawdę jest, OP?
lucasgcb

5
Ever heard the saying "You can have it on time, on budget, on spec. Pick two." ? Well you've apparently chosen time and budget. Guess what's going to happen to your project.
Aaron F

12
I can tell you from personal experience that giving estimates is hard. Very hard. You just can't know what will happen in the future, how long a certain task will take. And yes, I need coffee breaks too. The brain is like a muscle and overexercising it will yield diminishing returns. From what I could see, it seems you have too high of expectations what your employees can do per day. Forcing them to comply with your expectations will burn them out, as was seen with BioWare and others.
MechMK1

Odpowiedzi:


87

It's not unusual for workers to be less than 100% engaged in task work for the entire duration of the work day. Humans have a hard time focusing on one task for longer than 20 minutes without some form of interruption.

Research suggests that, out of an 8-hour day, on average, workers are productive for less than half.

In fact, reducing the total hours worked in a week can increase productivity in some circumstances.

This isn't an argument for "anything goes" or making drastic changes to your office hours without further investigation. But, a little variance in arrival times and some non-work activity occurring during work hours is not necessarily cause for alarm.

Clamping down in a draconian way to try to eliminate non-work activity may well backfire, leading to unhappy and burnt-out workers who are less productive or outright quit.

Instead, let your project milestones be your guide. If your workers are meeting the schedule goals that were established early on, then you'd seem to be on track. Refusing work over and above the agreed-upon schedule is a reasonable thing for a worker to do, and not necessarily a sign of slacking. If you have more work than your scheduled bandwidth allows, try to incorporate this learning into planning for your next sprint/milestone/work unit, so you can prioritize the tasks or bring in additional helpers as needed.

If the project is falling behind schedule, that gives you a good, evidence-based way to raise the issue with your team, and work with them to find solutions to bring it back on track.

Studios I've worked at have for example instituted "focus afternoons" 2 days a week, in which we're requested to not schedule meetings, play videos in the background, or have conversations at desks where they might cause distractions, so everyone has a block of time they can count on to be uninterrupted.

Talk to your team about whether something like that might work for them, and involve them in the decision-making, so they feel like they're collaborators finding solutions together, not children being disciplined (nobody does their best work when they're feeling punished). Just knowing what's at stake and being empowered to help solve it may be enough to inspire your team to adjust their arrival times / focus to pick up the slack, if that's what's missing.


4
Well put. I would just stress that things like "being empowered", "involve them in the decision-making", "let your project milestones be your guide" are the cornerstones of an agile mindset, which the OP claims to be using, so it should be right up their alley.
Reinstate Monica

4
I would go so far as to say that as long as the direct reports aren't being insubordinate in the way they do so, the fact that they are setting expectations like this rather than blindly saying "sure I can do that on top of my other tasks!" is a good sign that they are excellent employees who know how to manage time and risk, and whose judgment OP should trust more. Much more. They may well save the company from going way over schedule and budget.
bob

This is a nice reason I can give to my boss for why I'm not working at the moment, and instead reading SE
Redwolf Programs

1
It is worth noting that sometimes the plan ends up being unrealistic. As a result, cutting scope (or delaying it until after release) is frequently a solution that ought to be on the table.
jpmc26

@jpmc26 In some Agile methodologies like DSDM, it's the only solution for projects suffering from delays, since time, cost, and quality are all considered to be fixed.
nick012000

21

Good grief, reading this question stressed me out. You don't think your employees should be allowed to send personal messages and attend to their life during work hours? The top answer says it better than I will, but that's completely unrealistic. If you expect your employees to be focusing on their tasks 100% of the time, you're going to lose them.

Most businesses are open from 9 to 5, at least in America. It makes no sense, but it's the world we live in for some reason. That means that human beings who need to make appointments and deal with real life stuff are going to need to take care of it during work hours. If you offered flexible hours instead of insisting they come in at 9 (and presumably stay until all other businesses will be closed) then that would sort of be one thing (even then it's harsh), but demanding they stick to these rigid hours and then getting upset when they need to do people things is delusional.

Add on top of that that people have kids and family and situations at home, and you should be realizing that your expectations are insane. If you want to dedicate your entire life to work and sacrifice the meaningful portions such as relationships and health, that's your prerogative. But that's not a decision you should be making for your employees.

If you need to get more work done, you can hire more people. If that's not possible, you need to cut back on your expectations and goals for the project.


19

I think that strict working hours is generally not a good idea. For example I belong to these 20% of people who are much more productive at late hours. I worked in startups and big companies as well. I always had that talk with my managers about the late hours. After all I always told them, yes I can come to the office at 8am and be completely shut down until 2pm being almost useless... On the other hand, I always was completing my tasks on time and even before - I worked from 11am to 10pm because it was best for me - resulting in my own better productivity.

Also doing a little bit of own stuff (like answering couple of mails or even watching a YT video) is not a bad thing even contrary being a programmer, the job is intense and tedious. A human brain cant really work a full 9 hours straight; it needs little breaks - these breaks are actually much more productive than just sitting and staring at code - in these breaks I usually get the brightest ideas popping into my mind - that leads to good solutions for the problems. So I suppose everything is relative - of course it shouldn't be abused and the employees shouldn't watch YT all day long.

After all the best measurement of productivity is when you see if the employees are making their tasks in the given time (of course if the times are set correctly). I think the best way is to break the task into short time spans and check them once in a while - like once a week or once every 2 weeks or whatever makes more sense for you.

Taking all I said into consideration, if they are not meeting the deadlines consistently and not motivated enough to work on the project - then you have hired the wrong people and your best choice is to replace them with the people who will.


Feeling more productive at late hours is a cognitive bias for most people. I did trust this feeling until I mesured my productivity. Then I found I was more productive while sleeping, basically waking up to type code as it come for a short time.
bokan

17

I think apart from the above mentioned views, I guess one has to take the region/country where the company is located. The culture has a major impact on these kind of stuffs too.

For example. I have worked in India, US and Currently in Germany. In India, People tend to come late everyday, I observed them to be less productive on first few hours after entering the office. They frequently use mobile phones and enjoy coffee breaks in Cafeteria. Having said that, they tend to form a strong bond among their colleagues.So, when it comes to work, They tend to finish it somehow to meet the deadlines.

Meanwhile in US, you can't restrict them or pressurize them to do a certain tasks. They feel responsible for the job no matter happens. In short, they don't like people bossing them around.

In Germany, things are completely different. They strictly follow "Work Hard and Party Hard" culture. Inside the office, they won't do anything related to their personal life. Even when having a chat with their colleagues, it will be about the work flow. They are extremely sincere. They care more about the quality than velocity. But I haven't seen them working after their required working hours in a week. No matter what happens they leave the office after the requested period.

Hope this point of view helps for you to analyse your Resources


11

There are some red flags, but probably not the ones you expect

This

I set down a project roadmap with a lot of good documentation on what needs to be done and deadlines.

Both were asked to produce a timeline as to how these deadlines would be met. For the artist, I mentioned that if the workload was too much, it might be possible to hire an additional contractor for a month or two while they need help.

I have already started hearing things like, "well, I might need some extra help with this," and "I'm not exactly sure how long it will take me right now, so these timelines are just very rough estimates." And I get it, they're trying not to set themselves up for failure, but as a manager, I also need to know what the heck is going on.

...sounds more like waterfall and less like Agile than you're probably aiming for. The point of Agile is to manage risk better by planning less up front, when you know far less about scope, schedule, and budget, and instead focus on continually adding value to the product and planning only as much as you need to at any given time. This lets you 1) always have a product that you can demo and maybe even sell; 2) always know the pace your team is working at; and 3) what you can reasonably accomplish in a given amount of time. As a result you can better respond to schedule hiccups and changing customer needs, both of which are important for a startup.

It sounds like your employees are doing Agile and you're unintentionally trying to force them back into waterfall. I'd recommend spending some more time learning about Agile, particularly with a focus on startups where I understand the risks are high and you want to avoid costly mistakes.

But if I were going to create a software startup I would 100% choose Agile over waterfall, because it would enable me to be more agile instead of blindly going over the waterfall because my employees didn't set expectations with me and instead kept taking on more work while promising to meet a deadline that had been set in stone months ago and that was not achievable. You don't want that.

Bottom line: other than possibly the lateness issue, your employees are doing exactly what they should. You need to take a look at your management style; it seems to be the issue.


10

Having managed several studios for a few of the large game companies, I could write you a large answer about productivity, etc but the problem is rarely there:

First, you can't expect people to sit 8 hours focused, it won't happen.

Flexibility is very important because if people can't deal with calling their bank, etc at the office, you will start to feel it very quickly. Unless there are some important deadlines, and the work is purely related to the time put in (as in no problem solving, no research, etc) you can't measure the work in hours and it's much better for employees to have flexible time, within reason.

In order to get people to be productive, forget time and focus on short measurable goals but also make sure they really understand, and share, the end goal. If they don't care about your project and are just contractors that want to collect their pay, your product will never be good.

People go into games because they're passionate about it, so you already don't have most of the problems you'd have with contractors in general. But you have to get them interested in your product and involved in building it, not treat them as extensions of your brain that will implement what you tell them. If there is no team feeling, productivity will be low, no matter the talent.

Another common thing in games is that your schedule is probably wrong; in almost 30 years in this field, only one team I was a part of (making the most popular soccer game) had a schedule that was realistic and made sense. It was an experienced team where people were used to work together. You have to constantly refine the direction with the team to see what can be done with the time / budget you have left, keeping in mind that there are always unknowns, etc popping up.

Almost all the time, productivity issues stem from management mistakes. Make sure the team likes the project, want to see it published, are contributing to it more than just coding and drawing, like it's theirs too, and that the goal makes sense at any moment.


2
Well maybe I am just wrong but... I didnt like my last company’s product it wasnt just talking to me. However I got payed for that work I’ve done and I’ve done a great work I really proud of it from many aspects (I am a programmer) I have participated in the UI/UIX design and brought many features to it, I have done really great performant stable and multithreaded systems for that app (it was an audio middleware and also an app, I worked for the app) I worked on it alone and even finished 3 months before the scheduled deadline.
ColdSteel

My point is: I dont think that employees should be 100% believing in the product. Personally for me it doesnt even matter if I getting payed for something, I will do my best work, because this is how I was educated, this is how it works for me. I was hired I was payed a big money and I was providing my best. And yet, I didnt like the end product, I wouldn’t ever invest in it. So the point of dont care about the project is not a 100% situation, or I just dont understand something.
ColdSteel

That means you'd be an awesome employee at many places ;) There are people like that, but my experience with games is that passion for the product is a very important driver because we can't spec out everything since a lot of things depends on how the game feels, plays, etc; by having everyone buying into the product, each actor is making their own personal contribution to make the product parts fit together; having works for most major game companies, I've seen a lot more complaining than anything else from the programmers when they don't like part of the product.
Thomas

As I said I don’t know for everyone, after rethinking it again, perhaps it is just a personality aspect. I’ve done a lot for the games industry as well, I didnt like every task or every aspect of the particular game or a plugin, but I still did my best. I actually looking at it differently: I am selling my knowledge - my code as part of it to the employer and it is going to be the best I can provide.
ColdSteel

2
I am 32 couple of days back. And my quality is not driven by what other ppl will think about me or my job done there. Its just my vision of the world. If you hired me and I dont do my job well then I see it as stealing money from your pocket :-/.
ColdSteel

7

A few things you need to know about creative types:

Programmers love being 100% engaged for hours at a time. This allows them to achieve deep flow. To gain the benefits of this, you need to provide a work environment absolutely free of distractions. Separate offices or remote is ideal. Cubicles are marginal. Open workspaces obliterate productivity. Something as simple as asking someone what time they're going to lunch can destroy half an hour of work.

Whether a developer is in deep flow or not, code quality drops off precipitously after about five hours of hard thinking. And sometimes that thinking may not look like work. I do some of my best programming with my eyes closed on the couch.

Read up on Scrum and other Agile methodologies. Set reasonable tasks and deadlines (which is a skill in itself that you'll need to hone as a team) and then let your developers decide how to meet those goals. Other than your daily standup, you don't need to synchronize your schedules at all. In fact, it's probably better if you don't.


4
+1 for "Something as simple as asking someone what time they're going to lunch can destroy half an hour of work." It's like juggling - when someone snatches a ball from you, you drop all of them, getting back to the point of interruption takes you way way longer than the interruption itself.
Guntram Blohm supports Monica

Well thats individually for everyone. Some people can’t be interrupted, some can write code and talk at the same time (I am one of the last and also met 3 other people like me). However I find myself closing my eyes putting a hood on my head and thinking sometimes as well.
ColdSteel

@ColdSteel I think the ability to work in a distracting environment is a learned skill. I work in a very distracting office, and after a year I've managed to get my productivity up to maybe 60% of what it was when I worked from home.
ReinstateMonicaSackTheStaff

@TKK I always remember myself like that, but maybe you are right. For me there is little difference if I work from home or at the office.
ColdSteel

6

Adding to other answers, it's worth noting that on top of the average office worker, most creative work like art and programming certainly does not benefit from monitoring over the shoulder and counting down the minutes.

However, this doesn't mean you cannot track or expect a deadline for goals.

If your workers legitimately do not know when a task will be completed from your plan, their task is actually too big - or you've presented it as too big. Break the tasks down to things your workers can deliver frequently and effectively build up to your MVP. Think SMART goals and involve them in the process. Have a brief stand up meeting everyday to figure what's being tackled today, how work is going, or what's impeding their progress.

To say it again, do not set up overwatch on them with work hours. Gather with each team and discuss reasonable scope and deadlines. Do not micromanage, specially over creatives.


2

I think you were taking the problem on the reverse way (but hopefully the previous answers changed your mind).

Here is my way to lead creative people, and the way I like to be lead :

  • I make sure they feel engaged toward the project. It must be their baby, not mine. I'm very strict with the briefing and then give full freedom within the defined frame. I feel very bad when I have to say someone "I know you don't want to do this that way but you have to" each time it happend and the job is done I consider I have a big debt regarding the worker. If there is a technical choice to make, the ones more impacted by it have to make it. Also split the tasks so they can aim at the end of it (agile methods).

  • get focused very hard during small amount of time, then relax. Check pomodoro method, it force you to train to quit working even if you felt very productive at that time. Feel weird, but once you use it repeatedly you'll see it work. There are tons of similar methods. Make sure your employees experiment them, I'm so glad when I see my colleagues debating about these methods.

  • Make sure they have top environment: descent computer, keyboard, mouse, monitor, desk, chairs, network, good water, even fruits... It cost nothing compare to salaries.

  • Make sure they have a place to take a nap. Sometime after a bad night I could take a one hour nap, it saves me the rest of the day instead of fighting fatigue like a zombie in front of computer. Consider your developers are working while sleeping and exercising. They just come to work to type the code they though about while cooking the day before. If they sleep or have sport break during the day, you'll get two days of work for the price of one. The same apply at smaller scale with pomodoro methods. So make sure they have some quick stupid things to do. Ideally I would have a climbing wall in the office. So you can climb 5min get focused 25min... Also I would pay the one hour sport break.

  • experiment things that seems to be a waste of time. Like peer programing for exemple, I can't remember how many keyboard shortcuts or software feature I learnt this way and how grateful I'm to the ones who taught me them. It also create bonds between people. Also at one company I was working with, employees made presentation to others once a week during lunch time. It was not mandatory for employees to do it but considered as a present to others. The company paid pizzas... Quite cheap for a one hour and half lesson to 20 persons.

  • care for them, check the signs of fatigue, worries, bad health state. Talk with them, encourage exercising... It's like leading a sport team. Care for them, they'll care for you.

  • Make sure there is no shame of not being working at a time, so they never fake it. They send messages on slack because it's a less obvious break than doing push-ups...

But how can you be sure they are working if it all look like an holiday place? You'll feel it. Make sure there's some pressure, some deadline and challenge and that they care. It's really easy to make happy people productive.


2

In addition to the existing answers that cover A. “employees are humans and need to be able to also live their lives” And B. “Setting up long term waterfall based work loads and deadlines, but meeting daily about them, doesn’t count as agile”

I’ll add some additional information I think will help you succeed. There is, sadly, just statistically, but also from my takeaway of your situation and view points, nearly a 100% chance you will never ship a game.

The setup you have going, plus how game development works, plus this being your first shot at running it all where you are the last line and the bottom line, means failure is imminent.

The only chance you have to ship a product, of any sort, is to constantly adapt. The grand vision of a game you have right now, whatever it is, will sink you. Plan on shipping a tenth of that vision at best. Hold on to one key feature or essence, and let everything else be flexible or “cut-able”.

If you were an artist or an engineer yourself, then you could drive slightly more of the vision home via your own sweat equity. As it is now, every sprint, look at what you have and then make a decision about where to try to take things in the next 2 weeks. Forget about the grand plan. Figure out what pieces there are for a minimal viable product and try to dedicate sprints to achieving a single piece.

Agile development is especially difficult to manage at the very beginning of a software project. Many producer/designers end up turning it into waterfall development without realizing it...but with a lot more meetings.


0

To me, it kinda sounds like you hired the wrong people. I only work with people who I know will be just as motivated as I am. Doing personal stuff in between is no biggie (as long as it's not too long of course!), but showing up late seems to me like a lack of discipline / they don't take their job too seriously.

Look, I don't know you, I don't know them, I don't know the company, but it feels like you should go over this with them. It doesn't need to be in a stern manner, but rather ask how they perceive such issues and help them get motivated for the end-goal, your release.

Oh, and as an artist I totally understand their "I don't wanna do marketing stuff" mindset, because it may not be what they learned to do in school. For tasks like those you may rather hire a specialist, especially since you're a starting studio. Without marketing you'll die a swift and unnoticed death.

Hope this helps, succes with figuring it out!


If it were a big company the marketing observation would be sensible, but since it is a startup breaking a few eggs short-term is expected, specially with little budget. That said, I can't tell why this answer has been downvoted.
lucasgcb

My guess is that many devs (I'm one too) aren't in agreement with the implication that OP is correct to expect work without breaks. I agree that the late arrivals could very well be an issue, and the marketing suggestion sounds reasonable, but personally I think OP is describing micromanagement that will eventually drive away good workers or cause them to burn out, and from the other answers I think that's more or less the consensus. That's probably why this has gotten downvotes (I didn't downvote btw, even though I disagree with this answer).
bob

2
Perhaps the wording is confusing? This answer says "I only work with people who I know will be just as motivated as I am", which sounds like "no breaks is A-okay", and "Doing personal stuff in between is no biggie", which sounds like "breaks are A-okay". It's not clear which position is being taken. Clarifying might help, especially if you really are just focusing on the late arrivals.
bob

I don’t feel that this answer have to be downvoted, even though I disagree with part of it :-/
ColdSteel
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.