Производственная ментальность
Из дискуссии на RSDN. Давно хотел об этом написать, и подвернулся повод.
Собственно, с лекции о "производственной ментальности" я начинал свой трениг в Одессе для Codedgers". Это - основополагающая "лекция", необходимая для правильного понимания всего моего материала. Здесь - в ужатом варианте. В полном варианте я очень детально рассматриваю конкретные проявления "производственной ментальности" в методологии PSP/TST, основанной на CMMI (могу, благо работал под ней и официально сертифицирован), и в сетевом планировании.
...
Ну да. Позже я пришел к выводу, что разделение на defined и empiric процессы само по себе не вполне корректное и не самое точное. Более правильно взглянуть на проблему под чуточку другим углом.
Корень проблемы, лежащий в интуитивном непонимании природы процессов разработки лежит в феномене, который я назвал "производственная ментальность".
В чем отличие проектной деятельности от производственной? Цель производственного процесса - сделать серию [b]как можно более одинаковых[/b] изделий. Как этого достичь? Нам нужен процесс, который гарантирует качество. Так и делают.
Результат же каждого проекта уникален - таково определение проектной деятельности, и в этом ее сущность. Можно навесить на нее процесс, который будет гарантировать "качество" результата?
Скажем так, на определенном уровне абстракции, с которого все проекты выглядят для нас одинаково - да. Можно. И этот "процесс" будет нам помогать обеспечивать одинаковость этих абстрактных характеристик.
Но, при этом, совершенно неизбежно данный процесс будет игнорировать тот самый уникальный результат. А именно он, уникальный результат - и есть суть проекта. И, таким образом, обеспечить успех проекта процесс не способен принципиально.
Вывод? Акцент на процессах в проектной деятельности - безусловное зло. Процессные люди руководить разработкой не должны. Акцент должен быть на том самом уникальном результате, он главнее.
Значит ли это, что никакой "процесс" не нужен? Нет. Просто он не должен стоять во главе угла, и касаться частных процедур, которые реально не зависят от результата, и всегда одинаковы. Пример? Процедура чекина.
Эти рассуждения общие для всех видов проектной деятельности. Никакой софтверной специфики для объяснения не требуется. Но мы ее коснемся.
Дело в том, что автомобильным, к примеру, заводам - есть чему у нас поучиться. У нас, в софтостроении, самый совершенный производственный процесс. Изготовление "изделий"(дистрибутивов) по "рабочей конструкторской документации" (сорцам) - полностью автоматизировано, делается "роботами", происходит почти моментально, и выполняется всегда одинаково. Завидуйте, производственники! Перенимайте опыт!
Все вроде просто и понятно, но "производственная ментальность" интуитивно человеку понятна, и пустила свои корни очень глубоко. Гораздо глубже, чем кажется. И от нее очень непросто избавится. Скажем, ей пронизан весь PMBoK, как это ни смешно. Почему она и заслуживает отдельного названия. Не верите?
Показываю. Процесс понимается как набор активностей, берущих нечто на вход, и преобразующих этот вход в выход. За определенное время. Отличной, и, возможно лучшей нотацией для описания процессов является IDEF0/SADT.
В производстве процесс изготовления изделия описывается комплектом разных документов, часть которых "технологическая карта". Она показывает, из каких деталей и в какие этапы собирается изделие.
То есть, технологическая карта завязана на [b]структуру результата[/b]. Подразумевается, что разные элементы (модули) изделия мы изготавливаем отдельно, и потом собираем из них целое. Возможно - в несколько этапов.
Технологическая карта очень похожа на план проекта, с той разницей, что по ней изготавливается [b]много одинаковых изделий[/b]. Так как под качеством понимается одинаковость, и изделий много, у нас есть и время и возможность оптимизировать процесс. Так - правильно.
План проекта по классике (возьмем сетевой график) построен на той же концепции, и представляет собой развертку выполнения процесса во времени, в указанном выше понимании. Примерно как технологическая карта. Каждая задача - протяженна во времени. Но каждый проект уникален, и по этой "карте" в нашем случае делается [b]ровно одно изделие[/b]. Что нам уже символизирует, правда? :) Но это еще не все.
Главное в "производственной ментальности" - что? Мы должны в результате проекта по разработке сделать некий артефакт. Разработчики - это такие станки. Они перерабатывают документацию в документацию другого вида, и иногда - документацию в код. Из этого кода собирается большая система.
Программисты - это дорогие станки, и их надо как следует загрузить, они не должны простаивать... И если эти станки перерабатывают документацию в негодный, неправильный код - что надо делать? Поработать над документацией, сделав ее лучше, навесить на выход контроль качества, и, возможно, заменить глючные станки на другие.
Вот что такое "производственная ментальность". И мы попадаем в ее ловушку сразу же, как начинаем писать WBS и составлять сетевой график, от структуры результата, и пользуясь шаблоном процесса. А дальше - она свое возьмет. Процессы начнем оптимизировать, CMMI-и внедрять - логично же все?
В чем проблема? А вы перечитайте, с чего мы начинали. Чтобы более явно почувствовать "когнитивный диссонанс".
Проблема в том, что разработка - это процесс решения проблем, а не изготовления артефактов. Посмотрите цикл разработки RUP - это разумный подход. Он не завязан на активности. Он основан на цикле решения проблем. И решаемые проблемы - вовсе не совпадают со структурой результата, и иерархией модулей. Это все поменяться может в процессе разработки, ибо это один из вариантов _решения_ проблемы.
Главная же проблема, что все объяснения выше для большинства людей как об стенку горох. "Производственная ментальность" - это то, чему людей не надо учить. Это почему-то почти все люди интуитивно понимают, и интуитивно этой ментальности следуют.
Разные Agile-подходы имеют одно общее место - они так или иначе выбивают "производственную ментальность" из головы. Но при этом, за редкими исключениями, херово масштабируются. И вообще - выбить ее их головы - недостаточно. Для сложных проектов нужен нормальный инструмент планирования. Сетевой график же слишком легко использовать неправильно.
"Производственная ментальность" проявляется своей гранью также в интуитивном стиле выдачи заданий. Специально не тренированные люди интуитивно предпочитают решить проблему самостоятельно, и выдать задания подчиненным в терминах одного из вариантов решения этой проблемы. По факту действуя в стиле "сборки изделия", думая об исполнителях как о "станках". Этот стиль выдачи приказов и лидерства в военном деле называется "Befehlstaktik" - детальные приказы в терминах действий, которые надо совершить.
К счастью, военные (которые, как известно, занимаются крайне рискованными проектами в условиях неопределенности) придумали выход для стиля выдачи приказов. Более чем 100 лет назад разобрались с ситуацией. Ибо - дороговато им этот "интуитивный стиль" обходился.
http://en.wikipedia.org/wiki/Mission-type_tactics
Ну раз военные справились, то почему не можем мы? Далее мы логично переходим к методике планирования, в которой в принципе нет активностей. :) Но это уже другая история.
Собственно, с лекции о "производственной ментальности" я начинал свой трениг в Одессе для Codedgers". Это - основополагающая "лекция", необходимая для правильного понимания всего моего материала. Здесь - в ужатом варианте. В полном варианте я очень детально рассматриваю конкретные проявления "производственной ментальности" в методологии PSP/TST, основанной на CMMI (могу, благо работал под ней и официально сертифицирован), и в сетевом планировании.
...
Ну да. Позже я пришел к выводу, что разделение на defined и empiric процессы само по себе не вполне корректное и не самое точное. Более правильно взглянуть на проблему под чуточку другим углом.
Корень проблемы, лежащий в интуитивном непонимании природы процессов разработки лежит в феномене, который я назвал "производственная ментальность".
В чем отличие проектной деятельности от производственной? Цель производственного процесса - сделать серию [b]как можно более одинаковых[/b] изделий. Как этого достичь? Нам нужен процесс, который гарантирует качество. Так и делают.
Результат же каждого проекта уникален - таково определение проектной деятельности, и в этом ее сущность. Можно навесить на нее процесс, который будет гарантировать "качество" результата?
Скажем так, на определенном уровне абстракции, с которого все проекты выглядят для нас одинаково - да. Можно. И этот "процесс" будет нам помогать обеспечивать одинаковость этих абстрактных характеристик.
Но, при этом, совершенно неизбежно данный процесс будет игнорировать тот самый уникальный результат. А именно он, уникальный результат - и есть суть проекта. И, таким образом, обеспечить успех проекта процесс не способен принципиально.
Вывод? Акцент на процессах в проектной деятельности - безусловное зло. Процессные люди руководить разработкой не должны. Акцент должен быть на том самом уникальном результате, он главнее.
Значит ли это, что никакой "процесс" не нужен? Нет. Просто он не должен стоять во главе угла, и касаться частных процедур, которые реально не зависят от результата, и всегда одинаковы. Пример? Процедура чекина.
Эти рассуждения общие для всех видов проектной деятельности. Никакой софтверной специфики для объяснения не требуется. Но мы ее коснемся.
Дело в том, что автомобильным, к примеру, заводам - есть чему у нас поучиться. У нас, в софтостроении, самый совершенный производственный процесс. Изготовление "изделий"(дистрибутивов) по "рабочей конструкторской документации" (сорцам) - полностью автоматизировано, делается "роботами", происходит почти моментально, и выполняется всегда одинаково. Завидуйте, производственники! Перенимайте опыт!
Все вроде просто и понятно, но "производственная ментальность" интуитивно человеку понятна, и пустила свои корни очень глубоко. Гораздо глубже, чем кажется. И от нее очень непросто избавится. Скажем, ей пронизан весь PMBoK, как это ни смешно. Почему она и заслуживает отдельного названия. Не верите?
Показываю. Процесс понимается как набор активностей, берущих нечто на вход, и преобразующих этот вход в выход. За определенное время. Отличной, и, возможно лучшей нотацией для описания процессов является IDEF0/SADT.
В производстве процесс изготовления изделия описывается комплектом разных документов, часть которых "технологическая карта". Она показывает, из каких деталей и в какие этапы собирается изделие.
То есть, технологическая карта завязана на [b]структуру результата[/b]. Подразумевается, что разные элементы (модули) изделия мы изготавливаем отдельно, и потом собираем из них целое. Возможно - в несколько этапов.
Технологическая карта очень похожа на план проекта, с той разницей, что по ней изготавливается [b]много одинаковых изделий[/b]. Так как под качеством понимается одинаковость, и изделий много, у нас есть и время и возможность оптимизировать процесс. Так - правильно.
План проекта по классике (возьмем сетевой график) построен на той же концепции, и представляет собой развертку выполнения процесса во времени, в указанном выше понимании. Примерно как технологическая карта. Каждая задача - протяженна во времени. Но каждый проект уникален, и по этой "карте" в нашем случае делается [b]ровно одно изделие[/b]. Что нам уже символизирует, правда? :) Но это еще не все.
Главное в "производственной ментальности" - что? Мы должны в результате проекта по разработке сделать некий артефакт. Разработчики - это такие станки. Они перерабатывают документацию в документацию другого вида, и иногда - документацию в код. Из этого кода собирается большая система.
Программисты - это дорогие станки, и их надо как следует загрузить, они не должны простаивать... И если эти станки перерабатывают документацию в негодный, неправильный код - что надо делать? Поработать над документацией, сделав ее лучше, навесить на выход контроль качества, и, возможно, заменить глючные станки на другие.
Вот что такое "производственная ментальность". И мы попадаем в ее ловушку сразу же, как начинаем писать WBS и составлять сетевой график, от структуры результата, и пользуясь шаблоном процесса. А дальше - она свое возьмет. Процессы начнем оптимизировать, CMMI-и внедрять - логично же все?
В чем проблема? А вы перечитайте, с чего мы начинали. Чтобы более явно почувствовать "когнитивный диссонанс".
Проблема в том, что разработка - это процесс решения проблем, а не изготовления артефактов. Посмотрите цикл разработки RUP - это разумный подход. Он не завязан на активности. Он основан на цикле решения проблем. И решаемые проблемы - вовсе не совпадают со структурой результата, и иерархией модулей. Это все поменяться может в процессе разработки, ибо это один из вариантов _решения_ проблемы.
Главная же проблема, что все объяснения выше для большинства людей как об стенку горох. "Производственная ментальность" - это то, чему людей не надо учить. Это почему-то почти все люди интуитивно понимают, и интуитивно этой ментальности следуют.
Разные Agile-подходы имеют одно общее место - они так или иначе выбивают "производственную ментальность" из головы. Но при этом, за редкими исключениями, херово масштабируются. И вообще - выбить ее их головы - недостаточно. Для сложных проектов нужен нормальный инструмент планирования. Сетевой график же слишком легко использовать неправильно.
"Производственная ментальность" проявляется своей гранью также в интуитивном стиле выдачи заданий. Специально не тренированные люди интуитивно предпочитают решить проблему самостоятельно, и выдать задания подчиненным в терминах одного из вариантов решения этой проблемы. По факту действуя в стиле "сборки изделия", думая об исполнителях как о "станках". Этот стиль выдачи приказов и лидерства в военном деле называется "Befehlstaktik" - детальные приказы в терминах действий, которые надо совершить.
К счастью, военные (которые, как известно, занимаются крайне рискованными проектами в условиях неопределенности) придумали выход для стиля выдачи приказов. Более чем 100 лет назад разобрались с ситуацией. Ибо - дороговато им этот "интуитивный стиль" обходился.
http://en.wikipedia.org/wiki/Mission-type_tactics
Ну раз военные справились, то почему не можем мы? Далее мы логично переходим к методике планирования, в которой в принципе нет активностей. :) Но это уже другая история.