Как мы с разработчиком перестали говорить на разных языках

Привет, коллеги!
Сегодня хочу поделиться историей о том, как я научился выстраивать мосты между миром аналитики и разработки. Это не про формулы, а про понимание — самый ценный навык в нашей работе.

Проблема: Две планеты, один проект

На моём первом крупном проекте я столкнулся с классической ситуацией:

• Я, аналитик, составлял ТЗ в Excel с кучей формул и условных обозначений
• Разработчик получал файл и задавал вопросы, которые ставили меня в тупик:
  "А что значит эта ячейка с #ЗНАЧ! ?"
  "Почему здесь массив из 1000 строк, если нужны только итоги?"
  "Где логика этого расчёта?"

Мы говорили на техническом языке, но совершенно не понимали друг друга.

Решение: Создание общего языка

1. Визуализация вместо формул
   Перестал присылать "голые" расчёты. Теперь:
   Закрепляю шапку (CTRL+T)
   Выделяю цветом ключевые ячейки
   Добавляю комментарии (SHIFT+F2) с пояснениями типа:
   "Здесь специально оставлены нули — это валидные значения"
2. Работа с ошибками
   Вместо #Н/Д и #ЗНАЧ! теперь пишу явные заглушки:Copy=ЕСЛИОШИБКА(ВПР(...); "Нет в базе")
   
   Разработчик сразу видит проблемные места
3. Совместные "разборы полётов"
   Раз в неделю садимся на 15 минут:
   Я показываю, как данные должны выглядеть в идеале
   Он объясняет, какие форматы ему удобнее получать
   Завели общий глоссарий в OneNote с терминами

Результат: Неожиданные бонусы

1. Скорость
   Раньше на согласование ТЗ уходило 3 дня, теперь — 3 часа
2. Качество
   Разработчик стал предлагать улучшения логики расчётов
3. Карьера
   Научился говорить на языке бизнеса и техники одновременно

Что вынес для себя:

• Аналитик — это переводчик между данными и их реализацией
• Лучшая документация — та, которую понял разработчик
• Ошибки в формулах — часто не техническая, а коммуникационная проблема

📌 Ваш опыт?

1. Как вы организуете работу с разработчиками?
2. Какие фразы из их вопросов вас чаще всего ставят в тупик?
3. Поделитесь в комментариях своими лайфхаками коммуникации!

Подборка