Казалось за 10 лет уже все плохие вещи со мной случились, ан нет, каждый раз сталкиваешься с новыми и с новыми тараканами, и еще неясно какие из них более неприятные, большие и жирные, или мелкие и многочисленные.
К сожалению, чем дальше, тем больше прихожу к мысли, что основной проблемой разработки в России является неумение поставить и настроить процесс. И даже не неумение, а просто непонимание самого процесса. Когда не умеешь — несложно научится. Когда не понимаешь, но думаешь что понимаешь, все гораздо сложнее.
Частая ошибка менеджмента, и тех людей, кто на процесс влияют в том, что они считают, что все просто. Что процесс создания ПО не сильно отличается от процесса строительства дома. Что нагнал таджиков, дал им прораба, прорабу план в руки, показал где у плана верх где низ (что бы вместо маяка не получился колодец), и все, готовься стричь капусту.
Но со временем они понимают что почему-то не работает, или работает плохо, или работает не так как хочется. Начинаются поиски причины такого положения дел, но находят не причину а следствие. Следствие путается с причиной и начинается борьба с ветряными мельницами.
О чем это я? Нет, у меня не отняли ЖЖ, не отключили аську. Но есть вещи и похуже. И хуже они тем что не так заметны, что не столь бросаются в глаза. Это правила и регламенты.
Для примера вреда бюрократии, далеко ходить не надо, мы все помним совсем недавнее наше прошлое и видим настоящее, не спроста у нас слово «бюрократия» приобрело негативный оттенок. Наши чиновники, перекосы советского (да и современного) строя пытались исправить с помощью законов, указов, справок, приказов и другой волокиты. Не от хорошей жизни, а от непонимания, что корень проблем системы не в отсутствии правил, а в самой системе.
Это напоминает ситуацию, со старым или плохо построенным домом, когда вместо того что бы построить новый, к старому приделываются подпорки и растяжки.
Но нельзя так! Нельзя прикрывать собственную некомпетентность бумагой. Это только усугубляет проблему, создавая видимость работы, видимость результата и видимость процесса. Это обман! Ничего не становится лучше, просто появляется очередная подпорка.
Не нужно бояться признать свою некомпетентность, мало того, без этого ты никогда ничему не сможешь научиться. Как кто-то правильно сказал «только умный может сказать „какой я дурак“, только тот кто хочет научиться и хочет понять, может признать, что он не умеет и не понимает. А тот кто не хочет, тот будет себя уверять что уже все знает, а все проблемы от того, что вокруг не выполняют его правил.
Но вообще, бюрократия это пример того, что нельзя и на ёлку залезть и жопу не ободрать. Бюрократия, регламенты, правила и процедуры делают систему крепкой как танк, но такой же медленной и неповоротливой. А тем самым мы теряем её эффективность, и гибкость. Если вы оборонный завод, то наверное оно того стоит. Лучше 10 лет делать ракету, зато когда она полетит, то ух как полетит! Но в бизнесе нужна эффективность. Чем ты эффективнее, тем ты быстрее занимаешь рынки, тем ты больше зарабатываешь денег. Ну нельзя, по крайней мере в сфере разработки, создать эффективную систему с помощью регламентов. Именно поэтому методики гибкой разработки в первую очередь минимизируют бумажную волокиту. Либо то, либо другое. Либо надежность, либо скорость и гибкость.
Но бюрократия живет. Живет потому, что бюрократические механизмы просты, и не требуют анализа и глубокого понимания проблемы. Они одинаково применимы ко всему, и одинаково неэффективны, но зато дают видимый и главное понятный эффект. А то что они дают множество побочных эффектов, которые не так заметны, и могут долгое время не проявляться, это не так важно, никто не поймет, что очередная, вылезшая проблема есть результат больной системы. Давая видимый эффект сразу, коварная бюрократия не лечит болезнь, она, до поры, загоняет её внутрь.
Ну например…
У нас есть так называемый тестовый стенд, в составе которого есть сервер с VMware, на котором можно создавать песочницы для любых нужд разработчиков. Тестовый стенд специально создавался для этого, и сами виртуалки достаточно изолированны друг от друга. Но для того что бы виртуалка была создана, нужно заполнить заявку. Заявка только в бумажной форме, и должна быть заверена подписью начальника отдела.
Интересна история с самим тестовым стендом. ТЗ на него писалось несколько месяцев (три ли четыре), прошло несколько согласований, подписи у начальников разных уровней… три месяца на создание ТЗ на систему, реализация которой займет от силы 2 недели!
Даже имена в SVN у нас теперь подчиняются каким-то правилам, введены некие префиксы, существующие пользователи должны быть переименованы. Мелочи конечно, но когда таких мелочей масса, когда натыкаешься на на них там, где и не думал, когда рушатся твои планы только потому, что опять где-то что-то надо подписать, и бумажная волокита занимает иногда больше времени чем выполнение самой задачи…
Мы ищем ключи не там где потеряли, а там где светло
Один раз не замечаешь, второй — начинает раздражать, на третий раз начинает бесить, а потом думаешь а не послать ли все это к черту. Потому, что надоедает оправдываться, что из-за очередных согласований ты вновь не выполнил обещание сделать что-то к такому то сроку.
Я, кстати, до сих пор не понял, что является главным мотивом, побуждаюшим к созданию новых и новых правил? То ли где-то так учат, то ли это попытка прикрыть задницу, то ли попытка показать видимость работы. Наверное, даже сами авторы регламентов не понимают этого. И может быть искренне удивляются, когда ты говоришь, что это все лишнее. Это все равно что говорить средневековому лорду, что карета может ехать без лошади, просто у неё не хватает двигателя.
А ведь в командах разработчиков есть двигатель — это сами разработчики. И их нужно только мягко направлять в нужное русло, вместо того что бы ставить палки в колеса.
Как направить, это отдельная тема, а этот пост не для того что бы учить. Он для того что бы обозначить проблему. Понимание проблемы — это уже половина её решения.
К сожалению, чем дальше, тем больше прихожу к мысли, что основной проблемой разработки в России является неумение поставить и настроить процесс. И даже не неумение, а просто непонимание самого процесса. Когда не умеешь — несложно научится. Когда не понимаешь, но думаешь что понимаешь, все гораздо сложнее.
Частая ошибка менеджмента, и тех людей, кто на процесс влияют в том, что они считают, что все просто. Что процесс создания ПО не сильно отличается от процесса строительства дома. Что нагнал таджиков, дал им прораба, прорабу план в руки, показал где у плана верх где низ (что бы вместо маяка не получился колодец), и все, готовься стричь капусту.
Но со временем они понимают что почему-то не работает, или работает плохо, или работает не так как хочется. Начинаются поиски причины такого положения дел, но находят не причину а следствие. Следствие путается с причиной и начинается борьба с ветряными мельницами.
О чем это я? Нет, у меня не отняли ЖЖ, не отключили аську. Но есть вещи и похуже. И хуже они тем что не так заметны, что не столь бросаются в глаза. Это правила и регламенты.
Для примера вреда бюрократии, далеко ходить не надо, мы все помним совсем недавнее наше прошлое и видим настоящее, не спроста у нас слово «бюрократия» приобрело негативный оттенок. Наши чиновники, перекосы советского (да и современного) строя пытались исправить с помощью законов, указов, справок, приказов и другой волокиты. Не от хорошей жизни, а от непонимания, что корень проблем системы не в отсутствии правил, а в самой системе.
Это напоминает ситуацию, со старым или плохо построенным домом, когда вместо того что бы построить новый, к старому приделываются подпорки и растяжки.
Но нельзя так! Нельзя прикрывать собственную некомпетентность бумагой. Это только усугубляет проблему, создавая видимость работы, видимость результата и видимость процесса. Это обман! Ничего не становится лучше, просто появляется очередная подпорка.
Не нужно бояться признать свою некомпетентность, мало того, без этого ты никогда ничему не сможешь научиться. Как кто-то правильно сказал «только умный может сказать „какой я дурак“, только тот кто хочет научиться и хочет понять, может признать, что он не умеет и не понимает. А тот кто не хочет, тот будет себя уверять что уже все знает, а все проблемы от того, что вокруг не выполняют его правил.
Но вообще, бюрократия это пример того, что нельзя и на ёлку залезть и жопу не ободрать. Бюрократия, регламенты, правила и процедуры делают систему крепкой как танк, но такой же медленной и неповоротливой. А тем самым мы теряем её эффективность, и гибкость. Если вы оборонный завод, то наверное оно того стоит. Лучше 10 лет делать ракету, зато когда она полетит, то ух как полетит! Но в бизнесе нужна эффективность. Чем ты эффективнее, тем ты быстрее занимаешь рынки, тем ты больше зарабатываешь денег. Ну нельзя, по крайней мере в сфере разработки, создать эффективную систему с помощью регламентов. Именно поэтому методики гибкой разработки в первую очередь минимизируют бумажную волокиту. Либо то, либо другое. Либо надежность, либо скорость и гибкость.
Но бюрократия живет. Живет потому, что бюрократические механизмы просты, и не требуют анализа и глубокого понимания проблемы. Они одинаково применимы ко всему, и одинаково неэффективны, но зато дают видимый и главное понятный эффект. А то что они дают множество побочных эффектов, которые не так заметны, и могут долгое время не проявляться, это не так важно, никто не поймет, что очередная, вылезшая проблема есть результат больной системы. Давая видимый эффект сразу, коварная бюрократия не лечит болезнь, она, до поры, загоняет её внутрь.
Ну например…
У нас есть так называемый тестовый стенд, в составе которого есть сервер с VMware, на котором можно создавать песочницы для любых нужд разработчиков. Тестовый стенд специально создавался для этого, и сами виртуалки достаточно изолированны друг от друга. Но для того что бы виртуалка была создана, нужно заполнить заявку. Заявка только в бумажной форме, и должна быть заверена подписью начальника отдела.
Интересна история с самим тестовым стендом. ТЗ на него писалось несколько месяцев (три ли четыре), прошло несколько согласований, подписи у начальников разных уровней… три месяца на создание ТЗ на систему, реализация которой займет от силы 2 недели!
Даже имена в SVN у нас теперь подчиняются каким-то правилам, введены некие префиксы, существующие пользователи должны быть переименованы. Мелочи конечно, но когда таких мелочей масса, когда натыкаешься на на них там, где и не думал, когда рушатся твои планы только потому, что опять где-то что-то надо подписать, и бумажная волокита занимает иногда больше времени чем выполнение самой задачи…
Мы ищем ключи не там где потеряли, а там где светло
Один раз не замечаешь, второй — начинает раздражать, на третий раз начинает бесить, а потом думаешь а не послать ли все это к черту. Потому, что надоедает оправдываться, что из-за очередных согласований ты вновь не выполнил обещание сделать что-то к такому то сроку.
Я, кстати, до сих пор не понял, что является главным мотивом, побуждаюшим к созданию новых и новых правил? То ли где-то так учат, то ли это попытка прикрыть задницу, то ли попытка показать видимость работы. Наверное, даже сами авторы регламентов не понимают этого. И может быть искренне удивляются, когда ты говоришь, что это все лишнее. Это все равно что говорить средневековому лорду, что карета может ехать без лошади, просто у неё не хватает двигателя.
А ведь в командах разработчиков есть двигатель — это сами разработчики. И их нужно только мягко направлять в нужное русло, вместо того что бы ставить палки в колеса.
Как направить, это отдельная тема, а этот пост не для того что бы учить. Он для того что бы обозначить проблему. Понимание проблемы — это уже половина её решения.
