При внедрении какого-либо технологичного решения одними из самых очевидных убийц времени являются 10% никому не нужных деталей ТЗ (технического задания), которые, однако, попали туда по самым разным объективным и субъективным причинам. Обычно это незначительные корректирующие правки, например, величина отступа или размер шрифта в шаблоне договора, радиус округлости кнопок в пользовательском интерфейсе, раздел “промежуточный итог” в отчете, которые превращают сроки выполнения задачи из минут и часов в дни и недели.
Вот простой пример: имеем комплект документов на подпись по кредитной сделке. В одном из документов пункты договора перечисляются не монолитным текстом, а в виде таблицы, а вдобавок ко всему, данный документ единственный во всем комплекте, у которого должны быть колонтитулы.
С точки зрения юриста, который этот документ составлял, проблем, при автоматической подстановке данных клиента в этот договор, возникнуть не должно, так как ms word умеет самостоятельно разбивать на страницы “длинные строки”. Да и с колонтитулами проблема возникла вовсе не у него, а в тот момент, когда все ответственные за комплект участники процесса передали свои документы (в виде разрозненных файлов, конечно) разработчику на стороне IT.
Разработчик же начинает ломать голову, как все эти документы объединить в один PDF-файл. 90% (да даже все 99%) работы выполняются за 2-3 часа, а оставшийся 1% составляют именно колонтитулы и таблица с “длинными непереносимыми строками”. Формальная оценка-тестирование конечно же выявляет, что работа не закончена, и надо шаблон переделать – визуально различие действительно очевидное.
А теперь представим, что у разработчика нет доступа к тому самому юристу, который этот документ составил, чтобы понять – случайно у него колонтитулы включились (а такое бывает, когда не глядя новый документ создаешь из старого), и табличка у него ради чего используется: ради визуального удобства, или ради исполнения требований ЦБ. В этом случае разработчику ничего не остается, кроме как потратить весь день на поиск нужных библиотек, которые умеют делать переносы таблицы на разные страницы или рисовать колонтитулы в нужном месте, а в худшем случае – писать решение самостоятельно, что грозит переносом задачи на пару дней.

Прилагаю для примера список причин, которые не несут никакой бизнес-, pr-, нормативной или другой выгоды, но ежедневно усложняют жизнь доблестным бойцам IT-фронта:
1. “мне нравится” (пример: цвет кнопки в интерфейсе не из стандартной палитры) – ситуация, когда создатель ТЗ пытается выразить свое творческое начало
2. “так и было” (пример: новое ТЗ, например на создание отчета, копипастится из старого, а лишние пункты не удаляются) – ситуация, когда пункт ТЗ “вроде и не нужен, но вроде и не мешает”
3. “так будет лучше” (пример: новый руководитель отдела “наводит красоту” в бизнес-процессах, не ознакомившись с рекомендациями IT, предоставленными при разработке текущего процесса) – ситуация, когда люди начинают искать поводы, чтобы создавать видимость своей работы, которые обычно сводятся к незначительным корректировкам уже имеющегося документа/функционала/процесса (тут, ей богу, если очень хочется поработать, то лучше бы с нуля все переделали – IT сами кое где в этом заинтересованы, а вот “незначительные изменения” – для исполнителя обычно хуже не придумаешь)
4. “пусть поработают” (пример: сознательное усложнение структуры) – ситуация, когда подразделения конфликтуют между собой, и одни сотрудники нарочно создают работу другим