Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 153
Часто во внедряемом ПО как класс может отсутствовать такое понятие как юзабилити. Если людям неприятно пользоваться, то они будут активно сопротивляться внедрению. И никакая логика и приказы сверху не помогут.
> Т.е. если людям не захочется работать, то они и работать не будут
Для вас это новость? Покажите мне как вы будете отслеживать занимается человек делом или сидит в социальной сети.
Если сотруднику неинтересно, неудобно, не еще что-то, то его эффективность сильно снижается. Начинается сидение на фишках. Из-за фишек человеку не включиться в работу и он еще больше теряет в эффективности. Потом начинается апатия, недовольство и т.п.
Я сам и на себя наблюдал, и на подчиненных. Помогает работа с мотивацией и заинтересованностью.
Для вас это новость? Покажите мне как вы будете отслеживать занимается человек делом или сидит в социальной сети.
Если сотруднику неинтересно, неудобно, не еще что-то, то его эффективность сильно снижается. Начинается сидение на фишках. Из-за фишек человеку не включиться в работу и он еще больше теряет в эффективности. Потом начинается апатия, недовольство и т.п.
Я сам и на себя наблюдал, и на подчиненных. Помогает работа с мотивацией и заинтересованностью.
Денежная мотивация отнюдь не единственная. Есть много способов заработать, так что он еще и не самая главная. А вот самореализация, получение удовольствия от работы — куда как важнее.
Скрыть потерю производительности в 2 раза можно вполне. Всегда можно придумать как отмазаться. Есть и классическое «мой код компилируется» :)
Проблема не в пользе. Проблема в удобстве. Готовы ли ваши сотрудники ради мифической пользы делать 10 лишних телодвижения? Ведь слова «я осознаю пользу» и реальное осознание — разные вещи.
У нас в фирме был хороший пример: мы пытались заказчика заставить постить баги напрямую в баг-трекер. Неделю он это делал, а потом сказал: «долго, непонятно, неудобно» и стал снова отсылать все письмами.
Ваши сотрудники — это те же самые заказчики, только с очень большой лояльностью.
Скрыть потерю производительности в 2 раза можно вполне. Всегда можно придумать как отмазаться. Есть и классическое «мой код компилируется» :)
Проблема не в пользе. Проблема в удобстве. Готовы ли ваши сотрудники ради мифической пользы делать 10 лишних телодвижения? Ведь слова «я осознаю пользу» и реальное осознание — разные вещи.
У нас в фирме был хороший пример: мы пытались заказчика заставить постить баги напрямую в баг-трекер. Неделю он это делал, а потом сказал: «долго, непонятно, неудобно» и стал снова отсылать все письмами.
Ваши сотрудники — это те же самые заказчики, только с очень большой лояльностью.
На самом деле из-под палки вы не получите эффективного работника.
Крайне сложно мотивировать тех, кто пришел на работу не потому что интересно, а потому что зарплата_хорошая/больше_некуда_было/ну_надо_где_работать. Сами понимаете, есть ряд профессий и работ (например, на государство, где качество работы важно редко), где мотивация будет невысокой. Возможно, стоит попробовать изменить корень проблемы:
1. Рабочий процесс (чтобы в нем было хоть немого больше творческого начала)
2. Отсутствие духовной мотивации (на одном итальянском заводе по производству мопедов не могли добиться повышения качества никакими тренингами. Пока один менеджер не развесил по всему заводу листы с надписью «На этом мопеде через неделю будет ездить чей-то сын»).
3. Делигировать ответственность на работников (если сделать грамотно, то работник почувствует себя выше — он будет не шестеренкой, а кем-то, у кого есть зона ответственности).
Крайне сложно мотивировать тех, кто пришел на работу не потому что интересно, а потому что зарплата_хорошая/больше_некуда_было/ну_надо_где_работать. Сами понимаете, есть ряд профессий и работ (например, на государство, где качество работы важно редко), где мотивация будет невысокой. Возможно, стоит попробовать изменить корень проблемы:
1. Рабочий процесс (чтобы в нем было хоть немого больше творческого начала)
2. Отсутствие духовной мотивации (на одном итальянском заводе по производству мопедов не могли добиться повышения качества никакими тренингами. Пока один менеджер не развесил по всему заводу листы с надписью «На этом мопеде через неделю будет ездить чей-то сын»).
3. Делигировать ответственность на работников (если сделать грамотно, то работник почувствует себя выше — он будет не шестеренкой, а кем-то, у кого есть зона ответственности).
> А мотивация остаться на работе не достаточна сильна? :) = для меня никогда данное не было мотивацией! если ты не дятел работу найдешь всегда! А условия работы должны соответствовать твоим требованиям. ИМХО =)
А директор не понимает, что толку от таких отчетов — ноль? У самого него никогда не будет времени на вчитывание. Сотрудники же со временем привыкнут и начнут мухлевать, раз их никто не контролирует. Разве это — умение работать в команде?
Умение работать в команде, имхо, заключается прежде всего в способности объяснить своего коллеге и тем более начальнику в чем он не прав и почему. Этим вы повышаете эффективность и окружающих, и свою собственную.
Умение работать в команде, имхо, заключается прежде всего в способности объяснить своего коллеге и тем более начальнику в чем он не прав и почему. Этим вы повышаете эффективность и окружающих, и свою собственную.
Да, может быть я не совсем верно выразился.
Если меня что-то не устраивало для меня сменить место работы никогда не вызывало трудности. Могу сказать открыто, что я не боюсь таких перемен. Но когда я приходил в новую команду то приходилось принимать какие-то правила от code convensions до инструментов и методов их использования. Где-то это ежедневные отчеты в мантис и еженедельные на мыло дирректору, где-то это подробный отчет по каждой задаче. Далеко не всегда эти правила лично мне по душе, но принимаясь за работу нужно с ними соглашаться.
Вот именно умение работать в команде а не противостоять ей я считаю показателем профессиональности.
>
Тут вопрос интересный, у меян сейчас работает 2 человека, я у них не прошу отчетность, я прошу результат! и поверьте я стараюсь создать в офисе атмосферу аля Гугл, и людям и работа нравится, и работается легко. А принуждая что-то делать… например креативщика грузить отчетами, в момент его порыва и творения? Я на километр не подпущу к своему программисту, когда он работает! А его лучший отчет будет результат. А если Шеф бегает с биноклем за сотрудником… хм… он старомоден. Я говорю о том что: Создай человеку условия а не правила, и он будет работать. для меня это работает.
Если меня что-то не устраивало для меня сменить место работы никогда не вызывало трудности. Могу сказать открыто, что я не боюсь таких перемен. Но когда я приходил в новую команду то приходилось принимать какие-то правила от code convensions до инструментов и методов их использования. Где-то это ежедневные отчеты в мантис и еженедельные на мыло дирректору, где-то это подробный отчет по каждой задаче. Далеко не всегда эти правила лично мне по душе, но принимаясь за работу нужно с ними соглашаться.
Вот именно умение работать в команде а не противостоять ей я считаю показателем профессиональности.
>
Тут вопрос интересный, у меян сейчас работает 2 человека, я у них не прошу отчетность, я прошу результат! и поверьте я стараюсь создать в офисе атмосферу аля Гугл, и людям и работа нравится, и работается легко. А принуждая что-то делать… например креативщика грузить отчетами, в момент его порыва и творения? Я на километр не подпущу к своему программисту, когда он работает! А его лучший отчет будет результат. А если Шеф бегает с биноклем за сотрудником… хм… он старомоден. Я говорю о том что: Создай человеку условия а не правила, и он будет работать. для меня это работает.
Ну, за километр не подходить к разработчику и ждать результата — тоже не всегда хорошо. Мне, например, очень мотивирующе и приятно, если моей работой как программиста начальник интересуется и время от времени заглядывает что-то обсудить или спросить как успехи и не возникло ли проблем или идей. Жаль только, что реже, чем хотелось бы…
Ну вы сказали не о тех вещах о которых я имел ввиду =) Я имел ввиду не подпущу к разработчику, что бы ему мешать. А поповоду идей, это постоянно… именно поэтому я считаю программеров креативщиками. Потому как я подаю только идею, а разарботка его, иногда приходится брать временно программеров ему в помощь. И это решение исходит из нашего общения. А вот портить ему настроение отчетами и т.д.… он мне сам скажет о трудностях или прогрессах.
Если хотите, чтобы люди что-то делали для вас, сделайте так, чтобы они захотели это делать.
Сюрприз! Если людям не захочется работать, то они и правда работать не будут. Рабство отменили, благо. Самодурствующее руководство быстро растеряет всех хоть что-то умеющих сотрудников.
Есть отличный способ, который срабатывает как при смене операционной системы, так и при внедрении системы автоматизации — не оставлять альтернатив. Просто в один день всё предприятие переходит на использование ТОЛЬКО этого инструмента. Кто не перешёл — потерял в деньгах. Опробовано на внедрении Linux в компании со среднесписочной ~700 человек, а также в ИТ-отделе при переходе к электронной регистрации заявок («нет заявки — нет проблемы» — пользователям; «не закрыто — не расписано — не решено» — сотрудникам).
100 процентов работает. Не раз так делали у себя. Нужно перейти на новую систему багтрекинга? Просто удаляем нафиг старую и ставим новую. Нужно перейти с Visual Studio 2005 на 2008? ПМ приходит на работу на час раньше и на компах все разработчиков сносит нафих старую VS. С CVS на SVN перейти? Аналогично — репозитарий нафиг (с импортом в SVN, конечно) и флаг в руки.
Это при переходе с одного ПО на другое. При переходе с «таскания бумажных отчетов» на хоть какую систему документооборота подход другой — приходишь к Васе, который раньше обрабатывал документы, которые ему приносил Петя и объясняешь, что _бумажные_ документы от Пети он смело может выкидывать нафиг и ничего по ним не делать. И ничего ему за это не будет. А виноват будет Петя. На первой же планерке за необработанные документы отгребет тот, кто их сделал бумажными и дальше пойдет как по маслу.
Это при переходе с одного ПО на другое. При переходе с «таскания бумажных отчетов» на хоть какую систему документооборота подход другой — приходишь к Васе, который раньше обрабатывал документы, которые ему приносил Петя и объясняешь, что _бумажные_ документы от Пети он смело может выкидывать нафиг и ничего по ним не делать. И ничего ему за это не будет. А виноват будет Петя. На первой же планерке за необработанные документы отгребет тот, кто их сделал бумажными и дальше пойдет как по маслу.
думаю, тут подойдет такое сравнение:
автор наводит порядки на дорогах городка. ставит светофоры, делает разметку — все для того, чтобы пешеходам и водителям стало удобнее передвигаться. а пешеходы, негодяи, все так же идут на красный и переходят в неположенных местах, потому что им, видите ли, так ближе к дому.
нужны заборы и штрафы, чтобы система начала работать.
автор наводит порядки на дорогах городка. ставит светофоры, делает разметку — все для того, чтобы пешеходам и водителям стало удобнее передвигаться. а пешеходы, негодяи, все так же идут на красный и переходят в неположенных местах, потому что им, видите ли, так ближе к дому.
нужны заборы и штрафы, чтобы система начала работать.
Я ПМ запинаю ногами, если он тронет своими руками мой рабочий environment.
Вы считаете, что выбор средств разработки (не аддонов там или текстовых редакторов, а именно языков программирования и компиляторов) — это Ваше личное дело, к коему ПМ( или архитектор ) никак не причастен?
Каким компилятором/языком программирования мне пользоваться, говорит мне мой работодатель в лице моего начальника.
Приходить и сносить мне софт ПМ не должен, тем более при моем отсутствии на рабочем месте.
Приходить и сносить мне софт ПМ не должен, тем более при моем отсутствии на рабочем месте.
Правильно. Это должен делать системный администратор. И именно в ваше отсутсвие, вам деньги платят не за разглядывание прогресса инсталляции.
Администратор должен поставить мне на рабочую машину ОС + офис + аутлук. Все!
Настраивать свой рабочий environment разработчик должен сам.
Настраивать свой рабочий environment разработчик должен сам.
Environment это цвета в редакторе. А софт вам ставят.
Я был бы очень рад, если настройка environment'a ограничивалась только выбором цветового профиля в IDE.
FYI,
Integrated development environment
FYI,
Integrated development environment
Я очень рад, что вы умеете делать ссылки в википедию, но это не отменят того факта, что компилятор (с настройками), система контроля версий (со всеми своими настройками опять же), система автодокументирования (ну вы поняли) — корпоративный стандарт.
Не может один разработчик писать в VS2005, а другой в VS2008 (а то и VIM! с gcc). Не может один пользоваться SVN, а другой VSS. Не может один разработчик оптимизировать релиз по размеру, а другой по скорости. Не может один разработчик создавать обычную отладочную информацию, а другой для Edit&Continue. Не может один пользоваться sandcastle, а другой doxygen.
Цвета и шрифты (и то не произвольно) это всё что вы можете настроить. Если вам позволили настраивать больше, значит у вас бардак.
Не может один разработчик писать в VS2005, а другой в VS2008 (а то и VIM! с gcc). Не может один пользоваться SVN, а другой VSS. Не может один разработчик оптимизировать релиз по размеру, а другой по скорости. Не может один разработчик создавать обычную отладочную информацию, а другой для Edit&Continue. Не может один пользоваться sandcastle, а другой doxygen.
Цвета и шрифты (и то не произвольно) это всё что вы можете настроить. Если вам позволили настраивать больше, значит у вас бардак.
1. Я надеюсь, что ссылка с википедии оказалась полезной и теперь вы знаете, что dev environment не ограничивается цветовыми профилями в вашем редакторе.
2. Если в команде разработчиков, можно выбирать любимый редактор для написания программ и от этого никак не зависит выходной результат, то почему нет.
3. Представим ситуацию, что вы/ваш ПМ случайно удалил с вашей машины VS/CVS, а администратор в этот момент болен/в отпуске. У вас разработчики в силах установить это ПО самостоятельно? Или все будут ждать возвращения админа?
2. Если в команде разработчиков, можно выбирать любимый редактор для написания программ и от этого никак не зависит выходной результат, то почему нет.
3. Представим ситуацию, что вы/ваш ПМ случайно удалил с вашей машины VS/CVS, а администратор в этот момент болен/в отпуске. У вас разработчики в силах установить это ПО самостоятельно? Или все будут ждать возвращения админа?
Если компания крупная, то админов минимум два. Если мелкая, то тут и говорить не о чём.
Мне кажется, Вы, r3d, слишком близко к сердцу приняли тезис о том, что кто-то переустанавливает софт на Вашей машине без вас. Конечно, пользователь машины должен предупреждаться об изменениях, конечно, должны быть сделаны бекапы настроек, а время апгрейда софта — согласовано с каждым конкретным человеком. Это всё можно и нужно делать.
А вот чего делать нельзя — это говорить «так, нам нужно перейти вот на это — сделайте, когда Вам будет удобно и и будет время». В это случае перехода не произойдет никогда.
А вот чего делать нельзя — это говорить «так, нам нужно перейти вот на это — сделайте, когда Вам будет удобно и и будет время». В это случае перехода не произойдет никогда.
три месяца назад я случайно затер загрузчик семерки, теперь я постоянный линукс-пользователь. И хоть сейчас возможность восстановить загрузчик и есть, но вот уже желания нет. Так что отсутствие альтернатив работает! Проверено на себе.
Коммунисты точно так же устанавливали Советскую власть. У них получилось. Значит метод сработал. Но хорошо ли стало пользователям?
Зависит от контингента, который работает в компании. Если это пролетарии, то это хорошо. Думать не надо — за тебя будет думать власть(начальство).
Ну, в случае с политическим строем — тут конечно да. Но в случае внутрикорпоративных дел — а кто их спрашивает? Спрашивают у совета директоров, но не более того.
Да Вы что! Система 70 лет проработала без сбоев, пережила кучу креш-тестов, пятая часть шарика пользовалась. Дай Бог каждой разработке такую судьбу! :)
Кому не понравилось и была возможность уехали(уволились). Остальные работали. Значит нравилось или не было других альтернатив. В общем хороший вариант.
З.Ы. Тоже внедрение прошло хорошо. Просто запретили бумажки и все.
З.Ы. Тоже внедрение прошло хорошо. Просто запретили бумажки и все.
Как же вы чертовски верно выразились! Стопроцентное попадание.
В таких случаях нельзя давать людям выбор — они обязательно сделают неправильный :)
В таких случаях нельзя давать людям выбор — они обязательно сделают неправильный :)
Да уж, круто! Только вот если от этих людей что то зависит можно и коллапс устроить — пока они учится будут из под палки кто за них работать то будет?
Напоминает старый анекдот о том как русские взялись задешево перевести Англию на правостороннее движение, запустив по ее дорогам на неделю 500 камазов по правой стороне.
Исходя из ваших условий, вам этого и не надо, вас не должно волновать что после того как вы все оттестировали, всех обучили, показали выгоды и т.п. сотрудники НЕ вашего предприятия не пользуются ПО, почему? всё просто вы сделали свою часть работы, дальше идет часть начальства, которое потратило уйму бабла и это именно их забота.
Рассмотрим 3ий случай, когда вы являетесь начальством. Я конечно понимаю что каждому программисту удобнее кодить так как он привык, но если организация большая и всякие может быть(заболел, уволили и т.п.) и другому надо делать за него дела, тут конечно надо всё систематизировать, как решить данную проблему? Перевести всех на оплату 50%, а вторые 50% выдавать премиальными, что это дает? Это дает ввести систему штрафов. Если сотрудник не использует определенное ПО при разработке, то получает штраф, дальше он быстро сообразит как надо себя вести.
Рассмотрим 3ий случай, когда вы являетесь начальством. Я конечно понимаю что каждому программисту удобнее кодить так как он привык, но если организация большая и всякие может быть(заболел, уволили и т.п.) и другому надо делать за него дела, тут конечно надо всё систематизировать, как решить данную проблему? Перевести всех на оплату 50%, а вторые 50% выдавать премиальными, что это дает? Это дает ввести систему штрафов. Если сотрудник не использует определенное ПО при разработке, то получает штраф, дальше он быстро сообразит как надо себя вести.
Ну так вот, через премиальные, штрафы как таковые в трудовом законодательстве РФ запрещены, а схема оклад/премия нет, ну и соответственно невыдача премии — это и есть штраф, главный плюс тут в том что эта схема прозрачна для работников, если начальник вдруг пришел и сказал что половина оклада уходит в премию — то легко понять что в случае конфликтной ситуации этой премии можно недосчитаться, и сделать из этого выводы, или согласившись с новыми условиями, или найдя себе другое место работы.
Просто так — конечно нет, только с согласия сотрудников, кто не согласится — того попросят… но сотрудник опять-же может отказаться и от такой просьбы, чтобы уволить по сокращению штата — нужно уведомить за пол-года, чтобы за несоблюдение внутренней дисциплины — должны быть выговоры за собственно несоблюдения, чтобы уволить за несоответствующую квалификацию — там тоже свои заморочки… но в общем и целом мало кто будет настолько упорен в своей ненависти к начальству, так как поводы все-таки могут найтись — и это будет проблемной записью в трудовой.
Насчет дисциплины. Если приказом по компании требуется, скажем, пользоваться электронным документооборотом, линуксом и опеноффисом, а работник бегает с бумажками и сидит на винде — это разве не нарушение?
Так же как и слесарь, который сидит с напильником, потому что новый станок какой-то сложный и непонятный. Вполне себе повод для увольнения.
Так же как и слесарь, который сидит с напильником, потому что новый станок какой-то сложный и непонятный. Вполне себе повод для увольнения.
Ну как — я написал выше, а насчет засудят — не каждый станет судиться, вон после каждого увольнения контора должна выплачивать сотруднику пособие, 2 месяца или, если он устроился на новую работу раньше окончания этого срока, до нового трудоустройства, однако-же на деле я за два года своего опыта работы в различных конторах еще ни разу не видел что-бы кого-либо не попросили «уйти по собственному желанию», а в этом случае пособие не выплачивается, и ведь никто судиться не стал.
Зачем вы на меня клевещете, я целиком и полностью за то чтобы организации в полном объеме выполняли свои обязательства, регламентируемые трудовым законодательством Российской Федерации, так как я одно из лиц, чьи интересы это самое законодательство защищает… защищает де-юре к сожалению, а не де-факто.
Наши разговоры на хабре о законах — одно.
Реальная ситуация — совсем другое.
До сих пор осталось множество организаций и мелких и покрупнее, где выдают серую зарплату. Официально, на банковскую карту, перечисляется минимальные 7000 (8000 оклад минус 13%), а все остальное — плучается наличкой в бухгалтерии.
В нашей конторе, когда начали сокращения, всем, кто уволился по собственному, честно выплатили 2 полных зарплаты.
Если бы кто-то не захотел уходить сам — уволили бы по сокращению, с выплатой тех самых 7000.
Проведя тут на днях некоторую разведку по рынку труда, я обнаружил, что на аналогичные должности в других компаниях нанимают уже за гораздо меньшие деньги, чем платят мне. Потому я и держусь на этом месте. Потому я и плюю на конвертную систему. Разумеется, помимо зарплаты, есть еще плюсы, которые меня здесь удерживают.
Реальная ситуация — совсем другое.
До сих пор осталось множество организаций и мелких и покрупнее, где выдают серую зарплату. Официально, на банковскую карту, перечисляется минимальные 7000 (8000 оклад минус 13%), а все остальное — плучается наличкой в бухгалтерии.
В нашей конторе, когда начали сокращения, всем, кто уволился по собственному, честно выплатили 2 полных зарплаты.
Если бы кто-то не захотел уходить сам — уволили бы по сокращению, с выплатой тех самых 7000.
Проведя тут на днях некоторую разведку по рынку труда, я обнаружил, что на аналогичные должности в других компаниях нанимают уже за гораздо меньшие деньги, чем платят мне. Потому я и держусь на этом месте. Потому я и плюю на конвертную систему. Разумеется, помимо зарплаты, есть еще плюсы, которые меня здесь удерживают.
Зря вы так. Ведь если все продукты будут использоваться, то разработчик кроме морального удовлетворения получит еще и новые заказы на переделку, добавление функционала, на написание новых модулей.
Ваш пример про директора затронул меня до глубины души! Надо будет запомнить
ну не зря же придумали парное программирование. Директор интуитивно пошел по этому же пути.
Верно подмечено про написание велосипедов при разработке ПО. Вообще большая тема для обсуждения, часто с этим сталкиваюсь. Во фреймворке, особенно большом, часто необходимый функционал уже реализован, а программист даже понятия об этом не имеет. Как результат такого подхода — увеличение стоимости продукта и ухудшение качества.
А в каком документе прописано, что сторонняя фирма-разработчик компонентов ПО отвечает материально за потери, возникшие при их неправильной работе? Это каким-то образом письменно оговаривается при покупке компонента?
Думаю, не очень-то просто будет заставить разработчика компонентов выплатить компенсацию.
Думаю, не очень-то просто будет заставить разработчика компонентов выплатить компенсацию.
Директору — вечный почёт и уважение :)
Как уже написали — не оставлять альтернатив. У меня, например, система управления задачами генерирует отчеты. И если человек в конце дня не присылает отчет из нее… А премии почему-то нужны всем O_O
А хотя бы кратко — что в отчете? Какой процент от з/п составляет премия?
Если совсем кратко — есть некая самописная тулза, живущая в трее. Когда сотрудник приходит на работу, он нажимает кнопочку «Я тут». В тусле есть его задачи. Она начинает отсчитывать время, при этом сотрудник может указывать над какой задачей он сейчас работает, остановить таймер нельзя. Утром я нажимаю на кнопочку «покажи мне, шайтан-машина, чем вчера Вася занимался» и вижу чем он занимался. Соответственно, если там ничего нет, или оттикано два часа, или 8 часов потрачено на «рефакторинг всего» а в SVN две строчки поменялись — я начинаю интересоваться что же у него все так плохо. Психика человека устроена так, что он не хочет совсем откровенно подставляться.
Премия не то чтобы большая, но достаточная чтобы ради нее три минуты в день тратили на кликанье богомерзких кнопочек. Опять же, если я не вижу автоотчетов, то сотруднику будет гораздо тяжелее отпроситься уйти на три часа пораньше «пивка попить». А если вижу — то легко и непринужденно.
Пока плет нормальный.
Премия не то чтобы большая, но достаточная чтобы ради нее три минуты в день тратили на кликанье богомерзких кнопочек. Опять же, если я не вижу автоотчетов, то сотруднику будет гораздо тяжелее отпроситься уйти на три часа пораньше «пивка попить». А если вижу — то легко и непринужденно.
Пока плет нормальный.
Пробовал для себя подобный вариант, было жутко неудобно. Проблема не в том, чтобы три минуты в день тратить на смену текущей задачи, а в том, чтобы постоянно помнить и отдавать себе отчёт «а чем конкретно я сейчас занимаюсь»? Это жутко напрягает и утомляет, я долго мучился и забил на это окончательно.
А потом я где-то, кажется, у Джоэла, прочитал, что так действительно делать нельзя — неэффективно, а надо так: оценить, сколько всего времени потрачено на работу за день и разделить его по задачам, которые выполнялись. Попробовал — работает, так намного лучше.
А потом я где-то, кажется, у Джоэла, прочитал, что так действительно делать нельзя — неэффективно, а надо так: оценить, сколько всего времени потрачено на работу за день и разделить его по задачам, которые выполнялись. Попробовал — работает, так намного лучше.
роблема не в том, чтобы три минуты в день тратить на смену текущей задачи, а в том, чтобы постоянно помнить и отдавать себе отчёт «а чем конкретно я сейчас занимаюсь»? Это жутко напрягает и утомляет, я долго мучился и забил на это окончательно.
Все правильно, именно это я и делаю. Заставляя сотрудников отвечать на вопрос «а чем конкретно я сейчас занимаюсь» очень положительно влияет на планирование и производительность их труда. Да, им больно и неприятно — но это намного лучше, чем когда человек сидит в одноклассниках не потому что он раздолбай, а потому что с самоорганизацией у него плохо. Или по пятому разу переписывает тривиальный код «потому что он ему не нравится». Или пишет очередной велосипед, потому что «это прикльно и так три строчки сэкономим».
Тут надобно определиться что нам надо — управляемость и контроль или «свободное творчество». Как показывает практика, немногие программисты в рамках свободного творчества могут эффективно работать :(. И не потому что они плохие, а потому что люди так устроены. Как говорит известная поговорка — «Если дать программисту заниматься тем, чем он хочет — то программист будет делать всякие прикольные фигнюшки. После этого его полезность компании станет стремиться к нулю, его уволят и он умрет от голода» :).
Самоорганизация — сила. Тулза, стимулирующая самоорганизацию (пусть и болезненно) — самый дешевый из известных мне на данный момент способов манифестовать эту силу :(
P.S. А у Джоэла совсем другие люди и приоритеты. Ему никого стимулировать и контроллировать не надо. У меня же жестокая реальность — все могущие люди сидят в яндексе, майкрософте и гугле — приходится работать не с best of the best а с просто хорошими программистами ^_^.
Не-не-не, если моему шефу интересно, он подойдёт и спросит, что именно я делаю сейчас и я ему отвечу. Мониторить текущую задачу самому постоянно — у меня отнимало, пожалуй, процентов 30 мозгоресурсов. Попробуйте прочитать фантастический роман, каждый раз классифицируя текущий абзац по любой придуманной системе признаком — это будет отвлекать. Или попробуйте каждые 15 минут описать то, о чём вы думаете словами. Мониторинг «чем конкретно я занимаюсь сейчас» — из той же серии, хотя раз в месяц этим позаниматься, пожалуй, полезно.
Во-вторых — программисту, как правило, видно много того, что не видно руководству. В данном конкретном вашем подходе отрепортить что-то мелкое вроде «30 минут на рефакторинг foo.bar» зарепортить невозможно, это придётся заранее согласовывать и планировать, что ведёт к огромным накладным расходам на подобные мелкие задачи. Случайно обнаруженную ошибку, так же, проще порой сразу исправить, нежели тратить время на подобную отчётность.
В-третьих, сложно назвать эффективным подход, где исполнитель ограничен в выборе орудия труда, в данном случае — в выборе средства отчётности.
Наконец, оба подхода дают в результате часы работы и их соответствие задачам, так зачем тогда напрягаться больше?
Во-вторых — программисту, как правило, видно много того, что не видно руководству. В данном конкретном вашем подходе отрепортить что-то мелкое вроде «30 минут на рефакторинг foo.bar» зарепортить невозможно, это придётся заранее согласовывать и планировать, что ведёт к огромным накладным расходам на подобные мелкие задачи. Случайно обнаруженную ошибку, так же, проще порой сразу исправить, нежели тратить время на подобную отчётность.
В-третьих, сложно назвать эффективным подход, где исполнитель ограничен в выборе орудия труда, в данном случае — в выборе средства отчётности.
Наконец, оба подхода дают в результате часы работы и их соответствие задачам, так зачем тогда напрягаться больше?
В данном конкретном вашем подходе отрепортить что-то мелкое вроде «30 минут на рефакторинг foo.bar» зарепортить невозможно, это придётся заранее согласовывать и планировать, что ведёт к огромным накладным расходам на подобные мелкие задачи.
Не придется. Работнику, в зависимости от квалификации ставится общая задача. А он сам, с помощью тулзы ее разбивает на подзадачи. Добавлять себе «рефакторинг foo.bar» нужно для истории изменений, истории для планирования времени на будующее.
В-третьих, сложно назвать эффективным подход, где исполнитель ограничен в выборе орудия труда, в данном случае — в выборе средства отчётности.
В данном случае это лучше рассматривать не как орудие труда, а как методологию, организацию работы — воплощенную в программу.
Наконец, оба подхода дают в результате часы работы и их соответствие задачам, так зачем тогда напрягаться больше?
Это очень сложный вопрос. Оба подхода обладают как плюсами, так и минусами. В своем конкретном случае я выбрал первый. До этого пользовался вторым :). По моим критериям (управляемость, планирование) он показался мне более эффективным. В каких то случаях он, конечно, будет менее эффективен. Я, собственно, про него здесь рассказываю в рамках вопроса топикстартера — как сделать так, чтобы люди пользовались софтом. В моем случае люди пользуются софтом — у них отсекли варианты :).
Что-то тут не так.
Когда на моей бывшей работе внедряли документооборот, через небольшое время не пользоваться системой было просто нельзя — ни сотовый поменять, ни бумагу для принтера получить со склада, а уж PMу вообще нечего делать без него — все, буквально все — от появления названия проекта до закрытия счета проекта было через систему.
Так что думаю что ПО о котором речь в статье просто было откатным :)
Когда на моей бывшей работе внедряли документооборот, через небольшое время не пользоваться системой было просто нельзя — ни сотовый поменять, ни бумагу для принтера получить со склада, а уж PMу вообще нечего делать без него — все, буквально все — от появления названия проекта до закрытия счета проекта было через систему.
Так что думаю что ПО о котором речь в статье просто было откатным :)
Ээхх. Если бы…
В данный момент идет «обкатка», «приемка» которая длится уже 2 месяц… И работать в проекте не работают (сотрудники)… И принять не принимают (руководство) — потому что не могут увидеть как система работает (сотрудники). Замкнутый круг блять.
В данный момент идет «обкатка», «приемка» которая длится уже 2 месяц… И работать в проекте не работают (сотрудники)… И принять не принимают (руководство) — потому что не могут увидеть как система работает (сотрудники). Замкнутый круг блять.
А план внедрения вообще прорабатывался?
ПО-простому надо перевести коммуникации во внедряемую систему. То есть если Маша передает по цепочке работу Ване, то Ване надо директивно, в приказном порядке, запретить принимать работу иначе чем через систему. Делается это с задницы цепочки — сначала последним проводим обучение и заставляем вносить все в систему — это самое сложное ( нужно обсудить с начальством, обязать, простимулировать итд ), потом подключаем к ним тех кто им передает. При этом уже обученные рады страшно, поскольку с них снимается куча работы и так до самых первых.
Другой, обычно внутренний вариант — берется отдельный сегмент организации — и с понедельника все делается в системе ( конечно обучение и тесты, но помогает мало :) ) При этом часть людей делает работу два раза — по старинке и в системе.Помучавшись и привыкнув «радуем» их отменой «по-старинке», заодно переводим еще один отдел или вообще всех в систему.
В общем обычные офисные игры :)
ПО-простому надо перевести коммуникации во внедряемую систему. То есть если Маша передает по цепочке работу Ване, то Ване надо директивно, в приказном порядке, запретить принимать работу иначе чем через систему. Делается это с задницы цепочки — сначала последним проводим обучение и заставляем вносить все в систему — это самое сложное ( нужно обсудить с начальством, обязать, простимулировать итд ), потом подключаем к ним тех кто им передает. При этом уже обученные рады страшно, поскольку с них снимается куча работы и так до самых первых.
Другой, обычно внутренний вариант — берется отдельный сегмент организации — и с понедельника все делается в системе ( конечно обучение и тесты, но помогает мало :) ) При этом часть людей делает работу два раза — по старинке и в системе.Помучавшись и привыкнув «радуем» их отменой «по-старинке», заодно переводим еще один отдел или вообще всех в систему.
В общем обычные офисные игры :)
я сталкивался с ПО, с которым было просто отвратно работать.
то есть всякий раз, когда надо было с этим ПО что-то сделать — возникало почти физическое отвращение.
например, Документум (то, что в прошлой конторе писали на документуме).
просто у него хреновое юзабилити — совершенно неочевидные действия для того или иного результата (программисты разработали определенные шаманские действия с мышкой. если их выполнить правильно — будет результат, логики не наблюдается — конечно никто не захочет работать с таким ПО).
то есть всякий раз, когда надо было с этим ПО что-то сделать — возникало почти физическое отвращение.
например, Документум (то, что в прошлой конторе писали на документуме).
просто у него хреновое юзабилити — совершенно неочевидные действия для того или иного результата (программисты разработали определенные шаманские действия с мышкой. если их выполнить правильно — будет результат, логики не наблюдается — конечно никто не захочет работать с таким ПО).
В нашем случае внедрения документооборота дело поставлено пошагово:
1) Сначала оттестировали на узкой группе людей с узкими задачами (бывает такое на большом предприятии), но это был шаг вынужденный — прога самописная, заодно и невидимые баги отловили и юзабилити подправили (явные левые телодвижения).
2) Потом для всех запустили один модуль визирования на ограниченной группе ОРД-документов (приказы etc)
3) Потом в эту группу документов стали добавлять ещё документы, пока все документы не стали проходить через систему
4) Потом последовательно остальные модули (контроль исполнения etc)
И ещё, извините, конечно, не знаю что за прогу вы внедряете, но у меня впечатления после знакомства с большим количеством систем документооборота были не особо приятные. Очень часто это системы громоздкие, загаженные огромным количеством разных форм с подавляющим количеством контролов, с неявной логикой (видной только после вдумчивого изучения документации) изгаженной добавлением разных мелких фич непонятно для кого.
Людям трудно к такому сразу приспособиться и перенести у себя в голове техпроцесс «отнести Маше шоколадку и документ для визы у главного инженера» к процессу «открыть систему — внести документ (на кой-то требуют ещё какие-то поля заполнять, кроме самого текста документа) — нажать кучу кнопок для назначения визирующих лиц» и решить вопрос — нести или нет шоколадку и когда?
1) Сначала оттестировали на узкой группе людей с узкими задачами (бывает такое на большом предприятии), но это был шаг вынужденный — прога самописная, заодно и невидимые баги отловили и юзабилити подправили (явные левые телодвижения).
2) Потом для всех запустили один модуль визирования на ограниченной группе ОРД-документов (приказы etc)
3) Потом в эту группу документов стали добавлять ещё документы, пока все документы не стали проходить через систему
4) Потом последовательно остальные модули (контроль исполнения etc)
И ещё, извините, конечно, не знаю что за прогу вы внедряете, но у меня впечатления после знакомства с большим количеством систем документооборота были не особо приятные. Очень часто это системы громоздкие, загаженные огромным количеством разных форм с подавляющим количеством контролов, с неявной логикой (видной только после вдумчивого изучения документации) изгаженной добавлением разных мелких фич непонятно для кого.
Людям трудно к такому сразу приспособиться и перенести у себя в голове техпроцесс «отнести Маше шоколадку и документ для визы у главного инженера» к процессу «открыть систему — внести документ (на кой-то требуют ещё какие-то поля заполнять, кроме самого текста документа) — нажать кучу кнопок для назначения визирующих лиц» и решить вопрос — нести или нет шоколадку и когда?
элементарно, Ватсон.
Люди используют ПО, чтобы решать свои проблемы. Вам надо всего-лишь показать, что при помощи ПО можно решить проблемы.
Я так пересадил 40 человек с винды с фотошоп на Линукс — сделал видео уроки. :)
Люди используют ПО, чтобы решать свои проблемы. Вам надо всего-лишь показать, что при помощи ПО можно решить проблемы.
Я так пересадил 40 человек с винды с фотошоп на Линукс — сделал видео уроки. :)
Несмотря на то, что вообще отсутствует сколь-нибудь предметное описание проблемы, вам даже умудрились дать некоторые полезные, на мой взгляд советы (и вредные тоже).
По-моему очень мало данных для советов, крайне мало. Особенно вот тут: "Смею заверить, что это не так, и все процессы, интерфейс уже давно вылизаны до блеска, оттестированы, опробованы ответственными лицами и признаны полезными/удобными/понятными" очень сомнительно. Что-то значит не так, что-то не объяснили, что-то не работает, надо смотреть и разбираться. Может у вас надо мышкой много работать, а было не надо, может у вас отчёты непохожие на старые, да миллион может причин быть.
Конечно, люди всегда оказывают сопротивление, всегда. Но опять же всегда у клиента находится толковый человек-два, которые «схватывают», понимают в чём новая система удобнее и вот таких людей надо искать и за них цепляться. Опять же советы и просьбы этих людей надо выполнять. Программистам никогда полностью не понять предметной области клиента и его чаяний, им совсем другое удобнее.
По-моему очень мало данных для советов, крайне мало. Особенно вот тут: "Смею заверить, что это не так, и все процессы, интерфейс уже давно вылизаны до блеска, оттестированы, опробованы ответственными лицами и признаны полезными/удобными/понятными" очень сомнительно. Что-то значит не так, что-то не объяснили, что-то не работает, надо смотреть и разбираться. Может у вас надо мышкой много работать, а было не надо, может у вас отчёты непохожие на старые, да миллион может причин быть.
Конечно, люди всегда оказывают сопротивление, всегда. Но опять же всегда у клиента находится толковый человек-два, которые «схватывают», понимают в чём новая система удобнее и вот таких людей надо искать и за них цепляться. Опять же советы и просьбы этих людей надо выполнять. Программистам никогда полностью не понять предметной области клиента и его чаяний, им совсем другое удобнее.
Для решения проблемы должен быть приказ начальства работать только в ПО
За несоблюдение — шраф
Проблема в том что это никому ненадо — ПО заказали для «освоения бюджета», увы
За несоблюдение — шраф
Проблема в том что это никому ненадо — ПО заказали для «освоения бюджета», увы
Хорошие советы. Вот ещё как вариант: выявить актив в коллективе, хорошо натаскать и поставить перед ним задачу, актив подтянет инертную массу.
На актив можно давить, его можно стимулировать… теребить… (: эээ… извините увлекся…
Т.е. чтобы обучить стадо обезьян, нужно обучить главную обезьяну.
На актив можно давить, его можно стимулировать… теребить… (: эээ… извините увлекся…
Т.е. чтобы обучить стадо обезьян, нужно обучить главную обезьяну.
Интересная ситуация.
С одной стороны, дело тут может быть в том, что к новой системе надо привыкать и всем лень. Тогда тут могут помочь подробные тренинги и/или волевое решение руководства.
С другой стороны, может оказаться, что не смотря на все удобство, в некоторых случаях гибкости системы не хватает и проще позвонить или разобраться на бумажке. В этом случае сколько не дави, толку не будет.
С одной стороны, дело тут может быть в том, что к новой системе надо привыкать и всем лень. Тогда тут могут помочь подробные тренинги и/или волевое решение руководства.
С другой стороны, может оказаться, что не смотря на все удобство, в некоторых случаях гибкости системы не хватает и проще позвонить или разобраться на бумажке. В этом случае сколько не дави, толку не будет.
>А потом в конце месяца тратят кучу времени и сдают «неверные» отчеты.
Судя по этой фразе, ваша система хорошо помогает людям экономить время, т.е. делать больше за меньшее время. Почему бы не задать Балде службу, чтоб стало ему невмочь, а требовать чтобы он ее исполнил точь-в-точь? Другими словами, заставить приказом сверху в короткое время сделать столько работы, что без вашей системы ее в принципе за такое время не сделаешь?
Судя по этой фразе, ваша система хорошо помогает людям экономить время, т.е. делать больше за меньшее время. Почему бы не задать Балде службу, чтоб стало ему невмочь, а требовать чтобы он ее исполнил точь-в-точь? Другими словами, заставить приказом сверху в короткое время сделать столько работы, что без вашей системы ее в принципе за такое время не сделаешь?
Какие, имхо, могут быть причины (если с ПО действительно всё так
прекрасно):
— низкая производительность труда в период освоения: думаю многие тут, на хабре, проходили через это — новый продукт (или версия старого) обещает значительные плюсы, но освоение может длиться недопустимо долго, при том что текущую работу, дедлайны и т. д., никто не отменял — «надо еще вчера»
— боязнь показаться неквалифицированным (читай тупым :) ): не может быть, как правило, всё понятно в абсолютно новой системе, но задавать вопросы многие люди не любят, предпочитают или «на бумажке» или разбираться самим (что еще больше усиливает первый пункт)
— «коллективная боязнь» потерять должность/работу или получить дополнительную нагрузку (без дополнительной мотивации): сейчас люди «как-то» справляются со своими обязанностями, если новая система увеличит производительность их труда, скажем, вдвое, то текущие ежедневные задачи они выполнят условно до обеда, а после обеда делать им будет нечего. Вероятность, что начальство этого не заметит — или заметив сочтёт это нормальным, — достаточно мала… Или будут сокращения, или увеличится количество/сложность задач.
— банальная привычка или следование принципу «работает — не трогай»
прекрасно):
— низкая производительность труда в период освоения: думаю многие тут, на хабре, проходили через это — новый продукт (или версия старого) обещает значительные плюсы, но освоение может длиться недопустимо долго, при том что текущую работу, дедлайны и т. д., никто не отменял — «надо еще вчера»
— боязнь показаться неквалифицированным (читай тупым :) ): не может быть, как правило, всё понятно в абсолютно новой системе, но задавать вопросы многие люди не любят, предпочитают или «на бумажке» или разбираться самим (что еще больше усиливает первый пункт)
— «коллективная боязнь» потерять должность/работу или получить дополнительную нагрузку (без дополнительной мотивации): сейчас люди «как-то» справляются со своими обязанностями, если новая система увеличит производительность их труда, скажем, вдвое, то текущие ежедневные задачи они выполнят условно до обеда, а после обеда делать им будет нечего. Вероятность, что начальство этого не заметит — или заметив сочтёт это нормальным, — достаточно мала… Или будут сокращения, или увеличится количество/сложность задач.
— банальная привычка или следование принципу «работает — не трогай»
да, это всё есть. и связано в первую очередь с юзабилити (теперь его уже переименовали в юзер экспириенс) продукта.
я мог бы рассказать, но… ну да, чуть ниже я уже посоветовал книгу.
как раз там ответы на вопрос «почему люди не исследуют новые возможности».
потому что всегда используют необходимый минимум (есть люди-исключения — и они чаще программисты. но не всегда).
потому что любому программисту кажется, что продукт, который он написал — удобен в использовании и всё очевидно — даже если все комманды свалены в кучу и нужную функциональность приходится выковыривать…
а пользователь не склонен ковыряться в чужих запутанных штуках — он использует то, что минимально необходимо.
я мог бы рассказать, но… ну да, чуть ниже я уже посоветовал книгу.
как раз там ответы на вопрос «почему люди не исследуют новые возможности».
потому что всегда используют необходимый минимум (есть люди-исключения — и они чаще программисты. но не всегда).
потому что любому программисту кажется, что продукт, который он написал — удобен в использовании и всё очевидно — даже если все комманды свалены в кучу и нужную функциональность приходится выковыривать…
а пользователь не склонен ковыряться в чужих запутанных штуках — он использует то, что минимально необходимо.
Первое — запретить работать вне системы.
Второе — увеличить нагрузку до невозможной при ручной работе.
Челоек странное животное. ПО это ещё объяснимо — боъязнь новизны, низкий уровень развития, лень и т д. А вот как объяснить то что человек будет весь день таскать раствор или песок вёдрами при том что в десяти метрах стоит колёсная тачка. И человек этот работает на себя.
Я думаю мы просто не умеем получать удовольствие от своей работы. Не обучены-с.
Второе — увеличить нагрузку до невозможной при ручной работе.
Челоек странное животное. ПО это ещё объяснимо — боъязнь новизны, низкий уровень развития, лень и т д. А вот как объяснить то что человек будет весь день таскать раствор или песок вёдрами при том что в десяти метрах стоит колёсная тачка. И человек этот работает на себя.
Я думаю мы просто не умеем получать удовольствие от своей работы. Не обучены-с.
> Как бороться с человеческим фактором при внедрении ПО?
Повернуть его в свою пользу.
Повернуть его в свою пользу.
Может быть оно просто не нужно? Вы так говорите, что об очевидных преимуществах и нужности, но люди не юзают, причём вне зависимости от отношения к компам/образовании.
Ведь нужность понятие субъективное. Нужно кому? Скорее всего руководству, чтобы больше пахали. А рядовому сотруднику нафиг не нужно. Меньше бумажек в день — меньше работы. Больше механической работы — меньше умственной.
Ведь нужность понятие субъективное. Нужно кому? Скорее всего руководству, чтобы больше пахали. А рядовому сотруднику нафиг не нужно. Меньше бумажек в день — меньше работы. Больше механической работы — меньше умственной.
дело в том, что любой человек (кроме любителей исследовать программы) всегда использует тот минимум возможностей, который его удовлетворяет.
и… почитайте «Психбольницу в руках пациентов» Алана Купера — это поможет понять, почему люди плохо пользуются софтом.
и… почитайте «Психбольницу в руках пациентов» Алана Купера — это поможет понять, почему люди плохо пользуются софтом.
Контрпример. Намного более простой, но все же я думаю, похоже на вашу ситуацию.
Сотрудники некоей организации производили файлообмен через расшаренную директорию на сервере. Надо передать документ — скопировал в папку другому, отзвонился и всё.
Админы решили, что это рассадник вирусов и, будучи не в силах справиться с их наплывом другими способами, решили: отныне все будут меняться файлами через внутренний почтовый сервер! Надо ли говорить, что спустя полтора года файлообмен по-прежнему производится через шару?
А почему так произошло?
Чтобы отправить другому файл, следует предпринять ряд нетривиальных для хомо офисус действий: открыть почтовый клиент, открыть сравочник адресов сотрудников, найти сотрудника в справочнике, скопировать адрес, вставить в почтовый клиент, открыть диалог добавления приложения, пробиться через дебри файловой системы чтобы найти где-то в дереве файл, прикрепить его, написать сопроводиловку, отправить.
Но при этом он не знает — осведломлен же адресат тут же о получении файла (т.е. запущен ли у него при этом почтовый клиент и получил ли он уведомление о получении)? Что он делает? Правильно — поднимает трубку и звонит чтобы сообщить о передаче.
Что нужно сделать адресату? Страдать — держать почтовый клиент запущенным. При получении файла сохранять приложение на диск, пробираясь через дебри ФС и уже потом, снова отыскав его, открывать и просматривать.
Нафиг нужно! — скажут люди и будут правы. И продолжат по старинке копировать файл в нужную папку и звонить потому что ярлык на шару у них на рабочем столе, под рукой.
Я понимаю, что в ваших системах все может быть намного более прекрасно чем в моем примере, но может быть какие-то проблемы есть?
Сотрудники некоей организации производили файлообмен через расшаренную директорию на сервере. Надо передать документ — скопировал в папку другому, отзвонился и всё.
Админы решили, что это рассадник вирусов и, будучи не в силах справиться с их наплывом другими способами, решили: отныне все будут меняться файлами через внутренний почтовый сервер! Надо ли говорить, что спустя полтора года файлообмен по-прежнему производится через шару?
А почему так произошло?
Чтобы отправить другому файл, следует предпринять ряд нетривиальных для хомо офисус действий: открыть почтовый клиент, открыть сравочник адресов сотрудников, найти сотрудника в справочнике, скопировать адрес, вставить в почтовый клиент, открыть диалог добавления приложения, пробиться через дебри файловой системы чтобы найти где-то в дереве файл, прикрепить его, написать сопроводиловку, отправить.
Но при этом он не знает — осведломлен же адресат тут же о получении файла (т.е. запущен ли у него при этом почтовый клиент и получил ли он уведомление о получении)? Что он делает? Правильно — поднимает трубку и звонит чтобы сообщить о передаче.
Что нужно сделать адресату? Страдать — держать почтовый клиент запущенным. При получении файла сохранять приложение на диск, пробираясь через дебри ФС и уже потом, снова отыскав его, открывать и просматривать.
Нафиг нужно! — скажут люди и будут правы. И продолжат по старинке копировать файл в нужную папку и звонить потому что ярлык на шару у них на рабочем столе, под рукой.
Я понимаю, что в ваших системах все может быть намного более прекрасно чем в моем примере, но может быть какие-то проблемы есть?
именно так.
юзабилити (вернее, хреновое узабилити) — это основная причина, по которой пользователи отказываются от ПО.
но некоторые компании гораздо внимательнее подходятк этому вопросу.
и, да, количество кликов мышкой (и вообще, количество действий) — это критический фактор. всегда — чем меньше — тем лучше (второй важнейший фактор — это наличие необходимой пользователю информации и отсутствие того, что ему не нужно).
в одном интернет-магазине (большом) внедряли покупку одним кликом.
и программист по привычке после клика «купить» сделал запрос «вы уверены, что хотите купить?».
программисту дали по ушам — ведь было уже два клика.
юзабилити (вернее, хреновое узабилити) — это основная причина, по которой пользователи отказываются от ПО.
но некоторые компании гораздо внимательнее подходятк этому вопросу.
и, да, количество кликов мышкой (и вообще, количество действий) — это критический фактор. всегда — чем меньше — тем лучше (второй важнейший фактор — это наличие необходимой пользователю информации и отсутствие того, что ему не нужно).
в одном интернет-магазине (большом) внедряли покупку одним кликом.
и программист по привычке после клика «купить» сделал запрос «вы уверены, что хотите купить?».
программисту дали по ушам — ведь было уже два клика.
Обмен через шару удобнее, чем через почту.
Проблема-то была в вирусах, и решать нужно было именно её?
Например: лишить всех пользователей администраторских прав, запретить запись в Program Files и системные каталоги, запретить запуск приложений откуда-либо кроме папок Windows и Program Files, поставить всем антивирусы, сделать выход в интернет только через прокси, на котором блокировать нежелательный контент и IE, установить всем Firefox (юристам оставить IE но только для сайта консультанта и других нужных для работы, которые не поддерживают Firefox).
Работаю уже во второй крупной (тысячи сотрудников) компании — никогда не слышали ни о каких вирусах.
Проблема-то была в вирусах, и решать нужно было именно её?
Например: лишить всех пользователей администраторских прав, запретить запись в Program Files и системные каталоги, запретить запуск приложений откуда-либо кроме папок Windows и Program Files, поставить всем антивирусы, сделать выход в интернет только через прокси, на котором блокировать нежелательный контент и IE, установить всем Firefox (юристам оставить IE но только для сайта консультанта и других нужных для работы, которые не поддерживают Firefox).
Работаю уже во второй крупной (тысячи сотрудников) компании — никогда не слышали ни о каких вирусах.
Кстати, а вы просили самих работников письменно запротоколировать их аргументы против использования ПО? Пусть напишут сочинения на тему «как я использую новую систему в работе, как она экономит мое рабочее время и что в ней не так».
мне кажется, они не смогут честно ответить.
потому что с большой вероятностью честный ответ будет таким:
ПО такое мутное… я в нем не разбираюсь — что означает, что пользователю просто неудобна и непонятна работа в данном ПО.
потому что с большой вероятностью честный ответ будет таким:
ПО такое мутное… я в нем не разбираюсь — что означает, что пользователю просто неудобна и непонятна работа в данном ПО.
В таком случае поможет анонимный опрос, что бы понять суть проблемы.
скорее — внимательное исследование.
потому что часто человек и сам не может пояснить, что именно мутного в данном ПО.
и дальше уже смотреть.
если человек в каком-то месте подвисает — ищет, куда тыкнуть — значит мутная навигация и, возможно, перегрузка функциями.
если для того, чтобы научится работать надо прочитать килограммы доков — значит точно мутная навигация.
ну и так далее.
потому что часто человек и сам не может пояснить, что именно мутного в данном ПО.
и дальше уже смотреть.
если человек в каком-то месте подвисает — ищет, куда тыкнуть — значит мутная навигация и, возможно, перегрузка функциями.
если для того, чтобы научится работать надо прочитать килограммы доков — значит точно мутная навигация.
ну и так далее.
Полностью согласен. :)
Но если есть возможность полноценного юзабилити-тестирования, то по правильному оно явно должно быть проведено на этапе прототипа, а не когда «после внедрения продукт вдруг не идет».
А тут уж, если встали на грабли и ресурсов уже нет — то можно попробовать хотя бы опросом.
Вообще, в целом, в исходной задаче поста — недостаточно данных что бы дать толковые советы в конкретном случае.
Но если есть возможность полноценного юзабилити-тестирования, то по правильному оно явно должно быть проведено на этапе прототипа, а не когда «после внедрения продукт вдруг не идет».
А тут уж, если встали на грабли и ресурсов уже нет — то можно попробовать хотя бы опросом.
Вообще, в целом, в исходной задаче поста — недостаточно данных что бы дать толковые советы в конкретном случае.
eyetracking вам в помощь (как один из этапов) — с интерфейсом во всяком случае сможет помочь
«Смею заверить, что это не так, и все процессы, интерфейс уже давно вылизаны до блеска, оттестированы, опробованы ответственными лицами»
Если ответственные лица — это руководство, то это ни о чем не говорит. Часто бывает, что видение руководства сильно отличается от видения рядовых сотрудников.
На словах сотрудники могут говорить, что выгода есть. Но по факту — вряд ли это так. Рядовым сотрудникам от того, что они сэкономят время и не будут бегать с бумажками — никакой выгоды нет. Платить то им будут так же, а напрягаться придется больше. Так что действительно нужно не оставлять альтернатив, как уже предлагали выше.
Если ответственные лица — это руководство, то это ни о чем не говорит. Часто бывает, что видение руководства сильно отличается от видения рядовых сотрудников.
На словах сотрудники могут говорить, что выгода есть. Но по факту — вряд ли это так. Рядовым сотрудникам от того, что они сэкономят время и не будут бегать с бумажками — никакой выгоды нет. Платить то им будут так же, а напрягаться придется больше. Так что действительно нужно не оставлять альтернатив, как уже предлагали выше.
Стоит заметить что на стороне ретроградов стоит убийственный аргумент размером с гору Фудзи
ТАК ВЕДЬ РАБОТАЕТ!
И для того чтобы что-то менять когда всё работает необходимо иметь или волю или финансовую заинтерисованность для формирования воли.
Хорошо в Китае — расстреляли пару сотрудников за рисование табличек в word. Остальные уже интегрируют excell объектом.
Вот ещё вспомнил — у меня такое впечатление что я один в мире центрирую текст с помошью форматирования «выравять по центру» а не пробелами.
ТАК ВЕДЬ РАБОТАЕТ!
И для того чтобы что-то менять когда всё работает необходимо иметь или волю или финансовую заинтерисованность для формирования воли.
Хорошо в Китае — расстреляли пару сотрудников за рисование табличек в word. Остальные уже интегрируют excell объектом.
Вот ещё вспомнил — у меня такое впечатление что я один в мире центрирую текст с помошью форматирования «выравять по центру» а не пробелами.
Если вашим софтом не пользуются, значит ваш софт — говно. Если софт хороший, удобный и повышает продуктивность, то не нужно придумывать административно-принудительных путей для его внедрения, люди итак будут им пользоваться.
Просто пишите удобный, интуитивно понятный софт, спрашивайте пользователей как им удобнее и делайте именно так, постоянно отслеживайте в каких модулях происходит торможение. Ведь вы же пишете для людей, а не вопреки им…
После прочтения данного поста живо представил себе убогие софтины какие используются в гос структурах. Их пишут студенты просто чтобы отбить бабла, соответственно пользоваться ими в 99% случаев банально невозможно.
Просто пишите удобный, интуитивно понятный софт, спрашивайте пользователей как им удобнее и делайте именно так, постоянно отслеживайте в каких модулях происходит торможение. Ведь вы же пишете для людей, а не вопреки им…
После прочтения данного поста живо представил себе убогие софтины какие используются в гос структурах. Их пишут студенты просто чтобы отбить бабла, соответственно пользоваться ими в 99% случаев банально невозможно.
часто софт пишут для денег. :)
добавлюсь.
«много всевозможной функциональности» — это не то, что нужно.
пользователю нужен обычно весьма конкретный список функциональности. всё что сверх него (чем он не пользуется, но что есть в ПО «чтоб было» — загромождает и снижает удобство использования ПО).
добавлюсь.
«много всевозможной функциональности» — это не то, что нужно.
пользователю нужен обычно весьма конкретный список функциональности. всё что сверх него (чем он не пользуется, но что есть в ПО «чтоб было» — загромождает и снижает удобство использования ПО).
Вот вы легко перешли с 2003 офиса на 2007?
Интерфейс в новом офисе стал интуитивнее, но привычка-то осталась…
И ведь работало все и в 2003…
Интерфейс в новом офисе стал интуитивнее, но привычка-то осталась…
И ведь работало все и в 2003…
Кстати, лично я до сих пор 2003 использую. Пока работает обратная совместимость банально не вижу смысла переходить.
я легко перешел на OpenOffice.org и гуглодоки. пару раз пришлось столкнуться с кактусом '07 по служебной необходимости, но впечатления крайне негативные остались и я был рад когда такая необходимость отпала.
Возможно, вы нафантазировали в своих use cases такого, чего никогда не могло произойти в автоматизируемой организации. Если людям удобнее бегать с бумажками, то максимум, что можно сделать — внедрить в организацию средства митинговой колаборации: выдать ноуты, разместить в «рыбных местах» интранет-киоски, сделать доску с видеокамерой в переговорке. На худой конец, сделать, что бы формочки в вашем приложении можно было бы заполнять коллективно в реальном времени (не модально).
По себе сужу: разные системы issue трекинга у меня не приживаются, т.к. каждая заточена на одну конкретную задачу. Даже комбайны вроде trac и redmine лучше подходят для итераций разработки системного ПО, а не, скажем, развесистого дерева исходников приличного вебсайта (для контраста можно упомянуть вики-системы, которые можно использовать для множества целей, т.к. они универсальны). Вот и получается, что 10 системщиков решат: «trac это здорово», остальные посмотрят и скажут: «да, здорово!», только корпоративной CRM`ки/планировщика из этого не получится — слишком разнородные задачи. А что бы получилось, надо предусматривать возможность подключения к системе по открытым протоколам других пользовательских программ, которые больше подходят «остающимся за бортом». Для примера взгляните, как поступили яндексовцы со своими переговорками: habrahabr.ru/company/yandex/blog/77540/.
Отвечая на вопрос, выведенный в заголовок: с человеческим фактором не нужно бороться. Его надо просто учитывать.
По себе сужу: разные системы issue трекинга у меня не приживаются, т.к. каждая заточена на одну конкретную задачу. Даже комбайны вроде trac и redmine лучше подходят для итераций разработки системного ПО, а не, скажем, развесистого дерева исходников приличного вебсайта (для контраста можно упомянуть вики-системы, которые можно использовать для множества целей, т.к. они универсальны). Вот и получается, что 10 системщиков решат: «trac это здорово», остальные посмотрят и скажут: «да, здорово!», только корпоративной CRM`ки/планировщика из этого не получится — слишком разнородные задачи. А что бы получилось, надо предусматривать возможность подключения к системе по открытым протоколам других пользовательских программ, которые больше подходят «остающимся за бортом». Для примера взгляните, как поступили яндексовцы со своими переговорками: habrahabr.ru/company/yandex/blog/77540/.
Отвечая на вопрос, выведенный в заголовок: с человеческим фактором не нужно бороться. Его надо просто учитывать.
По первому пункту — все так и должно быть, простое правило Паретто, у вас как раз и выходит что из вашего ПО 20% идет на пользу, а 80% остальное прикрывает тыл.
Только даже думать не смейте что софт гавно, это не так, просто есть такое правило…
Сам с этим сталкивался
Только даже думать не смейте что софт гавно, это не так, просто есть такое правило…
Сам с этим сталкивался
В свое время в одной из фирм-клиентов был настоящий саботаж. Сотрудники не хотели работать ни в какую. Придумывали разные причины (от «не умею, не показывали» до «пробовала, не работает»).
Итог внедрения — около 10 докладных со стороны внедренцев и примерно такое же количество со стороны сотрудников компании-клиента. Трое уволенных. Жестоко, но либо нас либо их :)
Итог: ПО внедрено, работа около 3-4 лет, сотрудники довольны, к бумажной работе возвращаться не хотят.
Итог внедрения — около 10 докладных со стороны внедренцев и примерно такое же количество со стороны сотрудников компании-клиента. Трое уволенных. Жестоко, но либо нас либо их :)
Итог: ПО внедрено, работа около 3-4 лет, сотрудники довольны, к бумажной работе возвращаться не хотят.
Возможно, дело не только в интерфейсе, но и в неизбежно изменяющейся логике выполнения работы.
Пример: ПО позволяет (кроме прочего) по нажатию одной кнопки сформировать огромную спецификацию оборудования. Часть сотрудников продолжают делать это вручную (тупо копировать в ворд тысячи строк).
Причина: для того, чтобы всё сработало автоматически, надо всё-таки напрячься — внести оборудование в справочник. Внести тоже автоматически, через экспорт, но дело в том, что сначала надо понять, в какой раздел вносить. То есть, людям надо структурировать оборудование, с которым они работают каждый день. А это требует напряжения. Куда как проще потратить день на копирование строчек — никакого дискомфорта и человека даже нельзя назвать бездельником — он же трудится.
Пример: ПО позволяет (кроме прочего) по нажатию одной кнопки сформировать огромную спецификацию оборудования. Часть сотрудников продолжают делать это вручную (тупо копировать в ворд тысячи строк).
Причина: для того, чтобы всё сработало автоматически, надо всё-таки напрячься — внести оборудование в справочник. Внести тоже автоматически, через экспорт, но дело в том, что сначала надо понять, в какой раздел вносить. То есть, людям надо структурировать оборудование, с которым они работают каждый день. А это требует напряжения. Куда как проще потратить день на копирование строчек — никакого дискомфорта и человека даже нельзя назвать бездельником — он же трудится.
Напишите простую, понятную инструкцию на 1 странице 14-м шрифтом, не используя сложносочиненные предложения и специальную терминологию и разошлите ее всем сотрудникам. Хорошо еще дополнить эту инструкцию сопроводительным письмом из 1 параграфа о том, что используя ваше ПО, можно сократить время выполнения каких-либо служебных заданий. И люди к Вам потянутся :)
Убейте человеков!
Автору статьи, Привет!
Я в шоке!
Вы посмотрите, как вопрос ставите: «Как бороться с человеческим фактором при внедрении ПО?»
Создается впечатление, что пишет не человек, а робот по внедрению ПО.
Не нужно бороться. Люди не хотят использовать, то что начальство с вашей подачи им навязывает. Они не хотят прямо заявлять и обосновывать свою позицию, раскрываться, потому что не чувствуют себя в безопасности. Не видят, что копания защищает их и заботиться. Она этого и не делает. Они формально выполняют требования сверху и ждут очередной зарплаты, Они пришли работать за деньги, и не получают возможности для самореализации. Им безразличен результат их коллективного труда. Они несчастны.
Виноват организатор этого процесса и все спящие участники.
Тут ещё приходите вы, со своим ПО. Внедрен… слов нет. Люди едва приспособились к их ежедневному быту за мониторами, а тут снова, зачем? Они не заинтересованы, Вы навязываете им.
И потом вы называете их поведение «человеческим фактором». Такое положение не красит их. Они спят, но они люди. А вы? Их руководству вы втюхали свои продукты, услуги, вот только рабы есть это отказываются. Человеческий фактор — это всё, что имеет смысл. С ним нужно не бороться, его нужно найти и развивать. Вся эта хоботня для людей, или для внедрения ПО? Кто б… цель, а что средства?
Скайнет 2009: «надо что-то делать с человеческим фактором? Потребители совсем не потребляют наш, чудо-товар, они даже купят, а не едят, вот гады.»
Автор, проснись уже.
Всего хорошего!
Ф
Я в шоке!
Вы посмотрите, как вопрос ставите: «Как бороться с человеческим фактором при внедрении ПО?»
Создается впечатление, что пишет не человек, а робот по внедрению ПО.
Не нужно бороться. Люди не хотят использовать, то что начальство с вашей подачи им навязывает. Они не хотят прямо заявлять и обосновывать свою позицию, раскрываться, потому что не чувствуют себя в безопасности. Не видят, что копания защищает их и заботиться. Она этого и не делает. Они формально выполняют требования сверху и ждут очередной зарплаты, Они пришли работать за деньги, и не получают возможности для самореализации. Им безразличен результат их коллективного труда. Они несчастны.
Виноват организатор этого процесса и все спящие участники.
Тут ещё приходите вы, со своим ПО. Внедрен… слов нет. Люди едва приспособились к их ежедневному быту за мониторами, а тут снова, зачем? Они не заинтересованы, Вы навязываете им.
И потом вы называете их поведение «человеческим фактором». Такое положение не красит их. Они спят, но они люди. А вы? Их руководству вы втюхали свои продукты, услуги, вот только рабы есть это отказываются. Человеческий фактор — это всё, что имеет смысл. С ним нужно не бороться, его нужно найти и развивать. Вся эта хоботня для людей, или для внедрения ПО? Кто б… цель, а что средства?
Скайнет 2009: «надо что-то делать с человеческим фактором? Потребители совсем не потребляют наш, чудо-товар, они даже купят, а не едят, вот гады.»
Автор, проснись уже.
Всего хорошего!
Ф
Хоть отношения к делу не имеет, но продукт заказчик сам попросил установить.
И по формулировке «бороться с человеческим фактором» — возможно, нужно было написать «Как бороться с нежеланием сотрудников работать во внедренном ПО?», так наверное более четко звучит вопрос.
Идеальный вариант — пришли, установили, обучили, начали работать — возникли вопросы / пожелания — доработали софт — работаем спокойно. Все сыты и целы.
Реальный вариант — пришли, установили, обучили, заглохло…
Мой вопрос в том — что именно нужно делать, чтобы процесс пошел так как нужно. А бороться, действительно бесполезно :)
И по формулировке «бороться с человеческим фактором» — возможно, нужно было написать «Как бороться с нежеланием сотрудников работать во внедренном ПО?», так наверное более четко звучит вопрос.
Идеальный вариант — пришли, установили, обучили, начали работать — возникли вопросы / пожелания — доработали софт — работаем спокойно. Все сыты и целы.
Реальный вариант — пришли, установили, обучили, заглохло…
Мой вопрос в том — что именно нужно делать, чтобы процесс пошел так как нужно. А бороться, действительно бесполезно :)
если будет время — почитайте «Записки Автоматизатора» ag-orlov.narod.ru/itnotes.htm
Это очень полезная книга. Она же есть в печатном виде. Там есть всё о чём вы пишете.
Писал человек с огромным стажем работы. Не поленитесь хотя бы пробежаться по ней глазами.
Это очень полезная книга. Она же есть в печатном виде. Там есть всё о чём вы пишете.
Писал человек с огромным стажем работы. Не поленитесь хотя бы пробежаться по ней глазами.
Опыт показывает, что одним из главных критериев успешности внедрения ИТ-проекта является руководство.
Если руководитель адекватный, более того, требующий работать так и только так, и не делающий исключений ни для кого, успех будет.
Если же руководитель через месяц-другой забывает/забивает, то сотрудники чуют это особым нюхом сотрудника и тоже втихаря забивают… А если еще появляются исключения в виде любимчиков/любовниц/родственников…
Если руководитель адекватный, более того, требующий работать так и только так, и не делающий исключений ни для кого, успех будет.
Если же руководитель через месяц-другой забывает/забивает, то сотрудники чуют это особым нюхом сотрудника и тоже втихаря забивают… А если еще появляются исключения в виде любимчиков/любовниц/родственников…
Был опыт разработки и внедрения CRM, пользовались почти все сотрудники. Компания не особо грамотная в компьютерах (около 60-70 чел.)
Ну и несколько вещей я для подчерпнул для себя, которые были уже озвучены в комментах выше:
1) Огромным плюсом будет вовлечь сотрудников в процесс разработки, показывать этапы работы, какие-то готовые модули, обсуждать с ними. Причем не только с начальством, а именно с теми кто будет постоянно пользоваться. Человек внесший свой вклад (пусть даже своим мнением и советами) будет уже по другому относиться к данному продукту. Ну это больше психологический момент.
2) Организационный момент. Сделать процесс работы в компании зависимым от ПО. В моем случае, менеджерам выдавались ключи на корпоративные авто (для встреч с клиентами) только по специальной заявки из CRM. А заявка представляла собой просто задачу на встречу в планировщике. Таким образом менеджеры научились пользоваться планировщиком. Далее им стало удобно видеть свои встречи и планировать их вперед на неделю.
3) Еще способ. Call-центр получал бонусы за количество отработанных звонков на основании отчетов, которые формировались в CRM по итогам отчетных дат. Но сразу оговорюсь, что именно модуль call-центра вылизывался вместе с сотрудниками, мы спрашивали, советовались, что удобно, что нет, где много тратиться времени на ввод в систему звонка. Итог: сотрудники при входящем звонке уже не использовали ручки и бумажки ))) а сразу вводили данные в CRM.
4) Хороший модуль отчетности для руководства компании. Но об этом много написано уже.
Ну и несколько вещей я для подчерпнул для себя, которые были уже озвучены в комментах выше:
1) Огромным плюсом будет вовлечь сотрудников в процесс разработки, показывать этапы работы, какие-то готовые модули, обсуждать с ними. Причем не только с начальством, а именно с теми кто будет постоянно пользоваться. Человек внесший свой вклад (пусть даже своим мнением и советами) будет уже по другому относиться к данному продукту. Ну это больше психологический момент.
2) Организационный момент. Сделать процесс работы в компании зависимым от ПО. В моем случае, менеджерам выдавались ключи на корпоративные авто (для встреч с клиентами) только по специальной заявки из CRM. А заявка представляла собой просто задачу на встречу в планировщике. Таким образом менеджеры научились пользоваться планировщиком. Далее им стало удобно видеть свои встречи и планировать их вперед на неделю.
3) Еще способ. Call-центр получал бонусы за количество отработанных звонков на основании отчетов, которые формировались в CRM по итогам отчетных дат. Но сразу оговорюсь, что именно модуль call-центра вылизывался вместе с сотрудниками, мы спрашивали, советовались, что удобно, что нет, где много тратиться времени на ввод в систему звонка. Итог: сотрудники при входящем звонке уже не использовали ручки и бумажки ))) а сразу вводили данные в CRM.
4) Хороший модуль отчетности для руководства компании. Но об этом много написано уже.
расскажите о своем опыте внедрения CRM в колл-центре, интересует надо ли было вводить номер звонившего и время и длительность звонка, что добавили, что убрали?
Все довольно просто и банально:
CRM была основана на тонком клиенте (PHP, база и т.п.)
В компании стояла телефония от Cisco, которая могла запускать окно браузера на компьютере оператора call-центра c определенным номером звонившего в виде GET.
что-то типа crm/operator.php?number=89261232233
(Соответсвенно номер не надо было вводить руками)
а скрипт operator.php уже отрабатывал дальше все остальное, лез в базу, искал клиента или организацию. Если находил выводил информацию о нем, предлагал зафиксировать звонок. Если не находил, то открывал карточку заведения нового клиента и фиксации звонка.
Отчеты можно было смотреть из самой Cisco, там есть такой функционал (в циске не силен) — отчеты по длительности звонков и т.п., либо в самой CRM уже.
CRM была основана на тонком клиенте (PHP, база и т.п.)
В компании стояла телефония от Cisco, которая могла запускать окно браузера на компьютере оператора call-центра c определенным номером звонившего в виде GET.
что-то типа crm/operator.php?number=89261232233
(Соответсвенно номер не надо было вводить руками)
а скрипт operator.php уже отрабатывал дальше все остальное, лез в базу, искал клиента или организацию. Если находил выводил информацию о нем, предлагал зафиксировать звонок. Если не находил, то открывал карточку заведения нового клиента и фиксации звонка.
Отчеты можно было смотреть из самой Cisco, там есть такой функционал (в циске не силен) — отчеты по длительности звонков и т.п., либо в самой CRM уже.
Все очень просто в Вашем случае:
Сотрудники (а может и руководство) не чувствуют ценности программного решения для себя. То есть Вы прикрутили им ручку, а они не знают зачем они должны ее крутить. Ну а Вы расстраиваетесь, соответственно.
Выход следующий:
1. Определить бизнес-процесс который поддерживает Ваш софт. Определить значит нарисовать.
2. Определить роли сотрудников внутри этого процесса, то есть определить действия сотрудников и их ответственности.
3. Определить необходимую квалификацию сотрудников относительно их действий и ответственностей, определить критерии оценки квалификации при подборе сотрудников
4. Определить нормативы выполнения операций в процессах (здесь должен быть применен консервативный подход — в расчете на самого медленного сотрудника — пусть умные и быстрые больше отдыхают или занимаются своим развитием).
5. Нужно привести в соответствие систему оплаты работников с нормативами процессов, что бы человек точно знал последовательность МОЯ ОТВЕТСТВЕННОСТЬ — МОИ ДЕЙСТВИЯ К ЕЕ РЕАЛИЗАЦИИ — МОЙ ДОХОД (вместо дохода можно поставить все что угодно — знаете, некоторым нравятся грамоты и вымпелы).
6. Я не буду писать о том как процессы рисовать — это целая профессия, но по первости выше указанный алгоритм можно раз 5 пройти по кругу, когда например выяснится, что с такими требованиями к квалификации за имеющуюся з/п никто работать в жизни не согласится.
6а. По хорошему, в грамотных организациях еще проходит асессмент всех нынешних работников на предмет соответствия новым процессам с дальнейшим решением — учить или увольнять и искать новых.
Заметьте пока ничего от софте — это все управленческая часть и может быть сделана сторонними консультантами (если в организации такой функции нет).
Теперь когда все сделали, нужно сформировать требования к ПО, на основании бизнес процессов, выбрать поставщика, собрать команду проекта, сделать дизайн-сессии, поправить код, протестировать и.т.д.
А вот внедрять продукт надо отдать бизнесу (или отделу пользователю) и при этом нужно сначала донести до конечных исполнителей все то что было нарисовано в первой части. Тогда у людей будет понимание, что вот это ПО мне лично помогает денежки зарабатывать. Иногда при этом уменьшают кол-во работников или например ужесточают нормативы (только разумно и обоснованно).
А по другому ни как…
Обычно все решается если поработать с менеджментом и задать им вопрос про продуктивность сотрудников, benchmarking и.т.д. Вот тогда начинается настоящий операционный менеджмент, а не РУКО водство (при всей моей любви к русскому языку). Вы думаете у нас зря что ли продуктивность труда такая низкая в стране? Это потому что ни кто не следит за эффективностью — а ведь это главное в любом бизнесе, и ПО как продукт как правило и решает эту задачу — повышение эффективности. А эффективность это что — это отношение усилий к полученному результату.
Если хотите больше деталей — welcome!
Сотрудники (а может и руководство) не чувствуют ценности программного решения для себя. То есть Вы прикрутили им ручку, а они не знают зачем они должны ее крутить. Ну а Вы расстраиваетесь, соответственно.
Выход следующий:
1. Определить бизнес-процесс который поддерживает Ваш софт. Определить значит нарисовать.
2. Определить роли сотрудников внутри этого процесса, то есть определить действия сотрудников и их ответственности.
3. Определить необходимую квалификацию сотрудников относительно их действий и ответственностей, определить критерии оценки квалификации при подборе сотрудников
4. Определить нормативы выполнения операций в процессах (здесь должен быть применен консервативный подход — в расчете на самого медленного сотрудника — пусть умные и быстрые больше отдыхают или занимаются своим развитием).
5. Нужно привести в соответствие систему оплаты работников с нормативами процессов, что бы человек точно знал последовательность МОЯ ОТВЕТСТВЕННОСТЬ — МОИ ДЕЙСТВИЯ К ЕЕ РЕАЛИЗАЦИИ — МОЙ ДОХОД (вместо дохода можно поставить все что угодно — знаете, некоторым нравятся грамоты и вымпелы).
6. Я не буду писать о том как процессы рисовать — это целая профессия, но по первости выше указанный алгоритм можно раз 5 пройти по кругу, когда например выяснится, что с такими требованиями к квалификации за имеющуюся з/п никто работать в жизни не согласится.
6а. По хорошему, в грамотных организациях еще проходит асессмент всех нынешних работников на предмет соответствия новым процессам с дальнейшим решением — учить или увольнять и искать новых.
Заметьте пока ничего от софте — это все управленческая часть и может быть сделана сторонними консультантами (если в организации такой функции нет).
Теперь когда все сделали, нужно сформировать требования к ПО, на основании бизнес процессов, выбрать поставщика, собрать команду проекта, сделать дизайн-сессии, поправить код, протестировать и.т.д.
А вот внедрять продукт надо отдать бизнесу (или отделу пользователю) и при этом нужно сначала донести до конечных исполнителей все то что было нарисовано в первой части. Тогда у людей будет понимание, что вот это ПО мне лично помогает денежки зарабатывать. Иногда при этом уменьшают кол-во работников или например ужесточают нормативы (только разумно и обоснованно).
А по другому ни как…
Обычно все решается если поработать с менеджментом и задать им вопрос про продуктивность сотрудников, benchmarking и.т.д. Вот тогда начинается настоящий операционный менеджмент, а не РУКО водство (при всей моей любви к русскому языку). Вы думаете у нас зря что ли продуктивность труда такая низкая в стране? Это потому что ни кто не следит за эффективностью — а ведь это главное в любом бизнесе, и ПО как продукт как правило и решает эту задачу — повышение эффективности. А эффективность это что — это отношение усилий к полученному результату.
Если хотите больше деталей — welcome!
Еще два слова по тому что Вы пытались сделать:
Что пытались делать:
а) убеждать сотрудников, показывать им выгоды, обучать лично каждого и отвечать на все вопросы
>>> Убеждать бессмысленно, это своего рода насилие, как и уговаривать. У человека есть натуральный механизм (встроенный так сказать) — механизм приспособления. Так вот, убеждать не надо, надо изменить условия в которых он работает, что бы он понял, что ему нужно приспособится под них и Ваше ПО это то что ему в этом поможет. В умных книгах это называется «продать идею». Для этого надо обратиться к истокам решения — зачем нужно новое ПО? Какие цели его установки? Если удобство пользователей — то тут сколько людей столько мнений, а если скорость операций то это уже более конкретно — было 3 часа (бумажку напечатать, положить в ящик, найти, сходить к Вале, покурить по дороге, по трындеть по пути, посидеть в очереди и.т.д.), а можно за 5 минут. Так надо и посчитать сколько нужно людей если все по 5 минут. И решить — я хочу по 5 минут, сделаю Вам такой софт и отдел сокращу, а лишних перепрофилирую или уволю. Поставить задачу начальнику отдела и сотрудникам. Сказать — мы будем более эффективны сможем зарабатывать больше а тратить меньше, всем кто в итоге останется повысим зарплату. Будут помогать, еще как, будет лучше. Но надо быть готовым поделится своими успехами с сотрудниками потому что те кто вам поможет во внедрении — они главнее вас, они дадут возможность заработать больше. А если их кинете, то вообще останетесь у разбитого корыта.
б) делать спец.отчетность для руководства, чтобы было видно, кто работает в системах а кто нет — и можно было принимать решения.
>>> Это то же из серии РУКОводства — это борьба со следствием, а не с проблемой. Руководство не смогло продать идею сотрудникам, так будем лупить тех кто не купился. В таком случае лучше заменить руководство поскольку грош ему цена если не может менять поведение работников, оно тогда не руководство, а бюджетные контролеры и распределители ресурсов.
в) разговаривать с руководством… Хотя что их-то убеждать? Они заказали и оплатили это ПО. Самое главное у них желание, возможности есть, в том числе возможности «кнута и пряника». Собираются планерки, ставятся задачи, сроки… а «воз и ныне там».
>>> А это потому что они думают, что для того что бы быть руководителем достаточно денег много, кабинет, визитки и водилу в лексусе. Если они сами не понимают зачем ПО купили, и как это на бизнес повлияет, то чего их убеждать. А если понимают, но рассказать сотрудникам не могут, то та же история, а если рассказать могут но сотрудники не понимают, то то же не фонтан — что же набрали таких тупеньких… В таком раскладе, лучше деньги забрать за работу да и раскланяться, а название компании в презентации вставить.
Что пытались делать:
а) убеждать сотрудников, показывать им выгоды, обучать лично каждого и отвечать на все вопросы
>>> Убеждать бессмысленно, это своего рода насилие, как и уговаривать. У человека есть натуральный механизм (встроенный так сказать) — механизм приспособления. Так вот, убеждать не надо, надо изменить условия в которых он работает, что бы он понял, что ему нужно приспособится под них и Ваше ПО это то что ему в этом поможет. В умных книгах это называется «продать идею». Для этого надо обратиться к истокам решения — зачем нужно новое ПО? Какие цели его установки? Если удобство пользователей — то тут сколько людей столько мнений, а если скорость операций то это уже более конкретно — было 3 часа (бумажку напечатать, положить в ящик, найти, сходить к Вале, покурить по дороге, по трындеть по пути, посидеть в очереди и.т.д.), а можно за 5 минут. Так надо и посчитать сколько нужно людей если все по 5 минут. И решить — я хочу по 5 минут, сделаю Вам такой софт и отдел сокращу, а лишних перепрофилирую или уволю. Поставить задачу начальнику отдела и сотрудникам. Сказать — мы будем более эффективны сможем зарабатывать больше а тратить меньше, всем кто в итоге останется повысим зарплату. Будут помогать, еще как, будет лучше. Но надо быть готовым поделится своими успехами с сотрудниками потому что те кто вам поможет во внедрении — они главнее вас, они дадут возможность заработать больше. А если их кинете, то вообще останетесь у разбитого корыта.
б) делать спец.отчетность для руководства, чтобы было видно, кто работает в системах а кто нет — и можно было принимать решения.
>>> Это то же из серии РУКОводства — это борьба со следствием, а не с проблемой. Руководство не смогло продать идею сотрудникам, так будем лупить тех кто не купился. В таком случае лучше заменить руководство поскольку грош ему цена если не может менять поведение работников, оно тогда не руководство, а бюджетные контролеры и распределители ресурсов.
в) разговаривать с руководством… Хотя что их-то убеждать? Они заказали и оплатили это ПО. Самое главное у них желание, возможности есть, в том числе возможности «кнута и пряника». Собираются планерки, ставятся задачи, сроки… а «воз и ныне там».
>>> А это потому что они думают, что для того что бы быть руководителем достаточно денег много, кабинет, визитки и водилу в лексусе. Если они сами не понимают зачем ПО купили, и как это на бизнес повлияет, то чего их убеждать. А если понимают, но рассказать сотрудникам не могут, то та же история, а если рассказать могут но сотрудники не понимают, то то же не фонтан — что же набрали таких тупеньких… В таком раскладе, лучше деньги забрать за работу да и раскланяться, а название компании в презентации вставить.
Просто большинство людей не хотят быть винтиками в системе. Не хотят становиться рабами алгоритмов, даже если это является требованием эффективности. Людям нравится ощущать, что они контролируют процесс и результаты своего труда, а не процесс контролирует их.
На самом деле, весь «человеческий фактор» сводится к трем понятиям: лень, привычка и инертность мышления. И пусть интерфейс вашего продукта проектировал сам Артем Лебедев, но если конечные пользователи вашей системы привыкли за годы своей работы бегать с бумажками по коридорам, решать все вопросы лично или по телефону, то вам будет очень сложно заставить их пользоваться новым ПО. Дело даже не в том, что они не видят преимуществ по сравнению со старым процессом. Нет. Людям просто тупо лень. Они не хотят менять свои привычки и напрягать мозг там, где раньше этого делать не приходилось. Стоит просто признаться в том, что большинство людей большие консерваторы. Мы держимся за старые, привычные вещи и боимся всего нового и пока неизвестного.
Принуждение — вот единственный выход из этой проблемы.
Принуждение — вот единственный выход из этой проблемы.
Как бороться:
1. Сделать продукт, который будет решать задачи пользователя
2. Продумать интерфейс — четкие и небольшие подсказки — половина успеха использования. Если надо две кнопки для решения задачи — значит надо сделать только две кнопки. Если требуется текстовый редактор — то такой, который печатает текст, а не аля вектор-растро-супер-3д-редактор, в котором кое где можно печатать текст. Если требуется файлообменник — то настроить две папки для передачи не так трудно. Для оповещения о том, что в какой-то папке появился файл, используются программки. Сам такую юзал в офисе, когда занимался версткой (при поступлении файла в папке !Inbox выскакивало окно.
3. Ограничение в рамках операционки, но с возможностью отписать админам о своих мыслях. Простым языком — обратная связь.
4. Продумать альтернативу — иногда вроде бы нелогичные с точки зрения разработчика почему-то чаще используются пользователями.
И еще — необходимо посмотреть как работает работник прежде чем внедрять ПО.
1. Сделать продукт, который будет решать задачи пользователя
2. Продумать интерфейс — четкие и небольшие подсказки — половина успеха использования. Если надо две кнопки для решения задачи — значит надо сделать только две кнопки. Если требуется текстовый редактор — то такой, который печатает текст, а не аля вектор-растро-супер-3д-редактор, в котором кое где можно печатать текст. Если требуется файлообменник — то настроить две папки для передачи не так трудно. Для оповещения о том, что в какой-то папке появился файл, используются программки. Сам такую юзал в офисе, когда занимался версткой (при поступлении файла в папке !Inbox выскакивало окно.
3. Ограничение в рамках операционки, но с возможностью отписать админам о своих мыслях. Простым языком — обратная связь.
4. Продумать альтернативу — иногда вроде бы нелогичные с точки зрения разработчика почему-то чаще используются пользователями.
И еще — необходимо посмотреть как работает работник прежде чем внедрять ПО.
а вот тут ответы на многие ваши Вопросы :)
habrahabr.ru/blogs/ui_design_and_usability/77681/
habrahabr.ru/blogs/ui_design_and_usability/77681/
Еще раз перечитал название поста и понял в чем проблема. Как можно бороться с человеческим фактором если Вы делаете продукт для людей?
Это все равно что:
— Как бороться с клиентами ресторана если они покупают еду и не доедают и говорят что она гадкая?
— Как бороться с клиентами больницы если они мрут как мухи в процессе лечения?
:)
Это все равно что:
— Как бороться с клиентами ресторана если они покупают еду и не доедают и говорят что она гадкая?
— Как бороться с клиентами больницы если они мрут как мухи в процессе лечения?
:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как бороться с человеческим фактором при внедрении ПО?