Вы уже сто раз просили «сделать что-то с этим неудобным отчетом» или «добавить важную колонку в документ», но всё по-прежнему на месте? Знакомо? Разработчики будто вас не слышат, а работа стоит. На деле проблема чаще всего не в том, что они «не хотят», а в том, как мы ставим задачу.
Разберёмся, как говорить на одном языке с программистом — и вы увидите, что большинство вопросов решается быстро и без конфликтов, а недоработки в 1С, которые мешали нормально работать годами, будут решены.
Требование «Сделайте, чтобы было удобно» — не годится
Главная ошибка заказчиков — расплывчатые формулировки. «Сделайте красиво», «сделайте, как было», «сделайте удобно» — разработчику нечего с этим делать. Он либо недопонимает, либо трактует по-своему, а вы потом удивляетесь, почему что-то в вашей 1С работает «не так». И не стоит надеяться, что разработчик проявит инициативу и станет выяснять у вас, что же конкретно нужно. Такого просто не бывает. А значит, эту самую инициативу лучше взять в свои руки. Возьмите паузу и опишите задачу предельно конкретно. Самый простой формат — зафиксировать два состояния:
Если задача объёмная, разбивайте её на части. Но начать всё равно нужно с описания «как есть» и «как должно быть». Это экономит недели согласований.
Дробите крупную задачу на мелкие: разработчики боятся «крупняка»
Когда задача большая, попросите разработчика разбить её на этапы: сначала описание, потом макет, затем тестовая версия. Если ТЗ писать некому — просите разработчика оформить черновой вариант. Это хороший способ понять, что он вообще воспринял из ваших слов, а что ускользнуло от его внимания.
Чек-лист понятного ТЗ для разработчика
Напишите:
Что сейчас происходит:
Что именно мешает работе:
Как должно работать после доработки:
Пример (скриншот, документ, шаги):
Что считается готовым результатом:
ТЗ на словах никогда не будет взято в работу
Устные просьбы — в коридоре, по телефону или в чате — почти гарантированно потеряются. Разработчик забудет о них не из вредности, а потому что не обязан их фиксировать. И, конечно, ни один специалист IT-отдела не готов взять на себя ответственность за решение задачи, если она официально никак «не проведена».
Чтобы задача действительно попала в работу, оформляйте её:
- В корпоративной системе учёта задач.
- В письме.
- В чате — но так, чтобы её можно было найти.
Если это письмо — ставьте в копию руководство: своё и IT-отдела. Это простой способ убедиться, что задача не утонет в переписке.
Письмо или карточка задачи должны содержать:
- Сроки — дату начала работы и желательную дату завершения.
- Ответственного — или, как минимум, список кандидатов, если письмо отправляется руководству IT-отдела.
- Чёткое описание результата (вложите ТЗ или заполненный чек-лист ТЗ для разработчика).
- Вопрос разработчику или его руководству о точных сроках выполнения, а также о том, приоритетна ли для отдела ваша задача.
Совет: Если разработчик — внутренний сотрудник, попросите IT-руководителя включить задачу в официальный бэклог. Это отличный способ «подсветить» её в их рабочем плане, а не оставлять «где-то в списке на дне бэклога»
Делите задачу на этапы — так вы сможете контролировать выполнение
Даже если задача понятная, слишком крупная доработка легко «зависает». Разработчик оценивает её как «большую, не меньше чем на месяц», начинает делать ее, бросает, отвлекаясь на срочные и мелкие «задачки». Задача становится потеряшкой из-за того, что не каждый разработчик готов разобрать ее на отдельные этапы и составить график их завершения. А значит — это нужно сделать за него или вместе с ним разбивку большой задачи на этапы и составить график, в соответствие с которым эти этапы будут завершаться. Например:
- Подготовка технического задания — 2 дня.
- Создание макета или прототипа — 3 дня.
- Первая версия для проверки — через неделю.
Сам по себе график неплохо мотивирует разработчика не откладывать в долгий ящик выполнение задачи. Усилить мотивацию поможет просьба демонстрировать результаты по каждому этапу, пусть они даже сырые. А если этап задерживается, задайте простой вопрос: «Что именно сейчас мешает закончить шаг? Есть ли что-то, что я могу уточнить или предоставить?»
Договоритесь о приоритете вашей задачи— иначе она всегда будет «после всех остальных»
У разработчиков редко бывает пустой список задач. Обычно это десятки запросов от разных отделов, и без четкого понимания приоритетов ваша доработка автоматически сдвигается вниз — как менее критичная.
Здесь важно не просто сказать «нам нужно срочно», а объяснить последствия. Разработчик — не ваш руководитель, он не может сам назначить приоритет. Зато он может поставить вашу задачу выше внутри своей очереди, если понимает важность.
Что сделать:
Обоснуйте, почему задача важна: влияет ли она на сроки отчетности, ограничивает ли работу других сотрудников, увеличивает ли риски ошибки. И уточните прямо: «В какой части очереди сейчас стоит наша задача?» Когда место задачи в бэклоге проговорено, она перестает быть необязательной к выполнению.
С организационной точки зрения этого будет достаточно, чтобы добиться от разработчика решения вашей задачи. В следующий раз поговорим о том, как контролировать, правильность выполнения разработчиком вашей задачи.
Канал ведут специалисты компании «Фогсофт».