Blue Blazer

从www.reddit.com转载而来：) 受到了鼓舞

There are many successful one man software projects. I can think of many - you don't have to look very far. For example, Resourcer was made by one guy: Doug McKenna. I believe the game Glider Pro was written by one guy. Woz wrote the BASIC interpreter for the Apple I. I've done one person projects myself to deliver application software before many times.

My advice is that you don't just demand more people. Get their requirements and make a realistic plan of how you can complete the project by yourself. By "get their requirements" you need to have a good understanding of not only what the software needs to do, but what an acceptable solution might look like. Is it OK to use open source third party libraries in your solution? Whether they will allow this will make a big difference in how long it will take.

Come up with at least a high level design for the software/system. Decompose it into parts. Identify those parts that you know how to write and those where you are going to have to gain additional expertise. Make an estimate as to how long it will take to make each part. At this stage, your estimate should consist of two numbers. The earliest you think it could be finished if everything goes right and the latest it could be finished in the 90% worst case scenario. For parts of the project you know well, your estimates will be a little tighter. For parts of the project that you don't know well, your estimates will have to be looser. Budget time to get up to speed with any technology you don't know. Be a little generous with yourself here. If you do the project by yourself, it is actually a blessing because you will gain new skills by working in areas outside your normal expertise.

Make a list of any things you might need to buy in order to do the project. This could be computers, other equipment, software libraries, tools, etc. You might want to shop around for third party libraries to solve some of your problems. For example, let's say you decided to use XML in your project, you might need to shop around for an XML parser. Make sure it meets your technical AND business requirements. For example, can you use LGPL stuff in your project? How about GPL? If you go commercial - do you have the budget? Does the vendor require a royalty? These are just some of the questions.

Next, plan a proposed team that could complete the project. Your company might prefer to use contractors for this if they do not want the burden of additional full time employees. You probably will need at least one test engineer. This person could be a contractor. Speaking of quality, you need to understand their quality requirements. This will probably be driven by who the customer is and how critical the system is. If your bosses are non-technical, be prepared to answer why betty the office manager can't do your testing or why the users can't just test the system when it is deployed. Explain that while both of these things might have some value, those ideas basically mean that you are testing the software yourself which has risks because programmers tend to get myopic and have a difficult time testing their own code.

You need to have a plan for deploying the solution. If it replaces an existing solution, then the deployment plan will be more complex.

Then when you propose it to your bosses, lay out the various scenarios. One where you do everything yourself, then another where maybe it is just you and a test engineer, and then maybe a third solution where you bring in some additional developer(s) who have specific skillsets that complement yours. Explain to them that the benefit of this third solution is that they don't have to pay you to learn technology X where X is important for a specific reason and you don't know X already. If you want to do a great job, you could estimate the costs of each of these solutions for them.

Also, keep your team as small as possible. If you are hiring developers, make sure they pass a code test. An easy way to do this is to setup a clean machine with just the development environment, pick a topic like Poker and give your candidate a printout of the rules, and ask him to write a program to sort poker hands. It doesn't have to be poker - it could be anything like that. This is the simplest way I know not to hire a complete bozo. Be aware that you might have to interview ten people to find one that is not a bozo. Having a degree - even a PhD - or having worked for a big name company does not mean they know how to program.