ПМ во время оно блестяще развалили одну из дочек ГК «Оптима» :)
Одна из их и наших бед — это незнание нормативов трудоемкости тех или иных работ, выполняемых подразделениями под оперативным подчинением РП. РП ради собственного бонуса расписывают совершенно нереальные план-графики, к примеру, под разработку техзадания на систему электронного документооборота крупной газодобывающей компании был определен срок примерно в неделю. Полный абсурд, конечно.
С РП можно очень продуктивно бороться. На совещании в присутствии генерального мы как-то открыли замечательный, но, к сожалению, отмененный документ «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости. — Отраслевой стандарт ОСТ 4.071.030», в котором на разработку ТЗ средней сложности отводится чуть ли не год времени. Естественно, были возражения, что документ давно отменен, на что мы заявили, что даже если за 20 лет мы научились работать во много раз быстрее, то все равно на ТЗ должно отводиться не менее 3-х месяцев. В итоге компромисс был достигнут, больше РП безумные сроки нам не ставили.
Еще был прикол от начальника техписовского отдела. Он нарыл ГОСТ Р, полностью цельнотянутый с какого-то австралийского стандарта, в котором прописано было четко, что техпис должен писать не более 20 страниц нового текста в месяц, т.е. примерно по странице в день, и носился с этим стандартом по начальственным кабинетам. В итоге, разумеется, он победил всех :)
Слава богу, что уже лет восемь как не работаю наймитом, а веду собственный бизнес. Но впечатления от РП остались как об очень нехороших и тупо-упертых индивидах…
Уточнение: Ноу-хау — Не имеющие правовой охраны конфиденциальные знания, включая сведения технического, экономического, административного и финансового характера, использование которых обеспечивает определенные преимущества обладателю этих знаний [из п. 1.1.39 Р 50-605-80-93]
Р 50-605-80-93 — отличный терминологический документ, рекомендую.
Сам сижу на убунте уже лет восемь, винду пользую под виртуалбоксом всего лишь из-за одной программы, которой нет пока полноценного аналога в линуксе. Всем доволен и всему рад — ни тебе вирусов, ни тебе сетевых атак — убунте все пофигу :)
Спасибо, Артем — это совсем другое дело, а то все флуд да эмоции, а потом еще и в «минуса» меня. Дурная манера пытаться пройти по чужим головам.
При полном адеквате схема приблизительно такая и есть. Правда, от самого заказчика хрен чего дождешься, особенно от подчиненных его, которым ни до чего нет дела. Вот и пришлось однажды объезжать все объекты Оренбурггазпрома и буквально насильно заставлять древних теток заполнять непонятные им опросные листы, чтобы хоть какие-то требования заказчика поиметь.
С ТЗ несколько иначе — оно не отвечает на вопросы, а только является перечнем требований как к функционалу, так и ко всему прочему. А на вопросы уже отвечают документы, разрабатываемые на стадии «Технический проект». Если руководствоваться ГОСТами 34-й системы, то их там дофига и больше. А для подведения итогов разрабатывается Программа и методика испытаний, по которой испытания и проводятся, по результатам испытаний составляется Акт приемки сдачи и им работа завершается. Это так, все на пальцах, в жизни сложнее бывает.
ТЗ заказчику отдавать в откуп нельзя, поскольку исполнитель всегда «умнее», достаточно ТТ, по которым исполнитель разрабатывает ТЗ.
Что касается каши: она начинается именно с подготовки договора, в котором должно быть четко указано, по каким стандартам будет проводиться работа. Если это не указано или указано криво (эти особенно грешило Минобрнауки), то полный атас обеспечен. Тогда работа принимается исключительно за хороший откат. А с календарным планом обычно чудит сам исполнитель. неграмотно расписывая виды работ, после чего и получает люлей от всех, от кого только можно.
Вот фрагменты из Минобрнаучного ТЗ :)
«… обоснование характеристик сторонних программных средств...» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики — В темных очках;
«… унификация функциональных задач...» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
«… графических элементов интерфейсов...» — вероятно, имеются в виду элементы графического интерфейса пользователя;
«… графического интерфейса модулей...» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
«… сторонних систем...» — очевидно, речь идет о внешних системах;
«… Технический акт...» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
«… Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»...» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако — Круглые глаза;
«… контролем входной и выходной информации, основанной на методике кодирования объектов...» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
«… Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций...» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние...;
«… с возможностью «горячего резервирования» и перехода на резервное оборудование...» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
и, наконец, самое забавное — «… должна соответствовать требованиям эргономики и профессиональной медицины...»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы — Ржу! (смайл)
Это говорит о низкой морали в коллективе. Биение кода на части только уменьшает мораль, это не выход. Лучше помучиться первое время, но вбить в голову программистам, что код общий, а не персональный. Сегодня нагадил ты, завтра сам ковыряешься в говне.
Г-да, какое отношение имеет мораль к коду? И вообще — а какой морали может быть речь в условиях суровой капиталистической действительности?
Написание кода тем и отличается от жарки картофеля в Макдональдсе, что там каждый раз новая задача и всех ньюансов не опишешь.
Читаем проф. Б.П. Кузнецова — «Психология автоматного программирования». Правда, это мало кому тут поможет… Кто сейчас что умное читает?
Ну… Очень интересно! Прям проф. Кузнецов. Поднял бы рейтинг, если бы мог :)
В команде, конечно, наиболее предпочтительно автоматное программирование, тогда и никакие заглушки не понадобятся.
Уважаемый, если есть желание подискутировать — пишите конкретику, поскольку эмоциональных и безосновательных высказываний в рунете и без того выше крыши. Все это мало кому интересно. Как и то, что Вы любите или нет, что Вас расстраивает или нет.
Опубликуйте хотя бы одно из «сильно больше» такого ТЗ — обсудим, проверим на соответствие требованиям ГОСТов, найдем «неприменимости», в которых «виноваты» ГОСТы. А еще лучше — изложите свои понятия в части «достаточности» технических заданий, разработанных вне рамок ГОСТов, отдельной статьей. Тогда и пообщаемся, а флуд интереса не представляет.
Отнюдь не обожествляю ГОСТы, особенно ГОСТ Р, но опыт доказывает, что соответствие чего-либо требованиям ГОСТов есть хотя бы минимальный показатель качества этого чего-либо. Все прочее — отсебятина, и останется ей до тех пор, пока не не станет стандартизованной отсебятиной :)
И, поверьте, никому ничего не навязываю. Пусть каждый учится на своих ошибках, если не умеет на чужих :)
Одна из их и наших бед — это незнание нормативов трудоемкости тех или иных работ, выполняемых подразделениями под оперативным подчинением РП. РП ради собственного бонуса расписывают совершенно нереальные план-графики, к примеру, под разработку техзадания на систему электронного документооборота крупной газодобывающей компании был определен срок примерно в неделю. Полный абсурд, конечно.
С РП можно очень продуктивно бороться. На совещании в присутствии генерального мы как-то открыли замечательный, но, к сожалению, отмененный документ «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости. — Отраслевой стандарт ОСТ 4.071.030», в котором на разработку ТЗ средней сложности отводится чуть ли не год времени. Естественно, были возражения, что документ давно отменен, на что мы заявили, что даже если за 20 лет мы научились работать во много раз быстрее, то все равно на ТЗ должно отводиться не менее 3-х месяцев. В итоге компромисс был достигнут, больше РП безумные сроки нам не ставили.
Еще был прикол от начальника техписовского отдела. Он нарыл ГОСТ Р, полностью цельнотянутый с какого-то австралийского стандарта, в котором прописано было четко, что техпис должен писать не более 20 страниц нового текста в месяц, т.е. примерно по странице в день, и носился с этим стандартом по начальственным кабинетам. В итоге, разумеется, он победил всех :)
Слава богу, что уже лет восемь как не работаю наймитом, а веду собственный бизнес. Но впечатления от РП остались как об очень нехороших и тупо-упертых индивидах…
Р 50-605-80-93 — отличный терминологический документ, рекомендую.
Сам сижу на убунте уже лет восемь, винду пользую под виртуалбоксом всего лишь из-за одной программы, которой нет пока полноценного аналога в линуксе. Всем доволен и всему рад — ни тебе вирусов, ни тебе сетевых атак — убунте все пофигу :)
При полном адеквате схема приблизительно такая и есть. Правда, от самого заказчика хрен чего дождешься, особенно от подчиненных его, которым ни до чего нет дела. Вот и пришлось однажды объезжать все объекты Оренбурггазпрома и буквально насильно заставлять древних теток заполнять непонятные им опросные листы, чтобы хоть какие-то требования заказчика поиметь.
С ТЗ несколько иначе — оно не отвечает на вопросы, а только является перечнем требований как к функционалу, так и ко всему прочему. А на вопросы уже отвечают документы, разрабатываемые на стадии «Технический проект». Если руководствоваться ГОСТами 34-й системы, то их там дофига и больше. А для подведения итогов разрабатывается Программа и методика испытаний, по которой испытания и проводятся, по результатам испытаний составляется Акт приемки сдачи и им работа завершается. Это так, все на пальцах, в жизни сложнее бывает.
ТЗ заказчику отдавать в откуп нельзя, поскольку исполнитель всегда «умнее», достаточно ТТ, по которым исполнитель разрабатывает ТЗ.
Что касается каши: она начинается именно с подготовки договора, в котором должно быть четко указано, по каким стандартам будет проводиться работа. Если это не указано или указано криво (эти особенно грешило Минобрнауки), то полный атас обеспечен. Тогда работа принимается исключительно за хороший откат. А с календарным планом обычно чудит сам исполнитель. неграмотно расписывая виды работ, после чего и получает люлей от всех, от кого только можно.
Вот фрагменты из Минобрнаучного ТЗ :)
«… обоснование характеристик сторонних программных средств...» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики — В темных очках;
«… унификация функциональных задач...» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
«… графических элементов интерфейсов...» — вероятно, имеются в виду элементы графического интерфейса пользователя;
«… графического интерфейса модулей...» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
«… сторонних систем...» — очевидно, речь идет о внешних системах;
«… Технический акт...» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
«… Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»...» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако — Круглые глаза;
«… контролем входной и выходной информации, основанной на методике кодирования объектов...» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
«… Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций...» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние...;
«… с возможностью «горячего резервирования» и перехода на резервное оборудование...» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
и, наконец, самое забавное — «… должна соответствовать требованиям эргономики и профессиональной медицины...»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы — Ржу! (смайл)
Г-да, какое отношение имеет мораль к коду? И вообще — а какой морали может быть речь в условиях суровой капиталистической действительности?
Читаем проф. Б.П. Кузнецова — «Психология автоматного программирования». Правда, это мало кому тут поможет… Кто сейчас что умное читает?
В команде, конечно, наиболее предпочтительно автоматное программирование, тогда и никакие заглушки не понадобятся.
Опубликуйте хотя бы одно из «сильно больше» такого ТЗ — обсудим, проверим на соответствие требованиям ГОСТов, найдем «неприменимости», в которых «виноваты» ГОСТы. А еще лучше — изложите свои понятия в части «достаточности» технических заданий, разработанных вне рамок ГОСТов, отдельной статьей. Тогда и пообщаемся, а флуд интереса не представляет.
И, поверьте, никому ничего не навязываю. Пусть каждый учится на своих ошибках, если не умеет на чужих :)