Working alone on a project

So I am working on a small Project at my company, I am a mere trainee engineer (halfway through a Software Engineering degree), where we are developing an intranet – based project management and people management system – it incorporates Employee appraisals, personal skill management and development and so on.

Ive been working on this project for a little while, under the direction of a more senior engineer and there has been another trainee working on it too.

However soon, a big contract is coming up and the other two have been press-ganged for some of the work, which will tie them up for a long, long time.

This leaves me alone to work on this (really fun and full of learning) project alone. Dream come true! Or is it?

I’ve been worried about how I’m simply going to manage the work of three people, are there techniques, tools I can use? The more I think about it, the more intimidated I am (but still relishing the idea of a good challenge).

I have to think about planning, diagramming, release notes, test specs and my own hallways testing (where I grab a random person and say “break it!”), not to mention the actual programming work!

So in short, how can one person adapt to taking on the workload of three people?

Make sure you get input from the more senior member regarding security. Employee information is not public record.

Here are some time savers:

Management Brains – Are they aware this started as the 3 person job and is now down to one? Someone has to do the math and adjust.

Existing applications. There are a lot of ways to build an app, but some of your coworkers are going to return to this project (formally or informally) and review your work. Try to use some of the best practices they’ve already included. The reasoning is part: Don’t reinvent the wheel, they may have addressed needs that your infrastructure and/or company rules require, don’t let their personal bias towards certain techniques/frameworks cloud their judgment of your work.

Requirements Adjustment – the app you’re building could probably be bought off the shelf, so make sure you understand what your company needs that the other products don’t offer. Make these your priority and adjust the other requirements along the way. You don’t have to include all the bells and whistles they wanted upfront.

Team Overhead – You will have some advantage of not working with a team. You don’t have to sit in meetings and debating your decisions. This will save time, but you do lose the input from what may be better devs/two heads are better than one. They may not be on the project, but do what you can to get some code review even if you have to treat them to lunch.

Time, Energy and Resource Management – Figure out when you perform the best and schedule the difficult programming tasks for those times. You will feel a little drained, so use those times to do some of the mundane administrative tasks. Don’t forget social niceties and treat your hallway testers like gold. Listening to them talk about their cat is NOT a waste of time. Be the person they will take their time to help even though they have a full inbox.

Planning is good, but you have to get something built. Do the work and make plans, but don’t spend too much time between coding. Good luck with your first app.

If you mean that the distinct types of tasks were first divided among three, I suggest you request a weekly session (several hours) with the senior engineer to discuss progress, issues, ideas. It would be very unwise from the company standpoint to let you do it all alone, regardless of your level of expertise.

This could be difficult.

I think planning is your key. Do you have a project plan that the three of you are working to?

If not, I would suggest you come up with one before your colleagues jump ship. At the very least this will be a list of all the tasks you need to do on the project. The more detail the better (up to a point – but just saying “develop such-and-such a screen” is probably not detailed enough). Also include things like documentation and plans.

This is the top priority.

You should go through every task on the list and satisfy yourself that the time allowed for the task suits you. Its no good one of your colleagues estimating a day for a particular task, if its something you know nothing about and would likely take you a week. Also be aware that developers tend to be optimistic about timescales – since you say you have little experience in this area you will likely fall into this trap. Unfortunately the main thing that will help you there is experience, but some “rules” that spring to mind could be:

nothing takes less than a half-day. Even if its a one-line code change. Because you’ll lost the time elsewhere
however long you think it’ll take, double it (this isn’t one that I use because it cannot stand up to close scrutiny, but it may help you starting out)
if a single task takes longer than a week, you haven’t defined it well enough. The reason for this is simply that if you have a 20-day task its near impossible to say with any certainty that you’re 75% complete.

Depending on how important it is that you fit in with existing standards, you should add tasks (for other people) to review things like documentation, test plans and of course code. And you should add tasks (for yourself) to refactor your documentation/plans/code following these reviews.

If there are certain aspects of the project that you simply cannot do, or cannot do within a reasonable timeframe, or need training to do, say so.

Do not budget to work evenings or weekends. If you do this, and you slip, then you have no hope of making up the lost time. It may be that you feel the need to put in these extra hours, but you should use them to play catchup. Keep them up your sleeve, as it were.

Make sure your boss knows about this new plan, and is aware that delivery will take x weeks/months longer. If they want it more quickly, its up to them to either sort more resource or to descope parts of the project. This is important because if you don’t communicate these things to your boss, they will be expecting you to deliver things when you’re nowhere near ready.

Lastly, keep on top of your plan. If you are starting to slip, make sure you are the first to know. Now, whether you say anything to anyone or keep it to yourself will have to be a judgement call. If you’re confident you can get the time back, then there’s probably no point saying anything.

Bottom line is this: don’t let yourself be stitched up. If you find yourself missing deadlines, your only defence will be if you can say, “Look, I highlighted this as a risk x months ago.”

Filed under: softwareengineering - @ 10:49

Thẻ: design, planning, programming-practices

Thiết kế website giá rẻ

Danh mục

Working alone on a project