Работа in-house (на фикси) в среде 1С имеет свою ярко выраженную специфику. Разработчик находится внутри компании, знает её процессы и сотрудников лично. С одной стороны, это упрощает коммуникацию, с другой — порождает классическую проблему: пользователи считают, что программист обязан читать их мысли, знать все нюансы работы отделов по умолчанию и предвидеть любые нестыковки. Часто возникает ситуация, когда после сдачи задачи заказчик делает круглые глаза и заявляет: «Я имел в виду совсем другое!» или «Это же само собой разумеется, почему этого нет в программе?».
Перед каждым разработчиком на фикси встает дилемма: пытаться заставить пользователей писать подробные требования самостоятельно или взять эту рутину на себя, отдавая готовые документы лишь на утверждение. Давайте подробно разберем оба подхода, проанализируем лучшие практики ИТ-индустрии и выработаем работающий регламент, который защитит вас от бесконечных переделок и обвинений в «некачественной» работе.
Попытка заставить рядового бухгалтера, менеджера по продажам или даже начальника склада написать полноценное Техническое Задание (ТЗ) обречена на провал. Пользователи не знают и не должны знать архитектуру 1С. Они мыслят процессами на своем рабочем месте, а не понятиями структуры метаданных. Если вы обяжете их заполнять сложные шаблоны, вы столкнетесь с двумя проблемами:
Однако полностью освобождать пользователей от фиксации их «хотелок» тоже нельзя. Решением является четкое разделение зон ответственности и перевод требований на разные уровни.
Чтобы выстроить экологичный и бесконфликтный процесс, давайте разделим требования на три уровня. За каждый уровень отвечает свой человек:
Чтобы облегчить пользователям задачу формулирования бизнес-требований, дайте им простые и понятные шаблоны, заимствованные из методологии Agile.
Пользователь описывает свою потребность по строго заданной формуле:
«Как [Роль/Должность], я хочу [Действие в программе], чтобы [Бизнес-цель]»
Рассмотрим конкретные примеры:
Если задача чуть сложнее, попросите пользователя описать пошаговый алгоритм его идеальной работы в программе (без привязки к коду):
ЗаказКлиента.Давайте по шагам разберем наиболее эффективную схему взаимодействия, которая отлично зарекомендовала себя на практике в крупных компаниях:
Шаг 1. Подача заявки заказчиком.
Пользователь заводит задачу в хелпдеске (или отправляет на почту) короткое описание своей потребности в формате User Story.
Шаг 2. Интервьюирование и сбор требований.
Разработчик проводит беседу с заказчиком. На этом этапе крайне полезно использовать следующие техники:
Шаг 3. Составление ТЗ в терминах системы.
Вы сами пишете лаконичное ТЗ, где фиксируете интерфейсные решения (можно набросать макет формы прямо в конфигураторе на пустых формах или в Excel и приложить скриншот) и алгоритмы работы программы.
Шаг 4. Письменное утверждение.
Вы отправляете ТЗ заказчику на согласование. Важный момент: приступать к разработке можно только после получения однозначного письменного согласия (подписи на бумаге или ответа «Согласовано» в корпоративной почте/трекере задач).
Даже при наличии ТЗ вы можете столкнуться с тем, что заказчик начнет обвинять вас в ошибках, когда продукт будет готов. Разберем правила «самообороны» для фикси-разработчика.
Если вы обсудили задачу устно в коридоре или по телефону, сразу после разговора напишите пользователю письмо-резюме:
«Иван Иванович, по итогам нашего разговора фиксирую задачу: делаем автоматическую рассылку отчета по остаткам каждый понедельник в 9:00 на ваш email. Если все верно, подтвердите, пожалуйста, в ответном письме, и я беру задачу в работу».
Если Иван Иванович проигнорирует письмо, вы имеете полное право не приступать к задаче, сославшись на отсутствие подтверждения требований.
Внесите в ваш внутренний регламент ИТ-отдела (или просто озвучьте как жесткое правило работы) следующий пункт:
«Если требования в ТЗ могут трактоваться двояко, а заказчик не уточнил детали до начала разработки, исполнитель имеет право реализовать функционал по своему усмотрению. Любые последующие изменения будут выполняться в рамках новой задачи».
Если руководители отделов или топ-менеджеры принципиально отказываются писать требования и подписывать согласования, используйте две хитрости:
В современной разработке итерационный подход (когда программа дорабатывается по результатам тестирования пользователями) — это норма. Но если заказчик считает каждую итерацию вашей ошибкой, необходимо документировать процесс сдачи-приемки.
При передаче очередной сборки на тестирование пишите сопроводительное письмо следующего содержания:
«Функционал по ТЗ от [Дата] реализован в полном объеме и перенесен на тестовую базу. Ваши новые пожелания (например, добавить дополнительную колонку или изменить логику расчета скидки), возникшие в ходе демонстрации, не были предусмотрены первоначальным ТЗ. Мы с удовольствием реализуем их в рамках следующей итерации (Запрос на изменения / Change Request) после завершения приемки текущего этапа».
Это позволит вам четко разграничить ваши реальные ошибки (когда программа работает не так, как написано в ТЗ) и новые «хотелки» заказчика, которые он пытается выдать за исправление ваших недоработок.