How to effectively work with a programmer?

Question

Project management

Friends, give advice to a beginner in this matter.

I am a person with quite a lot of knowledge, besides directly server programming. Extensive experience in offline project management, design, UX, and little things like WordPress (sometimes freelancing). Due to various circumstances, I plan to start working on one project of medium complexity, for which I will need the help of a web programmer that I have not dealt with before. Timelines and quality of execution are my number one priority. I would not want the first pancake to come out in a coma. In addition to the difficulties with choosing, in fact, a person (how many freelancers are there, choose them according to the purity of the code or according to their track record?) - I want to understand how to control the process itself. Asana? Megaplan? Should I start a bugtracker? Something else? How to properly set a deadline? I understand that the topic is endless, but at least some other person's experience would help me a lot.

Perhaps someone has a well-established scheme for working with freelance backend workers?
Seek advice from the community.

Answer 1

A programmer is first and foremost a performer. In this role, use it. And by loading him with “deadlines” and other managerial nonsense, you force him to do work unusual for him, in fact, shifting your responsibility to him.
Do you want to be completed on time and in good quality? Break the task into as small iterations as possible in such a way that you can really check the results of each iteration and set exact technical tasks for each of them. So you can quickly understand how the developer is coping with the case, and in relation to the developer, act more honestly. The rest will have to rely on the developer.
If competent technical specifications are not your profile, then you will have to rely on the developer to an even greater extent. But get ready for mutual misunderstanding. The ideal developer in such a situation is also an analyst, a psychologist, and a manager. You'll be very lucky if you find one.
And what tools you personally will use in no way will affect the results of the developer's work.

Answer 2

asana, megaplane, etc. it's all bullshit to work with one person. He will name the term, multiply it by three (most likely you yourself know this). If he keeps within what he called, stick to it and never lose it =) What he writes you should see it, let him commit to github or somewhere else, commits should be every day.

Answer 3

A management system is needed, even if he himself is both a manager and a programmer in one person.
But enough of the simplest. Successfully used Trac (http://trac.edgewall.org/) in a team of 5 people.
You can do the installation and maintenance yourself (it’s not more difficult to set up Apache), or you can use ready-made Trac hostings.
Convenience - integration of the management system with the version control system.
We've been using bitbucket.org lately - enough for the needs of a small team.
A nice little thing is the possibility of hosting private projects with a team of up to 5 people.
But all these are just tools; in order to use them, it is necessary to establish a management process. Definitely need rules, at least on sheet A4, as mentioned above, the daily commit is a good candidate for these rules.
In my remote projects, I used elements of Scrum - planning, rallies, demonstrations. The completeness of the implementation depends on your capabilities and needs.
For example:
1. We are going on February 20th for planning, I determine the date for the sprint, let's take a week as training, then you can increase the duration as confidence in the estimates grows. We determine the number of story points in the sprint based on your agreements with the performer about how much time he will devote to work. Take the correction for yourself, an analogue of the focus factor (my personal preference is not to discuss ff with remote performers, therefore an analogue), the correction for a professional in a well-coordinated team is 0.7 - 0.8, for a pro in a new subject area - about 0 ,5. Check during the process. For example, we count 20 hours, taking into account ff 0.5 = 10 h / h. Set the sprint due date to February 27th (mind you, before we figured out what to do).
2. The contractor evaluates the tasks in hours, in real terms, unlike Scrum. Based on priorities and taking into account the integrity of the result at the end, you type tasks for the sprint, you can fix them in the version or milestone in trac.
3. Every day (or with a different frequency, but better daily) at the set time, you are going to a rally for 5-15 minutes, the performer will say three things: what he did yesterday, what he is doing today, what difficulties he encountered. This is the most important event of all, it stimulates work, allows you to reveal problems in advance. At this event, tasks are usually transferred to testing, but if there is no tester, you will probably replace him, in which case you accept completed tasks and report on their successful verification or return them to the executor the next day at the rally.
4. On February 27, we are going to a demonstration, let the performer himself report on the work done (show the implemented functionality point by point), he will probably talk about flaws, ideas, problems, incorrectly implemented logic will be revealed somewhere. (In the case when you are a tester yourself, this is a moot point, but I would recommend holding some event on delivery, albeit a short one).
It is important that the control system (method + tools) should help solve your problems, if something interferes with one of the participants, while not helping anyone, eliminate or modify this something.

Answer 4

1) The most important selection parameter at the moment is experience, look at the portfolio and in fact all exchanges allow you to look at previous contracts and estimates for them.
2) In any case, a bug tracker or task manager, for github or bitbucket code, you can always see when and how much the programmer committed, and there is no excuse, I write such and such code for a long time, if there are no commits, then nothing is written.
3) For a programmer, I set a deadline, after evaluating the task, if the task is eight hours and I take the programmer for full time, I set the deadline tomorrow, in my opinion the most optimal and understandable system, in life, of course, everything is more difficult, since there are external interactions , but the basic principle remains the same.

Answer 5

TK + Project Management System (PM, we use feng office ) + Version Control System (SVN).
At the first stage, a TOR is drawn up with a work plan and details.
PP: test processing module development:
1. Data model adaptation: 4 hours,
2. Data protocol sampling: 2 types of protocols, 2 hours each + 1 hour for debugging = 5 hours,
3. GUI development: 3 controls with graphical processing * 4 hours each + 2 table controls * 1 hour per control + 1 general information control * 0.5 hours = 14.5 hours
4. GUI testing: 3 graphics processing * 0.5 hours = 1.5 hours
5. Report development: design 16 hours + layout 8 hours + debugging 16 hours = 40 hours
Total: 60 hours
We draw up a TOR for the entire project, add from 50% to 200% of the time margin. In the future, the TOR will be revised, the work will be rearranged, the deadlines will be shifted up or down, but in fact the development will take the calculated time with a slight deviation. True, it takes quite a lot of time to draw up such a TOR.
Further, it is necessary to control the execution by the completed stages in PM and the commits associated with them in the version control system. It is also necessary to tightly control the health of the release branch in SVN. For a long-term task, it is necessary to create branches, and only for minimal changes that do not affect performance or have been fully tested, commit to the main one (PP GUI design change without changing the functional part).
When developing together, the practice of the 1st commit at 1-4 hours into the branch and every 4-7 hours, merging the branches proved to be good. Big changes do not accumulate and both are working on the current version. For my personal projects I try to follow the same rhythm. The main advantage when developing alone is the ability to quickly roll back the latest changes, and it is convenient to calculate the time spent.
The maximum allowable commit period is 8 hours (1 business day). If the commit interval exceeds this period, then only 3 options are possible: 1. The work is worth it, 2. There was a serious problem, 3. The task is too big and it was necessary to detail it in more detail. If it is the 3rd case that arises, then you need to check the TOR for similar tasks and detail them. Also, a commit should go to each bug fix, with the obligatory notification of the others about the need to urgently get a fresh version.
At least once a week, a detailed discussion of the status of the project by the entire department (company, group, underline as necessary), preferably with checklists for checking the operation of the program. Also, once a month, you can require a report on the work done in writing, possibly with a package of documentation for the program. The main thing is not to forget to add at least 4 hours per month to it in the TOR (if with documentation, then at least 8-16).
PS. As for choosing a developer, it's best to ask for help in choosing a familiar programmer. If not, then ask the candidate to send a sample code and evaluate it for formatting quality. Formatting rules are very easy to find. Or ask to evaluate the code of any programmer, for example, from Habr, some forum or somewhere else.
P.S.S. Good luck!

Answer 6

Version control system and review of commits. Regularity is important. I haven't found anything that works other than this. It is convenient to keep tasks in the bugtracker, breaking them into atomic units. You need to finish breaking in the process of work (everything will not work right away).