Петли обратной связи

Управляющие процессы изобилуют корректирующими петлями (запросами на проверку и уточнение)

Не маленьких размеров камешек забросил в огород любителей тяжеловесных формализованных процессов Алистэр Коуберн в работе «The New Face of Software Engineering». Алистэр очень педантичный исследователь и потому, разбирая ту или иную тему, докапывается до сути. Его рассуждения интересны и поучительны.

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

Не понятно, почему же менеджеры высокотехнологичных проектов, прекрасно понимая, что найти решения с первого раза получится далеко не всегда, по прежнему верят в диаграммы Ганта и метод критического пути.

Один комментарий к “Петли обратной связи”

  1. Ах вон эта фигня как называется! )
    Буду знать, спасибо )

    Тоже встретился с проблемой что любой процесс можно рассматривать на разных уровнях абстрации и соответственно описывать тоже. Но как ты его не опиши, это лишь слова… а любое слово это ложь… реальные знания получаются лишь через практические действия.

    Описания:
    1. Абстрактные: законы, политики, правила, положения, стандарты
    2. Средние: регламенты, распоряжения, постановления, приказы
    3. Конкретные: инструкции, сквозные примеры

    Слишком абстрактные описания – не понятно
    Слишком конкретные описания – это как раз тупики для исполнителей, т.к. тут и возникают эти самые петли. Потому надо быть в двойне осторожным.

    И самое главное, все это нужно структурировать по правилу ВИСИ (у меня на блоге есть). Чтобы петлей было меньше.

    А вот чтобы эти все описания заработали, нужно еще 3 элемента:
    1. Служба тех.поддержки: устранение отклонений возникающих по ходу процессов, консультации, разбор проблем
    2. Обучение: как правило нужно в случае внедрения каких то крупных изменений или при развити персонала между должностями и уровнями ответственности
    3. Ученичество: ввод молодых сотрудников под присмотром старичков

    Угадал?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *