group-telegram.com/tired_glebmikheev/2232
Last Update:
Избыточное разделение труда приводит к фрагментации понимания в коллективе
С появлением массовых производств и научной организации труда, дробить процесс на узкие зоны ответственности стало нормой. Логика простая: когда знаешь все этапы, что нужно на каждом и какая квалификация требуется — зачем грузить сотрудника общим пониманием? Достаточно регламинтировать как ставить задачу, как исполнять и что должно быть на выходе.
И вот, стройным потоком по конвейеру бегут рамы, на них накручивают подвески, колеса, ставят двери и бампера. Конвейер работает, машины собираются.
А потом этот подход переносят в разработку — всё расписывают по стадиям, фиксируют входы и выходы, всё чинно и логично, будто можно предсказать наперёд. Но, описание быстро устаревает, понимание требований плавает, решения приходится пересматривать на ходу. Чем выше неопределённость и новизна, тем хуже работает заранее прописанный порядок.
Фан-факт: Винстон Ройс в 1970 году в работе "Managing the development of large software systems" первым описал ватерфол. Но не как автор, а для критики: "Я верю в эту концепцию, но описанная выше реализация рискованна и ведёт к неудаче" (И да, он запускал ракеты в космос для Lockheed и знал толк в сложных проектах)
Основная проблема ватерфолла — обратная связь от работы происходит в саааамом конце, на стадии приемо-сдаточных испытаний. Вот тут и вылезают все проблемы, которые не учли в самом начале и на всех последующих этапах работы
Именно поэтому правильно дробить процесс на итерации — чтобы после каждой петли обратной связи от системы и ее использования на реальных клиентах превращать опыт в знание через рефлексию и адаптировать движение вперед. В этом ключевая задача гибких методологий. Они предлагают как работать на территории Emergent Practice (территория гипотез, проб, ошибок и накопления ценного опыта).
А при чем тут избыточное разделение труда?
В отличие от завода со строгим Run, мы находимся в Change. У нас нет знаний как конкретно достичь цели — нам нужна командная работа мотивированных экспертов, которая будет совместно, закрывая все необходимые экспертизы искать решения. Только так, овладевая общим пониманием, мы можем работать над проблемами и максимизировать качество результата.
А им для коллективной работы ну никак нельзя попасть в ситуацию, когда они знают только свой фрагмент и просто перекидывают через забор дальше по конвейеру. Именно поэтому, избыточное ролевое разделение, с сужением области ответственности и знаний о продукте\системе\процессах попросту убивает возможность быть гибкими. Поэтому, каждый раз слыша фразу "у меня все работает, это проблема у соседа", я начинаю тригериться и обьяснять как же на самом деле важно и почему это большая ошибка
П.С. Есть отдельный пласт отрицателей самой сути необходимости эмпирической методологии. Говорят "Вы просто не смогли написать нормальные требования и все посчитать". Ну-ну
BY Уставший техдир
Share with your friend now:
group-telegram.com/tired_glebmikheev/2232