Я написал статью о том, что в компаниях знаниях не накапливаются, а теряются и был удивлен, количеством комментариев и споров, которые возникли вокруг этой статье. Как я и обещал, продолжаю эту больную тему.
В этой статье не буду писать никаких решений, а только буду бить по больным местам… э… пожалуй, только по больным местам этой темы.
Итак, начнем с человека который генерирует знания (кстати, я вообще говорю о любых знаниях – технических, менеджерских, бизнес процессах и т.п.). Вот те вещи, которые отбивают охоту записывать знания:
а) Тот человек, которые создает знания и так их знает, поэтому для него запись знаний чаще всего бесполезная трата времени.
б) Запись знаний, чаще всего низкий приоритет в системе ценностей человека. И поэтому, когда встает выбор – разгребать текущие проблемы или создавать «нетленку» 🙂, то чаще всего начинают разгребать именно текущее дела.
Дальше, перейдем к менеджеру того человека, который генерирует знания. Опять же у него возникает проблема очень похожая на б):
в) Нужно ли заставлять подчиненного писать свои знания или делать остальную часть работы. Опять же возникает конфликт приоритетов.
Потребитель знаний:
г) Почему собственно нужно читать чьи-то ошибки, сделанные непонятно когда и кем и пытаться понять какие-то решения, принятые людьми, которые уже не работают в фирме?
д) Как справляться с тем потоком информации, которые могут быть сгенерированными многими людьми. Как отбирать только нужное и важное и не тратить время на все остальное?
Ну, и с точки зрения компания, проблемы следующие
е) Что делать с людьми, которые не хотят сохранять знания, особенно если они ими обладают. Должно ли стать это требованиям к работе. Что делать с теми, кто не хочет изучать знания?
ж) Какова приоритетность записи и изучения знаний? Это нужно для того, чтобы менеджеры могли выставлять приоритеты рабочим
В) Выделение специальных людей для сбора, организации знаний и контроля за этими процессами. Кстати, это требует финансов.
Д) Самое главное, как сделать весь этот проект прибыльным?
Возможно, я пропустил, что-то важное. Но, даже эти вопросы очень часто выбивают землю из под ног тех, кто пытаются организовать систему сохранения знаний.
Теперь перейду ко второй части статьи. Как многие ответили, нужен отдел, который бы занимался именно этими вопросами – контроль за тем, что знания сохраняются, изучаются, используются, что приоритетность выставляется правильная, что все бизнес процессы идут именно в соответствии с какими-то записанными методиками.
Как я уже писал, это затея очень неплохо «ест» деньги. И любой человек который работал или владел маленькой компанией знает, как для них критичен каждый доллар. И чаще всего вкладывается только в проекты первой приоритетности, которые могут вернуть деньги.
Даже, если деньги выделены, обычно в этот отдел нанимают юношей бледных со взором горящим. Я имею в виду, молодежь без опыта, знаний и только с амбициями и желанием менять мир (они наиболее дешевы при найме).
И именно это убивает эту идею на корню. Проблема состоит в том, что скажем тренер по футболу может натренировать команду с игроками, которые играют лучше него. Но вот человек не игравший в футбол никогда не может натренировать команду.
И вот те самые юноши (или девушки), которые были наняты контролировать, оказываются во главе процессов которые они не понимают, не знают и не пробовали. И получается, то самое, что я писал в названии статьи – они начинают пользоваться буквой закона, вместо духа закона.
Например, в правилах сказано, каждый работник должен записывать знания. Они выбивают их какого-нибудь большого начальника цифру (сколько конкретно нужно записывать в день). Предположим они получили цифру – три абзаца в день и теперь они начинают носить с этим проверяя, что каждый пишет не меньше, чем эти три абзаца.
И естественно, это вызывает мгновенно отвращение на всех уровнях организации. Вчера менеджер, ратовал за сбор знаний, а сегодня его обязуют написать не меньше, чем три абзаца информативного текста (при том, что он сегодня не в духе, у него горит проект или еще что-то).
Таким образом этот отдел, которые изначально был призван поддержать идею, вместо поддержки начинает ее активно и бездумно насаждать, что вызывает полное отторжение.
Как я и говорил, я не хочу писать никаких решений проблем, а только их формулирую. И проблема того, что отдел контроля становится своеобразным КГБ внутри организации очень типичная и большая проблема.
Очень хочется услышать ваше мнение о том, если я забыл указать какие-то проблемы и то, как вы считаете нужно решать самые серьезные их этих проблем.
Замечательный «концентрат» мыслей. Ну но на один из вопрос ты сам и ответил, нужно брать не «юношей бледных с взором горящим», а «тренеров». А чтобы это было выгодно, нужно прежде чем организовывать такой отдел, сначала провезти анализ предыдущей работы конторы и посчитать А (потерянную ожидаемую прибыль от проваленных проектов, или не полученных заказов), Б(прибыль, которую можно было бы получить, если бы часть этих проектов не была провалена, а заказы получены при имеющемся отделе. Она не будет равна А, т.к. это будет процент от А.), В(сумму которую потеряла бы контора обеспечивая работу отдела). Далее сравнивая Б и В мы поймем стоит ли овчинка выделки.
А вот тут вдруг возникает еще одна проблема, не упомянутая в статье. У нас в конторах не хранят данные о проваленных проектах и не полученных заказах. У нас вообще не ведется журнал фирмы, в подавляющем большинстве случаев. По которому можно было бы делать спустя год-два работы хоть какой-то анализ. Так что первый шаг на пути к решению проблем, это начать вести регистрацию отчетов о проделанных работах. При чем в таком формате, который был бы удобен для анализа, т.е. чтобы потом не нужно было штудировать 1000 страниц вики или документов и экселей. Чтобы основные параметры, по которым будет впоследствии вестись оценка и анализ, были бы сформулированы заранее. Инструментарий существует, его можно купить. Можно и свой инструмент написать на первое время, который может будет не особо устойчив и качественный, но будет выполнять основную задачу — сбор информации, как это пытались сделать у нас в СДД. К сожалению эту идею сбора информации «зарубила» группа людей, пришедших в контору года два с половиной назад. Это были матерые авторитетные люди — «Тренера». Директор им доверял. Потом правда пожалел об этом. Когда контора спустя два года едва не приказала долго жить.
шо то у меня комент плавно перекатился в критику некоторых тренеров 🙂 Соре…
Рекурсия выходит 😉
Чтобы построить правильный отдел контроля за сбором данных, нужно проанализировать данные о прошлом (о эффективности работы фирмы). Чтобы проанализировать данные их нужно собрать. Чтобы контролировать сбор данных — нужно иметь отдел контроля.
С одной стороны, я согласен, что отдел по контролю процессов (включая сбор данных) нужно нанимать людей умелых.
Проблема заключается в том, что
а) Люди которые умеют работать — работают, те кто умеют управлять — управляют.
Я видел мало профессионалов, которые интересуюется именно функциями контроля.
б) Люди должны быть также профессиональны в той области которую они контролируют. Прекрасно конечно, когда в отделе работает менеджер с стажем, но если он до этого о IT слыхом не слыхивал, для него будет нереально отличить полезную техническую информацию от бесполезной.
Насчет «убивания» сбора данных. Это самый лучший метод для того, чтобы мутить воду. Без наличия информации, невозможно реально оценить кто на самом деле лажает, а кто работает.
отвечу кратко:
а) это их, управленцев, работа. ну да, не особо интересная. так «в поле» тоже полно не интересной работы. ее ведь люди делают. чем менеджеры другие?
б) не факт. если человек действительно хороший менеджер, то у него есть как минимум два Senior Developer’s (причем есть всегда, конечно сеньйор-сеньйору рознь, но тем не менее), которые могут дать экспертное заключение.
и про «убивание сбора данных», предыдущая команда управленцев CDD — это мифические существа, о которых существует только два мнения «гении инженерии и руководства, увольнение которых едва не привело компанию к краху» и «злобные интриганы и макиавелианцы, которые едва не перевели компанию под свой личный контороль». не хочу никого судить, тем более, что я пришел в СDD уже при новом руководстве. однако, возвращаясь к теме сбора данных, я думаю тут не все однозначно — с одной стороны есть естественное желание владельцев минимизировать расходы, с другой — есть не желание технического менеджмента что-то доказывать, раз. не знание, граничащее с не компетентностью, стратегической необходимости подобного сбора, два. и естественное желание технического менджмента хорошо выглядеть в глазах подчиненных, три. в такой ситуации вольно или не вольно и возникает та самая «мутная вода». не обязательно мутить ее сознательно, из лучших побуждений скройте информацию до трех раз, и «вода» сама замутиться. 🙂
Ну насчет CDD пропускаю. Это отдельная тема (не имеющая отношения) к посту.
Насчет управленцев. Ладно еще с неинтересной работой, это штука субъективная.
Это обычно технический менеджер имеет пару Seniour Developer’ов в запасе (на своем же проекте).
Обычно отдел контроля не имеет в прямом подчинении никого. Да и не будут же они на каждый 3 абзаца дергать Seniour Dever’oв.
В том то и хитрость получается, что скажем Product Manager может быть не программистом, так как
а) Он может получить оценку ситуации у программистов
б) Он может поглядеть найденные баги от тестеровщиков
в) Он может попробовать продукт сам
Эти три вещи вполне позволяют ему разумно оценить обстановку дел.
Кстати и даже при этом иногда product manager’ы попадают в ситуацию, когда их «водят за нос» подчиненные выдавая желаемое за действительное.
В случае с сбором и контролем знаний они сами не могут проверить зачастую качество знаний (так как в отличии от продукта, знания гораздо менее точны и спецефичны).
Отсутствуют тестировщики знаний у которых можно запросить «баги».
Создатели знаний создают знания не как первичный продукт, а как вторичный и поэтому тоже могут дать гораздо меньше информации.
На счет продакт менеджеров. Я конечно понимаю, что вся их оценка субъективна, т.к. любой продакт менеджер — это фактически бизнесмен, только без инвестиций. Фактически — это экспериментатор за чужие деньги. Т.е. затрат минимум, а при удачном исходе куча бонусов в виде хорошей зарплаты и положительного опыта. Но лично я уверен, что если меня щас кинут вместо пхп на джаву, или си плюс плюc, или производство маргарина, или выработку угля, то я приложу максимум усилий, чтобы в минимальный срок, максимально разобраться в теме. И меня за нос водить никому не удасться. Нэ така я людына.
Я согласен, если человека водят за нос, то зачастую он позволяет водить себя за нос.
Однако, скажем, если нас бросят сейчас на…. скажем на разработку лекарств против шизофрении, то боюсь что пару лет мы убьем, в том, чтобы разобраться в деталях и понимать, когда нам вешают лапшу на уши, а когда говорят правду.
А ведь, есть множество менеджеров для которых программирование ничем не отличается от разработки лекарств от шизофрении.
я думаю, что для того, чтобы не получился КГБ нужно… не торопиться организовывать отел сбора, систематизации и конторля знаний. я думаю, что на начальном этапе, когда объем записанной информации сравнительно не велик, с этой функцией успешно справятся Project Manager’s и Head of Department’s, с привличение CТО на наиболее отвественных участках и Senior Developer’s, на наиболее технологически сложных участках. т.е. можно организовать review знаний силами команды/отдела/технологического направления и под руководством менеджеров среднего звена. таким образом мы избежим капиталовложений на ранних этапах и рисков, связанных с привлечением не компетентных ресурсов для контроля и систематизации информации.
самая важная проблема в системе накопления знаний — это проблема накопления знаний. все знают, что knowledge base — это хорошо. все видели как это работает. все хотят, чтобы их не отвлекали от работы по пустякам и не хотят рассказывать одно и тоже по 10 раз. все понимают, что сложные технлогические и организационные решения неплохо бы где-то записывать. все всё понимают — никто ничего не делает. «сейчас нет времени — потом, потом… а что я хотел записать, а? а, ну да, три недели назад я сделал одну такую фишку… по-моему вот так и так». в итоге теряется актуальность, часто не расставляется значимых акцентов и не оформляется должным образом детализация. как решать? пока не знаю, из всех доступных мне на современном рынке средств, я избрал для себя капанье на мозги и личный пример, пока не очень помогает. думаю использовать количество статей в Вики в качестве одного из индикаторов карьерного плана. тоже метод, хоть я не люблю такие.
В целом я согласен. Проблема просто возникает, когда не всех интересует сбор знаний. Тогда без отдельного отдела (может быть состоящего из одного человека) идея постоянно начинает пылиться и про нее забывают (особенно из-за текущих пожаров).
Именно-именно.
Честно говоря я тоже не нашел толкового метода пока. Поэтому и чувствую, что тема больная.
Точнее, я догадываюсь как это организовать в фирме на 300 человек, но как это эффективно сделать в фирме на 30 человек — дело сложное.
Гляньте «Хром», очень интересный отрывок из воспоминаний Примо Леви:
http://vivovoco.rsl.ru/VV/PAPERS/BONMOTS/VV_BM3_W.HTM
Сначала думал, что спам, но прочел и понял, это то самое, что происходит сейчас с IT индустрией и мы увидим эти самые застывшие краски и размалывание и добавление кислот через два десятка лет ;)))
Все у кого есть 15-20 минут, рекомендую прочесть от начала до конца.
Михаил, большое спасибо за ссылку.
Я в шоке. Я открыл, подумал что спам и не стал читать 🙂
А ведь просто потрясающая статья 🙂 Она говорит о том, что многие люди используют инструкции, не вникая в их суть. Т.е. им не интересно зачем и для кого они были написаны. Едошин привел пример, при этом ничего не сказал о своем собственном мнении. А у меня возник вопрос. Если я делаю бизнес, стоит ли составлять инструкцию? С одной стороны если ее будут бездумно выполнять (а так будут делать вероятнее всего около 90% работников, особенно если речь идет о десятках людей), то есть шанс, что при качественной инструкции даже бездумное выполнение сможет обеспечить достаточное качество для получения прибыли. С другой стороны, по моему просто хозяева лакрокрасок сравниваются с хозяевами айти. У них похожие проблемы — как доверить человеку. Как потом его частное решение применять к другим проблемам. Леви просто как и все его предшественнеки не описал решение своей проблемы четко, а просто показал ее техническое решение, ничего не объяснил и уволился. Логично, что потом все просто по инерции применяют его решения, т.к. они дают какой-то результат, хотя и не всегда, хотя и никто не знает «почему».
Меня лично химия тоже очень сильно привлекает. Я лично когда то себе задавал вопрос, а кем бы я был, если бы не было такого развития компьютерной техники и специальности программиста? Я дал себе ответ. Я был бы химиком. И может быть еще займусь химией, когда наконец у меня будет стока денег, что я смогу не работать на «дядю», а делать че мне захочется.
А ваще Едошину зачет за историческую аналогию.
Да, статья оказалась на удивление интересная и жизненная.
Вообще конечно, приятно видить, что мы решаем проблему, которая не первый раз в истории появилась.
Что меня правда напрягает, что толком она таки не решена.
И проблема именно в том, что все люди разные. И очень тяжело придумать схему, которая работала бы даже для большинства.
Насчет химии поддерживаю 😉
В свое время (Шура, Дима Горбунов, Саша Горобченко и еще пару человек) может помнят, мне сорвало крышу и я начал перечитывать учебники по химии. И даже была идея получать второе образование по химии.
Действительно что-то в химии есть похожее на программирование.
Свое мнение у меня такое, что я не знаю, как с этим бороться 🙂 То есть Леви-то, как я понял, все объяснил, написал отчет, но потом отчет посеяли, а рецептура осталась, а если кто, как Бруни, ею и интересовался, его отшивали, как бы чего не вышло.
Некоторые мысли in no particular order:
* Больше документации — не значит лучше, чем ее больше, тем меньше будут ее читать, тем больше сил будет уходить на ее написание и поддержку. У меня есть старенький iPod Shuffle, так вот, у него замечательный user manual. Он занимает ровно одну пластиковую карточку. Там есть и другой побольше, но он типа для редких случаев установки или troubleshooting’а. Эта карточка просто чудо в сравнении с теми кошмарными простынями или талмудами на всех языках, которые обычно идут к технике.
* Печатная документация недорогая, но трудная — читать тяжело, особенно типичный канцелярский стиль. И люди вообще в целом постепенно перестают читать. А хорошая документация с графикой, аудио, видео пока еще дорогая. Хотя можно найти и компромисные решения, вроде скринкаста.
* Главное — это процесс, привычки, а не мотивы. Бизнес-знание должно быть встроено в работу. То есть если есть какой-то стандартный процесс, то он должен быть не просто на листочке записан, а, например, сделан в виде шаблона для электронного планировщика, чтобы он людям был непосредственно полезен в работе — щелкнул и получил пошаговую инструкцию, в которой только отмечай, что сделал, а это, плюс время, уже автоматом уходит в результаты. То есть сделать систему, которой люди сами будут пользоваться, потому что она помогает в работе, а система одновременно будет собирать нужные данные.
* Документация должна быть «в контракте», одним из продуктов. То есть идет у нас фаза дизайна — на выходе должно быть что-то, что документирует принятые решения с комментариями, почему. Идет фаза интерфейса — то же самое. Если сдается только код, это еще не все сделано.
Я согласен, документация — это всего лишь артефакт. Главное — у людях в головах, чтобы они хотели и умели пользоваться. И зачастую меньше но более толковой документации — гораздо лучше.
>Главное — это процесс, привычки, а не мотивы. Бизнес-знание должно быть >встроено в работу.
Я согласен. Даже продолжу мысль. Идеально, если без процесса работать становится сложнее и тяжелее.
> Идеально, если без процесса работать становится сложнее и тяжелее.
Да, совершенно верно; не заставлять людей документировать из-под палки, а огранизовать дело так, чтобы люди сами документировали.
И еще: я думаю, у разных людей очень разные способности к документированию — возможно, на составление важной сводной документации стоит подбирать специального человека, у которого к этому способности и склонности.
Статья очень натуральная, спасибо 🙂
Ужас! Стало страшно читать, не говоря уже о том, что бы обсуждать! 🙂
Рецепт №1 для маленькой компании — использовать по максимуму готовые и (что важно) проверенные другими решения для построения своих продуктов.
Стараться по минимуму создавать собственные сложные компоненты (писать с нуля).
Если же все же хочеться «своего, родного» — нужно выбирать между:
а) низкой прибылью (или даже убытками), но с перспективой прорыва и высоким качеством (и идти по пути больших компаний в вопросе именно этой разработки)
б) риском не сделать вообще ничего из-за низкого качества, но делать компонент/продукт быстро (и в этом случае везение и личный опыт участников команды могут сильно помочь).
Из этого рецепта следует и отношение к накоплению уникальных знаний 🙂
Рецепт №2 для маленькой компании — сконцентрировать накопление знаний в руках одного-двух людей, которые ХОТЯТ, УМЕЮТ и СТРЕМЯТСЯ формализовать, упорядочить и самое главное добыть эти самые знания. Всем остальным объяснить/приказать/упросить помочь этим людям своими ОТВЕТАМИ на их уточняющие вопросы, и регулярным рецензированием их трудов.
Ежели… ежели нет таких людей в компании, то и рыпаться не имеет смысла, особенно всем вместе в «дружном порыве» 🙂
P.S. У нас в компании тоже много «запущенных» мест, кода и проектов 🙁 Но есть 2 человека, которые эту ситуацию понемногу исправляют.
Рецепт №3 — накапливать (в R&D) только ту информацию, которую мы точно знаем, что будем изучать, пересматривать, использовать в другой деятельности в ближайшей перспективе (до 3 лет). Если знаем, что это «на перспективу», но конкретно куда и когда пойдут знания непонятно — не стоит над ними и задумываться 🙂
Основные случаи повторного применения:
1. Пришел новый человек в компанию.
2. Пришел новый человек в R&D.
3. Пришел новый человек в проектную группу (занимающуюся разработкой по одному-двум направлениям).
4. Существует «костыль», который всем мешает, но еще год будет работать (не больше). Решили от него избавиться.
5. Запланирована (на конкретную дату) смена платформы для нескольких компонентов/продуктов. Необходимо подготовиться.
6. Компания вышла на новый рынок, либо значительно расширила свое участие на существующем рынке.
7. Компания выпустила успешный продукт, и его хочет выкупить вместе со знанимя и людьми большая корпорация.
В каждом из этих случаев НЕОБХОДИМО пересмотреть накопленные знания, произвести их «чистку» и четко обозначить пробелы.
В случаях 6 и 7 знания можно оформить книгой, и даже неплохо на ней заработать.
В случаях 1 и 2 — внутренним справочным руководством (в виде книги — идеально) 🙂
Мне кажется, многие рецепты сильно уклонены в сторону R&D.
Ниже мои комментарии, хотя они в основном с негативной стороны, это скорее не критика, а просто обсуждение/размышление.
Например, как работать(общаться) с заказчиками не укладывается в R&D.
>Рецепт №1 для маленькой компании — использовать по максимуму готовые и (что важно) >проверенные другими решения для построения своих продуктов.
С технической точки зрения согласен. С точки зрения разнообразных процессов в фирме. Как раз и есть проблема, что готовые решения не всегда хорошо ложатся в фирму.
>Рецепт №2 для маленькой компании — сконцентрировать накопление знаний в руках >одного-двух людей, которые ХОТЯТ, УМЕЮТ и СТРЕМЯТСЯ формализовать, упорядочить и >самое главное добыть эти самые знания.
С одной стороны логично. С другой стороны, вероятно эти люди окажутся и так наиболее опытными и им то результат этого нужен меньше всего. Если вдуматься в целом, формализация хороших привычек и идей нужна именно для средних/слабых членов команды, так как они еще не дошли своим опытом до каких-то истин и поэтому их надо «загонять» в эти истины.
Плюс, опасно, что и так болезненный уход ключевых людей еще и убьет процесс.
>Рецепт №3 — накапливать (в R&D) только ту информацию, которую мы точно знаем, что >будем изучать, пересматривать, использовать в другой деятельности в ближайшей >перспективе (до 3 лет).
С этим полностью согласен. Прицел на ближайшие 3 года — очень верный прицел.
Суммарно. Получается, что решение накопление информации- либо личная инициатива нескольких человек, либо специальный отдел. В первом случае — это не процесс, а делание чего-то по настроению, в втором случае — это процесс, но от которого всех тошнит.
> Мне кажется, многие рецепты сильно уклонены в сторону R&D.
Да, а как иначе? Я же не работал в ларечном бизнесе 🙂 Пишу о том, о чем знаю. Тем более многие примеры и обсуждения как раз сводились к процессу разработки, знания от которого «оставались в головах».
К консалтингу подобные рецепты применять нет смысла — это другая по своей сути деятельность, и документирование в ней the must (основа процесса).
В технической поддержке существует ITIL, и (если это действительно поддержка) «все ходы записаны», иначе счета выставлять не получится.
Другие виды деятельности, относящиеся к IT я комментировать не берусь 🙂
Я скорее имел работу фирмы целиком. Ведь R&D это только часть IT.
Есть — H&R, есть менеджмент, есть работа с заказчиками, есть финансовая часть и т.п.
Кое что из них лучше проработано, что-то хуже.
Фактически все взаимосвязанно и влияет друг на друга.
> С другой стороны, вероятно эти люди окажутся и так наиболее опытными и им то результат этого нужен меньше всего.
Как раз наоборот! Ведь самые опытные постоянно занимаются обучением и наставничеством. А документированные знания снимают бОльшую часть рутинной нагрузки уже на втором цикле обучения 🙂
В моем случае новый человек сначала читает бОльшую часть документации по продуктам, проекту и процессам. После чего задает уточняющие вопросы. И только после второго этапа изучения документации начинается наставничество (через контрольные вопросы и простые практические задания).
В конце обучения документация пересматривается, чиститься, дополняется с учетом заданных вопросов. И следующее обучение производится еще эффективнее.
Уход ключевых людей ВСЕГДА убивает процесс. Руководство компании должно это осознавать. И выбирать между:
а) экономия на процессе и количестве людей, но большой риск при уходе ключевых людей,
б) постоянное «выравнивание» всех сотрудников за счет уменьшения доходной части производства, увеличения штата и развития процесса.
Идеальных компаний не существует 🙂
> Суммарно. Получается, что решение накопление информации- либо личная инициатива нескольких человек, либо специальный отдел.
Не согласен. Грамотное руководство компании может совместить оба подхода — найти таких людей (реже — воспитать), и включить их в процессы компании, поощряя результаты деятельности этих людей. Такой подход включен в понятие «инновацонный менеджмент».
P.S. Виктор, я не понимаю вашего отношения к «процессу», как к тому, что обязательно нужно навязывать коллективу, и обязательно будет принято «в штыки» как минимум на этапе внедрения. Это проигрышная позиция. Большинство процессов хорошо адаптируются и под специфику бизнеса компании, и под конкретных сотрудников. Просто не нужно «забивать» на дисциплину подготовки и работы по адаптации. Даже менеджмент по ISO можно внедрить так, что 90% сотрудников будет как минимум поддерживать это внедрение. Конечно, это стоит денег и занимает много времени (по сравнению с тупым навязыванием) 🙂
>Виктор, я не понимаю вашего отношения к “процессу”, как к тому, что обязательно >нужно навязывать коллективу, и обязательно будет принято “в штыки”
Я пою то, что вижу.
Любые нововведения чаще всего воспринимаются в штыки. Особенно если исполнители этих нововведений не видят результата и не чувствуют заинтересованности.
> 90% сотрудников будет как минимум поддерживать это внедрение.
Наверное вы работаете в Раю ;)) Все коллективы где я работал достаточно неоднородны.
Может быть, поддержка на словах и была бы, но действовать точно люди не хотят.