Как правильно формулировать проектное задание
5 апреля 2009 в 08:26

Как правильно формулировать проектное задание

Помнится, когда был молодым специалистом, я где-то прочитал о том, как важно правильно формулировать проектное задание. Приводился пример. Было сформулировано задание — «предложить средства автоматизации и механизации загрузки и разгрузки товарных вагонов». Задача же была решена иначе — были предложены котейнерные перевозки.
ИТ — это же не только Интернет. Как ж/д транспорт для перевозки грузов — не только товарные вагоны.
См. на эту тему Antonov Alexander. Safe Global/Regional Informational Network. European Journal of Scientific Research. Vol. 28, Issue 1, 2009, pp. 165–174 [http://www.eurojournals.com/ejsr_28_1_15.pdf]
Думайте и предлагайте.

468
Комментарии (6)
  • 5 апреля 2009 в 17:26 • #
    Александр Рошка

    Александр, действительно сейчас идет некоторый уклон в сиюминутные запросы и задачи по автоматизации. Нет того Советского системного подхода "предложить средства автоматизации и механизации загрузки и разгрузки товарных вагонов". Думаю это не скоро вернется. Но думать и предлагать готов!

  • 5 апреля 2009 в 18:56 • #
    Олег Кильдюшов

    404
    The requested URL /ejsr_28_1_15.pdf] was not found on this server.
    The page cannot be found
    :-(

  • 5 апреля 2009 в 19:08 • #
    Борис Вольфман

    Александры! Готов Вам обоим возразить принципиально. Изменилась только терминология, а суть не изменилась. Любая методика, ГОСТ - Российский (34,19), буржуйный - 12207, CMMI, RUP, MSF и.т.п. утверждает первичны требования (в ТЗ, функциональных спецификациях, проектном задании - неважно).
    Минимум 50% проваленных программных проектов, НЕСООТВЕТСТВИЕ ожиданиям заказчика-то есть требования (ТЗ) не согласовано с заказчиком на старте проекта или результаты сдаются не в соответствии с предварительно требованиями или требования не однозначны, их можно по разному толковать, невозможно проверить.
    Это касается не только ИТ,
    Но сформулировать требования - необходим очень высокий ПРОФЕССИОНАЛИЗМ, так как специалист (аналитик) должен прекрасно ориентироваться в предметной области: контейнерные перевозки, бухучет, Интернет-магазин и т.п.) и разбираться в ИТ.

  • 5 апреля 2009 в 21:15 • #
    Михаил Плисс

    Согласен. Я как ИТ Директор очень хорошо знаю, что чем лучше опишешь требования, тем больше вероятность того, что проект получится и удовлетворит заказчика. Более того, это приходится делать не один раз, в разных терминах, с рисунками, плясками, схемами - сейчас видимо такое время, у всех информационный перегруз, и тяжелую документацию из многих листов по гостам никто не читает из тех, кто должен это делать. На это даже времени не выделяют, и всем все надо вчера. Поэтому при согласовании требований огромное внимание надо уделять дополнительным действиям - презентациям, рисункам, провоцирующим вопросам, неформальным беседам, которые пишутся на диктофон итд.... Такое уж сейчас время...

  • 5 апреля 2009 в 22:39 • #
    Борис Вольфман

    Михаил! И сегодня такое время, и вчера было такое время, и завтра будет такое время: только разная терминология и исполнители.
    Согласен с очень важной Вашей мыслью: на это даже времени не выделяют (и ресурсов).
    Для этого существует другой прием: на старте проекта согласуйте только ПОЛЬЗОВАТЕЛЬСКИЕ требования: один два листа, определяющие концепцию проекта в терминах ПОЛЬЗОВАТЕЛЯ (ЗАКАЗЧИКА), без излишних технических деталей. Далее высокоуровневые требования к программному обеспечению (ИТ) и use-case (варианты использования, сценарии использования, преценденты), также один-два листа.
    Обязательно согласуйте с Заказчиком: Заказчик должен понять, что будет на выходе и Вы убедитесь, что правильно поняли цели и задачи Заказчика.
    А потом: архитектура, макет, детальные функциональные и системные требования, программа и методика испытаний.
    А сдавать проект на соответствие самым 1-м ПОЛЬЗОВАТЕЛЬСКИМ требованиям.
    Но переделывать, вернее уточнять, изменять требования Вы в любом случае будете и также резервируйте на это время и ресурсы.
    Всего доброго.


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970