Comments 21
А это перевод какой-то статьи? Или это ваш текст и русский для Вас не родной язык?
Это топик-перевод, обозначено же.
Узкие места — это, конечно, очень важно. Но я потерял мысль где-то в той части, где начинается рассказ о «метауправлении» и «чтобы работать лучше Бобу нужно тратить больше времени на управление собой». Почему? Я, например, очень быстро понимаю, когда становлюсь «узким местом» — это когда я более двух дней подряд задерживаюсь на работе на несколько часов по окончанию рабочего дня. При этом я не начинаю «тратить время на управление собой», а сажусь и пишу развернутое письмо руководителю с объяснением ситуации, причин и предложениями по выходу (перепланировать сроки, перераспределить задачи, нанять еще людей). С этого момента руководитель видит узкое место и варианты его устранения. И пусть он занимается решением — у него работа такая. А я себе продолжу просто работать, в штатном режиме, не мучаясь переработками или угрызениями совести.
Как вообще может случиться, что ни сотрудник, ни его руководитель не заметят вовремя узкое место и не постараются его устранить?
Как вообще может случиться, что ни сотрудник, ни его руководитель не заметят вовремя узкое место и не постараются его устранить?
Ваш пример показывает, что вы ответственный работник. Вероятно, либо у вас есть такое человеческое качество изначально, либо внутри компании хорошо организован процесс и есть понимание того, что нужно делать в той или иной ситуации.
На практике же работник не всегда может правильно и вовремя определить, в чем проблема (в нем или его работе), поэтому слишком поздно становится понятно, где находится узкое место.
На практике же работник не всегда может правильно и вовремя определить, в чем проблема (в нем или его работе), поэтому слишком поздно становится понятно, где находится узкое место.
Не взирая на опечатки и грамматические (а так же стилистические и пунктуационные) ошибки, статья замечательная.
Самое плохое начинается когда менеджмент не контролирует процесс разработки, а давить начинает при приблежении дедлайна (причём, дедлайн раньше на пару месяцев почему-то).
Самое плохое начинается когда менеджмент не контролирует процесс разработки, а давить начинает при приблежении дедлайна (причём, дедлайн раньше на пару месяцев почему-то).
Мне проблема «узкого горлышка» кажется некой самоочевидной истиной, не говоря о том, что развернуто излагается в теории систем массового обслуживания и всевозможных публикация по менеджменту.
И как раз таки стоит раскрывать тему взаимозаменяемости — это и документирование внутренних решений и поощрение вниканию в проблемы друг-друга, коллективные обсуждения проблем, микростажировки, допустим, разработчику крайне полезно будет познакомиться с работой суппорта не на формальном уровне, понимание проблем продукта улучшится за самое короткое время и т.д.
Люди не взаимозаменяемы, но, всегда наступает момент когда сотрудника придется заменить. Люди болеют, уходят в отпуск, идут на повышение, увольняются, у них плавает производительность, бутылочные горлышки возникают сезонно или в виде пиков (например, закрытие проектного этапа), когда людей нужно срочно перебрасывать с одного участка работы на другой и это нормально, так как в другое время они бы пинали балду.
Чем выше осведомленность участников проекта об участках вне их зоны ответственности, тем больше шансов, что подобные проблемы будут решаться в горизонтальном порядке. Нужно делать так, чтобы сотрудники легко могли выполнят работу друг-друга.
P.S. перевод катастрофически плохой, это означает, что я не могу понять смысл кусков текста в принципе:
>Защитная ретроспектива: выделение процента времени сотрудников которые есть узкими местами на регулярное, стабильное улучшение есть обязательным. Никто не может иметь права решить что он «слишком занят» для пересмотра процессов, чтобы уйти в штопор. Необходимо доверять собственному менеджеру в том, когда внимание и улучшение действительно необходимы
И как раз таки стоит раскрывать тему взаимозаменяемости — это и документирование внутренних решений и поощрение вниканию в проблемы друг-друга, коллективные обсуждения проблем, микростажировки, допустим, разработчику крайне полезно будет познакомиться с работой суппорта не на формальном уровне, понимание проблем продукта улучшится за самое короткое время и т.д.
Люди не взаимозаменяемы, но, всегда наступает момент когда сотрудника придется заменить. Люди болеют, уходят в отпуск, идут на повышение, увольняются, у них плавает производительность, бутылочные горлышки возникают сезонно или в виде пиков (например, закрытие проектного этапа), когда людей нужно срочно перебрасывать с одного участка работы на другой и это нормально, так как в другое время они бы пинали балду.
Чем выше осведомленность участников проекта об участках вне их зоны ответственности, тем больше шансов, что подобные проблемы будут решаться в горизонтальном порядке. Нужно делать так, чтобы сотрудники легко могли выполнят работу друг-друга.
P.S. перевод катастрофически плохой, это означает, что я не могу понять смысл кусков текста в принципе:
>Защитная ретроспектива: выделение процента времени сотрудников которые есть узкими местами на регулярное, стабильное улучшение есть обязательным. Никто не может иметь права решить что он «слишком занят» для пересмотра процессов, чтобы уйти в штопор. Необходимо доверять собственному менеджеру в том, когда внимание и улучшение действительно необходимы
Есть другое правило — не решайте проблемы которые существуют только в вашем воображении.
Боб, Энди… Во-первых, перевод. Во-вторых, некачественный.
Гугл переводчик не идеален.
Хотел бы немного дополнить. На практике так же бывает что «сильное звено» — это узкое место. И чем сильнее звено, тем больше стоит посвящать ему времени. Помню случай из жизни. Когда уход директора привел к тому, что департамент расформировали. А все из-за того, что он был «очень сильным звеном». Все остальные подробности я оставлю при себе.
В прошлом провел на нескольких предприятиях поиск и устранение «узких мест» в работе сложно структурированного конвейерного производства, после чего прочитал «Цель», «Цель 2» Элияху Голдратта и «Deadline» Тома Де Марко для более глубокого понимания схемы оптимизации. Проектным менеджерам и управленцам – рекомендую к прочтению.
Статья замечательная и ссылки на книги именно «в тему», но статья не показывает на примере разработчиков процесс возникновения «узких мест», только подводит к размышлениям в этом направлении.
Давно уже планирую написать статью на эту тему с конкретными примерами и практиками, думаю, будет неплохо, как продолжение этой статьи.
Статья замечательная и ссылки на книги именно «в тему», но статья не показывает на примере разработчиков процесс возникновения «узких мест», только подводит к размышлениям в этом направлении.
Давно уже планирую написать статью на эту тему с конкретными примерами и практиками, думаю, будет неплохо, как продолжение этой статьи.
Исправьте, пожалуйста, «Эли Голбратта» на «Элияху Голдратта».
И хорошо было бы дать русские переводы указанных изданий. Например, The Goal [Элия М. Гольдратт, Цель. Процесс непрерывного совершенствования, М.: Поппури, 2009.]
И хорошо было бы дать русские переводы указанных изданий. Например, The Goal [Элия М. Гольдратт, Цель. Процесс непрерывного совершенствования, М.: Поппури, 2009.]
Sign up to leave a comment.
Не оставляйте проблемы на самоопределение