Послушный фрилансер — быль, а не сказка. Часть 3.
В первых частях я описал 3 причины, которые часто мешают успешно реализовать ИТ-проект:
1. Не определен ожидаемый результат;
2. Неправильно сформулирована задача;
3. Выбран первый попавшийся исполнитель или с наименьшей ценой
Если не успели прочитать, статьи доступны по ссылкам: https://vk.com/wall27509_1814
и https://vk.com/wall27509_1822
Продолжаю.
Причина 4: «недостаточный контроль выполнения».
Люди не любят излишний контроль, это факт. Но для заказчика отсутствие контроля опасно. Если фрилансер начал работу без предоплаты, заказчик рискует только затраченным временем. Если предоплата внесена, то временем и деньгами.
Важно понимать, что контроль должен быть разумным. Не нужно каждые полчаса докучать вопросами, требовать 2 раза в день предоставлять результат пропорционально прошедшему времени.
Риски при отсутствии мер контроля:
1. Задача не выполнена вовремя;
2. Задача полностью не выполнена. Иногда даже не начата;
3. Задача выполнена неправильно.
Если с первым пунктом все очевидно, расскажу о других двух.
Бывает такое, что исполнитель не рассчитал силы и не успел в оговоренные сроки начать выполнение задачи. Действия в такой ситуации зависят от:
а) наличия дополнительного доступного времени;
б) соответствия уровня исполнителя сложности задачи;
в) наличия связи с исполнителем.
Если исполнитель на связи, способен выполнить задачу, а время не исчерпано, не паникуйте — дайте дополнительное время для завершения задачи.
Если исполнитель пропал, на связь не выходит, придется искать нового. Как бы ни было неприятно, это не трагедия века.
Если задача оказалась сложнее расчетного, хороший фрилансер честно в этом признается и предложит найти другого. Совсем хороший еще и порекомендует, к кому в первую очередь стоит обратиться. Напрашивается вопрос: а что, заранее нельзя сообщить? Ответ тоже неоднозначен, но основные моменты таковы:
- бывают ситуации, в которых задача поставлена в очередь на несколько часов/дней, в расчетное время разобраться с не получилось. Тогда заказчик уведомляется при завершении отведенного срока, так как до последнего момента фрилансер надеялся на успех;
- служился форс-мажор;
- внешние обстоятельства, мешающие выполнению. Например, взаимодействие со сторонним сервисом, который перестал отвечать на запросы в последний момент. Предсказать такое невозможно.
Хуже, если исполнитель осознанно оттягивает ответ, заранее понимая, что не способен выполнить. Учесть такое отношение и в дальнейшем не сотрудничать.
Случается и другое: исполнитель на связи, задает периодически вопросы, в срок отчитывается о выполнении, а при проверке выясняется, что результат не соответствует требуемому. Здесь причина кроется либо в неправильной постановке задачи, либо неправильной интерпретации. Постановку задачи я описал кратко в первой части, но подробно об этом напишу отдельную статью. Или тоже получится серия статей.
Соответственно, рассмотрю ситуацию с неправильной интерпретацией задания.
Для минимизации таких ситуаций интересуйтесь в процессе работ прогрессом и не довольствуйтесь ответом общими фразами, а просите проверить и «пощупать» промежуточный вариант. Конечно, программисты и другие специалисты не любят показывать незавершенное, но ищите разумную середину.
Пример 1: задача на 90% состоит из поиска алгоритма, на оставшиеся 10% - из написания кода и верстки. Очевидно, по истечении половины времени не нужно просить показать что-то визуальное. Лучше ограничиться просьбой описать рассматриваемые алгоритмы. Возможно, в них будут логические ошибки или пустые места. Возможно, сразу будут написаны вопросы ответов и решений. Но это позволит увидеть, что исполнитель занимается задачей. Иногда это позволяет даже вовремя подсказать правильное направление, если заказчик ориентируется в вариантах решения.
Пример 2: верстка 5 страниц. Вложенные типовые страницы требуют до трети времени, необходимого для верстки главной страницы. Получается, что по прошествии половины срока будет готова только одна главная. Смотрите только главную. Если сразу указать на неточности, будет сэкономлено время при итоговой приемке.
В случаях, когда промежуточный вариант увидеть невозможно, мерой контроля становится диалог с открытыми вопросами, отвечая на которые, исполнитель подробно расскажет о выбранных методах решения. Преимущество — попутно появятся вопросы, обсудить которые полезно сразу, а не при приемке.
Поскольку описанные ситуации и примеры не являются исчерпывающими, оптимальным решением будет согласование способов контроля с фрилансером до начала работ. Тогда и фрилансер, и заказчик будут знать, когда и что показывать или проверять.
Если задача маленькая (4 часа и менее), дергать исполнителя мало смысла. Проще дождаться и обсудить по итогу.
Другая ситуация — исполнитель против промежуточных отчетов, но если заказчик уверен в успешном завершении задачи, не нужно ничего лишнего выдумывать. Достаточно проверить только после завершения работ.
Обращу внимание на разные объемы задач и проектов. Если задача небольшая (до 3-4 дней), контролировать не всегда требуется. Если проект крупный (свыше 2-х недель), разбивайте на много мелких задач, проверяйте по мере выполнения.
====
Тема контроля обширна, в статье даны только общие рекомендации. В следующей статье опишу оставшийся пункт — приемка результатов работ.
Напишите в комментариях, как Вы контролируете выполнение задач? С какими сложностями сталкиваетесь?
На какие аспекты обратить внимание?
Кстати, внезапно данная серия статей становится больше — Анастасия Емельянова спросила, как выбирать исполнителя, когда никто из кандидатов не стремится уточнить детали.
Пишите комментарии, задавайте вопросы — возможно, Ваш комментарий станет началом новой статьи!
#mvoevodskiy #марафонконтента #автоматизация #автоматизациябизнеса #фрилансеры #ошибки #тз #постановказадач #контроль #контрольвыполнения
В первых частях я описал 3 причины, которые часто мешают успешно реализовать ИТ-проект:
1. Не определен ожидаемый результат;
2. Неправильно сформулирована задача;
3. Выбран первый попавшийся исполнитель или с наименьшей ценой
Если не успели прочитать, статьи доступны по ссылкам: https://vk.com/wall27509_1814
и https://vk.com/wall27509_1822
Продолжаю.
Причина 4: «недостаточный контроль выполнения».
Люди не любят излишний контроль, это факт. Но для заказчика отсутствие контроля опасно. Если фрилансер начал работу без предоплаты, заказчик рискует только затраченным временем. Если предоплата внесена, то временем и деньгами.
Важно понимать, что контроль должен быть разумным. Не нужно каждые полчаса докучать вопросами, требовать 2 раза в день предоставлять результат пропорционально прошедшему времени.
Риски при отсутствии мер контроля:
1. Задача не выполнена вовремя;
2. Задача полностью не выполнена. Иногда даже не начата;
3. Задача выполнена неправильно.
Если с первым пунктом все очевидно, расскажу о других двух.
Бывает такое, что исполнитель не рассчитал силы и не успел в оговоренные сроки начать выполнение задачи. Действия в такой ситуации зависят от:
а) наличия дополнительного доступного времени;
б) соответствия уровня исполнителя сложности задачи;
в) наличия связи с исполнителем.
Если исполнитель на связи, способен выполнить задачу, а время не исчерпано, не паникуйте — дайте дополнительное время для завершения задачи.
Если исполнитель пропал, на связь не выходит, придется искать нового. Как бы ни было неприятно, это не трагедия века.
Если задача оказалась сложнее расчетного, хороший фрилансер честно в этом признается и предложит найти другого. Совсем хороший еще и порекомендует, к кому в первую очередь стоит обратиться. Напрашивается вопрос: а что, заранее нельзя сообщить? Ответ тоже неоднозначен, но основные моменты таковы:
- бывают ситуации, в которых задача поставлена в очередь на несколько часов/дней, в расчетное время разобраться с не получилось. Тогда заказчик уведомляется при завершении отведенного срока, так как до последнего момента фрилансер надеялся на успех;
- служился форс-мажор;
- внешние обстоятельства, мешающие выполнению. Например, взаимодействие со сторонним сервисом, который перестал отвечать на запросы в последний момент. Предсказать такое невозможно.
Хуже, если исполнитель осознанно оттягивает ответ, заранее понимая, что не способен выполнить. Учесть такое отношение и в дальнейшем не сотрудничать.
Случается и другое: исполнитель на связи, задает периодически вопросы, в срок отчитывается о выполнении, а при проверке выясняется, что результат не соответствует требуемому. Здесь причина кроется либо в неправильной постановке задачи, либо неправильной интерпретации. Постановку задачи я описал кратко в первой части, но подробно об этом напишу отдельную статью. Или тоже получится серия статей.
Соответственно, рассмотрю ситуацию с неправильной интерпретацией задания.
Для минимизации таких ситуаций интересуйтесь в процессе работ прогрессом и не довольствуйтесь ответом общими фразами, а просите проверить и «пощупать» промежуточный вариант. Конечно, программисты и другие специалисты не любят показывать незавершенное, но ищите разумную середину.
Пример 1: задача на 90% состоит из поиска алгоритма, на оставшиеся 10% - из написания кода и верстки. Очевидно, по истечении половины времени не нужно просить показать что-то визуальное. Лучше ограничиться просьбой описать рассматриваемые алгоритмы. Возможно, в них будут логические ошибки или пустые места. Возможно, сразу будут написаны вопросы ответов и решений. Но это позволит увидеть, что исполнитель занимается задачей. Иногда это позволяет даже вовремя подсказать правильное направление, если заказчик ориентируется в вариантах решения.
Пример 2: верстка 5 страниц. Вложенные типовые страницы требуют до трети времени, необходимого для верстки главной страницы. Получается, что по прошествии половины срока будет готова только одна главная. Смотрите только главную. Если сразу указать на неточности, будет сэкономлено время при итоговой приемке.
В случаях, когда промежуточный вариант увидеть невозможно, мерой контроля становится диалог с открытыми вопросами, отвечая на которые, исполнитель подробно расскажет о выбранных методах решения. Преимущество — попутно появятся вопросы, обсудить которые полезно сразу, а не при приемке.
Поскольку описанные ситуации и примеры не являются исчерпывающими, оптимальным решением будет согласование способов контроля с фрилансером до начала работ. Тогда и фрилансер, и заказчик будут знать, когда и что показывать или проверять.
Если задача маленькая (4 часа и менее), дергать исполнителя мало смысла. Проще дождаться и обсудить по итогу.
Другая ситуация — исполнитель против промежуточных отчетов, но если заказчик уверен в успешном завершении задачи, не нужно ничего лишнего выдумывать. Достаточно проверить только после завершения работ.
Обращу внимание на разные объемы задач и проектов. Если задача небольшая (до 3-4 дней), контролировать не всегда требуется. Если проект крупный (свыше 2-х недель), разбивайте на много мелких задач, проверяйте по мере выполнения.
====
Тема контроля обширна, в статье даны только общие рекомендации. В следующей статье опишу оставшийся пункт — приемка результатов работ.
Напишите в комментариях, как Вы контролируете выполнение задач? С какими сложностями сталкиваетесь?
На какие аспекты обратить внимание?
Кстати, внезапно данная серия статей становится больше — Анастасия Емельянова спросила, как выбирать исполнителя, когда никто из кандидатов не стремится уточнить детали.
Пишите комментарии, задавайте вопросы — возможно, Ваш комментарий станет началом новой статьи!
#mvoevodskiy #марафонконтента #автоматизация #автоматизациябизнеса #фрилансеры #ошибки #тз #постановказадач #контроль #контрольвыполнения
An obedient freelancer is a reality, not a fairy tale. Part 3
In the first parts I described 3 reasons that often interfere with the successful implementation of an IT project:
1. The expected result is not defined;
2. The task is incorrectly formulated;
3. The first contractor or the one with the lowest price selected
If you do not have time to read, the articles are available at the links: https://vk.com/wall27509_1814
and https://vk.com/wall27509_1822
I continue.
Reason 4: “Inadequate follow-up.”
People do not like excessive control, it is a fact. But for the customer, lack of control is dangerous. If the freelancer started working without an advance payment, the customer risks only the time spent. If the prepayment is made, then time and money.
It is important to understand that control must be reasonable. It is not necessary to bother with questions every half an hour, require 2 times a day to provide the result in proportion to the elapsed time.
Risks in the absence of control measures:
1. The task was not completed on time;
2. The task is not fully completed. Sometimes not even started;
3. The task completed incorrectly.
If everything is obvious with the first paragraph, I will talk about the other two.
It happens that the contractor did not calculate the strength and did not have time to start the task on time. Actions in this situation depend on:
a) the availability of additional available time;
b) compliance with the level of the performer of the complexity of the task;
c) the presence of communication with the contractor.
If the contractor is in touch, able to complete the task, and the time is not exhausted, do not panic - give extra time to complete the task.
If the performer is missing, does not get in touch, you have to look for a new one. No matter how unpleasant, this is not the tragedy of the century.
If the task turned out to be more complicated than the calculated one, a good freelancer honestly admits this and suggests finding another. He’ll also quite recommend who he should first turn to. The question begs: what, it is impossible to inform in advance? The answer is also ambiguous, but the main points are:
- there are situations in which the task is put in the queue for several hours / days; at the estimated time, it did not work out. Then the customer is notified at the end of the allotted time, since until the last moment the freelancer hoped for success;
- force majeure was served;
- external circumstances that impede implementation. For example, interaction with a third-party service that stopped responding at the last moment. It is impossible to predict this.
Worse, if the performer deliberately delays the answer, realizing in advance that he is not able to perform. Take this attitude into account and not cooperate in the future.
Another thing happens: the contractor is in touch, periodically asks questions, reports on time on time, and during verification it turns out that the result does not meet the required. Here the reason lies either in the incorrect statement of the problem, or in the incorrect interpretation. I described the problem statement briefly in the first part, but I will write a separate article about this in detail. Or you’ll also get a series of articles.
Accordingly, I will consider the situation with an incorrect interpretation of the assignment.
To minimize such situations, take an interest in the progress in the process of work and not be satisfied with the answer in general phrases, but ask to check and "touch" the intermediate option. Of course, programmers and other professionals do not like to show incomplete, but look for a reasonable middle ground.
Example 1: the task consists of 90% of the search algorithm, the remaining 10% - of writing code and layout. Obviously, after half the time, you do not need to ask to show something visual. It is better to limit your request to describe the algorithms in question. Perhaps they will have logical errors or empty spaces. Perhaps questions of answers and solutions will be written right away. But this will allow you to see that the performer is engaged in the task. Sometimes this allows even prompting in time the right direction, if the customer is guided in the solutions.
Example 2: layout of 5 pages. Nested sample pages require up to a third of the time required for layout of the main page. It turns out that after half the deadline only one main thing will be ready. See only the main one. If you immediately point out inaccuracies, time will be saved during the final acceptance.
In cases where it is impossible to see the intermediate option, a dialogue with open questions becomes a measure of control, answering which, the contractor will tell in detail about the selected solution methods. Advantage - along the way there will be questions that are useful to discuss immediately, and not during acceptance.
Since the described situations and examples are not exhaustive, the optimal solution would be to coordinate control methods with a freelancer before starting work. Then both the freelancer and the customer will know when and what to show or check.
If the task is small (4 hours or less), pulling the artist makes little sense. It’s easier to wait and discuss the outcome.
Another situation is the executor against interim reports, but if the customer is confident in the successful completion of the task, there is no need to invent anything extra. It is enough to check only after completion of work.
I will pay attention to different volumes
In the first parts I described 3 reasons that often interfere with the successful implementation of an IT project:
1. The expected result is not defined;
2. The task is incorrectly formulated;
3. The first contractor or the one with the lowest price selected
If you do not have time to read, the articles are available at the links: https://vk.com/wall27509_1814
and https://vk.com/wall27509_1822
I continue.
Reason 4: “Inadequate follow-up.”
People do not like excessive control, it is a fact. But for the customer, lack of control is dangerous. If the freelancer started working without an advance payment, the customer risks only the time spent. If the prepayment is made, then time and money.
It is important to understand that control must be reasonable. It is not necessary to bother with questions every half an hour, require 2 times a day to provide the result in proportion to the elapsed time.
Risks in the absence of control measures:
1. The task was not completed on time;
2. The task is not fully completed. Sometimes not even started;
3. The task completed incorrectly.
If everything is obvious with the first paragraph, I will talk about the other two.
It happens that the contractor did not calculate the strength and did not have time to start the task on time. Actions in this situation depend on:
a) the availability of additional available time;
b) compliance with the level of the performer of the complexity of the task;
c) the presence of communication with the contractor.
If the contractor is in touch, able to complete the task, and the time is not exhausted, do not panic - give extra time to complete the task.
If the performer is missing, does not get in touch, you have to look for a new one. No matter how unpleasant, this is not the tragedy of the century.
If the task turned out to be more complicated than the calculated one, a good freelancer honestly admits this and suggests finding another. He’ll also quite recommend who he should first turn to. The question begs: what, it is impossible to inform in advance? The answer is also ambiguous, but the main points are:
- there are situations in which the task is put in the queue for several hours / days; at the estimated time, it did not work out. Then the customer is notified at the end of the allotted time, since until the last moment the freelancer hoped for success;
- force majeure was served;
- external circumstances that impede implementation. For example, interaction with a third-party service that stopped responding at the last moment. It is impossible to predict this.
Worse, if the performer deliberately delays the answer, realizing in advance that he is not able to perform. Take this attitude into account and not cooperate in the future.
Another thing happens: the contractor is in touch, periodically asks questions, reports on time on time, and during verification it turns out that the result does not meet the required. Here the reason lies either in the incorrect statement of the problem, or in the incorrect interpretation. I described the problem statement briefly in the first part, but I will write a separate article about this in detail. Or you’ll also get a series of articles.
Accordingly, I will consider the situation with an incorrect interpretation of the assignment.
To minimize such situations, take an interest in the progress in the process of work and not be satisfied with the answer in general phrases, but ask to check and "touch" the intermediate option. Of course, programmers and other professionals do not like to show incomplete, but look for a reasonable middle ground.
Example 1: the task consists of 90% of the search algorithm, the remaining 10% - of writing code and layout. Obviously, after half the time, you do not need to ask to show something visual. It is better to limit your request to describe the algorithms in question. Perhaps they will have logical errors or empty spaces. Perhaps questions of answers and solutions will be written right away. But this will allow you to see that the performer is engaged in the task. Sometimes this allows even prompting in time the right direction, if the customer is guided in the solutions.
Example 2: layout of 5 pages. Nested sample pages require up to a third of the time required for layout of the main page. It turns out that after half the deadline only one main thing will be ready. See only the main one. If you immediately point out inaccuracies, time will be saved during the final acceptance.
In cases where it is impossible to see the intermediate option, a dialogue with open questions becomes a measure of control, answering which, the contractor will tell in detail about the selected solution methods. Advantage - along the way there will be questions that are useful to discuss immediately, and not during acceptance.
Since the described situations and examples are not exhaustive, the optimal solution would be to coordinate control methods with a freelancer before starting work. Then both the freelancer and the customer will know when and what to show or check.
If the task is small (4 hours or less), pulling the artist makes little sense. It’s easier to wait and discuss the outcome.
Another situation is the executor against interim reports, but if the customer is confident in the successful completion of the task, there is no need to invent anything extra. It is enough to check only after completion of work.
I will pay attention to different volumes
У записи 11 лайков,
0 репостов,
202 просмотров.
0 репостов,
202 просмотров.
Эту запись оставил(а) на своей стене Михаил Воеводский
