Читал, что для тех.задания на разработку ПО описан ГОСТ, но есть вопрос, скорее всего наивный, думаю что даже крупные компании не используют его в описании ТЗ. Так ли это? Если есть опыт, подскажите, как в небольших компаниях до 10 человек в IT-отделе формировать ТЗ. Сейчас же делаю ТЗ по принципу:
1.Описание
2.Условия
3.Доп.требования к задаче.
Также пытаюсь писать документацию, даже скорее всего развернутые описания добавленного функционала, чтобы любой сотрудник компании мог прочесть, понять, может даже воспользоваться.
Если у вас есть опыт в PM, подскажите с этими аспектами работы - что взять за основу, вообще верно ли я делаю?
По ГОСТ (ЕСПД) оформляют документацию не тогда, когда нужно решить какие-то пользовательские и программистские задачи, а когда есть бюрократические требования. Например, в госзаказе.
Надо понимать, что ЕСПД в своей основе напоминают требования к стандартизации конструкторской документации (ЕСКД). Но если конструкторская документация действительно требует какого-то единообразия, то ЕСПД выглядит больше как требования ради требований. Какой смысл тратить время на эти телодвижения в конторах с крайне ограниченными человекоресурсами?
shurshur, по этому и спросил ,т.к нахожусь в своеобразном вакууме из которого нужно выйти ,найти доп.работу на должность PM ради развития ,но т.к первый и пока единственный опыт этой позиции это текущее место работы ,то возникают вопросы , в частности как пишут тз и документации в небольших компаниях и агентствах
Ни разу не сталкивался с ТЗ по 19 (ЕСПД), но постоянно работаю с ТЗ по 34 (АС). Тем, кто говорит, что ГОСТ это про бюрократию, рекомендую в ограниченные сроки создать автоматизированную систему с нуля хотя бы масштаба одного города, в которой будут работать хотя бы человек 20, поработать с инфобезом по ней. Сразу станет понятно, для чего ГОСТ 34 нужен, и ПМИ для чего, и проект на систему.
С ГОСТами на АС не имел дело, только с ЕСПД. Там главная проблема, которая возникала, это необходимость настроить TeX таким образом, чтобы были все нужные колонтитулы, а титульный лист оформлен правильным образом. Собственно, содержательная часть в этих ГОСТ не такая уж и большая, многое на уровне очевидных банальностей, и если ставить задачу следовать каким-то стандартам - то я думаю наверняка есть стопицот стандартов для нормального бизнеса уровнем намного лучше наших государевых.
Организация работы по внедрению - это не про ГОСТы вообще, и про ПМИ я ничего плохого не говорил, вообще-то, и для чего составляют проект я тоже знаю. Но ГОСТ тут причём? Задача должна состоять не в следовании ГОСТ, а в решении определённых задач. Это мне напоминает логику современных левых, рассуждающих о том, как совок победил в стране регулярный голод от неурожаев, хотя при этом весь цивилизованный мир поборол этот же голод без необходимости введения у себя совка. Надо исходить из того, что проект, ТЗ, документация, эксплуатационные инструкции, регламенты и всё такое пишутся не для того, чтобы соответствовать ГОСТ и предъявляться регулирующим органам, а чтобы решить конкретные задачи.
Мы вообще обсуждаем в данном вопросе не внедрение какой-то замороченной АИС в госсектор с низкоквалифицированными операторами, а разработку ТЗ в фирме, где его составлением занимается ИТ-отдел, даже не отдельный проектный отдел. Мы при этом не знаем, что они там разрабатывают, кто заказчик, каков уровень требований и всё такое. И автор как бы сам считает следование ГОСТ для себя избыточным, хотя хочет, чтобы вот это вот всё было сделано хоть как-то нормально и грамотно.
Там главная проблема, которая возникала, это необходимость настроить TeX таким образом, чтобы были все нужные колонтитулы
Ну то есть до написания по ГОСТ вас остановил инструмент? Возможно TeX и пользуются профессиональные техписы, но я все делаю в обычном wordе, один раз настроили рамки и колонтитулы и все ок.
Собственно, содержательная часть в этих ГОСТ не такая уж и большая, многое на уровне очевидных банальностей
Так они должны покрывать структуру и порядок, это своеобразный чеклист, что должно быть отображено. Иначе банальный вопрос безопасников типа «опишите список технологических процессов» поставит в тупик.
Задача должна состоять не в следовании ГОСТ, а в решении определённых задач.
ГОСТ помогает решать определенные задачи, о которых вы ещё узнаете в будущем.
Да и вообще, откуда стереотип про госслужбу? Ну рассмотрите банк, оператора, завод или логистическую компанию. Не надо рассматривать стандарты лишь как формальную сторону вопроса.
Валентин, нет, меня не остановил инструмент, он вообще не мог меня остановить, потому что написание по ГОСТ в этом проекте было ОБЯЗАТЕЛЬНО. Я говорю об уровне требований, где важнее было соблюсти размеры букв и расположение колонтитулов, чем достичь какой-то реальной осязаемой пользы.
И должен заметить, что больше мне никогда в жизни этой хренью страдать не приходилось. Потому что реально это никому не нужно.
Ну вот я сейчас работаю в фирме, где пишут документацию на софт. Опытный техпис обязательно в тексте спецификации API делает лист с изменениями, описание терминов, введение хотя бы на полстранички с объяснением о чём тут вообще, все запросы API тщательно описаны, но при этом ГОСТ явным образом не следует, он просто делает аккуратно и полезно. Для сравнения, у меня тут спецификация, разработанная mail.ru, они на это вообще положили (титульного нет, первая страница содержание, вторая краткое описание, причём больше половины страницы - скриншот мобильного телефона, на третьей странице уже начинается описание первого метода API, описаний изменений между версиями документа вообще не найти), но реализации этой спецификации подобное абсолютно не мешает.
"Стереотип" не про госслужбу, а о работу на государство. Я больше 10 лет проработал в бюджетных организациях, не являясь госслужащим.
И в данных вопросах я говорю не о стандартах вообще, а конкретно о ГОСТ в части ЕСПД, которые слишком уж сильно скопированы с ЕСКД и слишком уж слабо годны для процесса нормальной разработки ПО.
shurshur, сожалею о вашем неудачном опыте. Возможно в вашем случае это действительно был только формализм. И описание api - это не ТЗ на создание системы и не технорабочий проект. Потому что API это не самодостаточная система, это только интерфейс. В моем мире я регулярно анализирую ТЗ на 150-200 страниц, сверяю проекты на сотни страниц, проверяю Огромные ПМИ (600+ страниц). И это далеко не всегда госуха. По работе с документами в таких объемах крайне желательно соблюдение стандартов, чтобы понимать, какой раздел тебе нужен.
И ещё раз повторюсь, не обязательно следовать формализму в виде шрифтов и рамок. Но применение структуры и состава крайне желательно (задачи, цели, автоматизируемые процессы и тд)
Валентин, можно открыть и посмотреть ГОСТЫ на ЕСПД и сразу понять, что их соблюдать нет смысла.
Например, открываем ГОСТ 19.004-80 (введёт в действие с 1 июля 1981 г.), и что там написано?
"Для каждого понятия установлен один стандартизованный термин. Применение терминов-синонимов стандартизованного термина запрещается.
...
5. Программное изделие / Program product. Программа на носителе данных, являющаяся продуктом промышленного производства"
Кому эта хрень 40-летней давности нужна?
А слово "программа" тоже недопустимо, надо "программа вычислительной машины", даже если это приложение для телефона. Кстати, слово "приложение" тоже недопустимо, ибо синонимы недопустимы.
До кучи советую посмотреть https://habr.com/ru/post/218735/ - там опять в тексте рассуждения о правильных отступах и в комментариях народ катком по этому проехался.
Простой
