Ошибки при оценке деятельности в 1С

Правильно диагностировать и определять ошибки при оценке работы в программном обеспечении 1С очень полезно для того, кто хочет стать руководителем проектов и верно оценивать деятельность в программе. Особенно способы такой оценки пригодятся для решения задач нестандартным методом.

Также понимание данной темы позволит определять, почему те или иные разработчики уходят из проектов, в том числе из высокооплачиваемых.

Ошибки удаленных разработчиков и программистов 1С

1. Неправильная оценка времени для тестирования и исправление

Важно уметь закладывать правильное время на тестирование и исправление ошибок. Данный навык приходит с опытом.

2. Неправильная оценка времени из-за беглого изучения ТЗ

Зачастую пониманию технического задания требуется уделять немало времени, а также разные детали проявляются только во время выполнения работы. Поэтому следует рассчитывать время с запасом и не делать поспешных выводов. Также рекомендуется уточнять постановку задач у заказчика.

3. Неправильная оценка времени на подготовку

Для правильной оценки времени на работу надо знать о разных факторах, влияющих на процесс выполнения задач.

Например:

• где именно будет происходить работа;
• имеется ли база данных;
• получен ли доступ и т.д.

Каждый из подобных вопросов следует обработать, и в случае необходимости, выделить время на подготовку.

4. Неправильная оценка сдачи-приемки

Надо понять, как именно вы будете сдавать работу, и сколько конкретно времени для этого понадобится. Также бывают случаи, когда заказ принимают несколько человек, а не один.

5. Неправильная оценка окружения

Окружение значительно влияет на время разработки и может существенно выбить из графика. Следует задать разные вопросы и получить на них ответы.

Например:

• в каком хранилище конфигурации проходит работа;
• есть ли расширения;
• насколько понятен регламент.

Опытные разработчики советуют умножать время работы на 1.5 за каждую задачу, в выполнении которой у вас еще не было опыта.

6. Не выделены границы

Помимо задач в регламенте, роль играет человеческий фактор, детали, по которому следует проговорить заранее. Например, заказчик хочет, чтобы вся работа проводилась на его серверах и не удаленно, а разработчика это не устраивает. Будет неприятно узнать об этом, когда все уже готово к работе.

К сожалению, во время постановки задач зачастую недоговаривают множество важных деталей, причем не всегда это делается специально. Рекомендуется написать или сообщить заказчику обо всех своих особенностях. Например, о том, что вы работаете только из дома, и уже потом приниматься за ознакомление с детальной документацией и регламентом. Также опытные разработчики советуют выделить, что каждый тип деятельности должен оплачиваться и это надо проговорить. Многие заказчики считают, что определенные задачи входят в стоимость всей работы или вообще выполняются бесплатно.

С опытом ошибок с установкой границ будет все меньше, но полностью защититься от них нельзя.

Ошибки консультантов-аналитиков (методистов) 1С

Некоторые программисты и разработчики также выполняют задачи аналитиков-консультантов.

1. Указание последовательности действий

Следует максимально подробно расписать весь ход работы, чтобы сэкономить множество времени в будущем. Также это поможет лучше понять поставленную задачу и погрузиться в нее.

2. Нет резерва времени для исправления ошибок

От допущения ошибок не застрахован никто, так что стоит закладывать время на их исправление вне зависимости от сложности выполняемого заказа.

3. Нет резерва времени на сдачу и прием завершенных проектов

Требуется ли куда-то ехать, кому и каким образом будет сдана готовая работа, потратится ли время на ожидание заказчика? Эти и другие вопросы надо задать заранее, и в случае, если время на ожидание будет включать себя работу разработчика, нужно взять оплату и за простой.

4. Не учтены издержки транзакций

В деятельности разработчика 1С регулярно возникают простои времени. Будь то два часа между интервью с обсуждением конкретных задач, или ожидание на ответ по электронной почте.

В подобных ситуациях заказчику приходится платить за простой, ведь вы буквально теряете время и не занимаетесь ничем. Поэтому также рекомендуется обсудить с ним этот вопрос заранее. Возможно, получится договориться о принципах работы, при которых простоев и задержек будет меньше. Полностью от них избавиться вряд ли получится.

5. Нет фиксации результата

Требуется понимать и четко представлять результат завершенной работы, иначе качественной разработки не получится. Данный навык приходит с опытом, а пока его нет, следует прислушиваться к программистам или аналитикам с опытом. Можно даже показать почти завершенную работу другому разработчику. Наверняка он найдет, что посоветовать и исправить. Зачастую у новичков много ошибок даже в документации.

Ошибки при оценке последовательности действий в 1С

В мини проектах работает методист и 1-3 разработчика. Обычно руководителем выступает именно методист, который контактирует с заказчиком, формирует техническое задание, принимает работу всех разработчиков и сдает итоговый результат заказчику.

1. Неверно указана последовательность выполнения

Надо представить, как будет проходить процесс выполнения поставленных задач. Рекомендуется избегать моментов, когда на одного человека возлагается больше одной задачи, ибо это существенно уменьшит его работоспособность, ведь в процессе деятельности он и так будет выполнять несколько задач одновременно, дополнительной не надо точно.

2. Нет учета транзакционных задержек

Между аналитиком и программистами тоже нужно избежать задержек и ожидания, заранее сформировав график или договорившись о принципах работы. То же самое относится к взаимодействию между командой программистов.

3. Перегрузка ресурсов

Этот пункт лучше объяснить на примере. Допустим, есть задача на 9 месяцев, которую надо сделать за один месяц. Она не решается тем, что берется 9 программистов с делегированием полномочий между собой. При таком раскладе в лучшем случае она выполнится за полгода, а не 9 месяцев.

Суть в том, что нельзя загружать разработчиков на 100%. Лучше поддерживать нагрузку в районе 50-70%.

4. Ошибки в окружении

В деятельности нескольких разработчиков требуется оценивать, как и в каком окружении они будут взаимодействовать между собой. Например, если планируется объединять между собой различные конфигурации, следует учесть, что они могут конфликтовать друг с другом и мешать всей работе. Причем обнаруживать подобные ошибки в окружении лучше самостоятельно, не доводя их до заказчика.