Проектная документация - ЗЛО?

Часть людей не понимают смысла технического задания. Якобы его придумали IT-шники, чтобы защитить себя. С другой стороны программисты тоже не любят писать технические задания, спецификации и пр. проектные документы.

Например, в видео “Пример технического задания на разработку сайта“ от канала Yastudia (https://youtu.be/3UdGbkRKPPs?t=35) проговаривает следующие минусы тех.задания:

-Клиент не понимает Ваших задач и целей, а Вы не понимаете в продукции/процессах клиента. Необходимо долго описывать всё и выйдет сложный документ;

-ТЗ пишется долго;

-ТЗ не помощник, а щит против заказчика.

Зачем тогда мы тратим кучу часов на написание  технической документации? Разбираемся в требованиях? Рисуем какие-то схемки?

Давайте рассмотрим классический пример отсутствия проектной документации. Практически у каждого была история приведённая ниже, а если не было, то наверняка слышали!

“С компанией подрядчиком определялись не долго. С лёгкой руки директора была выбрана студия мужа подруги жены — «мировые ребята, Люся всегда о них хорошо отзывалась».  После первой же встречи было решено, что задача стоит совершенно простая — запилить сайт-визитку. Ребята уже 1000 раз такое делали и были полностью уверены, что справятся быстро и без проблем. На попытку Антона что-то сказать о планировании проекта  разработчики только улыбнулись: «Да чего тут думать? Тут делать нужно». [...] В конце собрания было решено, что сайт должен быть готов через полтора месяца и не минутой позже.

Проблемы начались почти разу: сперва, разработчики вернулись через 2 недели после вышеупомянутого собрания и принесли не то. Мой товарищ так им и сказал, после чего ребята обиженно ушли переделывать. Позднее, когда они пришли с более подходящим вариантом Иннокентия ждал новый сюрприз. В процессе демонстрации продукта коллегам он выяснил, что те представляли корпоративный сайт совершенно иначе. По их мнению всё нужно было срочно переделать.  Вот с этого момента начался Кешин персональный ад. Сперва он день ото дня ругался с коллегами, объясняя, что сайт-визитка не предполагает возможности прямой продажи продуктов через интернет и решает совсем другие задачи.[...]

В результате работа, которая должна была занять два месяца растянулась почти на полгода, бюджет проекта вырос в два раза, а Кеша в конечном итоге уволился из компании и начал свою карьеру в IT.”

https://iampm.club/blog/bez-tz-rezultat-hz/

Да-да, отсюда напрашивается весьма банальный вывод, что проектная документация  и техническое задание в частности закрепляют в понимании единый образ проекта и не даёт заказчику подкинуть дополнительных “хотелок”, а разработчику притащить сырой проект.

Теперь перейдём к другим плюшкам проектной документации.

Ещё в 2015 году ходила на собеседование в Сбертех. Они искали сотрудника, который сделает обратное ТЗ и опишет работу одной из их платформ, чтобы они смогли безопасно, насколько это возможно, перейти на новую платформу.

Тогда я подумала, что они странные люди, т.к. в энергетике у нас было всё чётко: запрос на изменения, спецификация, отчёт о тестировании, технологический паспорт. Конечно были и свои косяки, но документацию старались вести, чтобы понять как работает система. Особенно бдили изменения в расчётной части, т.к. любая поломка в ней или некорректная работа могла привести к миллионным счетам за электроэнергию. Журналисты и проверяющие до боли любят такие истории!

Прошли годы, новые команды, новые коллективы и теперь у меня члены команды не любят писать требования на разработку, а не говоря уже о  ТЗ и спецификации.

Обычно в трекере проектов задача открывается заказчиком или службой заказчика, а потом только заказчик пишет комментарии по проекту. Разработчик всё время молчит.

Однажды в рамках реализации одной из функций столкнулись с тем, что никто не знал правильно ли сейчас рассчитываются лимиты по банковским картам. Стали искать информацию, а как же на самом деле должны работать эти самые лимиты, т.к. заказчик утверждал, что система работает не корректно по определённым ситуациям. Откуда-то отыскали какую-то документацию и стали по ней смотреть корректность работы алгоритмов. Сначала выявили, что по части замечаний алгоритмы отрабатывают корректно и согласно  найденному документу. Потом стали опрашивать старожилов и у кого-то в переписке за “лохматые года” оказалась информация о требовании клиента изменить алгоритм расчёта лимита по некоторым категориям клиентов. В результате оказалось, что все ошибки, обозначаемые клиентом были не ошибками, а «‎хотелками».

Самое смешное, что отдел заказчика, который жаловался на ошибки алгоритма сам внёс изменения в алгоритм расчёта лимита.

Поскольку явной документации не было, то на все разбирательства ушло полгода!

Или ещё случай из “внутренней кухни”. Два месяца назад попросили протестировать фичу в СРМ. Открываю задачу, а там какая-то переписка заказчиков по установке требований и висит постановка задачи от заказчика. Всё! Никакого комментария от технолога или разработчика. На основании крупиц составляю чек-лист, тестирую, описываю баги. После моих замечаний разработчик проснулся и стал возмущаться, что они делали только 2 поля в интерфейсе, а остальное не их работа!

Надеюсь, из последних примеров было видно, что проектная документация помимо понимания общих договоренностей и границ проекта также помогает:

• развивать продукт, не откатываясь на ступень назад и не исследовать текущее состояние работы функционала/системы;
• благополучно сопровождать продукт, отделяя желания пользователей от реальных багов;
• удачно проводить тестирование функционала без отклонений в стороны от цели, не вызывая лишних споров.