В новогодние праздники разбирался с гостами группы 34.ххх Стандарты информационной технологии. О них чуть позже будет несколько статей. А сейчас о мыслях, которые навеяны одним из этих стандартов.
В ГОСТ 34.602-89 есть указание на список требований, которые должны (могут) быть зафиксированы в техническом задании на разработку. Тот же подход можно использовать при заключении договора, формировании задания на оказание тех или иных услуг. Потому решил поделиться мыслями на этот счет.
При приобретении программного обеспечения всегда нужно обращать внимание на требования, которые предъявляют его разработчики для обеспечения комфортной работы данного ПО. Это могут быть требования к используемой операционной системе, производительности и иным параметрам оборудования, квалификации персонала и прочие. Если не принять эти требования в счет, то есть риск, что приобретенный продукт просто не будет работать, или будет работать совсем не так, как это требуется.
При разработке какого-либо продукта подход должен быть тем же, про что прямо сказано в упомянутом выше стандарте. Требования нужно четко фиксировать в задании.
В случае оказания услуг данные требования также желательно обговаривать заранее либо до знакомства с объектом на основании предыдущего опыта и иной доступной информации, либо непосредственно на стадии обследования объекта перед заключением договора на оказание услуг.
Зачем это нужно:
Чтобы снизить свои риски резкого роста затрат по проекту и/или отказа от его выполнения.
Например, вы оказываете услуги по настройке какого-либо программного продукта. По предыдущему опыту вы знаете, что набор одних и тех же действий на разных объектах выполнялся то 3 часа, то 3 и более дня. Причины этой восьмикратной разницы могли быть разные:
— где-то пользователи совершенно не умели пользоваться программой (а про это изначально не было сказано), и нужно было их учить с нуля, а не просто рассказать, что нового добавили.
— где-то заказчик потребовал в ходе выполнения работ физического присутствия на объекте и показа офлайн, хотя в других случаях все выполнялось дистанционно.
— где-то используется совершенно не производительное оборудование, скорость работы которого оказалась в разы меньше рекомендуемого поставщиком ПО.
— где-то не приобретены и не установлены дополнительные компоненты, которые необходимы для требуемого заказчиком функционала, в итоге тратится время на их поиск, установку либо поиск аналогов или иные путей решений проблемы.
— где-то тип лицензии не соответствует требуемому, и нужно тратить время на замену, переустановку и так далее.
Потому вполне возможно, что список требований с каждым новым реализованным объектом будет расширяться по мере накопления опыта, как правило негативного, когда в ходе работы над проектом выявляется что-то заранее не предусмотренное, но влияющее на затраты проекта.
П.С. Стандарты оказались интересными. Скоро про них напишу.
Другие материалы по этой теме:
Дебиторка. Вам должны, но вам от этого не легче
Долги покупателей: Добро или Зло?