ERP-баталии, сезон «Отчётность-конец-месяца».
— «Почему кнопка не работает?!» — бух Наталья колотит по клавише Enter.
— «Так и задумано», — Владимир-разработчик даже не поднимает глаз от конфигуратора.
У обоих горят сроки, но они будто обитают на разных планетах. Ниже — инструкция, как перестать устраивать айтишный апокалипсис за обедом и все-таки настроить мост между технарями и бизнесом.
Где ломается коммуникация
Разные «очки».
- Разработчик видит систему целиком: объекты, транзакции, зависимые модули.
- Пользователь видит задачу: «мне нужен отчёт ровно к полудню».
Разные ожидания
- Пользователь ждёт «волшебную кнопку».
- Разработчик — описанный бизнес-сценарий и тестовые данные
Один лист ≠ тысяча писем
Правило: любая хотелка описана в одном подробном ТЗ.
- Что болит («При перемещении товара остатки не обновляются сразу»).
- Как заметили (шаги, база, релиз, скрин/видео).
- Что считаем успехом («В отчёте “Остатки” цифры меняются сразу после проведения»).
Экономия: минус 10 писем и два круга «ещё раз объясните, что именно не так».
Формула «3 вопроса» для написания ТЗ
- Зачем? (какая бизнес-цель).
- Что болит? (конкретный пример/скрин/файл).
- Как проверим? (куда нажимать, что увидеть).
Практики коммуникации, которые работают
- Скринкаст. Видео или скриншоты вместо 20 сообщений «там ошибка».
- Тест-данные до старта. Пользователь присылает копию проблемного документа - разработчик не ищет «ту самую накладную».
- Демо-пятница. 15 минут раз в две недели: «показываем-трогаем» черновик.
- Один чат для обсуждений — сообщения не теряются по разным чатам, всё в одном месте.
Чек-лист для пользователя
- Проблема, не решение: «Не обновляется отчёт», а не «добавь кнопку».
- Информативный скрин + путь: где и как (важно чтобы скриншот отражал максимальное количество информации)
- Приоритет задачи: ставьте её заранее, а не «на завтра» — указывайте, блокирует ли она зарплату или может подождать до закрытия квартала.
- Поддержка: кто и как будет жить с этой кнопкой через полгода?
Чек-лист для разработчика
1.Проверить, нет ли уже похожего решения в 1С клиента.
Часто нужная функция встроена или скрыта за другой кнопкой, прежде чем писать доработку, стоит убедиться, что велосипед не изобретён ранее.
2. Выяснить цель бизнеса (зачем).
3. Перевести на язык объектов 1С (что именно и где).
4. Согласовать с руководителем или заказчиком предполагаемое решение.
Например, вы планируете вывести кнопку для запуска расчёта вручную, а заказчик ожидал, что всё будет работать автоматически «по таймеру». Согласование на этом этапе избавит обе стороны от сюрпризов и переделок.
5. Сделать минимум один тест с реальными данными.
6. Написать или провести мини-инструкцию (2 строки — куда нажать).
7. Держать заказчика в курсе статуса раз в 2-3 дня (при возникновении проблем писать и разбирать их сразу!)
8. Резюмируйте каждую дополнительную встречу или «маленькую» просьбу.
После созвона или личной беседы фиксируйте итоги письмом / комментарием в задаче: что изменилось, кто согласовал. Это спасает от «а кто сказал перекрасить колонку?» — когда программист потратил полдня на доработку, а главный бухгалтер видит её впервые.
Итог: один язык — это язык результата
Когда стороны обсуждают цель и конкретику, а не «кто виноват», задачи решаются быстрее и дешевле, бизнес получает кнопки без боли, а разработчик — код без хаоса.