> Менять на переправе коней, т.е. поставщиков - это вообще песня. Выход, как мне кажется, в долгосрочных тендерах. Чтобы можно было на определённых этапах отказаться и уйти к другим при невыполнении поставщиком своих обязательств. Но если поставщик устраивает, то избавиться от необходимости устраивать ежегодные тендеры для продолжения работ.
> Если ТЗ будет делать одна компания, а работы по ТЗ выполнять другая, то в результате, в большинстве случаев, это выльется в написание нового ТЗ, бо каждый разработчик пишет ТЗ под себя.
Иного выхода нет, обязательно будет обновенное ТЗ.
Специалисты, которые уже конкретно будут заниматься разработкой - другие, соотв. у них другое понимание устройства используемых технологий, их качества и т.п.
> Если ТЗ будет делать одна компания, а работы по ТЗ выполнять другая, то в результате, в большинстве случаев, это выльется в написание нового ТЗ, бо каждый разработчик пишет ТЗ под себя.
Ну вот как раз поэтому более правильно, когда ТЗ диктует заказчик. При этом ТЗ перечисляет что должно быть сделано (возможно с указанием почему так), какие требования предъявляются, в какие сроки желательно было бы уложиться. Но в ТЗ не закладываются конкретные способы реализации. Это дает возможность использовать нормально написанное ТЗ для конструктивного общения с разными исполнителями.
Правда, практически никогда не приходилось видеть, чтобы в разработке софта кто-то всерьез придерживался ГОСТовской последовательности этапов: техническое задание, эскизный проект, технический проект и т.д. Сейчас все по более гибким схемам происходит -- заказчик озвучивает список своих функциональных требований, под них исполнитель быстренько формирует т.н. vision (т.е. описание того, как решение в принципе могло бы выглядеть), если заказчика устраивает vision и коммерческое предложение, то начинается проект, на начальной стадии которого формулируется и подписывается ТЗ. Однако, с некоторыми заказчиками ТЗ может формулироваться чуть ли не на протяжении всего времени выполнения проекта и, фактически, подписываться ТЗ может одновременно с актами приемо-сдаточных испытаний :)
Ну и, кстати говоря, переход к модным нонче гибким методологиям и итерационной разработке с выдачей промежуточных версий раз в месяц (или раз в 1.5-2 месяца) так же не способствует тщательному написанию подробного ТЗ до начала разработки.
не правильно составленная задача на конкурсе, показывает на сколько не компетентны люди которые это создали задание.....
По поводу разработки да, время мало.. цена приличная
> Ну вот как раз поэтому более правильно, когда ТЗ диктует заказчик.
Не соглашусь. Держать в штате заказчика спецов для написания полноценного ТЗ никому не выгодно. В итоге получим то, о чём говорили в этом ролике, только применимо к персоналу заказчика: хорошие спецы не пойдут на предлагаемую зарплату, а посредственные будут клепать такие же ТЗ.
> Правда, практически никогда не приходилось видеть, чтобы в разработке софта кто-то всерьез придерживался ГОСТовской последовательности этапов: техническое задание, эскизный проект, технический проект и т.д. Сейчас все по более гибким схемам происходит.
Опять возвращаемся к сроку ограниченному бюджетом - год (по факту гораздо меньше). Уложиться в это время по крупному проекту практически нереально.
> Не соглашусь. Держать в штате заказчика спецов для написания полноценного ТЗ никому не выгодно.
Тут, скорее, вопрос в том, кто и что именно включает в ТЗ. Доводилось видеть ТЗ, которые выглядели именно как ТЗ, т.е. задания на разработку софта с такими-то требованиями. Как правило, это был компактный документ на 15 страниц максимум. Все дополнительные материалы шли дополнительными документами в рамках проекта.
Доводилось видеть и ТЗ, в которых подробность была похлеще, чем в технических проектах. Мало полного перечня оборудования, софта и схем развертывания, там еще и чуть ли не полностью программа и методика испытаний :)
ТЗ первого вида вполне может сделать заказчик самостоятельно. И даже подозрительно, если на их стороне не будет человека, способного это сделать.
А вот ТЗ второго вида без исполнителя, причем вполне конкретного исполнителя, проведшего этап предварительного обследования и проектирования, никак не написать.
> Держать в штате заказчика спецов для написания полноценного ТЗ никому не выгодно.
Вы ещё учтите, что любая госорганизация привлекает к работам кучу разных компаний: одни им водопровод чинят, другие материалы поставляют, третьи ещё какую-то пользу наносят, и на всех нужно заводить тендеры. И по каждому - специалиста, который написал бы детальное руководство, что именно делать. Это просто невозможно.
> Именно что только верхнеуровневое. Без таких частностей, как расположение, форма и цвет кнопок на формах мобильного приложения.
Камрад, за редким исключением (например, Таможня) у госов в ходу 34-ая серия ГОСТ. Там расписано, и что такое ТЗ, и что в него входит, и где место форме и цвету кнопок (не в ТЗ) и еще много-много всего. Наверняка же знаешь. В том числе расписано затем, чтобы свести к минимуму разночтения.
> Правда, практически никогда не приходилось видеть, чтобы в разработке софта кто-то всерьез придерживался ГОСТовской последовательности этапов: техническое задание, эскизный проект, технический проект и т.д.
Годами вижу практически каждый рабочий день. И участвую.
А в солидных местах еще и делается. В ФСБ, например, есть практика "любимого подрядчика". Который назначается по секторам деятельности прямым указом (или распоряжением, не помню точно) Президента. И со всеми профильными нуждами, которые возникают за время пребывания этого подрядчика на посту, Контора обращается к нему. А вот если он откажется - тогда уже можно и на "рынок".
> В ФСБ, например, есть практика "любимого подрядчика". Который назначается по секторам деятельности прямым указом (или распоряжением, не помню точно) Президента. И со всеми профильными нуждами, которые возникают за время пребывания этого подрядчика на посту, Контора обращается к нему.
То Контора.
Не все госорганизации могут себе это позволить, особливо если закон предписывает открытость запросов и прозрачность процедур.
И сразу вспоминается тендер про разработку мобильного рабочего места руководителя Газпрома.
Который с легкой руки журналистов превратился в "планшет для Миллера за 119 миллионов рублей"
> И сразу вспоминается тендер про разработку мобильного рабочего места руководителя Газпрома. > Который с легкой руки журналистов превратился в "планшет для Миллера за 119 миллионов рублей"
Это вообще был полный ахтунг. Журналисты как явление начинают бесить.
Впрочем там и без журналистов хватило, даже в якобы профессиональной среде.
> Годами вижу практически каждый рабочий день. И участвую.
Так я ж не утверждал, что этого вообще нет. Просто мне практически не приходилось с таким сталкиваться, что не удивительно, т.к. выборка совсем небольшая, а госов там еще меньше.
Меня тут за советы уже пожурили, но всё-же. Если переговорить лично с представителем заказчика, бОльшая часть вопросов отпадёт, а по представителю будет видно чего он хочет: решения задачи или получения личной выгоды. Если последнее - поставщик имеет возможность сберечь денежные средства и нервы своих сотрудников. Как-то так.
И ведь интересно, людям начинаешь говорить про элементарную зарплату разработчикам софта - упорно твердят "за 50 тыщ в месяц в Сызрани (условно) отличный программист". Сами при этом за 150 с дивана не встанут.
> Кому: Mityakin, #116 > > > в якобы профессиональной среде. > > И ведь интересно, людям начинаешь говорить про элементарную зарплату разработчикам софта - упорно твердят "за 50 тыщ в месяц в Сызрани (условно) отличный программист". Сами при этом за 150 с дивана не встанут.
Профессиональный уровень в очень большой степени определяется уровнем задач, над которыми работает данный специалист.
Отсюда просто принципиальное непонимание этими комментаторами, что там по системным соображениям неоткуда взяться высококлассным, но дешевым разработчикам.
Новости
VIP
