Comments 45
А как объяснить, что Google Translate выдаёт какие-то другие варианты произношения, совсем не похожие на предложенное?
translate.google.com/?hl=ru#ru/ja/%D0%BF%D0%BE%D1%82%D0%B5%D1%80%D0%B8
(Собственно, вопрос, где ударение, если это, конечно, правда?)
translate.google.com/?hl=ru#ru/ja/%D0%BF%D0%BE%D1%82%D0%B5%D1%80%D0%B8
(Собственно, вопрос, где ударение, если это, конечно, правда?)
Полагаю имелось в виду 無駄 「むだ, мудá」, переводится как «отходы» или «быть напрасным».
Автор привел каноническое написание на русском языке базового термина Кайдзен — не очень понял, где в статье про ударение. Гляньте первоисточники — хорошие переводы работ Масааки Имаи.
Кстати, почему в «что почитать» их нет — они вполне достойны там присутствовать.
Кстати, почему в «что почитать» их нет — они вполне достойны там присутствовать.
無駄 (му́да) с японского переводиться как «напрасный, бесполезный, ненужный, бесплодный». Очень распространённое в разговорном языке слово на все случаи жизни. Для «потерь» более-менее подходит слово 被害 (хига́й).
Собственно ответ: Ударения в японских словах обычно советуют ставить на предпоследний слог (на последний в словах заканчивающихся на н), в самом языке силовое ударение отсутствует.
Собственно ответ: Ударения в японских словах обычно советуют ставить на предпоследний слог (на последний в словах заканчивающихся на н), в самом языке силовое ударение отсутствует.
По моему оно и без перевода отлично характеризует происходящее.
Здесь с вами трудно не согласиться. И такое происходит очень часто. Автор предложил вполне рациональные способы «избавления от скверны». Что-то подобное видел в западном блоге, но здесь все очень хорошо адаптировано под наши суровые будни.
Именно, что отлично, даже превосходно! Будем надеяться, что материал хоть в какой-то мере поможет исправить ситуацию. Автору — отдельная благодарность за картинки (особенно заводчанин в каске и пасаж про мрозданье). Прям настроение поднимают! А так вы расписали все правильно и не заунывно. По поводу рутины — вспомнилась вот эта статья на Хабре (ой, теперь — на МегаМозге). И вот тут полезный материал в тему.
UFO just landed and posted this here
Если нужно обратить внимание на многое — глубоко в это не погрузишься, если нужно погрузиться глубоко — много не охватишь.
Это вещи друг другу противоречащие по определению — концентрироваться на одном, или распыляться на многое.
Ну либо придется принять, что возможности человека безграничны (то, что мы можем ими пользоваться, скажем, только на треть этого еще не означает).
Это вещи друг другу противоречащие по определению — концентрироваться на одном, или распыляться на многое.
Ну либо придется принять, что возможности человека безграничны (то, что мы можем ими пользоваться, скажем, только на треть этого еще не означает).
отличная статья для нового проекта ТМ megamozg.ru/, не хотите туда перенести?
Спасибо за статью. Как ни крути Тойота на пути применения Кайдзен продвинулась дальше всех и у нее стоит многому поучится.
Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.
Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.
Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе.
Никогда не поздно признать свои ошибки и исправить их вместо того, чтобы отнекиваться тем, что все давно переговорено. Реально, такие мелочи способны медленно, но верно точить мотивацию членов команды. А мотивация — это наше все.
Кстати, в этом случае это подточит лучших людей, т.к. только
Суть не в том, чтобы остаться на svn, а в том, что все доводы и контрдоводы должны быть записаны, чтобы не мусолить всё заново.
Если аргумент устарел, это повод пересмотреть решение.
Если аргумент устарел, это повод пересмотреть решение.
Кстати у меня знакомый, который работает в команде google chrome как-то рассказывал что мол весь сырец Хрома хранится в svn. Но никто в здравом уме конечно svm локально не использует, все отправляют на сервер через git-svn bridge. Как-то вот так сложилось видимо, а теперь менять все это долго и дорого.
Ну что ж, я долгое время работал в группе, которая хранила исходники в MS Source Safe. Это действительно отстойное хранилище по сравнению с тем что есть сейчас, технология отжила свое еще в прошлом веке. Тем не менее группа не испытывала никаких проблем с хранением исходников, все давно привыкли и умели. Никто не отвлекался на проблемы хранения годами.
Однако все остальные группы, как более молодые, к тому времени переехали на svn. И под давлением руководства последний SourceSafe решено было перевезти. Ну что ж, перевели, один день всем все настраивали и бережно переносили 10-летнюю историю. Еще неделю объясняли программистам что SVN это правда лучше (и это правда) и что скоро они почувствуют весь кайф. Еще где-то пару месяцев программисты регулярно поднимали вопросы как сделать что-то, что они могли на SorceSafe.
Да, через какое-то время все привыкли к SVN и перестали его замечать.
Но что группа или компания выиграла? Только теоретические вещи — теоретически лучше, теоретически надежнее, теоретически круче. Практически же было потеряно огромное количество человеко-часов на переезд. Зачем?
Я не призываю сидить на допотопных инструментах. Но каждое решение о смене базовых технологий процесса должно четко отвечать на вопрос «зачем». Ответ должен быть измерен, желательно, в деньгах.
Однако все остальные группы, как более молодые, к тому времени переехали на svn. И под давлением руководства последний SourceSafe решено было перевезти. Ну что ж, перевели, один день всем все настраивали и бережно переносили 10-летнюю историю. Еще неделю объясняли программистам что SVN это правда лучше (и это правда) и что скоро они почувствуют весь кайф. Еще где-то пару месяцев программисты регулярно поднимали вопросы как сделать что-то, что они могли на SorceSafe.
Да, через какое-то время все привыкли к SVN и перестали его замечать.
Но что группа или компания выиграла? Только теоретические вещи — теоретически лучше, теоретически надежнее, теоретически круче. Практически же было потеряно огромное количество человеко-часов на переезд. Зачем?
Я не призываю сидить на допотопных инструментах. Но каждое решение о смене базовых технологий процесса должно четко отвечать на вопрос «зачем». Ответ должен быть измерен, желательно, в деньгах.
UFO just landed and posted this here
Брайан Трейси в своё время писал, что каждый человек в цепочке увеличивает время её прохождения информацией в 2 раза. Актуально для 4 и 6 пунктов, имхо
Всё очень правильно. (Кроме фразы про Excel.)
Кстати да, эта строчка смутила. Это как швейцарский нож привести в пример «переизбытка бесполезных фич». Excel выделился если бы хоть кто-то из основных аналогов был менее напичкан. Google Docs, Polaris Office, iWork, Feng Office, OpenOffice, LibreOffice, Kngston Office… короче вы поняли.
Согласен, функционал хороший и профессионалы наверно в восторге, но если 90% людей пользуются минимумо функций — жди что какой-то онлайновый сервис вроде Google Docs отберет у тебя 90% рынка.
Лично я пользуюсь уже им очень давно.Потом родителей подсадил и весь офис. То есть в моем окружении не осталось людей с экселем. А все потому, что не уследили за тем что нужно 90% людей.
Личный пример конечно не показатель, но звоночек майкрософту.
Лично я пользуюсь уже им очень давно.Потом родителей подсадил и весь офис. То есть в моем окружении не осталось людей с экселем. А все потому, что не уследили за тем что нужно 90% людей.
Личный пример конечно не показатель, но звоночек майкрософту.
Просто вы путаете рынки. Excel — это офисное приложение, оно доминирует на рынке офисных приложений.
Тот факт, что массовому потребителю теперь тоже надо немного иногда посчитать-учесть, привёл к тому, что образовался другой рынок, который полностью заполнился простыми решениями, и в частности облачными.
Я и сам в обычной жизни пользуюсь google docs, но уверяю вас, когда надо сделать действительно сложный документ — большой отчёт, много сложной статистики и проч., то лучше чем продукт от MS вам не найти.
Тот факт, что массовому потребителю теперь тоже надо немного иногда посчитать-учесть, привёл к тому, что образовался другой рынок, который полностью заполнился простыми решениями, и в частности облачными.
Я и сам в обычной жизни пользуюсь google docs, но уверяю вас, когда надо сделать действительно сложный документ — большой отчёт, много сложной статистики и проч., то лучше чем продукт от MS вам не найти.
Только с MS Word плохой пример. Большой функционал это часть стратегии.
Посмотрите график: lib.rus.ec/i/27/351127/img_1.jpeg
Первые в жизненном цикле идут новаторы и ранние последователи. А их 10 функциями не возьмёшь.
Я про Photoshop могу тоже самое. Там такой же процент использования.
Посмотрите график: lib.rus.ec/i/27/351127/img_1.jpeg
Первые в жизненном цикле идут новаторы и ранние последователи. А их 10 функциями не возьмёшь.
Я про Photoshop могу тоже самое. Там такой же процент использования.
Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе. И как стандарт у себя решили принять svn.Не бывает. Если бы полностью разобрались — решили бы принять Git.
Тогда уж Mercurial, для полностью «разобравшихся».
Поскольку Mercurial — это Git минус проблемы с сабмодулями и минус возможность «сделать что-то не то и сломать репозиторий».
Поскольку Mercurial — это Git минус проблемы с сабмодулями и минус возможность «сделать что-то не то и сломать репозиторий».
Уже не помню, когда в последний раз у меня Git ломал репозиторий.
Больше того, Git периодически выручал, казалось бы в безвыходной ситуации.
Проблем с сабмодулями не наблюдаю тоже никаких. Возможно использую их не на «всю катушку»?
Даже не представляю, что можно сделать, чтобы получилось лучше, удобнее и быстрее, чем Git.
Про Mercurial слышу много хорошего, но вот чем конкретно он лучше того же мейнстримного Git, пока никто так и не объяснил.
Больше того, Git периодически выручал, казалось бы в безвыходной ситуации.
Проблем с сабмодулями не наблюдаю тоже никаких. Возможно использую их не на «всю катушку»?
Даже не представляю, что можно сделать, чтобы получилось лучше, удобнее и быстрее, чем Git.
Про Mercurial слышу много хорошего, но вот чем конкретно он лучше того же мейнстримного Git, пока никто так и не объяснил.
Многие пункты завязаны на инструкции сотрудникам, грамотно выстроенный бизнес-процесс и хороших управленцев.
Если в студии высокая текучка кадров, например, то передачи проектов неизбежны. А с ними — потеря продуктивности.
По сути большинство «муд» о том, что нужно ценить людей, давать им интересные задачи и создавать комфортную рабочую среду (и речь не о настольном футболе и гамаках, а об отсутствии бесполезных брейнштормингов).
Если в студии высокая текучка кадров, например, то передачи проектов неизбежны. А с ними — потеря продуктивности.
По сути большинство «муд» о том, что нужно ценить людей, давать им интересные задачи и создавать комфортную рабочую среду (и речь не о настольном футболе и гамаках, а об отсутствии бесполезных брейнштормингов).
Сколько промежуточных звеньев между тем, как идея клиента попадёт из его головы к тому человеку, который будет конкретно ее делать?Частенько встречается ситуация, когда в небольшой компании поначалу клиент общается почти напрямую с программерами, естественно нервирует их, но задачи решаются достаточно быстро и точно.
Контора подрастает, решает что нужно выделить роль РП — переговорщика с клиентом. Отлично, ввели передаточное звено. РП сразу же заваливается кучей работы, совещаний, ведь теперь чтобы передать информацию от заказчика исполнителю нужно вдвое больше времени: поговорить сначала с заказчиком, потом столько же времени с исполнителем. И это не считая затрат на потерю информации и переключения.
Дальше, руководство видит что РП зашивается, не справляется общаться со всеми заказчиками и всеми исполнителями, и вводит ему подмогу со стороны программистов — техлида, например. Или руководителя группы/отдела. Но как бы не так, этот парень встает ровно в ту же лужу. Дальше вводят аккаунт-менеджера, аналитиков, пресейлов, цепочка удлиняется, пока на выходе не даст белый шум.
И самое печальное, при поверхностном взгляде руководства кажется что эти ребята просто жизненно необходимы для процесса — т.к. они сильнее всех завалены работой. Но по сути эта работа — передача данных с потерями. И эту бесполезную работу делают довольно дорогие сотрудники.
За все надо платить, главное, чтобы затраты окупались. Когда заказчик контактирует напрямую с программистами, то мы получаем отвлечение программистов от их основных обязанностей. Введение РП позволяет команде итерацию писать код, тестировать его, документировать и т.д. А новые требования обсуждать с привлечением заказчика (или без) только раз в две недели. Что результативность команды, обычно, повышает. С другой стороны, как вы правильно заметили, снижение скорости прохождения информации и потери. Поэтому нельзя бросаться из крайности в крайность. Заказчик -> программисты — крайность, заказчик -> 100500 промежуточных звеньев -> программисты — тоже крайность.
Это затраты на функционирование самой системы с ее ростом. И это неизбежно (есть очень интересная тема — жизненный цикл организации).
Однако никто не мешает оптимизировать процесс. Если бюрократия минимальна, а РП фильтрует пожелания клиентов и подает входные данные в обработанном и подготовленном для разработчиков формате, то от этого одни только плюсы.
То, что где-то не так говорит только о том, что система организована неправильно.
Однако никто не мешает оптимизировать процесс. Если бюрократия минимальна, а РП фильтрует пожелания клиентов и подает входные данные в обработанном и подготовленном для разработчиков формате, то от этого одни только плюсы.
То, что где-то не так говорит только о том, что система организована неправильно.
у Хаббарда эта штука называется Девти. От слов development traffic. Суть в том что ростет трафик, а результат нет.
Но идеи абсолютно идентичны. Называются иначе. Но он также исследовал этот предмет и искал пути его снижения на разных предприятиях и отраслях. Есть работы на эту тему.
Мы также в свое веб студии применяли эти решения и снижаем девти (муды).
Муды — как слово мне нравится больше. Перехожу на него :)
Но идеи абсолютно идентичны. Называются иначе. Но он также исследовал этот предмет и искал пути его снижения на разных предприятиях и отраслях. Есть работы на эту тему.
Мы также в свое веб студии применяли эти решения и снижаем девти (муды).
Муды — как слово мне нравится больше. Перехожу на него :)
Sign up to leave a comment.
8 сортов муды в твоей веб-студии