3 ms·
Sounds like this is the root of the problem: "When the programmers get it (the specs), they often start negotiating with him about what's going to be built. Th
by garagemc2 14y ago
Sounds like this is the root of the problem:
"When the programmers get it (the specs), they often start negotiating with him about what's going to be built. They exchange countless emails, and he's being constantly interrupted and being asked to clarify exactly what the spec means. "
A simple solution is: speaking about the project/product feature with your developers first. Understand what will take long, what won't, what can be stripped out in the first iteration. Once this is done, work with designers to push something out.
Another super simple solution is videos.
Writing takes time. Wherever possible I try to make videos for the designers or even better have live calls.
In terms of idle time, there should be always a backlog of specced out work or bug fixes that the developers can focus on. Failing that, they can work on optimising past projects, refactoring or reading about new things.
- danso 14y agoWriting takes more time than producing videos? Are these videos largely unedited? And if so, how do you measure the time lost in the inefficiency of interpreting the video?
- garagemc2 14y agoUnedited videos, remember, this is for design briefs. For developers, videos may not be the best form. I can imagine on some very complex projects videos being a difficult medium. But for me it's great: I just record the things I want to get done, bring up examples from other websites, use the mouse as a pointer to direct the viewers focus. I summarise what I want to be done at the end. Usually I send over the video and checklist of things to do.