This is a repost from a FB comment related to someone's difficulty with developers abandoning projects mid stream.
I currently employ 13 developers on various projects. I've dealt with many more through my past, so i have some thoughts.
It wasn't clear from your post what exactly the employment arrangement was. I gather from your comments this was a part-time-ish contract. OR it was a "fix pay for fixed deliverable", meaning that I"ll pay you $X and you deliver Y. I'll start with the latter because my hunch is that is what you are doing.
Software/Games have two giant problems:
1) Devs horribly underestimate effort
2) There are many many ways to interpret a feature/functionality
It's not like carpentry where a 2"x4' is such an exact specification that it never varies by person, culture, tool, or time.
So you say "I want the win screen to have rainbows and a pot of gold" and he thinks "Ok, i'll throw up a PNG of a rainbow and a PNG of a pot of gold, no problem". When what you thought you were getting was a shader that would slowly bleed in the colors and a pot that would have thousands of particles of gold flying into it and eventually filling it. Maybe you and your dev are totally aligned on feature/functionality, i use this illustration only to show how there is tons of room for difference of interpretation.
Most of the devs i've hired or worked with charge into the project like a bull thinking "this will be easy" and make tons of apparent progress right away. Then they hit the middle where apparent progress dwindles to nothing and they are fixing bugs or refactoring early work in order to support the later work. Most personal game projects end here.
The second aspect is that the dev thinks "this should only take me a month", even if they commit to 3, they internally think something else. Once the project gets past their internal timeframe, they get extremely discouraged.
Now you are dealing with a morale issue. Which, if pay is low, is compounded. But the pay issue is separate. People in general find it easier to quit than to renegotiate or, to do the hardest, to say they were wrong in their assumptions (takes a big person to do that). So they are stuck in this trap of not wanting to work on the thing, wishing they were done, and feeling stupid for their inability to get it done or being so wrong on the estimate. Most people can't work in this kind of environment.
If you or someone on your team is there, you don't have a lot of options. You can try to motivate them, you can try to renegotiate, and you can try to hear them out in a "safe talk" where they can really level with you on how they feel (most professionals won't, it's never been safe to really share one's thoughts)
There are some solutions to NOT getting there:
1) Organize the project into small chunks/sprints/milestones (whatever your methodology is). 2-3 week chunks at most. Make these milestones where you get together and talk honestly about the project. It has to be ok for the dev to say "wow, this really isn't going well". Then you aren't blindsided later if they abandon. Tie payment to these milestones. Money keeps people hungry. Actually hunger keeps people hungry, so they always need money. Short sprints keeps their money needs and your programming needs aligned.
2) Don't do the very typical "half down, half at completion". They'll work real hard at first because they just got a chunk of cash and they are beholden to you. But then in the mid part of the project they are short on money and still have a tone of work to go to get to that last milestone, so it's easier to abandon then to continue. They feel like they've done enough to justify the first payment, and if someone else is tempting them with a better offer than the last payment is, they'll jump over to that and repeat this cycle.
3) They may simply hate the project. Maybe at first they though it was great, or they didn't care, they just needed the money, but over time they've found they just don't believe in it. Again, it is the rare person that will say "I just don't believe in this project." I've had that happen once with a contractor. I appreciated the honesty and wound down his work and moved on to someone else who did believe in it.
It's very easy for people to believe in a project up front, because it's all rainbows and puppy dog tails. But as things become concrete, as they see what it is and where it is going, they may realize "I don't want to go there." Or, and this is important, they thought they would have a lot of input on the project to chart its course, but it ends up not being so, and while they were interested in doing OUR project they are not interested in doing YOUR project. This is a project management/team issue not solved by proper sprints, it's an issue of HOW you work.
Finally, check out https://www.16personalities.com/personality-types and use it when interviewing potential candidates. God basically made 16 types of people. Some don't work well with others, the problems are easily predictable. Test yourself and the candidate and see if you are a match.
I have seen, and maybe you have too, that skill is really a secondary consideration (people can always improve their skill): its "work fit" that is the primary consideration when selecting a team member. It's WAY harder for someone to change their personality type or character than it is to pick up a tool or language.
It feels like over my 20 years I've dealt with pretty much every kind of employee problem one could ever have, from sexual harassment, to flat out racism, to faking an illness, to bad corporate cultures, to flatulence, to someone refusing to retire, and even someone with narcalepsy. I've also had to hire my fair share of HR consultants to deal with issues legally. So if you would like to chat more about it i'm certainly open to it.
Monetization models, best practices, marketing, branding, SEO, social media, and funding.
2 posts • Page 1 of 1
- Posts: 25
- Joined: Thu May 12, 2016 1:21 pm
- Location: Richmond, Indiana
- Area of Focus: Concept Art, Illustration, Graphic Design & Game Design
- Occupation: Freelance Artist
Dividing the project into milestones is just smart and something that totally skipped me. Avoiding the half now and half later also. And I'm guilty of not doing both. I think if I had done that, I probably would have actually had something playable at CGDC and wouldn't have hit several snags during the May-June time I got a coder to help me out. But certainly errors I will learn from!
Great nuggets to keep in mind here Thomas, excellent post.
Great nuggets to keep in mind here Thomas, excellent post.
One thought opens a thousand eyes, one sun brings a thousand dawns.
Who is online
Users browsing this forum: No registered users and 0 guests