Отношение к программистам 1С

Техническое задание

Давайте рассмотрим конкретное задание, которое поставил заказчик: Добавить галочку «Одобрено» в документ поступления товаров.

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

Разберём несколько ситуаций, в которых мы имеем двух программистов с разным подходом к работе.

Ситуация 1

Программист 1: Добавляет в документ реквизит и выносит эту галочку на форму. Время затраченное на работу - 30 минут.

Программист 2: Создаёт документ «Согласование», создаёт табличную часть «Товары», делает регистр накоплений «Согласование» и описывает логику заполнения табличной части. Время затраченное на работу порядка 10 часов.

Заказчик: Считает что программист №1 очень быстро выполнил поставленную задачу, в отличии от программиста №2 и готов платить ему в 2-3 раза больше. Ведь долгий программист №2 ещё и просит дополнительную оплату.

Ситуация 2

Бухгалтерия закрывает отчётный период.

Программист 1: Находит код, запрещающий изменение документов в закрытом периоде и правит его, чтобы можно было согласовывать документы. Задача сложная, программисту приходится повозиться и ориентировочно по времени он потратит 4 часа.

Программист 2: Ничего не делает.

Заказчик: Считает, что программист №1 работает и хочет ему помочь, а программист №2 не желает помогать.

Ситуация 3

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

Программист 1: Добавляет реквизит «Согласовал» с типом «Справочник.Пользователи», который заполняется хитрым алгоритмом обхода закрытого периода. Затраченное время - 1 час.

Программист 2: Ещё в первой ситуации добавил реквизит «Ответственный» в свой документ и снова ничего не делает.

Заказчик: Считает, что программист №1 делает как ему удобно. Просто, понятно и в списке документов можно видеть согласовано или нет. А программист №2 написал какой-то непонятный код и понапрасну заставляет людей создавать ещё документы.

Ситуация 4

Заказчик хочет, чтобы согласовывающие люди видели новые документы, которые им необходимо согласовать.

Программист 1: Добавляет обработку, форма, которая раз в несколько секунд делает запрос по документам, у которых не стоит галочка. Или ко всем документа, а потом в цикле сравнивает ТекщийПользователь и Согласовал. Обработка эта открывается ПриНачалеРаботыСистемы. Затраченное время на работу ещё 3 часа.

Программист 2: Делает отчёт, показывающий остатки регистра накоплений из первой ситуации. Потраченное время примерно 30 минут.

Заказчик: Думает, что программист №2 совсем не понимает, что требуется сделать, а программист №1 отлично справился с задачей. Всё просто и понятно.

Ситуация 5 (заключительная)

Возникает проблема, что часть товаров может быть согласована, а часть нет.

Программист 1: Переносит реквизиты «Согласовано» и «Согласовал» в табличную часть, в списке документов обрабатывает событие «ПриВыводеСтроки», чтобы определить согласован документ целиков или нет, переделывает алгоритм обхода даты запрета, переделывает обработку, которая открывается «ПриНачалеРаботыСистемы». Затраченное время равняется 6 часа.

Программист 2: Ничего не делает, потому что всё готово было в первой ситуации.

Заказчик: Начинает понимать, что программист №2 всё предусмотрел заранее, но реальную работу он видит у программиста №1. Поэтому в глазах заказчика побеждает программист №1 со счётом 4:1.

Какой итог

Программист №1 тратит 14,5 часов.

Программист №2 тратит 10,5 часов.

Заказчик получает, казалось бы, одинаковый результат, но программист №1 ему нравится больше, работать с ним выгоднее, он делает «красивее» и ставка у него ниже. Но заказчик ещё не знает что доработки программиста №1 будут добавлять 15 минут к каждому следующему обновлению конфигурации. Заказчик ещё не знает, что эти доработки приведут к серьёзным проблемам в будущей производительности и возможным блокировкам, с которыми программист №1 не сможет разобраться и опять напишет кучу всего подобного. И после кучу таких костыльных доработок заказчик начнёт от программиста №1 слышать ответы по типу «Мы не может вести учет в разрезе двух складов, а если доработаем - вся компания может встать», т.к. предусмотреть все сложные месте невозможно.

Вот и получается, что в глазах заказчика программист №1 - хороший, а программист №2 - плохой, а по результатам получается совершенно наоборот.

Выводы

Итак, очень сложно людям, далёким от программирования, определить хорошего от плохого программиста сложно, т.е. если программист исполняет все Ваши желания и при этом стоит не дорого, совершенно не означает, что он хороший. Даже если программист стоит дорого и делает долго, тоже не означает, что он хороший.

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

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