Есть формулировки задач, после которых разработчик 1С сразу понимает: быстро не будет.
“Не хотим заполнять документ, это долго. Нужно, чтобы когда его создали, он откуда-то подтянул все данные, заполнился и записался”.
На первый взгляд запрос понятный. Пользователи устали заполнять документ вручную. Хотят автоматизацию. Всё логично.
Но для разработки это пока не задача. Это направление мысли.
Потому что за словами “откуда-то подтянул” спрятаны десятки вопросов:
- из какого объекта брать данные;
- из какой базы;
- по какому ключу искать;
- что делать, если найдено несколько вариантов;
- что делать, если данные не найдены;
- какие поля заполнять всегда, а какие только при условиях;
- нужно ли записывать документ автоматически;
- кто имеет право запускать заполнение;
- что делать при ошибке;
- как пользователь поймет, что документ заполнен корректно;
- какой результат будет считаться готовым.
Если эти вопросы не задать до разработки, они всё равно появятся. Только позже: во время реализации, на демо, при приемке или уже после запуска.
И вот тогда задача становится дорогой.
Мутная задача всегда становится дорогой.
Дорогой не обязательно по бюджету в договоре. Она становится дорогой по часам разработчика, количеству уточнений, переделкам, потерянному фокусу команды и нервам заказчика.
В этой статье разберу, какие требования нужны 1С-разработчику, почему “сделайте удобно” — не задача, и как простая карточка постановки может сэкономить больше времени, чем кажется.
Разработчик не против вопросов. Он против гадания
Иногда кажется, что разработчик придирается, когда начинает задавать уточняющие вопросы.
“А зачем это нужно?” “А какой сценарий?” “А что делать, если данных нет?” “А кто будет проверять результат?” “А какие права у пользователя?” “А в какую систему это должно попасть после согласования?”
Со стороны может выглядеть так, будто человек усложняет. Но чаще всего он пытается не написать код в пустоту.
Разработчик может разобраться в сложной задаче. Может прочитать чужой код. Может отладить запрос. Может найти ошибку в проведении документа. Может сделать интеграцию, обработку, отчет, печатную форму или регламентное задание.
Но он не должен быть телепатом.
Если в задаче нет сценария, разработчик сам начинает достраивать картину:
- как пользователь будет работать;
- какие данные нужны;
- что считается правильным;
- какие исключения возможны;
- что делать при ошибках;
- какие права нужны;
- кто принимает решение.
И вот тут начинается риск.
Разработчик может додумать логично. Но не так, как нужно бизнесу.
А потом на демо прозвучит классическое:
“Всё хорошо, но нам нужно немного другое”.
И это “немного другое” иногда означает не правку одного реквизита, а переделку половины алгоритма.
Плохая постановка задачи выглядит невинно
Плохая задача не всегда выглядит как полный хаос. Часто она выглядит вполне рабочей.
Например:
“Нужно сделать, чтобы после согласования данные отсюда попадали в другую систему 1С”.
Вроде понятно: есть согласование, есть данные, есть другая система 1С. Нужно передать.
Но для разработки этого мало.
Нужно понять:
- что значит “после согласования”;
- какой именно статус считается финальным;
- какие данные передавать;
- в каком виде передавать;
- в какую базу или контур;
- как сопоставлять объекты;
- что делать при повторном согласовании;
- нужно ли обновлять уже переданные данные;
- что делать при ошибке передачи;
- кто должен увидеть ошибку;
- можно ли отправить повторно;
- какие права нужны пользователю;
- какой лог должен остаться.
Без этих уточнений задача звучит коротко, но внутри нее может быть полноценная интеграционная логика.
И если начать разработку сразу, почти гарантированно появятся сюрпризы.
Причем сюрпризы не из-за того, что кто-то плохо работает. Просто в начале не договорились о важном.
Самое частое, чего не хватает в 1С-задачах
По моему опыту, в задачах чаще всего не хватает не красивого описания, а нескольких очень практичных вещей.
1. Сценария работы
Сценарий — это не формальность.
Для 1С он часто важнее длинного общего описания. Нужно понимать, кто, где и в какой последовательности выполняет действия.
Плохо:
“Нужно автоматизировать заполнение документа”.
Лучше:
“Менеджер создает документ X из карточки клиента. При нажатии кнопки система ищет активный договор, последнюю заявку и действующие условия. Если найден один договор — заполняет автоматически. Если договоров несколько — показывает выбор. Если договора нет — выводит сообщение и не записывает документ”.
Во втором варианте уже можно работать.
2. Условий “если то, а если это”
В 1С почти никогда не бывает только одного идеального сценария.
Всегда появляются варианты:
- а если данных нет;
- а если данных несколько;
- а если пользователь без прав;
- а если документ уже согласован;
- а если документ помечен на удаление;
- а если организация другая;
- а если период закрыт;
- а если нужно перезаполнить;
- а если часть данных уже изменили вручную.
Если эти ветки не обсудить заранее, разработчик всё равно примет решение. Просто сам.
А потом может выясниться, что бизнес ожидал другое.
3. Цели задачи
Редко, но очень важно: в задаче не всегда пишут, для чего вообще это нужно.
А зря.
Когда разработчик понимает цель, он может предложить решение лучше.
Иногда в процессе нормального сбора требований выясняется, что функционал вообще не нужен. Пользователь просил доработку, потому что видел только один путь решения. А после уточнений оказалось, что можно изменить инструкцию, использовать типовой механизм, поправить настройку или сделать маленькую корректировку вместо большой разработки.
Такие случаи особенно ценны.
Лучшие часы разработки — это иногда те часы, которые удалось не потратить на ненужную разработку.
4. Прав пользователей
Права часто вспоминают слишком поздно.
Задачу сделали. На тесте у разработчика всё работает. На демо у аналитика тоже. А потом реальный пользователь говорит:
“У меня кнопки нет”.
Или:
“Документ не записывается”.
И начинается отдельное расследование: роль, RLS, доступ к организации, права на справочник, доступность команды, ограничения формы, настройки пользователей.
Если функционал зависит от прав, это нужно учитывать до разработки.
5. Критериев приемки
Если не договориться, как проверяем результат, спор почти неизбежен.
Разработчик может считать, что задача выполнена: кнопка есть, документ заполняется, запись проходит.
Пользователь может считать, что задача не выполнена: не учли второй сценарий, нет удобного сообщения, не передается часть данных, не работает для другой организации.
Критерии приемки нужны не для бюрократии.
Они нужны, чтобы до разработки договориться, где финиш.
Большое ТЗ нужно не всегда
Я не считаю, что на каждую 1С-задачу нужно писать огромный документ.
Иногда большое ТЗ только замедляет работу. Особенно если задача небольшая, команда понимает контекст, а процесс уже знаком.
Но даже маленькая задача должна быть достаточно ясной.
Для меня главный критерий нормальной постановки простой:
После чтения задачи разработчик должен с минимумом вопросов взять ее в реализацию и не возвращаться к требованию по каждому шагу.
Это не значит, что вопросов вообще не будет. Вопросы будут почти всегда.
Но есть разница между нормальными уточнениями и ситуацией, когда разработчик вообще не понимает, что нужно делать.
| Плохая постановка | Нормальная рабочая постановка |
|---|---|
| “Сделать удобно” | Описан конкретный сценарий пользователя |
| “Пусть само заполнится” | Указано, откуда брать данные и что делать при исключениях |
| “Передать в другую 1С” | Понятно, какие данные, когда, куда и по какому правилу передавать |
| “Система неправильно считает” | Есть пример, ожидаемый результат и фактический результат |
| “Добавить кнопку” | Понятно, кто нажимает, что происходит и как проверить итог |
| “Нужно срочно” | Понятно, какой бизнес-риск и почему срок именно такой |
Хорошая постановка — это не всегда длинный документ.
Хорошая постановка — это когда в ней есть достаточно информации для действия.
Шаблон простой карточки задачи
Я бы начинал не с тяжелого ТЗ, а с простой карточки.
В большинстве случаев для первичной постановки 1С-задачи достаточно такого набора.
| Поле | Что написать | Зачем нужно |
|---|---|---|
| Название задачи | Кратко и конкретно | Чтобы по названию было понятно, о чем задача |
| Что нужно сделать | Какие действия ожидаются от разработчика | Чтобы не было размытых формулировок |
| Зачем это нужно | Бизнес-цель или проблема пользователя | Чтобы разработчик понимал смысл, а не только кнопку |
| Какую проблему решаем | Что сейчас неудобно, долго, ошибочно или рискованно | Чтобы отличить реальную боль от пожелания |
| Ожидаемый эффект | Экономия времени, снижение ошибок, ускорение процесса | Чтобы понимать ценность задачи |
| Сценарий работы | Кто, где и в какой последовательности работает | Чтобы разработчик видел реальный процесс |
| Данные | Откуда брать, куда записывать, какие поля участвуют | Чтобы не гадать по объектам и реквизитам |
| Исключения | Что делать, если данных нет, их несколько или они некорректны | Чтобы не ловить сюрпризы после запуска |
| Права | Кто должен видеть и выполнять действие | Чтобы не выяснить на приемке, что пользователь не может работать |
| Критерии приемки | Как проверяем, что задача выполнена | Чтобы не спорить на демо |
| Контактное лицо | Кто отвечает за требования и проверку результата | Чтобы у задачи был владелец |
Если задача совсем небольшая, часть полей можно объединить.
Но цель остается той же: не заставлять разработчика восстанавливать бизнес-процесс по обрывкам фраз.
Пример: автоматическое заполнение документа
Возьмем тот самый запрос:
“Не хотим заполнять документ, это долго. Нужно, чтобы когда его создали, он откуда-то подтянул все данные, заполнился и записался”.
В плохом варианте задача так и уходит в разработку.
В нормальном варианте она превращается в карточку.
| Название | Автоматически заполнять документ “Заявка на оплату” по данным договора и счета |
| Что нужно сделать | При создании документа добавить команду заполнения. По выбранному контрагенту и договору подтянуть реквизиты, сумму, статью расходов и ответственное подразделение. |
| Зачем это нужно | Пользователи вручную переносят данные из нескольких мест, тратят время и допускают ошибки. |
| Сценарий | Пользователь создает документ, выбирает контрагента, нажимает “Заполнить”. Система ищет данные, заполняет поля и показывает результат. |
| Если данных нет | Документ не записывать автоматически, показать сообщение с перечнем незаполненных данных. |
| Если найдено несколько вариантов | Показать пользователю выбор, не подставлять случайное значение. |
| Права | Команда доступна пользователям роли “Бухгалтер” и “Ответственный за оплату”. |
| Критерий приемки | На трех тестовых примерах документ заполняется корректно, при отсутствии данных выводится понятное сообщение, лишние документы не записываются. |
Это всё еще не огромный документ.
Но это уже задача, которую можно оценивать, разрабатывать и проверять.
Пример: “пусть после согласования попадет в другую 1С”
Теперь другой типичный запрос:
“Нам нужно, чтобы что-то отсюда после согласования попало в другую систему 1С”.
В этой фразе опасно почти каждое слово.
“Что-то” — это какие данные?
“Отсюда” — из какого объекта, документа, регистра, процесса?
“После согласования” — после какого статуса, этапа, визы, действия?
“Попало” — создалось, обновилось, отправилось в очередь, записалось в файл, передалось через обмен?
“В другую систему 1С” — в какую базу, в какой объект, по каким правилам сопоставления?
Вот как такая задача должна уточняться.
| Вопрос | Почему без него опасно |
|---|---|
| Какой объект является источником? | Иначе непонятно, откуда брать данные |
| Какой статус считается финальным согласованием? | Можно отправить данные слишком рано или слишком поздно |
| Какие реквизиты передаются? | Разработчик может передать неполный набор |
| Куда именно записывать в другой базе? | Нужно понимать объект-получатель и правила заполнения |
| Как сопоставлять контрагентов, договоры, организации? | Без сопоставления возможны ошибки и дубли |
| Что делать при повторном согласовании? | Можно создать дубль вместо обновления |
| Что делать при ошибке передачи? | Нужен лог, уведомление и возможность повторить |
| Кто контролирует результат? | Иначе обмен может падать тихо |
После таких вопросов иногда выясняется, что задача больше, чем казалась.
И это не плохая новость.
Плохая новость — узнать это после оценки и начала разработки.
Ошибки постановки, которые приводят к переделкам
Переделки редко появляются из ниоткуда.
Чаще всего они возникают из-за того, что на входе не обсудили важные детали.
Ошибка 1. Неверно описан процесс
Если процесс описан неправильно, разработчик автоматизирует неправильную логику.
Потом начинаются экстренные исправления и уточнения:
“Мы думали, что процесс такой, но на самом деле сначала должно быть согласование, потом проверка, потом отправка, а для этой группы пользователей вообще отдельное правило”.
Здесь проблема уже не техническая. Код может быть написан хорошо. Просто автоматизировали не тот процесс.
Ошибка 2. Не описаны исключения
Идеальный сценарий обычно работает быстро.
Но реальная жизнь начинается с исключений:
- не заполнен реквизит;
- несколько подходящих значений;
- пользователь без прав;
- закрытый период;
- документ уже проведен;
- данные пришли повторно;
- объект уже существует;
- часть данных изменилась после согласования.
Если исключения не описаны, разработчик выбирает поведение сам. А это почти всегда риск.
Ошибка 3. Не учтены права
Права в 1С — не мелочь.
Функционал может работать у разработчика и не работать у пользователя.
Если задача затрагивает документы, справочники, команды формы, отчеты или обмены, нужно заранее понимать:
- кто запускает действие;
- какие роли у пользователя;
- доступны ли нужные объекты;
- есть ли ограничения по организации или подразделению;
- нужно ли показывать команду всем или только части пользователей.
Ошибка 4. Нет владельца требования
Если у задачи нет владельца, она начинает расползаться.
Один пользователь говорит одно. Второй — другое. Руководитель приходит на демо и добавляет третье. Потом появляется смежный отдел и говорит, что без их сценария работать нельзя.
В какой-то момент разработчик уже не понимает, чью версию процесса он реализует.
У задачи должен быть человек, который отвечает за итоговое решение.
Ошибка 5. Нет критерия готовности
Если нет критерия приемки, финиш плавает.
Сегодня задача готова, потому что кнопка появилась. Завтра не готова, потому что не учли второй сценарий. Послезавтра не готова, потому что нужно еще одно поле. Потом оказывается, что нужно передать данные в другую базу.
Критерий готовности нужен не для галочки.
Он защищает и разработчика, и заказчика.
Почему плохие требования увеличивают часы
Плохо собранное требование почти всегда увеличивает трудозатраты.
Причем не только на саму разработку.
Часы уходят на:
- повторные уточнения;
- созвоны;
- переписки;
- переделку алгоритма;
- исправление ошибок после демо;
- повторное тестирование;
- обновление связанных механизмов;
- экстренные исправления;
- объяснение, почему оценка выросла.
Особенно это важно, если часы разработчика дорогие.
Если специалист может за это время решить сложную задачу, закрыть инцидент, оптимизировать процесс или убрать техдолг, странно тратить его часы на восстановление требований по кусочкам.
Часы разработчика нужно использовать максимально эффективно. Плохая постановка задачи — один из самых простых способов эти часы сжечь.
Иногда кажется, что быстрее “сразу отдать в разработку”, чем тратить время на вопросы.
Но это иллюзия.
Вопросы до разработки дешевле, чем переделки после нее.
Когда сбор требований отменяет разработку
Есть интересный эффект: качественный сбор требований иногда приводит к тому, что задачу вообще не нужно делать.
У меня были такие случаи.
Сначала приходит запрос на функционал. Кажется, нужна разработка. Начинаешь задавать вопросы:
- зачем это нужно;
- какую проблему решаем;
- как сейчас работает процесс;
- как часто возникает ситуация;
- кто пользователи;
- какой эффект ожидается;
- есть ли типовой способ;
- можно ли решить настройкой или инструкцией.
И постепенно выясняется, что разработка не нужна.
Иногда достаточно изменить порядок работы. Иногда — настроить типовой механизм. Иногда — объяснить пользователям существующий функционал. Иногда — поправить отчетность или добавить инструкцию. Иногда — перенести задачу в другую, уже существующую доработку.
Это не значит, что аналитик “зарубил” задачу.
Это значит, что команда сэкономила время.
Хороший сбор требований не всегда приводит к разработке. Иногда он приводит к правильному отказу от разработки.
Минимальный шаблон постановки задачи
Если нужен совсем простой шаблон, я бы оставил такой вариант.
| 1. Название задачи | Кратко и конкретно: что меняем и где. |
| 2. Что нужно сделать | Описание действия без размытых формулировок. |
| 3. Зачем это нужно | Бизнес-цель, боль пользователя, причина задачи. |
| 4. Какой сценарий работы | Кто, где, когда и в какой последовательности работает. |
| 5. Какие данные участвуют | Документы, справочники, реквизиты, отборы, периоды, источники. |
| 6. Какие есть исключения | Что делать, если данных нет, их несколько, они некорректны или пользователь без прав. |
| 7. Какие права нужны | Кто видит, кто запускает, кто редактирует, кто проверяет. |
| 8. Ожидаемый эффект | Экономия времени, снижение ошибок, ускорение процесса, отказ от ручной операции. |
| 9. Критерии приемки | Как понять, что задача выполнена правильно. |
| 10. Контактное лицо | Кто отвечает за требование и принимает результат. |
Такой шаблон не решит все проблемы.
Но он сильно снижает вероятность, что разработчик будет гадать, а заказчик — удивляться результату.
Что должен понять руководитель или заказчик
Плохая постановка задачи — это не проблема только разработчика.
Это риск для сроков, бюджета и результата.
Если задачу плохо собрали, команда почти неизбежно заплатит за это позже:
- сроками;
- дополнительными часами;
- переделками;
- раздражением пользователей;
- экстренными исправлениями;
- потерей доверия к разработке;
- ощущением, что “разработчики опять сделали не то”.
Но часто разработчики сделали именно то, что смогли понять из задачи.
Если на входе была мутная формулировка, на выходе редко получается точное решение.
Поэтому нормальные вопросы на старте — это не бюрократия.
Это экономия.
Экономия времени разработчика, времени пользователей, времени аналитика и времени руководителя, который потом не будет разбирать, почему задача опять выросла в два раза.
План улучшения постановки задач за 30 дней
Не обязательно сразу внедрять тяжелый процесс управления требованиями. Можно начать проще.
Неделя 1. Собрать типовые проблемы
- Посмотреть последние задачи, где было много уточнений.
- Найти задачи, которые вернулись на переделку.
- Выписать, какой информации не хватало на старте.
- Отметить повторяющиеся формулировки вроде “сделать удобно” и “поправить процесс”.
Неделя 2. Сделать короткий шаблон
- Ввести обязательные поля: цель, сценарий, данные, исключения, права, приемка.
- Не делать шаблон слишком большим.
- Проверить его на 3–5 реальных задачах.
- Убрать лишнее и оставить то, что реально помогает.
Неделя 3. Договориться о правилах входа
- Не брать в разработку задачи без минимального сценария.
- Фиксировать владельца требования.
- Отделять новые требования от замечаний по текущей задаче.
- Переоценивать задачу, если меняется объем.
Неделя 4. Закрепить практику
- Разобрать с командой первые результаты.
- Показать заказчикам примеры хороших и плохих постановок.
- Собрать типовые вопросы разработчика в чек-лист.
- Добавить шаблон в рабочий процесс.
Цель не в том, чтобы заставить всех писать идеальные ТЗ.
Цель проще: чтобы разработчик мог взять задачу и понимать, что именно нужно сделать, зачем это нужно и как проверить результат.
Главный вывод
“Сделайте удобно” — не задача.
“Пусть само заполнится” — не задача.
“Что-то отсюда должно попасть в другую 1С” — тоже еще не задача.
Это хорошие стартовые формулировки для обсуждения. Но плохие формулировки для передачи в разработку.
Нормальная 1С-задача должна отвечать хотя бы на несколько вопросов:
- что делаем;
- зачем делаем;
- кто пользователь;
- какой сценарий;
- какие данные участвуют;
- какие есть исключения;
- какие права нужны;
- как проверяем результат;
- кто принимает решение.
Чем мутнее задача на входе, тем дороже она становится на выходе.
И наоборот: чем лучше собраны требования, тем меньше лишних уточнений, переделок, споров на демо и экстренных исправлений.
Я бы оставил одну мысль:
Разработчик не должен быть телепатом. Если бизнес хочет точный результат, задачу нужно формулировать так, чтобы ее можно было не угадывать, а реализовывать.
Это не бюрократия.
Это уважение к времени команды.