Comments 233
бюрократия части создается теми, кому нечего делать. особенно это часто бывает в больший международный компаниях, где есть куча народу, нанятая черти когда для конкретных целей, выполнившие эту конкретную цель и оставленные просиживать штаны. всем хочется повышения, прибавки — но для этого надо что то делать, доказать что ты полезный. вот такие люди и начинают придумывать «бумажки», «процессы», ревью комитеты, вордовые документы о банальном релизе длинною 20 страниц с обязательным требованием от разработчиков заполнения каких-то форм, которые никому не нужны и никто их потом не смотрит. это да же не беда наших российских людей, когда каждый начальник чувствует свою власть только когда ему каждый день носят какие-то бумажки на подпись — это просто беда всех компаний.
Прямо как бальзам на душу
Однако, если в сфере бизнеса с бюрократией все как-то попроще, то в госструктуре вы никуда от нее не денетесь, потому что все идет сферху. Я, например, вместо того, что внедрять информатизацию процессов в своем учреждении, пишу миллионы бумажек о том, что «да, да, надо внедрять. нет, на это у нас денег и работников нет.» Итог, я постепенно из ИТ-специалиста становлюсь бумажной крысой.
Кроме того, любое твое начинание или идея губится на корню, ибо если она понравится — то будет указание «в срок до такого-то реализовать», а ресурсов не выделится и основной работы не уменьшится. Итог — я не справлюсь, меня обругают и лишат стимулирующих выплат, а мне еще кормиться надо.
Однако, если в сфере бизнеса с бюрократией все как-то попроще, то в госструктуре вы никуда от нее не денетесь, потому что все идет сферху. Я, например, вместо того, что внедрять информатизацию процессов в своем учреждении, пишу миллионы бумажек о том, что «да, да, надо внедрять. нет, на это у нас денег и работников нет.» Итог, я постепенно из ИТ-специалиста становлюсь бумажной крысой.
Кроме того, любое твое начинание или идея губится на корню, ибо если она понравится — то будет указание «в срок до такого-то реализовать», а ресурсов не выделится и основной работы не уменьшится. Итог — я не справлюсь, меня обругают и лишат стимулирующих выплат, а мне еще кормиться надо.
Пережитки советского союза, где все должно было подчиняться инструкциям — начиная от того, как ковыряться в носу, и заканчивая тем, как работать с мейнфреймом.
У нас в отделе вся системность — тикеты и тикеты-таски. Всё. Остальное доносится в частном порядке в аське-джаббе-ирц.
У нас в отделе вся системность — тикеты и тикеты-таски. Всё. Остальное доносится в частном порядке в аське-джаббе-ирц.
совсем без бюрократии будет анархия
но, к сожалению, не всем удается найти золотую середину
но, к сожалению, не всем удается найти золотую середину
не будет анархии. анархия это когда власти нет, а власть в компании есть всегда.
неправы вы
есть такой тип компаний — анархический
у них есть свои плюсы, но вместо бюрократии там постоянная грызня за ресурсы на всех уровнях управления
и в развитии они сильно ограниченны — не могут левел-ап взять из-за внутренних конфликтов
есть такой тип компаний — анархический
у них есть свои плюсы, но вместо бюрократии там постоянная грызня за ресурсы на всех уровнях управления
и в развитии они сильно ограниченны — не могут левел-ап взять из-за внутренних конфликтов
А есть компании где достаточно написать письмо админам, и твоя просьба выполняется, без всяких бумаг. А если твоя просьба идиотская, то сам виноват. И все работает, работает замечательно. И никаких подписей у начальства. И никакой анархии.
А правила регулируются самой командой, потому что только команде они и нужны. А бумага которую нужно подписывать начальству есть единственная — бумага на выгрузку релиза на продакшен, и предназначена она для того что бы прикрыть жопу разработчиков а не начальства, потому что если начальник разрешил выгрузку, он берет ответственность на себя.
А правила регулируются самой командой, потому что только команде они и нужны. А бумага которую нужно подписывать начальству есть единственная — бумага на выгрузку релиза на продакшен, и предназначена она для того что бы прикрыть жопу разработчиков а не начальства, потому что если начальник разрешил выгрузку, он берет ответственность на себя.
есть, не спорю
что мешает в них работать?
что мешает в них работать?
А как по письму админам понять какой просьбой заниматься твоей или чей-то другой? где указан приоритет задачи? а что если задач с конкурирующим приоритетом много? Как определить к какому числу просьба еще может потерпеть, а к какому нет? Как определить который именно из админов должен заниматься работой и как проконтролировать, что ваше письмо не попало в спам у админов по случайности?
Решения сделанные, чтобы ответить на данные вопросы — начало бюрократии…
Но я согласен — нужно отлично понимать где мера не вдаваться в фанатизм… также для каждого отдельного случая мера своя… «что русскому хорошо, немцу — смерть»
В вашем примере с виртуалкой можно также посмотреть также на то, какую проблему пытаются решить заполнением заявок (другой вопрос, почему именно в письменном виде). Может у вас ограниченные ресурсы фермы — и их использование пытаются таким образом контролировать…
Решения сделанные, чтобы ответить на данные вопросы — начало бюрократии…
Но я согласен — нужно отлично понимать где мера не вдаваться в фанатизм… также для каждого отдельного случая мера своя… «что русскому хорошо, немцу — смерть»
В вашем примере с виртуалкой можно также посмотреть также на то, какую проблему пытаются решить заполнением заявок (другой вопрос, почему именно в письменном виде). Может у вас ограниченные ресурсы фермы — и их использование пытаются таким образом контролировать…
«письмо админам» — суть зачатки формального ведения дел. Много хороших вопросов задает koal каментом выше :)
при правильном применении бюрократии, бумаги не для того, чтоб прикрыть жопу, а для того, чтоб зафиксировать момент и намерения заинтересованных сторон.
при правильном применении бюрократии, бумаги не для того, чтоб прикрыть жопу, а для того, чтоб зафиксировать момент и намерения заинтересованных сторон.
ну тогда я думаю надо совсем отказаться от общения, и надеяться что админы будут сами понимать что тебе нужно, стоит только об этом подумать. письмо админам это не бюрократия это элементарное удобство, что бы не бежать лично. это быстро и удобно.
я уже приводил пример, когда что-то удобное для других, становится абсолютно недостаточным для других. Где грань?
Я бы перефразировал мудрецов: бюрократия начинается там, где кончается твоя свобода, а твоя свобода заканчивается там, где начинается свобода другого.
Я бы перефразировал мудрецов: бюрократия начинается там, где кончается твоя свобода, а твоя свобода заканчивается там, где начинается свобода другого.
эти мудрецы, которых вы перефразировали, совсем не мудрецы. Но это отдельная тема.
а грань находится в общении, дискуссии, компромиссах у уступках. главное что в поиске этих граней задействованы люди, занятые непосредственно в процессе, а у нас регламенты принимаются людьми в процессах не участвующих, но желающих что бы все вокруг по линеечке ходили.
а грань находится в общении, дискуссии, компромиссах у уступках. главное что в поиске этих граней задействованы люди, занятые непосредственно в процессе, а у нас регламенты принимаются людьми в процессах не участвующих, но желающих что бы все вокруг по линеечке ходили.
Зачем-же отказываться от общения? Можно не писать писем, можно звонить, или общаться во время перекура или за обеда.
— Дим, у меня что-то ресурс XYZ на файлопомойке долго по-утрам отправляется, по несколько минут.
— Ок, я посмотрю, может отвалилось чего.
границы «вот тут уже бюрократия, а вот тут еще удобство» как таковой нет. Эту границу в головах проводят люди. А ведь Дима мог сказать «напиши письмо, а то я могу забыть, или приду — а там работы навалят». А мог и сказать «напиши тикет в трекере».
Если задумться — «сказать», «написать письмо», «тикет в трекере» — это всё разные уровни удобства для админа Димы.
Некоторым людям, например очевидно, что тикет — это чертовски удобно. Это гораздо удобнее чем письмо, и тем более, чем реплика по телефону или устно, за обедом. Но наверняка найдутся люди, которые даже письмо сочтут за бюрократию.
У разных людей разные точки зрения на один и тот-же процесс. И разные оценки одинаковым фактам.
Хотя, я не буду спорить, что написание бумаги в запросом на починку «медленно открывающегося ресурса XYZ», и визирование её у нескольких начальников — это ужас-ужас. Но разница с хорошим трекером (где начальник Димы может менять приоритеты тикетов), у такой бумаги не очень большая. В основном — уровнем автоматизации процесса подачи заявки и удобствами отслеживания заявок и времени их решения, для начальства Димы. Да-да, удобства начальника Димы.
Жаль, что вы не ответили на вопросы koal, в предыдущем комментарии.
— Дим, у меня что-то ресурс XYZ на файлопомойке долго по-утрам отправляется, по несколько минут.
— Ок, я посмотрю, может отвалилось чего.
границы «вот тут уже бюрократия, а вот тут еще удобство» как таковой нет. Эту границу в головах проводят люди. А ведь Дима мог сказать «напиши письмо, а то я могу забыть, или приду — а там работы навалят». А мог и сказать «напиши тикет в трекере».
Если задумться — «сказать», «написать письмо», «тикет в трекере» — это всё разные уровни удобства для админа Димы.
Некоторым людям, например очевидно, что тикет — это чертовски удобно. Это гораздо удобнее чем письмо, и тем более, чем реплика по телефону или устно, за обедом. Но наверняка найдутся люди, которые даже письмо сочтут за бюрократию.
У разных людей разные точки зрения на один и тот-же процесс. И разные оценки одинаковым фактам.
Хотя, я не буду спорить, что написание бумаги в запросом на починку «медленно открывающегося ресурса XYZ», и визирование её у нескольких начальников — это ужас-ужас. Но разница с хорошим трекером (где начальник Димы может менять приоритеты тикетов), у такой бумаги не очень большая. В основном — уровнем автоматизации процесса подачи заявки и удобствами отслеживания заявок и времени их решения, для начальства Димы. Да-да, удобства начальника Димы.
Жаль, что вы не ответили на вопросы koal, в предыдущем комментарии.
эх, ресурс XYZ, конечно не отправляется долго, а открывается ;)
прошу прощения, еще не проснулся окончательно ;(
прошу прощения, еще не проснулся окончательно ;(
очень просто. сказанное на словах можно забыть. мне не выгодно что бы он забыл, поэтому я пишу письмо, где четко описываю что мне нужно. это удобно как мне, который это письмо пишет, так и тому кому оно предназначается, так как он тоже не рискует забыть детали.
написанное в письме менее удобно чем написанное в трекере, потому как при большом потоке писем у получателя, оно может быть «забыто», хотя, конечно с меньше вероятностью.
Кроме того, у почты нет удобных (как для вас, так и для исполнителя) механизмов отслеживания сколько времени висит та или иная заявка (всё руками, причем каждый у себя сам). И я уж не говорю о людях, которые должны контролировать процесс, и управлять им.
Разница «сказал» и «написал письмо» — вам очевидна и вы считаете, что конечно «написал письмо» удобнее. Вот мне, точно так же очевидна разница «написал письмо» и «написал тикет». (кстати, по трудозатратам тикет не сильно дороже письма получается).
К чему это я всё? Под «бюрократия» обычно понимают — крайнюю точку, когда эффективность процесса очень низкая, а накладные расходы высоки. Шкала «от анархии до бюрократии» непрерывная. Хуже того — нелинейная. И с разных точек зрения, нелинейность очень разная.
И самая фишка в том, что бюрократия — это тоже результат оптимизации процесса. Только не по критерию «эффективность» :))
Кроме того, у почты нет удобных (как для вас, так и для исполнителя) механизмов отслеживания сколько времени висит та или иная заявка (всё руками, причем каждый у себя сам). И я уж не говорю о людях, которые должны контролировать процесс, и управлять им.
Разница «сказал» и «написал письмо» — вам очевидна и вы считаете, что конечно «написал письмо» удобнее. Вот мне, точно так же очевидна разница «написал письмо» и «написал тикет». (кстати, по трудозатратам тикет не сильно дороже письма получается).
К чему это я всё? Под «бюрократия» обычно понимают — крайнюю точку, когда эффективность процесса очень низкая, а накладные расходы высоки. Шкала «от анархии до бюрократии» непрерывная. Хуже того — нелинейная. И с разных точек зрения, нелинейность очень разная.
И самая фишка в том, что бюрократия — это тоже результат оптимизации процесса. Только не по критерию «эффективность» :))
у меня есть пример, когда 3-4 админа управлялись с потоком писем от организации в 100 человек (примерно), а это десяток проектов, и столько-же отделов. Без всяких трекеров. Впрочем трекер это тоже вариант.
у нас 3-4 инженера управляются с потоком «обращений» от нескольких десятков организаций. И письма пишут, и по телефону звонят, и на мобильный в шесть утра (в разных часовых поясах заказчики, ага). Но нам, было-бы ГОРАЗДО удобнее, чтоб все заявки шли через трекер. Только поди, попробуй их туда всех загони. Особо умные берут своих генеральных директоров, и идут к нашему генеральному, со стонами «что они там себе позволяют, что за бюрократию разводят?! Неужели так сложно просто по звонку сделать то, что нам нужно?!»
То, что есть великие люди разгребающие почту — я верю охотно. Но я не верю, что этот процесс эффективнее чем трекер, а главное, не верю что он более управляемый.
А если управляемость низкая — то о качестве можно даже не говорить.
Что случается, если у вас один админ уходит в отпуск, а другой — вдруг заболевает с температурой (да будут они все здоровы!)?
То, что есть великие люди разгребающие почту — я верю охотно. Но я не верю, что этот процесс эффективнее чем трекер, а главное, не верю что он более управляемый.
А если управляемость низкая — то о качестве можно даже не говорить.
Что случается, если у вас один админ уходит в отпуск, а другой — вдруг заболевает с температурой (да будут они все здоровы!)?
+100 Как вы точно описали анархический тип компаний.
И в последнее время я все больше смотрю на бюрократизацию компании. В пределах разумного конечно.
Один из основных принципов — работники должны работать самостоятельно.
И в последнее время я все больше смотрю на бюрократизацию компании. В пределах разумного конечно.
Один из основных принципов — работники должны работать самостоятельно.
10 лет работы именно в анархической компании, временами очень захватывающе + адреналин нон-стоп :)
примеры в студию. :) Ну точнее назовите ее, объсните, почему вы ее так и назвали и привидите примеры анархических решений. Грызня за ресурсы есть вообще везде. Это главный показатель работы менеджмента и главная его цель — грызня за ресурсы. Другой не существует (что бы не писали книги по менеджменту).
Автору топика:
«Я, кстати, до сих пор не понял, что является главным мотивом, побуждаюшим к созданию новых и новых правил? То ли где-то так учат, то ли это попытка прикрыть задницу, то ли попытка показать видимость работы.»
Причина существования бюрократии состоит в двух вещах:
1. главная задача организации выжить. (чтобы не писали учебники по менеджменту).
2. грубо говоря, вероятность того, что из-за полезных действий компания сдохнет всегда выше, чем вероятность того, что компания сохранит свою жизнь, если все будет оставаться по старому.
Автору топика:
«Я, кстати, до сих пор не понял, что является главным мотивом, побуждаюшим к созданию новых и новых правил? То ли где-то так учат, то ли это попытка прикрыть задницу, то ли попытка показать видимость работы.»
Причина существования бюрократии состоит в двух вещах:
1. главная задача организации выжить. (чтобы не писали учебники по менеджменту).
2. грубо говоря, вероятность того, что из-за полезных действий компания сдохнет всегда выше, чем вероятность того, что компания сохранит свою жизнь, если все будет оставаться по старому.
а еще лучше вообще не выходить на улицу, вероятность выжить будет больше
вы задали вопрос. Я вам ответил.
Можно на ответ обидеться, можно попытаться мне объяснить, что это вовсе не так. Все это можно. :)
Можно на ответ обидеться, можно попытаться мне объяснить, что это вовсе не так. Все это можно. :)
я просто в корне не согласен что шансы выжить, ничего не меняя выше. Мир меняется, и если на него вовремя не реагировать, то конец неминуем. и то когда он придет, зависит от изначальных ресурсов. Если вы макрософт то наверное можно и забить на развитие, и выпускать говнобраузеры. Если вы гугл, то без инноваций без изменений и постоянного совершенствования всех процесов, вы умрете.
гм… название как бы некорректно, потому признаки попробую привести
сразу скажу, что это встречается в любой организации, но как не бывает чистых типов личности, так не бывает и чистых типов организаций
итак, первичные признаки анархической организации:
— отсутствие сформулированной стратегии (заработать побольше бабла стратегией не является, это просто жизненная необходимость);
— отсутствие четко выраженных уровней управления и развитые горизонтальные связи;
— разрозненность видов деятельности;
— частые приказы через голову непосредственного начальника;
— практически неограниченная власть руководителей в нижнюю сторону (понятно, что вверх другие ограничат:).
Не могу сказать, что это плохие компании и там плохо работать. Такая структура дает очень много свободы и возможности для самореализации. Деньги зарабатывать тоже нормально получается. Но нервных клеток менеджмента в них уничтожается тоже не мало.
Коряво, конечно, написал, но как умею :)
сразу скажу, что это встречается в любой организации, но как не бывает чистых типов личности, так не бывает и чистых типов организаций
итак, первичные признаки анархической организации:
— отсутствие сформулированной стратегии (заработать побольше бабла стратегией не является, это просто жизненная необходимость);
— отсутствие четко выраженных уровней управления и развитые горизонтальные связи;
— разрозненность видов деятельности;
— частые приказы через голову непосредственного начальника;
— практически неограниченная власть руководителей в нижнюю сторону (понятно, что вверх другие ограничат:).
Не могу сказать, что это плохие компании и там плохо работать. Такая структура дает очень много свободы и возможности для самореализации. Деньги зарабатывать тоже нормально получается. Но нервных клеток менеджмента в них уничтожается тоже не мало.
Коряво, конечно, написал, но как умею :)
«Низы не могут, а верхи не хотят», ага :) Тут ИМХО каждому надо решить для себя что лучше: работать в маленькой, но гибкой компании, или работать в большой компании, но с тучей бюрократов. Бюрократию не победить пониманием проблемы, и уж тем более не победить её постами на Хабре и петициями в Гаагский трибунал. Занятная штука в том, что её вообще хрен победишь :) Даже если случится чудо, и ваш пост прочитает Самый Большой Начальник, это ничего не изменит. Даже если начальник проникнется вашей идеей, потеряет сон, сделает татуировку «Бюрократы маст дай» и организует клуб анонимных бюрофобов, эта самая бюрократия всё равно никуда не денется. Тупо потому, что над нашим Самым Большим Начальником всё равно есть Убер Мега Начальник с мега-резистом к инновационным идеям и детской травмой, связанной с татуировками. Такие начальники руководствуются принципом «Деньги идут → нет проблемы → все идут лесом». И пусть вы предложите схему, которая сделает труд работников в стопицоттыщ раз удобнее, такому сферическому начальнику в вакууме будет пофиг.
Так что, наиболее адекватными вариантами здесь мне кажутся два: найти компанию, в которой уровень бюрократии не будет вызывать несварение у данного конкретного индивидуума, или смириться, сказав себе: «Они мне платят баблищще, остальное пофиг».
Так что, наиболее адекватными вариантами здесь мне кажутся два: найти компанию, в которой уровень бюрократии не будет вызывать несварение у данного конкретного индивидуума, или смириться, сказав себе: «Они мне платят баблищще, остальное пофиг».
Дело в том, что пусть компания не мелкая, но наш отдел разработки совсем небольшой.
У вашего отдела наверняка есть менеджеры и начальники, которые отчитываются перед более высоким начальством. Это более высокое начальство душит ваше локальное начальство, а ему, судя по всему, ничего не остаётся, кроме как душить вас :) Решить проблему наверняка можно, но начинать надо с самого высокого уровня и самого главного начальника. Просто статистика говорит не в пользу таких волшебных метаморфоз, к сожалению.
В чем проблема послать начальство на йух и сделать так, как надо? Даже если уволят, ты всегда найдешь себе работу (если на прежней не просто штаны просиживал). А с таким начальством каши не сваришь. Жизнь одна, не стоит её растрачивать на глупости. Дураки рано или поздно в любом случае загнуться, лучше быть не на их корабле в этот момент.
ну например в том, что я не имею прав развернуть виртуалку, а тот кто имеет, тербует бумажку. Или в том, что сегодня комичусь, а логин не подходит. Оказалось что молча меня переименовали, ибо права на администрирование SVN, с какого-то перепуга, согласно опять же каким то регламентам, не у меня.
проблема не в том что переименовали, а в том, что не уведомили. Как мне видится.
ну насчет этого уже успели извинится. это вторая проблема. но первая это то что из-за этого переименования мне на всех серверах придется пользователей пере сохранять, и скрипты выгрузки менять, которые рассчитаны на то что у меня везде один пользователь. Да мелочь, пол часа делов, но когда таких вещей много, а смысла в них ноль, это раздражает.
У вас очень понятно и просто расписано как построить дом. Это же элементарно!
Именно так думают про постройку разработку ПО те кто умеет строить дома.
Может в этом корень зла?
Именно так думают про постройку разработку ПО те кто умеет строить дома.
Может в этом корень зла?
имхо, примеров надо бы побольше
Работаю как раз в конторе государственной, работающей частью на оборону, частью — на частных инвесторов. Вот где бюрократия портит жизнь. Примеров приводить можно огромную массу.
Ввели «систему электронного документооборота». Быстро, без волокиты, потому что какому-то высокому дядьке понравилась аналогичная система на другом предприятии. Итог — изменения в документации проводятся МЕСЯЦ. Хотя раньше проводились за неделю.
Но одновременно с этим реально полезные и нужные решения принимаются месяцами из-за бюрократической волокиты. Потому что на бумажке должны поставить подпись восемь человек. Причем зачастую как минимум четверо отношения к этой бумажке не имеют, но «так положено по стандарту предприятия».
Недавно ко мне вернулся документ на изменение конструкции. Он ходил по подписям… ГОД!!! 12 месяцев и три дня!!! Вот тогда это был апофеоз моего неприятия бюрократии…
Ввели «систему электронного документооборота». Быстро, без волокиты, потому что какому-то высокому дядьке понравилась аналогичная система на другом предприятии. Итог — изменения в документации проводятся МЕСЯЦ. Хотя раньше проводились за неделю.
Но одновременно с этим реально полезные и нужные решения принимаются месяцами из-за бюрократической волокиты. Потому что на бумажке должны поставить подпись восемь человек. Причем зачастую как минимум четверо отношения к этой бумажке не имеют, но «так положено по стандарту предприятия».
Недавно ко мне вернулся документ на изменение конструкции. Он ходил по подписям… ГОД!!! 12 месяцев и три дня!!! Вот тогда это был апофеоз моего неприятия бюрократии…
на оборонке бюррократия скорее добро чем зло. цена ошибки очень высока
Тут я с Вами согласен, конечно. В какой-то степени Вы правы. Но всегда есть НО. Как Вам например формулировочка из письма заказчика: «Несмотря на то, что ТЗ на изделие было подписано 22.10.09, просим подготовить первый комплект для сдачи не позднее 31.12.09».
А почему ТЗ было подписано 22.10.09? А потому что бюрократия, а потому что ТЗ и дополнения к нему согласовываются месяцами. Согласовываются людьми, которые их читают мельком, а потом, когда всплывут косяки (которые, к слову, вылавливает всегда разработчик в основном), удивляются: «А как это я ТАКОЕ мог подписать?».
А почему ТЗ было подписано 22.10.09? А потому что бюрократия, а потому что ТЗ и дополнения к нему согласовываются месяцами. Согласовываются людьми, которые их читают мельком, а потом, когда всплывут косяки (которые, к слову, вылавливает всегда разработчик в основном), удивляются: «А как это я ТАКОЕ мог подписать?».
цифровую подпись введите, и срок проставления подписи под документом. Либо проставил подпись, либо отказался. Если в срок не уложился — лишайся части премии. Потому что не выполнил работу: подписать или написать резолюцию.
Так в Альфа Банке кажется было одно время. Клевая система по-моему.
Так в Альфа Банке кажется было одно время. Клевая система по-моему.
Согласен. Необходима мотивация.
Разруха в головах: даже с применением ЭЦП можно перемудрить… Вот пример: разрабатывали систему PKI для госструктуры — для каждого открытого ключа обязательным было печатать его на бумаге (полностью, в хексе), все долговременные параметры (тоже полностью) и заверять эту бумагу подписями обычными, чернильными. Хорошо хоть не кровью:)
Ооо! Цифровая подпись — это эпопея :))) «Система электронного документооборота», введенная на предприятии — это модуль 1C-PDM. Затрачены большие усилия по его внедрению, но человек, который всех должен обучать — это не разработчик этой системы и даже не представитель 1С. Это некая женщина, которую уполномочили обучать. Все обучение сводится к показу через проектор интерфейса программы и слов «чтобы сделать то-то, нажмите туда-то». О какой эффективности системы может идти речь.
А электронные подписи. Не поддерживает 1С-PDM электронных подписей. И неизвестно, будет ли поддерживать. Когда выбирали систему оборота, никто даже не задумывался о том, чтобы она поддерживала ЭЦП. Вот так и работаем. Месяц изменения в документации проводятся, а теперь помимо бумажных документов обычных появился еще некий «Удостоверяющий лист», на котором не менее 7 подписей. Этот лист удостоверяет, что ты сдал документ в электронном виде :) *WALL*
А электронные подписи. Не поддерживает 1С-PDM электронных подписей. И неизвестно, будет ли поддерживать. Когда выбирали систему оборота, никто даже не задумывался о том, чтобы она поддерживала ЭЦП. Вот так и работаем. Месяц изменения в документации проводятся, а теперь помимо бумажных документов обычных появился еще некий «Удостоверяющий лист», на котором не менее 7 подписей. Этот лист удостоверяет, что ты сдал документ в электронном виде :) *WALL*
А у нас все ровно наоборот. Когда ввели электронный документооборот, то бумаги, которые терялись и ходили неделями, стали обрабатываться максимум за три дня. А почему? Потому что босс стал видеть у кого сейчас какая бумага, кто просрачил отведенные на обработку три часа и вдувал нехило этим сотрудникам невзирая на чины и заслуги…
как по мне — ничего страшного (ИМХО)
ничего страшного для людей у которых есть только необходимость посидеть на стуле определенное время и в определенное число подойти за зарплатой
для специалиста такой уровень бюррократии отставание в развитии
для специалиста такой уровень бюррократии отставание в развитии
какой уровень бюрократии? заявление для использования виртуалки и соглашение об именах?
все перечислить? стал бы я из-за такой мелочи писать?
соглашение об именах это не бюрократия, имхо
а вот идти к начальнику с запросом на новую вирт. машину это уже бюррократия, начальник вообще имхо обычно в этих делах мало что понимает
а вот идти к начальнику с запросом на новую вирт. машину это уже бюррократия, начальник вообще имхо обычно в этих делах мало что понимает
если начальник в «этих делах» мало что понимает, то это плохой начальник
с чего бы? программист для начальника должен быть как черный ящик, на входе задача, на выходе решение. другое понимание начинает как раз генерировать бюррократию. это болезнь бывших программистов, ставших начальниками, которые хотят все контроллировать, но ведь задачи у них поменялись
над программистом по идее начальник — проджект менеджер, который задачи ему ставит. большинство проджект менеджеров не знают как выглядят простой запрос к БД, но вместе с тем очень хорошие руководители, и проекты достаточно успешно выпускают
над программистом по идее начальник — проджект менеджер, который задачи ему ставит. большинство проджект менеджеров не знают как выглядят простой запрос к БД, но вместе с тем очень хорошие руководители, и проекты достаточно успешно выпускают
я тут не соглашусь. если начальник в прошлом опытный программист, он как раз таки понимает вред бюрократии. а если только и знает как запрос выглядит, то да, скорее всего лучше бы не знал.
У проект-менеджера в круг задач не должно входить управление программистами. Управление разработчиками — тим лид.
тим лид распределяет ресурсы и следит за выполнением плана работ? чем тогда занимается проджект менеджер? следит за выполнением плана тимлида и распределяет ресурсы тим лидов?
тим лид это ответственный за группу разработчиков, выполняет самую сложную работу релиза и консультирует других участников группы разработки, помогает им и решает технические вопросы.
ваше понятие тим лида?
тим лид это ответственный за группу разработчиков, выполняет самую сложную работу релиза и консультирует других участников группы разработки, помогает им и решает технические вопросы.
ваше понятие тим лида?
соглашения об именах бюрократия, потому что это нафиг не нужно. я работал и в больших командах, и накаких проблем с именами в свн небыло. Тем более, что то как пользователи называются в свн, никого, кроме как самих пользователей не касается.
Скажите, а Вы мержили ветки нескольких разработчиков, или пытались найти ответственного за изменения трёхмесячной давности в очень большом проекте с активными коммитами? С утверждением, что это касается только пользователей я был бы поаккуратнее.
в нормальной системе не нужно мержить ветки нескольких разработчиков, и искать ответственных за изменение трехмесячной давности. Хотя никаких проблем здесь я не вижу.
А в идеальном мире вообще прекрасно жить
Что есть «нормальная» система? Не является ли такой системой, системая с четко прописанными правилами? Не являются ли правила минимальной бюрократитей?
нормальная система (организации работы) это та, которая не заставляет искать крайнего спустя три месяца работы, и мержить сразу несколько бренчей, при этом получая какие-то проблемы. это как минимум. причем все это происходит не потому что есть регламент, а просто потому что так эта система работает.
вот ваш пример с тестовым стендом.
а как начальник объясняет, каким образом касается его заведение новой машины для ваших нужд, почему это надо согласовывать с ним? есть какие-то аргументы?
ps. меняйте работу, либо в минуты «ожиданий согласований» занимайтесь втихушку своими делами, другого не дано
а как начальник объясняет, каким образом касается его заведение новой машины для ваших нужд, почему это надо согласовывать с ним? есть какие-то аргументы?
ps. меняйте работу, либо в минуты «ожиданий согласований» занимайтесь втихушку своими делами, другого не дано
начальник тоже считает что бумаги не нужны, но заведением новой машины занимается другой отдел, и он требует бумаги, потому что так по регламенту. Мало того, начальник того отдела тоже мог бы обойтись без бумаги, но не хочет брать на себя ответственность, так как по регламенту бумага нужна.
1. а внести изменения в регламент нельзя?
2. в регламент можно внести какие-то упоминания сроков? допустим такая-то бумажка должна от заказчика до исполнителя доходить за два дня. кто профакапил сроки — тому люлей.
3. в регламенте прописано по каким причинам может быть отказ подписания?
4. если отказ не прописан, не проще ли прописать в регламенте что заявка должна всего лишь логгироваться, ибо какой смысл просить разрешения на то, что будет разрешаться всегда?
2. в регламент можно внести какие-то упоминания сроков? допустим такая-то бумажка должна от заказчика до исполнителя доходить за два дня. кто профакапил сроки — тому люлей.
3. в регламенте прописано по каким причинам может быть отказ подписания?
4. если отказ не прописан, не проще ли прописать в регламенте что заявка должна всего лишь логгироваться, ибо какой смысл просить разрешения на то, что будет разрешаться всегда?
1. Подписано гендиром. Значит отменять тоже должен он, а это само по себе бюрократия и время.
2. Они есть. Два дня на поднятие вертуалки. Но поднимать её по факту 1 час. А если копировать то вообще 15 мин.
3. Нет.
4. А вот фиг его знает зачем тут вообще разрешение, ибо ничему новая виртуалка не угрожает. Но изменить регламент непросто. Особенно с учетом того, что тот кто его создавал стоит за него горой, и вообще не хочет обсужадать этот вопрос.
2. Они есть. Два дня на поднятие вертуалки. Но поднимать её по факту 1 час. А если копировать то вообще 15 мин.
3. Нет.
4. А вот фиг его знает зачем тут вообще разрешение, ибо ничему новая виртуалка не угрожает. Но изменить регламент непросто. Особенно с учетом того, что тот кто его создавал стоит за него горой, и вообще не хочет обсужадать этот вопрос.
Возможно, я нарываюсь, но, мне кажется Вы субъективны
в чем? В том что эта система мешает мне работать?
Вы абсолютно уверены, что ее отсутствие не будет кому-то другому мешать работать?
Вы можете однозначно определить какой объем бюрократии еще номрально, а какой уже зло?
или Вы вообще против любой бюрократии?
можно ли сравнить правила дорожного движения с бюрократией в предприятии?
Вы можете однозначно определить какой объем бюрократии еще номрально, а какой уже зло?
или Вы вообще против любой бюрократии?
можно ли сравнить правила дорожного движения с бюрократией в предприятии?
да я уверен что отсутвие бюрократии не будет мешать никому, зато сделает работу разработчиков, тех людей, кто в нашем отделе и создает продукт, намного эффективнее, что в итоге принесет компании прибыль.
Я не зря спросил про правила дорожного движения. Думаю, что много водителей ругаются про себя на них также, причем не в самых ее «бюрократических» проявлениях. Например, джигиты двигающиеся на красынй свет или подгазовывающие на желты, а также умолишенные, ездящие свыше 60 км. в час без особых на то разрешений.
Что будет если правила вообще отменить?
Прочитайте мой пример с админами. Я думаю, в случае «анархичного» управления — вы довольно скоро попросите о каких-нибудь ограничениях…
Что будет если правила вообще отменить?
Прочитайте мой пример с админами. Я думаю, в случае «анархичного» управления — вы довольно скоро попросите о каких-нибудь ограничениях…
правила дорожного движения плохой пример, ну хотя бы потому что там намного больший состав участников, и их задачи, а так же последствия ошибки. При этом, задача движения не доехать до места быстрее всех, а просто доехать. А задача бизнеса именно доехать быстрее всех.
микрософту про скорость езды расскажите
это монополист, они кстати еще поплатятся за то что вовремя не поняли что надо меняться. Уже отступают по всем фронтам.
Джоел Спольски, который, как известно, когда-то работал в микрософте не лестно отзывался о том, как там сейчас поставлен процесс разработки — во многих группах там «внедрили» несколько «управленческих» уровней, которые снижают эффективность работы и даже заваливают некоторые проекты.
К сожалению, точную цитату привести не могу, прочел об этом в бумажной книге «Джоел о программировании», которой нет под рукой :)
К сожалению, точную цитату привести не могу, прочел об этом в бумажной книге «Джоел о программировании», которой нет под рукой :)
не помню кто, то ли Балмер, то ли Сам отвечал на подобную критику, что стратегией МС не является как можно быстрее других сделать продукт, а в том, чтобы их продукты были в каждом доме (а в идеале и в каждом кармане)
т.е. инновации как таковые для МС неважны, для них важно внедрение инноваций повсеместно
есть книжка Гейтса «Дорога в будущее», после прочтения которой начинаешь лучше понимать зачем МС совершает или не совершает те или иные действия
Спольского, кстати, тоже люблю почитать, а про заваленные МСом проекты сам недавно топик писал :)
т.е. инновации как таковые для МС неважны, для них важно внедрение инноваций повсеместно
есть книжка Гейтса «Дорога в будущее», после прочтения которой начинаешь лучше понимать зачем МС совершает или не совершает те или иные действия
Спольского, кстати, тоже люблю почитать, а про заваленные МСом проекты сам недавно топик писал :)
я согласен с Вами про то, что МС двигает продукты в каждый дом, и это основная задача. И это на самом деле правильная позиция. Однако, мне кажется, что компания, о которой говорит автор топика, далеко не МС :) МС может себе позволить брать на себя реализацию таких масштабных задач в ущерб эффективности. Однако, вспомните, как начинался МС — не думаю, что там было все забюрократизировано, иначе они бы не смогли совершить прорыв.
ну собственно Спольски в своих статьях и описывает, как там было не в самом начале, но довольно давно — бюрократия неизбежная цена дальнейшего роста
автор может обсуждать любую компанию, но он не владеет всей полнотой информации, а может судить только со своего рабочего места и мы никогда не узнаем, зачем именно в этой компании введены столь длинные процедуры, которые могут быть для именно этой компании вполне оправданными
автор может обсуждать любую компанию, но он не владеет всей полнотой информации, а может судить только со своего рабочего места и мы никогда не узнаем, зачем именно в этой компании введены столь длинные процедуры, которые могут быть для именно этой компании вполне оправданными
по-моему мнению, задача бизнеса не просто доехать быстрее всех, но также доехать с получением прибыли. Именно на достижение последнего «небольшого нюанса» и направлена бюрократия.
то есть если задача выполняется 3 месяца вместо двух недель, это увеличит получение прибыли? если на выполнение задачи требуется не час а два дня, это увеличивает прибыль? а все компании, в кторых нет бюрократии работают на альтруизме. угумс.
компаний без бюрократии нет в принципе, вопрос в её количестве
я уже говорил, что мера должна быть. Вы же вообще против нее.
Невыполнение задачи за 2 недели может отчасти лежать на ответственном за ее выполнение — в частности, на человеке ответственном за согласование документа во всех инстанциях — это он должен был ходить и всех пинать.
Мое мнение, совсем без бюрократии в организациях, а не маленьких сборищах народу, нельзя.
Невыполнение задачи за 2 недели может отчасти лежать на ответственном за ее выполнение — в частности, на человеке ответственном за согласование документа во всех инстанциях — это он должен был ходить и всех пинать.
Мое мнение, совсем без бюрократии в организациях, а не маленьких сборищах народу, нельзя.
кстати а где я говорил что никаких ограничений быть не должно? ограничения есть, например собственный опыт, опыт коллег, условия задачи, ответвенность, распределение ролей в команде, лень, начальство в конце концов. мало?
В каком виде заданы, осуществляются и контролируются ограничения:
— условия задачи
— ответственность
— распределение ролей
— работа с начальством
— условия задачи
— ответственность
— распределение ролей
— работа с начальством
условия задачи — задаются менеджером
ответственность — неотъемлемое качество хорошего сотрудника и человека
распределение ролей — в процессе работы команды
начальство — ограничивает своей властью
ответственность — неотъемлемое качество хорошего сотрудника и человека
распределение ролей — в процессе работы команды
начальство — ограничивает своей властью
— не задается ли задача и сроки ее исполнения бумажкой (пусть и электронной)?
— как определять ответственность в достаточном объеме еще на собеседовании? Что делать если человек не ответственный, но отличный специалист.
— что делать, когда есть постоянный приход и уход людей из команды?
— есть ограничения на ограничения властью? что защищает от произвола властей?
— как определять ответственность в достаточном объеме еще на собеседовании? Что делать если человек не ответственный, но отличный специалист.
— что делать, когда есть постоянный приход и уход людей из команды?
— есть ограничения на ограничения властью? что защищает от произвола властей?
— электронность бумажки многое меняет. хотя часто задача ставится на словах, что для меня лучше, так как если есть у кого спросить, нафига мне бумажка?
— для новичка команда просто не должна давать лишних прав, а их распределением должен руководить тимлид, без бумажек. если человек не ответвленный его нужно увольнять. потому что он часть команды, и может её подставить
— надо распускать всю компанию к черту. высокая текучка признак что в компании не умеют наладить процесс. и бюрократия это костыль в таком случае. подпорка под шатающуюся систему.
— вышестоящее начальство.
— для новичка команда просто не должна давать лишних прав, а их распределением должен руководить тимлид, без бумажек. если человек не ответвленный его нужно увольнять. потому что он часть команды, и может её подставить
— надо распускать всю компанию к черту. высокая текучка признак что в компании не умеют наладить процесс. и бюрократия это костыль в таком случае. подпорка под шатающуюся систему.
— вышестоящее начальство.
1. бумажка (пусть электронная ;) поможет и тому и другому — первый не забыл чего хотел в итоге, второй не забыл к чему должен прийти.
2. Что значит, не давать лишних прав? Где лишние и не лишние права описаны? Есть ли какие-то обязанности у команды перед новичком? Как их контролировать?
3. За что увольнять неответственного? Формальный повод?
4. Текучка не в компании, а в команде. Кому-то стало больше нравится программировать, вместо тестирования. Кого-то в другой проект перекинули, потому что туда новичков одних не наберешь.
5. А как вышестоящее начальство узнает о произволе власти?
2. Что значит, не давать лишних прав? Где лишние и не лишние права описаны? Есть ли какие-то обязанности у команды перед новичком? Как их контролировать?
3. За что увольнять неответственного? Формальный повод?
4. Текучка не в компании, а в команде. Кому-то стало больше нравится программировать, вместо тестирования. Кого-то в другой проект перекинули, потому что туда новичков одних не наберешь.
5. А как вышестоящее начальство узнает о произволе власти?
я не ставил своей целью учить вас управлению командами. если вам нужны четкие предписания а сами вы ни на что без них не годны, это ваши проблемы.
a) меня не надо учить
б) я не ставил перед собой целью узнать у Вас ответы на вопросы, ответы к которым я могу сам сформулировать.
Я уже видел, что Вы согласились с тем, что без бюрократии совсем не обойтись. Поэтому предлагаю закрыть дискуссию. Спасибо.
б) я не ставил перед собой целью узнать у Вас ответы на вопросы, ответы к которым я могу сам сформулировать.
Я уже видел, что Вы согласились с тем, что без бюрократии совсем не обойтись. Поэтому предлагаю закрыть дискуссию. Спасибо.
совсем без бюрократии не обойтись, но те случаи что привели вы, в бумажной волоките не нуждаются. но существуют другие, редкие случаи, когда лучше подписать бумагу, чем разгребать последствия. именно они и не требуют внимания, что редки, и от них редко когда зависит скорость выполнения задач.
Т.е. вы просто против бумажной волокиты? И подразумевается, что «электронной» волокиты быть не может?
Хотя я согласен, электронная волокита может быть оптимизирована и автоматизирована. В другом случае, она может стать не лучше бумажной.
Хотя я согласен, электронная волокита может быть оптимизирована и автоматизирована. В другом случае, она может стать не лучше бумажной.
вот именно, вот смотрите. тот же пример с вирталками
1. Найти форму заявки, распечатать, заполнить 5 полей ручкой, подойти к начальнику, если он на месте, подписать, если нет, ждать, потом спустится на несколько этажей, отдать бумагу техдиру.
2. написать письмо: «петь, сделай виртуалку с дебианом, и юзера там заведи pupkin с правом на sudo. P.S. Шэф, если согласен, форвардни в техотдел», и отослать его начальнику. ВСЕ!
Что меняется? А то что результат тот, же а действий меньше. Да и то, в том случае если мне не доверяют, нужно слать через шефа, по мне так это лишний этам для данной задачи.
В другой компании у нас было еще лучше, была страничка со списком электронных заявок, при нажатии на нужный вариант например «создание виртуалки» открывался почтовик, с шаблоном письма. Надо было заполнить несколько полей, и просто нажать на кнопку «отправить». Если админ считает что делать этого не стоит, или не доверят тебе, то он уже сам мог связатся с начальством и уточнить, без всяких бумаг. Но такое требовалось редко, так как те кто может писать напрямую были в команде четко определены, а другие просто слали через этих людей.
Опять же, эта система нужна была не для того что бы прикрыть задницу админам, а для того что бы прикрыть задницу самих разработчиков, перевешивая ответственность на лидеров команды.
Но писать бумажную заявку да еще и с подписью начальника отдела, такое и в голову никому прийти не могло.
1. Найти форму заявки, распечатать, заполнить 5 полей ручкой, подойти к начальнику, если он на месте, подписать, если нет, ждать, потом спустится на несколько этажей, отдать бумагу техдиру.
2. написать письмо: «петь, сделай виртуалку с дебианом, и юзера там заведи pupkin с правом на sudo. P.S. Шэф, если согласен, форвардни в техотдел», и отослать его начальнику. ВСЕ!
Что меняется? А то что результат тот, же а действий меньше. Да и то, в том случае если мне не доверяют, нужно слать через шефа, по мне так это лишний этам для данной задачи.
В другой компании у нас было еще лучше, была страничка со списком электронных заявок, при нажатии на нужный вариант например «создание виртуалки» открывался почтовик, с шаблоном письма. Надо было заполнить несколько полей, и просто нажать на кнопку «отправить». Если админ считает что делать этого не стоит, или не доверят тебе, то он уже сам мог связатся с начальством и уточнить, без всяких бумаг. Но такое требовалось редко, так как те кто может писать напрямую были в команде четко определены, а другие просто слали через этих людей.
Опять же, эта система нужна была не для того что бы прикрыть задницу админам, а для того что бы прикрыть задницу самих разработчиков, перевешивая ответственность на лидеров команды.
Но писать бумажную заявку да еще и с подписью начальника отдела, такое и в голову никому прийти не могло.
OK. Я отлично понимаю ваши недовольства. И уже говорил, что бумажка может и лишняя.
Вы вот говорили, что почти все вовлеченные стороны почти готовы отказаться от бумажки.
* 1-ое «почти» — не готов самый главный босс
Тут все понятно — может действительно босс-самодур. Такое бывает и вам надо выбирать — насколько критично это для вас. Вам ваша работа важнее или же вам претит то, что вами рулит начальник-самодур.
* 2-ое «почти» — кто-то чего-то боится.
Выясните, чего конкретно они боятся: база данных полетит, проверяющие могут только бумажки проверять, на основании бумажек начисляется бухгалтерией премия и т.п. Если все опасения объективно напрасны — отказывайтесь от бумажек все вместе, ибо у базы данных есть бэкап, никаких проверяющих нет или они могут и в электронном варианте все проверять (учтите, что проверять письма в том виде, которое вы указали довольно трудно), а бухгалтерия верит всем на слово. Все равно отсутствие бумажек никто не заметит.
Вы вот говорили, что почти все вовлеченные стороны почти готовы отказаться от бумажки.
* 1-ое «почти» — не готов самый главный босс
Тут все понятно — может действительно босс-самодур. Такое бывает и вам надо выбирать — насколько критично это для вас. Вам ваша работа важнее или же вам претит то, что вами рулит начальник-самодур.
* 2-ое «почти» — кто-то чего-то боится.
Выясните, чего конкретно они боятся: база данных полетит, проверяющие могут только бумажки проверять, на основании бумажек начисляется бухгалтерией премия и т.п. Если все опасения объективно напрасны — отказывайтесь от бумажек все вместе, ибо у базы данных есть бэкап, никаких проверяющих нет или они могут и в электронном варианте все проверять (учтите, что проверять письма в том виде, которое вы указали довольно трудно), а бухгалтерия верит всем на слово. Все равно отсутствие бумажек никто не заметит.
бос не самодур, просто тот кто писал эти регламенты как то смог убедить это подписать.
бахгалтерия непричем. это просто желание делать по правилам. типа моя хата скраю, вам надо вот и выполняйте…
да, бороться с этой системой буду, но на это нужно время, которого итак из-за этого бардака не хватает. пойти, открыть дверь ногой гендира и наябедничать тоже не выход, хотя это и могло бы быстро все решить.
бахгалтерия непричем. это просто желание делать по правилам. типа моя хата скраю, вам надо вот и выполняйте…
да, бороться с этой системой буду, но на это нужно время, которого итак из-за этого бардака не хватает. пойти, открыть дверь ногой гендира и наябедничать тоже не выход, хотя это и могло бы быстро все решить.
ну про угрозы и т.п. это вы можете всего и не знать. вы же профессионально не занимаетесь администрированием вирт. машин.
если нету причин отказа, то непонятно зачем это все надо — конечный результат всегда известен, получается это все просто лишняя цепочка шагов, которую можно вычеркнуть…
но учитывая что тот кто разрабатывал регламент — упертый, то тут либо писать последнее китайское предупреждение (последняя попытка что-то исправить) начальнику начальника что мол как все плохо, исправлять будем? либо увольняться, ну либо смириться
если нету причин отказа, то непонятно зачем это все надо — конечный результат всегда известен, получается это все просто лишняя цепочка шагов, которую можно вычеркнуть…
но учитывая что тот кто разрабатывал регламент — упертый, то тут либо писать последнее китайское предупреждение (последняя попытка что-то исправить) начальнику начальника что мол как все плохо, исправлять будем? либо увольняться, ну либо смириться
я достаточно опытный Юникс-прользователь, и отлично представляю себе все опасности. Мало того, я уже работал в компании где каждый пользователь имел свой jail, и никаких бумаг для создания нового не требовалось, и проблем никаких не возникало. Мало того, я так же работал в компании где каждый разработчик имел всего лишь свою хому, в качестве места разработки, то есть теоретически мог помешать другим разработчикам, но даже при этом никаких проблем не возникло ни разу. А здесь изолированная виртуалка!
Если подробнее, звоню техдиру в другой отдел, прошу машину. Он сначала соглашается, потом перезванивает и напоминает про бумагу. Я предлагаю просто поставить на него задачу через начальника моего отдела. То есть я ставлю на начальника, он, переводит на техдира, чем подтверждает что согласен. НО это не катит с формулировкой что «а вдруг база с тикетами похерится», при этом уверяет что ничего не имеет против создания машины без документа, но таковы правила которые не он придумал и не ему их отменять.
Автор, сократи статью в 4 раза, вылей всю воду и можно будет читать.
Правила и регламенты разработки обычно нужны для того, что бы потом можно было разобраться что к чему.
Стандарты именования вещь тоже полезная хотя бы для того что бы через год не заниматься археологией и изысканиями что это за версия и о чем вообще разговор был…
Относительно запросов на VMware image. Может у вас там люди подсчитывают каждую лицензию на Windows, и поэтому придирчиво относятся к новым istance (у нас например так). Статические IP-адреса тоже имеет смысл держать под контролем, что бы не было конфликтов.
Возможно у вас регламентаторы перегнули палку, но в большом количестве случаев они правы. Попробуйте просто посмотреть на правила их глазами и понять зачем они вводили правила.
Стандарты именования вещь тоже полезная хотя бы для того что бы через год не заниматься археологией и изысканиями что это за версия и о чем вообще разговор был…
Относительно запросов на VMware image. Может у вас там люди подсчитывают каждую лицензию на Windows, и поэтому придирчиво относятся к новым istance (у нас например так). Статические IP-адреса тоже имеет смысл держать под контролем, что бы не было конфликтов.
Возможно у вас регламентаторы перегнули палку, но в большом количестве случаев они правы. Попробуйте просто посмотреть на правила их глазами и понять зачем они вводили правила.
стандарты именования пользователей свн никаого удобства для изысканий не дают
если лицензии на VMware что-то для нас стоят, в чем я сомневаюсь, нет никаких проблем заменить её бесплатной версией, qemu, virtualbox, jail и кучей чего еще.
ip адреаса в локальной сети ресурс халявный
если лицензии на VMware что-то для нас стоят, в чем я сомневаюсь, нет никаких проблем заменить её бесплатной версией, qemu, virtualbox, jail и кучей чего еще.
ip адреаса в локальной сети ресурс халявный
Командная работа не для вас…
Если уж вам известно, что срок создания виртуалки — два дня, то почему бы заранее не попросить об этом? По-моему проблема надумана. А порядок в разработке еще никому не мешал.
создание виртуалки — 1 час. создание виртуалки + подписание бумаг заняло 2 дня. Конечно в будующем займет меньше. Но все арвно гораздо больше чем просто звонок или email
А смысла в бумаге просто ноль! Особенно учитывая что я сделаю эталон, который можно будет просто копировать, что вообще будет занимать 10 мин. То есть 10 мин создание виртуалки и 20 подписание бумаги. Охрененно.
И я повторяю, если бы это была единственная бумага, и единственный припон, можно было пережить. Но таких вот мелочей масса. И каждый день их количество растет, и не знаешь что придумают завтра.
А смысла в бумаге просто ноль! Особенно учитывая что я сделаю эталон, который можно будет просто копировать, что вообще будет занимать 10 мин. То есть 10 мин создание виртуалки и 20 подписание бумаги. Охрененно.
И я повторяю, если бы это была единственная бумага, и единственный припон, можно было пережить. Но таких вот мелочей масса. И каждый день их количество растет, и не знаешь что придумают завтра.
Хехе, у нас похожая ситуация с базами данных и серверами: без бумажек, одними запросами по IM наплодили стомильенов баз и стомильенов серверов приложений. И теперь ооооочень сложно разобраться, нужна щас эта база или ее можно грохать, нужен ли сервер или его можно не переносить на новое железо.
Так что зря вы так, вы смотрите только со своей стороны, взгляните со стороны ответственных за это.
Так что зря вы так, вы смотрите только со своей стороны, взгляните со стороны ответственных за это.
А что меняет бумажка? От неё сервера сами будут умирать без ведома админа?
Нет. Но когда встанет вопрос «А это что еще за фигня в Оракле, может ее грохнуть?» по бумажке (тикет системе, etc) можно будет отследить кому и зачем создавалась схема и потом тыкать палочкой уже в конкретного человека.
бумажка и тикет это не одно и тоже. Тикет это элементарное удобство, выгодное обоим сторонам, он гарантирует что одна сторона не забудет сделать, а вторая что первая старана не скажет «ниче ты мне не говорил».
Но зачем бумажка?
Но зачем бумажка?
>бумажка и тикет это не одно и тоже.
Вот тут то у вас по-моему и проблема. Это на самом деле одно и то же. Просто тикет хранится в БД, а бумажка — в папочке у сисадмина (в архиве, etc). Написать текст заявки в шаблоне, распечатать и сносить на подпись не сильно дольше чем написать текст заявки в тикет трекере.
Вот тут то у вас по-моему и проблема. Это на самом деле одно и то же. Просто тикет хранится в БД, а бумажка — в папочке у сисадмина (в архиве, etc). Написать текст заявки в шаблоне, распечатать и сносить на подпись не сильно дольше чем написать текст заявки в тикет трекере.
Побей бюрократа собственным оружием — затяни процесс и свали на долгий регламент
всё вспоминал, что мне эта истерика напоминает…
вспомнил — http://habrahabr.ru/blogs/i_am_clever/48097/ — автор тот же
в общем у автора явно проблемы с окружающим миром — ждём очередного поста "я уволился"
вспомнил — http://habrahabr.ru/blogs/i_am_clever/48097/ — автор тот же
в общем у автора явно проблемы с окружающим миром — ждём очередного поста "я уволился"
У человека наболело!
Ну это везде так ( это не болезнь России… это болезнь мест где есть инертность. Где человек может сидеть два, три, четыре года ничего не делая, создавая видимось работы, напрягая ненужным флудом рабочий процесс и потом спокойно уйти на повышение или на покой (благодаря каким то семейно-личным факторам). Его производительность или ее отсутствие не влияет радикально на производство, по крайней мере на период его работы… Тут или менять место жительства или брать коктейль сами знаете кого и провозгашать Новую Идеологию… но через некоторый промежуток времени все равно появится инертность…
Ну это везде так ( это не болезнь России… это болезнь мест где есть инертность. Где человек может сидеть два, три, четыре года ничего не делая, создавая видимось работы, напрягая ненужным флудом рабочий процесс и потом спокойно уйти на повышение или на покой (благодаря каким то семейно-личным факторам). Его производительность или ее отсутствие не влияет радикально на производство, по крайней мере на период его работы… Тут или менять место жительства или брать коктейль сами знаете кого и провозгашать Новую Идеологию… но через некоторый промежуток времени все равно появится инертность…
Бюрократия в некотором роде нужна. Документация, по сути, — тоже бюрократия. Крупная компания не может себе позволить зависеть от одного человека, который как хотел, так и спроектировал/запустил/написал что-то. Все это приходится утверждать. Утверждения хранить. В случае неисправности можно будет найти кого надо и исправить что надо.
В мелких компаниях все по-другому. Все висит в голове одного-двух человек, которые являются ключевыми для компании. И уже не важно, сколько высококвалифицированных специалистов наймет компания, уход первых двух грозит крахом всей конторе.
Представьте, что вы руководите группой, где каждый принимает решение сам и делает все сам, не зная, что делают другие. А теперь представьте что вы руководите группой руководителей, которые так же руководят.
Бюрократия замедляет процесс. Иногда очень даже существенно. Но это скорее необходимость, чем чьи-то изыски.
Есть предел, когда имеется смысл «ставить на поток» компанию, а когда нет. Вы работаете в немаленькой компании (заглянул вам в профиль). Либо миритесь, либо ищите другую работу.
В мелких компаниях все по-другому. Все висит в голове одного-двух человек, которые являются ключевыми для компании. И уже не важно, сколько высококвалифицированных специалистов наймет компания, уход первых двух грозит крахом всей конторе.
Представьте, что вы руководите группой, где каждый принимает решение сам и делает все сам, не зная, что делают другие. А теперь представьте что вы руководите группой руководителей, которые так же руководят.
Бюрократия замедляет процесс. Иногда очень даже существенно. Но это скорее необходимость, чем чьи-то изыски.
Есть предел, когда имеется смысл «ставить на поток» компанию, а когда нет. Вы работаете в немаленькой компании (заглянул вам в профиль). Либо миритесь, либо ищите другую работу.
>Представьте, что вы руководите группой, где каждый принимает решение сам и делает все сам, не зная, что делают другие
Тогда меня надо уволить. Бюрократия тут непричем. Это вопрос коммуникации и управления командой.
Тогда меня надо уволить. Бюрократия тут непричем. Это вопрос коммуникации и управления командой.
Ну опять Вы перегибаете. Правила (часть бюрократии) определяют кому, что и когда делать, кому, как и с кем коммуницировать, кому, как и в каком объеме сдавать работу, кому, кто, когда и сколько за эту работу заплатят.
вы когда находитесь в обществе пукаете и рыгаете? Нет? А почему? Где это все написано, в каких правилах?
Но ведь кто-то так делает… и его ничего не останавливает… не было бы правил оговариваемых явно родителями, садиком, школой и пр., то это бы происходило на каждом углу. Но правила есть, я думаю они даже где-то описаны.
Суть в том, что эти правила достаточно просты и они только отчасти относятся к теме управлению людьми и коллективами.
В управлении же группами людей «неявных» правил будет уже недостаточно ибо у каждого свое воспитание, свои взгляды на жизнь и жизненные приоритеты. Они никогда не будут абсолютно самоорганизующимися, самомотивирующимися и самодостаточными. Это — коммунизм. Мечта, хоть и красивая. Чтобы хоть как-то усреднить возможное неблагоприятное воздействие и хаос (который необязательно, но может возникуть) формируются правила работы с группой этих людей. Чтобы все правила каждому не запоминать и не пересказывать их заново новому человеку их оформляют письменно.
Суть в том, что эти правила достаточно просты и они только отчасти относятся к теме управлению людьми и коллективами.
В управлении же группами людей «неявных» правил будет уже недостаточно ибо у каждого свое воспитание, свои взгляды на жизнь и жизненные приоритеты. Они никогда не будут абсолютно самоорганизующимися, самомотивирующимися и самодостаточными. Это — коммунизм. Мечта, хоть и красивая. Чтобы хоть как-то усреднить возможное неблагоприятное воздействие и хаос (который необязательно, но может возникуть) формируются правила работы с группой этих людей. Чтобы все правила каждому не запоминать и не пересказывать их заново новому человеку их оформляют письменно.
таких немного, и обычно они не долго держатся в приличном обществе. Это и есть направляющий фактор. Так и в командах, да, есть шанс что придет неадекват, но он долго не продержится в нормальной команде, его либо перевоспитают либо вытолкнут из команды. И без всяких бумажек и правил.
И именно для того есть тимлид, который, в случае перекосов, должен направить команду, разобратся в причине прекоса, а не просто ткнуть рожей в правила.
И именно для того есть тимлид, который, в случае перекосов, должен направить команду, разобратся в причине прекоса, а не просто ткнуть рожей в правила.
В приличном, согласен, не много… Но велико ли это приличное общество само по себе? :)
Так и с командой… вы же сами уже косвенно ссылались (в ветке про ПДД) на то, что правила начнуться тогда, когда количество элементов вовлеченных в процесс будет больше. Не спорю, внутри команды (если она достаточно замкнута в плане прихода новых людей) можно установить соглашения не публикуя их на бумаге и такое происходит всюду и все. Но это чаще всего заканчивается только этой командой, т.е. когда появляются несколько команд и между ними нужно взаимодействие — здесь уже нужны будут другие правила и скорее всего проработанные, обсужденые и документально оформленные.
Так и с командой… вы же сами уже косвенно ссылались (в ветке про ПДД) на то, что правила начнуться тогда, когда количество элементов вовлеченных в процесс будет больше. Не спорю, внутри команды (если она достаточно замкнута в плане прихода новых людей) можно установить соглашения не публикуя их на бумаге и такое происходит всюду и все. Но это чаще всего заканчивается только этой командой, т.е. когда появляются несколько команд и между ними нужно взаимодействие — здесь уже нужны будут другие правила и скорее всего проработанные, обсужденые и документально оформленные.
вот именно. конечно существую примеры команд из 100 разработчиков, и там, может быть, свои законы. Но тут речь о небольших командах. И наверное, команды будут различаться в подходах, это зависит от их составах, от их лидеров, от их задач. Но кардинальных различий все равно не будет, так как все команды будут тяготеть к удобству, и врятли станут пересылать письма голубиной почтой, и расписываться кровью. Тем более в условиях конкуренции между собой, их подходы быстро унифицируются, и никаких регламентов не понадобится, потому как обычно люди не враги себе, и стремятся выбирать наиболее эффективные подходы.
В идеальном мире, да.
Но в реальном мире, бюрократия в том или ином виде все равно будет ибо система не замкнута и именно взаимодействие с другимим системами и будет регламентироваться. Пример в ваших терминах, таже «тикет-система».
В зависимости от количества и качества связей, регламент может быть как обговоренный чисто на словах (ты делаешь то, ты делаешь это) так и закрепленный в бумаге (за выполненную работу ты получишь такие вот плюшки).
Но в реальном мире, бюрократия в том или ином виде все равно будет ибо система не замкнута и именно взаимодействие с другимим системами и будет регламентироваться. Пример в ваших терминах, таже «тикет-система».
В зависимости от количества и качества связей, регламент может быть как обговоренный чисто на словах (ты делаешь то, ты делаешь это) так и закрепленный в бумаге (за выполненную работу ты получишь такие вот плюшки).
во первых не нужно оправдываться неидеальностью мира.
во вторых, никто не говрит что надо искоренять бюрократию (кстати я этот термин применил именно в плохом смысле, а не вообще к документообороту как таковому) полностью. понятно что раздавать рута всем желающим не следует.
а тикет-система нужна для удобства в первую очередь тех, кто ей пользуется.
во вторых, никто не говрит что надо искоренять бюрократию (кстати я этот термин применил именно в плохом смысле, а не вообще к документообороту как таковому) полностью. понятно что раздавать рута всем желающим не следует.
а тикет-система нужна для удобства в первую очередь тех, кто ей пользуется.
Понимание неидеальности мира, помагает предусмотреть варианты событий, которые в идеальном мире никогда не случились бы. А равно направлять усилия на решение конкретных задач заранее, а ни когда они уже стало поздно.
Иначе (я конечно утрирую, но это же идеальный мир),
— зачем мне описывать регламент работы с админами, ведь я всегда знаю, что все мои запросы *всегда* не потеряются и отбработаются вовремя;
— зачем мне подписывать заявление на отпуск, бухгалтерия и так догадается что я ухожу в отпуск и перечислит мне отпускные вовремя;
— зачем описывать процесс приемки работ заказчиком, мы же друг другу доверяем я и так наизусть помню да и он никогда не забудет о чем мы договаривались полгода назад.
Иначе (я конечно утрирую, но это же идеальный мир),
— зачем мне описывать регламент работы с админами, ведь я всегда знаю, что все мои запросы *всегда* не потеряются и отбработаются вовремя;
— зачем мне подписывать заявление на отпуск, бухгалтерия и так догадается что я ухожу в отпуск и перечислит мне отпускные вовремя;
— зачем описывать процесс приемки работ заказчиком, мы же друг другу доверяем я и так наизусть помню да и он никогда не забудет о чем мы договаривались полгода назад.
— регламент работы с админами — тимлид решает кто может работать с админами. админы решают форму подачи заявки. Вот и весь регламент.
— Заявление на отпуск требуется по закону. Речь тут не об этом. Наличие этого правила, установленного законом России, не говорит что сверху надо придумать еще и заявление на выходные или там заявление на уход с работы домой, а каждый день писать утром заявление о приеме на работу.
— никакого описания приемки работ не требуется. заказчик, или его представитель участвует в проекте непрерывно, и естетсвенно, ничего забыть просто не может, ибо все время контролирует ход проекта.
— Заявление на отпуск требуется по закону. Речь тут не об этом. Наличие этого правила, установленного законом России, не говорит что сверху надо придумать еще и заявление на выходные или там заявление на уход с работы домой, а каждый день писать утром заявление о приеме на работу.
— никакого описания приемки работ не требуется. заказчик, или его представитель участвует в проекте непрерывно, и естетсвенно, ничего забыть просто не может, ибо все время контролирует ход проекта.
— время обработки заявки? ее приоритет? зависимость времени обработки от приоритета? правила установки приоритета? Да даже то, что вы описали уже «бюроктратия» иначе бы в реальном мире не работало (но мы уже по кругу ходим)
— а закон РФ для вас не бюрократия? Ведь государстово, по сути корпорация со своими департаментами, проектами, проектными командами (и здесь опять по кругу)
— заказчик всегда может участвовать в проекте в реальном мире? (все, замкнулся).
DeadLock
— а закон РФ для вас не бюрократия? Ведь государстово, по сути корпорация со своими департаментами, проектами, проектными командами (и здесь опять по кругу)
— заказчик всегда может участвовать в проекте в реальном мире? (все, замкнулся).
DeadLock
не доводи до фанатизма (с)
извините, это все доводы?
а что еще? Вы дошли до того что бы отменить законы РФ. Давайте еще и законы физики отменим, это ведь тоже бюрократия. Почему скорость света такая, я хочу другую скорость света.
где я это писал? я поставил законы РФ как более глобальную аналогию того с чем вы боретесь локально. То что я хочу их отменить — Вы сами придумали.
эта аналогия и есть фанатизм. потому что никакой аналогией здесь и гне пахнет хотя потому что людей миллионы а сотрудников в компании всего лишь сотни, а в отделе, о котором тут и идет речь — десятки.
где грань? на каком конкретно по номеру человеке (мое мнение — на втором) аналогия начинает быть верна?
какой ответ вы хотите получить на свой вопрос? Я вам скажу 200 человек — грань. И что бы доказать, мне придется провести ряд экспериментов с разным количеством людей, и защитить диссертацию по этому вопросу. А до этого, будем начинать с двух, просто на всякий случай, вдруг и правда грань начинается с двух человек. Ну а когда я закончу свой научный труд, тогда посмотрим. Так получается?
Вот она логика тех кто пишет директивы. Так недалеко до того что вы в своей семье будете создавать законы, и жить по ним.
Вот она логика тех кто пишет директивы. Так недалеко до того что вы в своей семье будете создавать законы, и жить по ним.
А разве не так (про семью)? Пример, брачные контракты.
Вы только не путайте, что неформальные договоренности это тоже «правила». Просто в какой-то момент времени их удобнее записать их на бумаге. А в какой-то времени начать требовать формальное подтверждение этим договоренностям.
Вы только не путайте, что неформальные договоренности это тоже «правила». Просто в какой-то момент времени их удобнее записать их на бумаге. А в какой-то времени начать требовать формальное подтверждение этим договоренностям.
брачные контракты это пример идиотизма и бюрократии там, где это не нужно. Но это другая тема.
неформальные договоренности никогда не требуют их записи на бумаге, так как чем дальше, тем они крепче. и если они небыли записаны с самого начала, но при этом работают, то никуда их записывать нет никакой надобности.
неформальные договоренности никогда не требуют их записи на бумаге, так как чем дальше, тем они крепче. и если они небыли записаны с самого начала, но при этом работают, то никуда их записывать нет никакой надобности.
меряйте не длительностью, а объемом (договоренностей или людей). Человеческая память не может хранить многое и долго и это не всегда вина конкретного человека.
в том то и дело что память не нужна. вы же не забываете как ходить, что есть, что матом ругатся нельзя, что нужно здороваться, что нужно уступать место старикам и огромное количество других общественных договоров, несмотря на то что их становится все больше и больше.
а зачем тогда на дверях в метро приклеили «придерживайте двери», а в общественном транспорте объявляют «про пожилых, беременных женщин и пассажиров с детьми» и т.д. и т.п.?
кажется дискуссия заходит в тупик, все остаются при своем, т.к. на каждый аргумент находится контр.
кажется дискуссия заходит в тупик, все остаются при своем, т.к. на каждый аргумент находится контр.
но вас же не заставляют в метро подписывать бумагу что вы обязуетесь уступать место бабушкам
находясь в ОТ вы обязаны выполнять правила этого самого ОТ (по сути, вы соглашаетесь с договором публичной оферты), а в этих самых правилах прописано, сколько мест отводится старикам и детям
кстати, без бюрократии ОТ не мог бы функционировать :)
ладно, я заканчиваю спорить ибо бессмысленно, вы через чур импульсивны
кстати, без бюрократии ОТ не мог бы функционировать :)
ладно, я заканчиваю спорить ибо бессмысленно, вы через чур импульсивны
Заявка только в бумажной форме на виртуалку. Это маразм.
Вообще бумага в IT признак необходимости сменs CIO.
Вообще бумага в IT признак необходимости сменs CIO.
А у нас обратная ситуация. Пытаемся внедрить хоть немного бюрократии (в хорошем смысле слова).
ну смотря что называть бюрократией. например тикет-система это бюрократия? Помоему это элементарное удобство.
Но согласитесь, может найтись человек, который может утверждать обратное.
Особенно, если сказать, просто «тикет-система». Вы же не указываете, что под ней подразумаваете. Может в моем понятии это ежечасные апдейты по тикету, относительно проделанной в рамках этого тикета работы.
Особенно, если сказать, просто «тикет-система». Вы же не указываете, что под ней подразумаваете. Может в моем понятии это ежечасные апдейты по тикету, относительно проделанной в рамках этого тикета работы.
а об этом я тут уже как то писал, когда у нас Jira попытались использовать не как инструмент учета задач, а как инструмент слежки за сотрудниками. вот пост habrahabr.ru/blogs/development/47022/
Собственно ничего не вышло, никто не захотел следовать этому идиотскому регламенту, а чуть позже уволилось половина разработчиков, а за ними сбежал (при достаточно странных обстоятельствах) и тот, кто этот регламент придумал.
Собственно ничего не вышло, никто не захотел следовать этому идиотскому регламенту, а чуть позже уволилось половина разработчиков, а за ними сбежал (при достаточно странных обстоятельствах) и тот, кто этот регламент придумал.
Я немножко про другое.
Я про различные уровня понимания одного предмета, разными людьми, которые видят в нем достижения разных целей.
Пример 1: нет тикет-систем — задачи раздаются на словах.
Девелопер: «ну нормально, мы все понимаем что делать, ничего что я могу что-то забыть — тимлид всегда помнит, если что напомнит»
ленивый девелопер: «круто, могу схалявить, потом скажу что не так понял, не то имел ввиду или вообще забыл»
Кастомер: «мне не удобно, я сказал им что у меня соединения на сильном трафике отпадают, когда они это профиксят, фиксят ли они это сейчас, может вообще забыли»
Пример 2: просто тикет-система (пришла задача-ушла задача)
Девелопер: «это же удобно, я знаю, что на мне лежит задача, я могу указать когда я ее закончу»
ленивый девелопер: «это же бюрократия, они следят за мной, никакой свободы»
Кастомер: «ну вот тикет взяли, видимо работают, а что конкретно сейчас делается, чтобы у меня все профиксилось, я уже из-за постоянно рвущихся соединений кучу звонков пропустил»
Пример 2: тикет-система с получасными апдейтами
Девелопер: «это же бюрократия, они следят за мной»
ленивый девелопер: «я увольняюсь»
Кастомер: «ну вот тикет взяли, уже доложились, что уже поняли в чем проблема, сказали, что пишут патч, через полчаса просят предоставить ресурсы для загрузки патча, пойду, открою тикет админу — пусть подготовится»
Я про различные уровня понимания одного предмета, разными людьми, которые видят в нем достижения разных целей.
Пример 1: нет тикет-систем — задачи раздаются на словах.
Девелопер: «ну нормально, мы все понимаем что делать, ничего что я могу что-то забыть — тимлид всегда помнит, если что напомнит»
ленивый девелопер: «круто, могу схалявить, потом скажу что не так понял, не то имел ввиду или вообще забыл»
Кастомер: «мне не удобно, я сказал им что у меня соединения на сильном трафике отпадают, когда они это профиксят, фиксят ли они это сейчас, может вообще забыли»
Пример 2: просто тикет-система (пришла задача-ушла задача)
Девелопер: «это же удобно, я знаю, что на мне лежит задача, я могу указать когда я ее закончу»
ленивый девелопер: «это же бюрократия, они следят за мной, никакой свободы»
Кастомер: «ну вот тикет взяли, видимо работают, а что конкретно сейчас делается, чтобы у меня все профиксилось, я уже из-за постоянно рвущихся соединений кучу звонков пропустил»
Пример 2: тикет-система с получасными апдейтами
Девелопер: «это же бюрократия, они следят за мной»
ленивый девелопер: «я увольняюсь»
Кастомер: «ну вот тикет взяли, уже доложились, что уже поняли в чем проблема, сказали, что пишут патч, через полчаса просят предоставить ресурсы для загрузки патча, пойду, открою тикет админу — пусть подготовится»
1. общение должно быть всегда, и задача должна в первую очередь объяснятся на словах. ТЗ, тикеты это все второстепенные вещи, вспомогательные.
2. тикет ставится кастомером, и в принципе девеловеру кагбы параллельно, ну стоит тикет, ну и пусть сибе стоит, помнишь на словах, отлично, забыл, тут у тебя выбор — посмотреть в тикет или подойти к тимлиду или ПМу. Нет смысла быть против тикета.
3. Кастомер всегда может подойти/позвонить/написать и узнать состояние задачи, и делать это может так часто, как считает необходимым.
И никаких проблем нет ни у кого! Халявить не удастся, так как есть личный контроль, тикеты есть, но ими пользуется тот, кому это удобнее. Все в курсе состояния проекта. Сохраняется живое общение, и проблемы выясняются по ходу.
Представим пример когда это не работает. Ну например ПМ не интересуется ходом задачи. Этого же нет в правилах подписанных гендиром. Отлично, через месяц выясняется что задача выполнена неверно. ПМ потирает пятую точку, девелопер тоже не в восторге. Я думаю эта идиотская ситуация больше не повторится, да и сама по себе она маловероятна, так как никому не выгодна.
Создается система, устраивающая всех. Ну разве что ленивый ПМ может быть недоволен, но это уже не проблема разработчика.
2. тикет ставится кастомером, и в принципе девеловеру кагбы параллельно, ну стоит тикет, ну и пусть сибе стоит, помнишь на словах, отлично, забыл, тут у тебя выбор — посмотреть в тикет или подойти к тимлиду или ПМу. Нет смысла быть против тикета.
3. Кастомер всегда может подойти/позвонить/написать и узнать состояние задачи, и делать это может так часто, как считает необходимым.
И никаких проблем нет ни у кого! Халявить не удастся, так как есть личный контроль, тикеты есть, но ими пользуется тот, кому это удобнее. Все в курсе состояния проекта. Сохраняется живое общение, и проблемы выясняются по ходу.
Представим пример когда это не работает. Ну например ПМ не интересуется ходом задачи. Этого же нет в правилах подписанных гендиром. Отлично, через месяц выясняется что задача выполнена неверно. ПМ потирает пятую точку, девелопер тоже не в восторге. Я думаю эта идиотская ситуация больше не повторится, да и сама по себе она маловероятна, так как никому не выгодна.
Создается система, устраивающая всех. Ну разве что ленивый ПМ может быть недоволен, но это уже не проблема разработчика.
В данном конкретном случае:
Ну то есть это нормально, когда у кастомера проблема, а это он еще и к вам должен за статусами бегать каждые полчаса, а не вы к нему за его деньги?
Нормально каждые полчаса ПМу бегать к тимлиду за статусом задачи?
Нормально тимлиду бегать к каждому девелоперу за статусом?
Если специфика работ такова, что подобные тикеты являются больше практикой, чем исключением — это обговаривается в должностных инструкциях и правилах проекта (бюрократия?).
Иначе, крайнего никогда не найти. Каждый может сослаться, что ничего не слышал, ничего не понял. Несознательных девелоперов наказывать не за что, несознательных тимлидов и менеджеров тоже — всем, как вы говорите, параллельно… Мир-то идеальный, бабло течет, делать ничего не надо.
Ну то есть это нормально, когда у кастомера проблема, а это он еще и к вам должен за статусами бегать каждые полчаса, а не вы к нему за его деньги?
Нормально каждые полчаса ПМу бегать к тимлиду за статусом задачи?
Нормально тимлиду бегать к каждому девелоперу за статусом?
Если специфика работ такова, что подобные тикеты являются больше практикой, чем исключением — это обговаривается в должностных инструкциях и правилах проекта (бюрократия?).
Иначе, крайнего никогда не найти. Каждый может сослаться, что ничего не слышал, ничего не понял. Несознательных девелоперов наказывать не за что, несознательных тимлидов и менеджеров тоже — всем, как вы говорите, параллельно… Мир-то идеальный, бабло течет, делать ничего не надо.
да это нормально бегать к разработчику, так как это выгодно для проекта в целом, а значит выгодно и тому кто платит деньги и тому кто управляет процессом. а каждые пол часа или каждый день это уже по ситуации.
Ну вот Вы и ответили на свои вопросы — бюрократия в плохом смысле слова появляется тогда, когда какой-то элемент системы начинает думать, что он самый главный.
Вы только что привели, пример, рассуждения типичного бюрократического винтика — пусть они ко мне побегают, это же *им* надо.
Вы только что привели, пример, рассуждения типичного бюрократического винтика — пусть они ко мне побегают, это же *им* надо.
это вы щас привели типичный пример рассужедния «зачем он это просит, ах, хочет ЧСВ поднять, нихрена, мой ЧСВ больше» и даже и мысли небыло о том, что так просто лучше для проекта, ибо именно программист производит продукт. Что бы было если бы рабочий у конвейера каждые пол часа останавливал бы его, что бы пойти сообщить о количестве брака.
то что я сказал это просто оптимально и логично, и «пусть они побегают» тут абсолютно непричем
то что я сказал это просто оптимально и логично, и «пусть они побегают» тут абсолютно непричем
Кто определяет «что лучше»? Если Вы, то почему Вы это за кого-то определили и чем тогда Вы лучше тех, кто определяет, что лучше для Вас?
здравый смысл определяет и удобство обоих участников процесса. повторяю участников процесса, а не сторонних личностей, пишущих регламенты.
я говорил о сторонних личностях? если вы против всех (но вы же вроде не против) регламентов, значит ли это что ваш непосредственный начальник и начальник начальника тоже против?
Кто определяет здравый смысл? Когда здравый смысл перестает быть здравым?
Как я уже говорил, вы оперируете субъективными понятиями и никак не хотите посмотреть хотя бы по ту сторону баррикад, чтобы быть чуть-чуть объективнее.
Кто определяет здравый смысл? Когда здравый смысл перестает быть здравым?
Как я уже говорил, вы оперируете субъективными понятиями и никак не хотите посмотреть хотя бы по ту сторону баррикад, чтобы быть чуть-чуть объективнее.
вот как бы объяснить, что многие странные для разработчика требования — на самом деле банальная жизненная необходимость. что-то требует кастомер, без чего-то будут проблемы при интегрэйшине, где-то дефицит ресурсов а что-то банально неприоритетно или невозможно, а бывает еще так, что есть действительно абсолютно бредовое требование или процесс, но по каким-то независимым причинам приходится ему следовать, ибо менять его выйдет дороже.
а еще бывает «документацию прочитал по диагонали, почту не читаю, но вчера у меня все работало!», «а у меня на машине работает, это у вас неправильный сервер!» и «а нафига нам эти тесты и coding style checking?» или «а мне неудобно писать комментарии к коммитам!», и хоть трава не расти!
дочтаточно давно я работаю «по ту сторону» разработки ПО и очень обидно сталкваться с подобным непониманием.
да, бумага на создание VM — это просто ужасно (сейчас сам в похожем положении), но стандарт на именование и структуру директорий в svn — на многих проектах весьма полезен, так же, как и соглашения по именованию переменных, так же, как и общий процесс для перехода в QA и еще многие вещи. после определенного баръера человеко-часов без этой бюрократии проект может просто развалиться под собственным весом.
а еще бывает «документацию прочитал по диагонали, почту не читаю, но вчера у меня все работало!», «а у меня на машине работает, это у вас неправильный сервер!» и «а нафига нам эти тесты и coding style checking?» или «а мне неудобно писать комментарии к коммитам!», и хоть трава не расти!
дочтаточно давно я работаю «по ту сторону» разработки ПО и очень обидно сталкваться с подобным непониманием.
да, бумага на создание VM — это просто ужасно (сейчас сам в похожем положении), но стандарт на именование и структуру директорий в svn — на многих проектах весьма полезен, так же, как и соглашения по именованию переменных, так же, как и общий процесс для перехода в QA и еще многие вещи. после определенного баръера человеко-часов без этой бюрократии проект может просто развалиться под собственным весом.
все перечисленное легко решается без бумаг и регламентов.
буду искренне благодарен примерам. как минимум одна бумага будет всегда — набор исходных требований (техзадание, бизнес-требования, спецификация и так далее). и их бывает очень много или они бывают довольно большими. а иногда еще и загадочными.
из практики:
1.) тестовый стенд. приближен к «боевым условиям» — то есть, интерфейс взаимодействия крайне ограничен. можно инсталлировать приложение, можно передать набор конфигураций через специальный интерфейс, ничего другого — нельзя, ибо при выходе в production не факт что нам дадут хотя бы это. да, можно подцепиться отладчиком, посмотреть логи, сделать рестарт и очистку кэшей, разумеется, все, остальное только read-only.
2.) приведенный выше пример следовать заданной степени test coverage, комментировать коммиты и осмысленно закрывать таски (да, иногда требуется немного больше, чем поставить статус FIXED) — что-то вытекает из внешних требований, что-то из внутренней организации процесса.
3.) из-за жестких требований иметь на все исходный код и передавать в качестве релиза исходный код всего, кроме ряда исключений, опять таки — суровые ограничения на использование инструментов (билд система, кое-что даже на ide завязано) и общих/внешних компонент и библиотек.
отзывы, соответственно:
1.) а мы сделали по-своему и у нас работает
2.) нам это не удобно и мы так не хотим/не будем
3.) что за бред?
и, пожалуй, я все три реакции понимаю, особенно последнюю, так как она вступает в противоречие с некоторыми исходными требованиями и некоторыми best practice, ровно как и со здравым смыслом (на первый взгляд)
вопрос — как сделать не прибегая к жестким мерам и регламентации процессов? из третьего, например, следует, что перед тем как брать какой-либо внешний компонент, надо заапрувить это решение (благо, делается без бумаг и довольно быстро — полуавтоматически, но некоторая бюрократия присутствует).
на аналогичном проекте сделали по принципу «ничего не должно мешать разработке». теперь ни выйти в production не получается, ни с соседями интегрироваться.
из практики:
1.) тестовый стенд. приближен к «боевым условиям» — то есть, интерфейс взаимодействия крайне ограничен. можно инсталлировать приложение, можно передать набор конфигураций через специальный интерфейс, ничего другого — нельзя, ибо при выходе в production не факт что нам дадут хотя бы это. да, можно подцепиться отладчиком, посмотреть логи, сделать рестарт и очистку кэшей, разумеется, все, остальное только read-only.
2.) приведенный выше пример следовать заданной степени test coverage, комментировать коммиты и осмысленно закрывать таски (да, иногда требуется немного больше, чем поставить статус FIXED) — что-то вытекает из внешних требований, что-то из внутренней организации процесса.
3.) из-за жестких требований иметь на все исходный код и передавать в качестве релиза исходный код всего, кроме ряда исключений, опять таки — суровые ограничения на использование инструментов (билд система, кое-что даже на ide завязано) и общих/внешних компонент и библиотек.
отзывы, соответственно:
1.) а мы сделали по-своему и у нас работает
2.) нам это не удобно и мы так не хотим/не будем
3.) что за бред?
и, пожалуй, я все три реакции понимаю, особенно последнюю, так как она вступает в противоречие с некоторыми исходными требованиями и некоторыми best practice, ровно как и со здравым смыслом (на первый взгляд)
вопрос — как сделать не прибегая к жестким мерам и регламентации процессов? из третьего, например, следует, что перед тем как брать какой-либо внешний компонент, надо заапрувить это решение (благо, делается без бумаг и довольно быстро — полуавтоматически, но некоторая бюрократия присутствует).
на аналогичном проекте сделали по принципу «ничего не должно мешать разработке». теперь ни выйти в production не получается, ни с соседями интегрироваться.
Ты же программист!
Бюрократия — это программа. А люди — процессоры, которые ее исполняет!
Зачем ты пишешь программы? Вот затем и все это.
Ты даешь процессору решать за тебя что должна делать твоя программа?
Хотя ты можешь никогда не понять всех тонкостей, которые в нем происходят, ты запросто им пользуешься и не чувствуешь угрызений совести :)
Бюрократия — это программа. А люди — процессоры, которые ее исполняет!
Зачем ты пишешь программы? Вот затем и все это.
Ты даешь процессору решать за тебя что должна делать твоя программа?
Хотя ты можешь никогда не понять всех тонкостей, которые в нем происходят, ты запросто им пользуешься и не чувствуешь угрызений совести :)
Проблема в том, что процессоры сами и разрабатывают программу для себя.
Можно придумать хохму.
Вот представь, что в твоём ноуте проц разработал бы операционку. Сам! Исходя из своих, а не твоих, разумений. Как ты думаешь, сможешь ли ты выполнять СВОЮ работу на такой операционке?
Можно придумать хохму.
Вот представь, что в твоём ноуте проц разработал бы операционку. Сам! Исходя из своих, а не твоих, разумений. Как ты думаешь, сможешь ли ты выполнять СВОЮ работу на такой операционке?
Это тебе так кажется. ;)
Тебе приходится исполнять инструкцию, которую разработал не ты, а кто-то дургой.
Ты думаешь что это другой процессор ее разработал по той причине, что от него ты ее скачал. А вполне возможно ее создал пользователь, который незримо пользуется компом, в котором стоит этот проц :)))
Ну или программа создающая программу — не такой и сложный прикол. :)
Вообщем не важно — для тебя как программиста инструкция — это всего лишь программа.
Тебе приходится исполнять инструкцию, которую разработал не ты, а кто-то дургой.
Ты думаешь что это другой процессор ее разработал по той причине, что от него ты ее скачал. А вполне возможно ее создал пользователь, который незримо пользуется компом, в котором стоит этот проц :)))
Ну или программа создающая программу — не такой и сложный прикол. :)
Вообщем не важно — для тебя как программиста инструкция — это всего лишь программа.
А Вы воспринимайте это как вызов :) Найдите способ обойти: автоматизируйте, сделайте так, чтобы не делать это, придумайте ещё что-нить!
Если Вы, поленившись обойти эти плёвые препятствия (по сути), не создадите что-то великое, то виновны — Вы и никто другой. Бюрократ не виновен, также как плесень — он всего лишь следствие иного процесса, такого же как влажность.
Бюрократов надо уничтожать, но не плакать из-за них. Можно только спрашивать совета, как уничтожать и делиться своими рецептами.
Если Вы, поленившись обойти эти плёвые препятствия (по сути), не создадите что-то великое, то виновны — Вы и никто другой. Бюрократ не виновен, также как плесень — он всего лишь следствие иного процесса, такого же как влажность.
Бюрократов надо уничтожать, но не плакать из-за них. Можно только спрашивать совета, как уничтожать и делиться своими рецептами.
Похожая ситуация была в одной компании — все с правами админа, все творили что хотели. Но при возникновении какого-то сбоя или проблемы приходилось тратить кучу времени чтобы понять в чем дело и кто подложил свинью.
Потом появились регламенты по созданию и настройке площадок — всё привелось к единому виду и на любом этапе любой сотрудник может быстро въехать в состояние проекта. Права администрирования разделили. Появилась ответственность за свои действия.
Только плюсы.
Потом появились регламенты по созданию и настройке площадок — всё привелось к единому виду и на любом этапе любой сотрудник может быстро въехать в состояние проекта. Права администрирования разделили. Появилась ответственность за свои действия.
Только плюсы.
все с правами админа это не от отсутствия регламента, это от отсутвия головы на плечах.
Это от того, что каждый специалист считал себя самым специалистом и был уверен в себе (и своей якобы незаменимости в компании). На деле же это бардак.
это еще и признак неумение управлять командой. этот бардак решается и без всяких правил.
У вас в коллективе сколько человек работает? Сколько проектов одновременно в работе?
это сложный вопрос, в компании около 200 человек, но далеко не все занимаются IT, а если брать отделы связанные с IT, то нужно еще учитывать что у нас много аутсорсеров, что многие из тех кто ведут проекты, разработчиками не являются… количество проектов в работе тоже сложно назвать, так как у каждого проекта свои особенности, какие-то больше маркетинговые, какие-то чисто технические…
Без разумной бюрократии организация менее жизнеспособна. Я не могу провести ни одно свое решение, не защитив его перед юристами, службой безопасности, технарями и финансистами. Выработанное вместе решение намного лучше того, что было первоначально. Я не против такой бюрократии.
если челоек не может самостоятельно принять решение, не доверяет самому себе, то наверное он плохой специалист.
Аналогично, если человек слишком самоуверен и думает, что его слова — истина в послдней инстанции — плохой специалист
да, это тоже плохо. потому я, если сомневаюсь, пойду и посоветуюсь с тем кто может мне подсказать, тогда когда вопрос того требует. но я сам приму решение посоветоватся, а если не приму, то беру на себя всю полноту ответвенности, и в итоге, если ошибся, то сам от этого и пострадаю. То есть советоватся в принципе в моих интересах. И для того что бы это понимать, мне не нужны никакие бумаги. У нас же нет закона «каждый гражданин России обязан пить, есть и спать» ну для того что бы кто-то не забыл и не умер. Мы не забываем, так как нам это выгодно.
Разумный объем бумаг необходим из-за кругооборота людей в природе :) Я не пойду в организацию, где «гении» после себя не оставили документации или пойду директором, чтобы навести порядок.
о документации это отдельная тема. тут о другом.
Кстати есть способы как минимизировать объемы документации, при этом повысив эффективность. Но да, гораздо проще принять регламент по которому каждая строчка кода должна быть прокомментирована, чем создавать систему, при которой документация будет не нужна.
Кстати есть способы как минимизировать объемы документации, при этом повысив эффективность. Но да, гораздо проще принять регламент по которому каждая строчка кода должна быть прокомментирована, чем создавать систему, при которой документация будет не нужна.
так создайте, пожалуйста, такую систему (идеальную для работы в неидеальном мире)!
система никогда не будет идеальной, на это нечего и рассчитывать. Но из всего множества неидеальных систем, есть наиболее эффективная. И к ней нужно стремится тогда когда во главу угла ставится эффективность.
Другое дело, что уровень знаний и масштаб мышления у всех разные, и многие пытаются идти по наиболее простому и очевидному пути, при этом даже не думая что он не самый эффективный.
Другое дело, что уровень знаний и масштаб мышления у всех разные, и многие пытаются идти по наиболее простому и очевидному пути, при этом даже не думая что он не самый эффективный.
типа, «лучше полдня потерять, потом за пять минут долететь»?
нет, лучше просто работать, а возникающие проблемы решать так, что бы убрать саму причину а не просто её запретить. То есть проблема не должна возникать не потому что её запретили правилами и регламентами, а потому что никому не нужно будет выполнять порядок действий приводящих к проблеме. Неудобно или не выгодно.
В этом и есть суть умного, грамотного руководства, когда процесс налажен так что работает сам по себе, опираясь на внутренние силы команды, на её понятия о целесообразности, а не на запреты. Запретить проще всего, только система запретов в итоге бьет по мотивации команды (нам не доверяют), и подсознательно рождает желание эти запреты обойти.
Другими словами, нужно всегда учитывать Человеческий фактор, и не только учитывать но и использовать в своих целях. Грамотный руководитель должен быть еще и психологом.
В этом и есть суть умного, грамотного руководства, когда процесс налажен так что работает сам по себе, опираясь на внутренние силы команды, на её понятия о целесообразности, а не на запреты. Запретить проще всего, только система запретов в итоге бьет по мотивации команды (нам не доверяют), и подсознательно рождает желание эти запреты обойти.
Другими словами, нужно всегда учитывать Человеческий фактор, и не только учитывать но и использовать в своих целях. Грамотный руководитель должен быть еще и психологом.
читал как-то заметки одного менеджера от производства, побывавшего на заводе Тайоты. Так вот больше всего его поразило то, как организован там конвейер: там где нужно закрепить болт, который нужно завернуть ключом, а можно забить молотком, у работника не окажется под рукой молотка, а будет именно ключ, которым он всё сделает правильно и в соответствии тех процессу.
Это прекрасный пример правильной организации труда, понимания того, что человеки все разные, и бюрократии направленной на эффективность.
Это прекрасный пример правильной организации труда, понимания того, что человеки все разные, и бюрократии направленной на эффективность.
«Не могу», означает «не имею права». И это правильно — компания не может брать на себя риск «ошибка IT-гения» :)
в таком случае в компании будут работать одни IT-идиоты
Увы, Вы опять, к сожалению, не правы. IT-идиот не сможет продвинуть и защитить ни одно свое решение — ему не позволят, в следствие чего у нас концентрация идиотов равна нулю.
а IT идиоту и не нужно будет продвигать свои решения, можно просто поддакивать. Да и решения могут быть такими, которые продвинутся в любом случае. Такой стиль работы я знаю, видимость работы сохраняется, но думать не нужно.
Согласен. Так бывает. Я в основном имею в виду проектную работу. И в связи с тем, что никто мне не поддакивает, приходится изучать их сторону работы, что в итоге идет мне на пользу.
вот именно. зачем регламенты если вы сами понимаете что изучить опыт другого вам же на пользу?
Я работал в разных компаниях. И как же я был рад, когда в новой компании не надо было отвлекать коллег распросами. Огромное количество информации было в политиках, регламентах, должностных инструкциях. И не важно, что до меня систему поддерживало и развивало 5 человек в течение 10 лет. Все 5600 изменений системы были задокументированы!!! Через месяц я уже мог продуктивно работать.
это плохо. общение должно поощряться.
Главные проблемы бюрократии — это 1) снижение личной ответственности и 2) замедление всех производственных процессов.
Во-первых, чем больше на бумажке должно быть подписей, тем легче жить подписавшему её. Типа ответственность лежит на всех. Ага, а в результате крупных косяков (о! я был свидетелем epic fail в нашей конторе) простых разработчиков депремируют, а крупняк плавает, как и раньше, спокойно.
Во-вторых, из-за постоянных задержек на согласование на работу времени-то и не остаётся. Как результат — не успевают всё продумать и предусмотреть, и тогда наступает epic fail.
Пример из нашей конторы. Из-за срыва планов (догадайтесь, почему они произошли) документация на одно наше изделие должна быть скорректирована за 25 дней. Надо сказать, что устройство это было серьёзное, с кучей сложных модулей на 12-слойных печатных платах, поэтому любой допущенный в схеме косяк — и можно готовый девайс швырять на помойку, ибо уже не доработаешь. Так вот, склепали всю документацию, утвердили и пошло-поехало производство. Спустя полгода (!) при подготовке к испытаниям нашего чудо-изделия выясняется, что в одном документе косяк! Стоимость косяка — невыполнение ТЗ стратегического значения.
ппц! И всё из-за того, что никто (!) ввиду спешки не проверял документацию. Короче, epic fail. Я чувствую, что могут полететь начальники.
Но самое печальное, что выводов никто не сделает, и в будущем всё останется неизменным.
Во-первых, чем больше на бумажке должно быть подписей, тем легче жить подписавшему её. Типа ответственность лежит на всех. Ага, а в результате крупных косяков (о! я был свидетелем epic fail в нашей конторе) простых разработчиков депремируют, а крупняк плавает, как и раньше, спокойно.
Во-вторых, из-за постоянных задержек на согласование на работу времени-то и не остаётся. Как результат — не успевают всё продумать и предусмотреть, и тогда наступает epic fail.
Пример из нашей конторы. Из-за срыва планов (догадайтесь, почему они произошли) документация на одно наше изделие должна быть скорректирована за 25 дней. Надо сказать, что устройство это было серьёзное, с кучей сложных модулей на 12-слойных печатных платах, поэтому любой допущенный в схеме косяк — и можно готовый девайс швырять на помойку, ибо уже не доработаешь. Так вот, склепали всю документацию, утвердили и пошло-поехало производство. Спустя полгода (!) при подготовке к испытаниям нашего чудо-изделия выясняется, что в одном документе косяк! Стоимость косяка — невыполнение ТЗ стратегического значения.
ппц! И всё из-за того, что никто (!) ввиду спешки не проверял документацию. Короче, epic fail. Я чувствую, что могут полететь начальники.
Но самое печальное, что выводов никто не сделает, и в будущем всё останется неизменным.
Не согласен с самой постановкой вопроса автором статьи.
Объём и сложность выполнения регламентов в каждой конкретной организации должен соответствовать размеру организации, цене ошибки и объёму конкретной задачи.
Маленькие коллективы энтузиастов могут и должны жить динамичной жизнью. Сложные регламенты в таком случае демотивируют и ведут к неэффективной работе сотрудников.
В то же время если организация уже подросла, а адекватных регламентов так и не внедрила — проблемы начинают сыпаться как из рога изобилия. Эффективность также снижается.
Как и везде крайности плохи, нужно искать золотую середину.
Проблема ещё в том, что рядовые сотрудники, как правило, не видят всех минусов отсутствия регламентов во всех областях, кроме тех, где они являются непосредственными исполнителями — получать задачи всем удобно в структурированном виде.
Другая проблема в том, что зачастую руководители перегибают палку, что ведет к неоправданным количеству и сложности регламентов.
В завершение (дословно не помню):
Объём и сложность выполнения регламентов в каждой конкретной организации должен соответствовать размеру организации, цене ошибки и объёму конкретной задачи.
Маленькие коллективы энтузиастов могут и должны жить динамичной жизнью. Сложные регламенты в таком случае демотивируют и ведут к неэффективной работе сотрудников.
В то же время если организация уже подросла, а адекватных регламентов так и не внедрила — проблемы начинают сыпаться как из рога изобилия. Эффективность также снижается.
Как и везде крайности плохи, нужно искать золотую середину.
Проблема ещё в том, что рядовые сотрудники, как правило, не видят всех минусов отсутствия регламентов во всех областях, кроме тех, где они являются непосредственными исполнителями — получать задачи всем удобно в структурированном виде.
Другая проблема в том, что зачастую руководители перегибают палку, что ведет к неоправданным количеству и сложности регламентов.
В завершение (дословно не помню):
Если ты ре революционер в 20 — у тебя нет сердца
Если ты не консерватор в 40 — у тебя нет ума
Я, кстати, до сих пор не понял, что является главным мотивом, побуждаюшим к созданию новых и новых правил?
по-моему, главным мотивом подобных действий является исключительно желание сделать так, чтобы какую-то деятельность могли выполнять люди со все более меньшей квалификацией. больше ничего здесь нет. все эти «корпоративные стандарты», правила оформления документов, сам набор документов — все это преследует одну цель, о которой я сказал выше. причем, смотрите, эти «мотивы» движут «специалистами» в очень многих областях, например, в области HR. возникает вопрос, зачем. а затем, что людей для выполнения такой работы можно также подготавливать «по стандартам», что оправдано экономически.
и, кстати говоря, Вы говорите в своей статье о бизнесе, который должен быть эффективным… все так, однако, эти принципы были со временем переложены на другие области, в результате чего мы и имеем те эффекты, которые Вы описываете :)
Да, наболело… понимаю. :) Вы не первый, кто с этими проблемами столкнулся и кому не все равно.
Я думаю, если посмотреть в корень проблемы, то можно найти 2 базовые причины: невежество (нежелание включить здравый смысл) и отсутствие ориентации на результат (или отличие заявляемых целей и реальных). Отсюда политические игры, направленные на: 1. имитацию бурной деятельности, чтобы скрыть свою некомпетентность и прикрыть свой зад в случае чего («как не работает? все же по учебникам и умным книгам сделано!»), и 2. добиться своих личных целей пусть даже в ущерб эффективности и результату. Т.е. в корне неверный системообразующий фактор действующей системы управления и бизнеса в целом. А люди, которые приходят на работу, чтобы работать, и для которых важно удовлетворение от получаемого результата, страдают…
Еще одна причина, как уже было подмечено выше: стремление превратить труд программистов из интеллектуального в контролируемый производственный процесс, чтобы можно было за компьютеры посадить дешевых обезьянок-кодеров и получать профит, ничего не делая. Про тотальный контроль в проектах и про политику в проектах тоже уже писал.
Я думаю, если посмотреть в корень проблемы, то можно найти 2 базовые причины: невежество (нежелание включить здравый смысл) и отсутствие ориентации на результат (или отличие заявляемых целей и реальных). Отсюда политические игры, направленные на: 1. имитацию бурной деятельности, чтобы скрыть свою некомпетентность и прикрыть свой зад в случае чего («как не работает? все же по учебникам и умным книгам сделано!»), и 2. добиться своих личных целей пусть даже в ущерб эффективности и результату. Т.е. в корне неверный системообразующий фактор действующей системы управления и бизнеса в целом. А люди, которые приходят на работу, чтобы работать, и для которых важно удовлетворение от получаемого результата, страдают…
Еще одна причина, как уже было подмечено выше: стремление превратить труд программистов из интеллектуального в контролируемый производственный процесс, чтобы можно было за компьютеры посадить дешевых обезьянок-кодеров и получать профит, ничего не делая. Про тотальный контроль в проектах и про политику в проектах тоже уже писал.
«Не гони волну.» ©
Как из глючной и медленной проги сделать хорошую:
1) нужен программист с доступом к исправлению кода
2) нужен механизм профайлинга
3) нужно собирать логи ошибочных ситуаций
Т.е
1) Нужно чтобы кто-то мог править все эти инструкции и бизнесс процедуры скопом. И чтобы это была его работа.
2) нужно отслеживать какие задачи сколько выполнялись и почему — находить узкие места и устранять
3) нужна форам обратной связи, чтобы это не на Хабр писали, а человеку в п1
Но такого по какой-то причине не делают… обычно…
1) нужен программист с доступом к исправлению кода
2) нужен механизм профайлинга
3) нужно собирать логи ошибочных ситуаций
Т.е
1) Нужно чтобы кто-то мог править все эти инструкции и бизнесс процедуры скопом. И чтобы это была его работа.
2) нужно отслеживать какие задачи сколько выполнялись и почему — находить узкие места и устранять
3) нужна форам обратной связи, чтобы это не на Хабр писали, а человеку в п1
Но такого по какой-то причине не делают… обычно…
Sign up to leave a comment.
IT-бюрократия