Iforgot said:
I've been at my job for a couple of months now, and it's tough job. I'm actually designing and building things that other people will use. It's a completely different beast than my PhD in experimental (UHV,rf,clean room facilities) physics. Cludge isn't acceptable... What's a guy to do?
I can't tell if I'm getting dumber, or my projects are getting harder. I always thought I was clever (at least until I started grad school) b/c coding came easy to me. But my coding and cludging intuition isn't helping me with this job.
When it comes to project design, 1) I want to build a quick crappy prototype using cheap parts, and continuously refine it (like code). 2) My boss wants me to spend serious time designing it, and making sure all parts are compatible in advance. 3) I was trained in grad school to take whatever is lying around and make do.
On the plus side, it's a boatload of awesome experience. I'm building this whole thing myself. Everything from the circuit design and optics setup, to the processing software and chassis machining. I'm also getting the chance to work on my own proposals. All these will be notches on the good old belt.
On the down side, we are a small company (#people< 6), and I'm the only one working on my project. One of my coworkers has experience with my project, and he's very helpful. But still I feel overwhelmed.
To the people on this forum, what are your experiences building a producing stuff, and just working at small companies in general?
That's a very good set of questions. I'll try to give my perspective on some of them.
First, what I've found to work best for me (and the company that I've been with from startup to medium size company), is to shortcut to some of the more important design answers with quick prototypes and tests, and then do the overall product planning and optimization. It's not so much using kludges in the design process, it's more like separating out possible from not-so-possible early, so that you can focus on how to optimize the possible. (I may have to make a follow-up post with examples to make this point more clear).
And since I have experience with helping to take a small (private) company to a medium-size public company, there are some important things to point out. First, early in a small company's life, it's okay to have spartan documentation and only a person or two who understand a product's design. That's enough to support the small product line and keep it successful. But as the product line(s) grow, and as the number of customers grow (hey, that's a good thing!), you really need more people, and dedicated support people, who understand the products and can help with issues that come up in Production or in the field. That is where good design documentation becomes key.
For those reasons, and others, the ISO 9000 process stuff has a number of requirements for documentation and process control. It's not so much a PITA documentation requirement, as much as a way to be sure that product designs are done and documented in a way that helps to ensure quality control and customer satisfaction. When we became big enough to need to implement ISO 9000+ controls on our processes (PDP=product development process and QMS=quality management system, I think), it was a lot of extra work, but it helped us to formalize the whole design process so that we can be sure to track what we do, and respond to customer requests and needs.
So even though you are working at a small company right now, I'd recommend a few things to you:
** Keep your design documentation on a shared server that other employees can access, preferably under document/design control (like with Perforce or Agile or WinCVS).
** Hold formal Design Reviews at critical project milestone points, typically right before you go out for layout of a PCB. Design Reviews take some extra work for you as a designer, but are super-important checkpoints, especially for a smaller company with critical projects in the pipeline.
EDIT -- I've learned very important things at Design Reviews for my designs that I've called, and I've also been able to provide important helpful hints and catch important mistakes at Design Reviews that I've been invited to...
** As part of your documentation, write up a Functional Specification early in the project, and use that as a morphing document that eventually ends up being an overall Theory of Operation document. Early on, it will mostly reflect the Marketing Requirements Document that you get from Marketing or whoever, but will gradually take on a more technical nature as you get farther along with your design. In the end, it is an invaluable technical document, for anybody who needs to understand or support or build upon your design work on the project.
** Keep a running technical log of your Design Verification Testing (DVT) and Electromagnetic Compatibility Testing (EMC Testing) work on your design, as you go through the EN 61000-4-x test suite. Include photos of your test setups in the docs. I like to just use Excel for this testing phase. Having this doc helps you to be sure that your product is robust, and also helps you remember how to do the testing on future products that you design.
As you work for bigger and bigger companies (or as your present small company succeeds and grows), these steps will become more natural, and more a part of the standard product development process. The ISO PDP/QMS process and sign-off sheets are now a standard part of my company's development process, and I think it's a good thing. You can just lose too much by playing fast and loose for too long on product development. Especially when you are successful with several generations of products in a row, and grow the company well.
Have fun!
