Стандартизация документации разработки
Разработка программ и автоматизированных систем — сложная, продолжительная и дорогостоящая деятельность, в которую вовлечены разные организации (или их подразделения), специалисты, начальники разного ранга. У них есть свои групповые и персональные интересы. Если что-то пойдет не так, например, на программный продукт не окажется спроса, или внедрение автоматизированной системы провалится, то пострадавшие примутся искать виноватого, а когда найдут, попытаются получить с него моральную и материальную компенсацию в максимально возможном размере. Поскольку оказаться крайним обычно никто не хочет, каждый заинтересован в как можно более четком ограничении собственной зоны и меры ответственности. На уровне финансов, сроков, имущественных прав и т.п. взаимные обязательства фиксируются в договорах. На содержательном уровне — в технической документации.
По завершении каждой стадии создания программы или автоматизированной системы заказчик и разработчик фиксируют полученные результаты в технической документации и утверждают последнюю. Это линия отреза. После того, как техническая документация утверждена, пересмотр ее содержания заказчиком или разработчиком в одностороннем порядке юридически невозможен.
Пример 1. Если в утвержденном техническом задании (ТЗ) на автоматизированную систему сказано, что посетитель сайта должен видеть лозунг «Слава труду», заказчик не имеет права вдруг потребовать еще и демонстрации рекламного ролика на эту тему. Вполне возможно, что показывать ролик — неплохая идея, но заказчику следовало высказать ее раньше, когда разработчик согласовывал с ним техническое задание. С другой стороны, если вместо положенного текста система будет выдавать рекламу ночного клуба, у заказчика появятся все основания потребовать от разработчика внесения в систему необходимых изменений, и не платить ему денег, пока система не будет приведена в соответствие техническому заданию.
Пример 2. Если в утвержденном техническом проекте зафиксировано, что для реализации автоматизированной системы используется скрипт на PHP , разработчик не имеет права огорошить заказчика предложением вместо бесплатного интерпретатора этого языка приобрести Lotos Domino. Но, с другой стороны, и заказчик не может потребовать от разработчика вместо нормального сервера использовать компьютер БК 0010, завалявшийся в кладовке с советских времен.
Бюрократически правильное ведение технической документации заставляет всех участников разработки вести себя предсказуемо по отношению друг к другу, что конечном счете, всем выгодно, несмотря на дополнительные затраты. Ведение технической документации позволяет предотвратить многие недоразумения и злоупотребления. В том случае, если заказчик и разработчик так испортят отношения, что дело дойдет до арбитража, техническая документация будет служить для ущемленной стороны средством доказать свою правоту. Без технической документации вероятность и болезненность всевозможных склок и «разборок» сильно повышается.
Всякая бюрократизация подразумевает соблюдение определенных форм. Формы договоров и основных финансовых документов продиктованы законодательством. Аналогично, формы технических документов продиктованы гостами. При этом техническая документация на программы описывается Единой системой программной документации, а техническая документация на автоматизированные системы Комплексом стандартов на автоматизированные системы (ГОСТ 34).