Устал биться головой об стену! Сотрудники организаций, в которых мы внедряем ПО, не используют его возможности полностью, или вообще не используют.И это, в принципе, случается не только у нас, но и у других разработчиков/внедренцев в организациях всех размеров. Да что говорить, внутри своей компании внедрение различного по для багтрекинга/контроля версий/управления проектами/сниппет-хранилища проходит со скрипом. И это среди программистов!
Приведу три примера:
1. Организация 50 человек,
средний возраст коллектива 20-30 лет, уровень владения компьютером от низкого до среднего. Программное обеспечение, разработанное нами и покрывающее практически все аспекты работы организации. ПО состоит из 5 модулей, и за 2(!) года использования — до сих пор используют только 1. Можно было бы подумать, что остальные 4 неудобные/глючные/малофункциональные… Смею заверить, что это не так, и все процессы, интерфейс уже давно вылизаны до блеска, оттестированы, опробованы ответственными лицами и признаны полезными/удобными/понятными. Но они их не используют… А все так же по старинке бегают с бумажками, созваниваются, переписываются в чатах и пр. А потом в конце месяца тратят кучу времени и сдают «неверные» отчеты.
2. Большая государственная организация.
1000 человек. Уровень владения компьютером средний (так как все рабочие места связаны с компом). Возраст разный. ПО — известная система документооборота. Внедряли почти полгода, обучили всех сотрудников: сначала общими лекциями и презентациями а потом и лично каждого — показали на примере как работать. Потребность в системе очень большая, так как документооборот, отчетность просто колоссальны по объему, а сроки «отработки» документов сравнительно небольшие. Из за всей этой кутерьмы, естественно, хоть и малая часть, но документы теряются, лежат в столах и много сил тратится на отчетность. В системе — пока лично не подойдешь и не «пнешь» — не работают (по миллиону разных причин).
3. Мои программисты.
Люди с высшим образованием, с опытом от 2 лет в программировании, «кровно» заинтересованы в быстром исполнении проектов. Вместе выбираем удобное и подходящее ПО — устанавливаем, обучаемся… И первые три дня работаем. Потом все забрасывается…
И в том и в другом случае,
выгоды от использования ПО очевидны и это признают сами сотрудники. Есть очень большое желание руководства эти проекты внедрить. Руководство довольно жесткое, но даже этого недостаточно чтобы люди в программах начали работать так как надо.
Получается ситуация «все понимают, хотят, могут, нужно(!) — а результата нет».
Что пытались делать:
- а) убеждать сотрудников, показывать им выгоды, обучать лично каждого и отвечать на все вопросы
- б) делать спец.отчетность для руководства, чтобы было видно, кто работает в системах а кто нет — и можно было принимать решения.
- в) разговаривать с руководством… Хотя что их-то убеждать? Они заказали и оплатили это ПО. Самое главное у них желание, возможности есть, в том числе возможности «кнута и пряника». Собираются планерки, ставятся задачи, сроки… а «воз и ныне там».
Уважаемые Хабровчане, поделитесь кто и как боролся с человеческим фактором, что еще можно попробовать? Может есть какие-то «рецепты»?
комментарии (151)
Т.е. если людям не захочется работать, то они и работать не будут? Что это за фирма, в которой логика и «приказы сверху» ничего не значат?
Для вас это новость? Покажите мне как вы будете отслеживать занимается человек делом или сидит в социальной сети.
Если сотруднику неинтересно, неудобно, не еще что-то, то его эффективность сильно снижается. Начинается сидение на фишках. Из-за фишек человеку не включиться в работу и он еще больше теряет в эффективности. Потом начинается апатия, недовольство и т.п.
Я сам и на себя наблюдал, и на подчиненных. Помогает работа с мотивацией и заинтересованностью.
«Покажите мне как вы будете отслеживать занимается человек делом или сидит в социальной сети.» зачем отслеживать? Не надо следить за человеком, надо следить за прогрессом работы. Напротив драконовские методы быстрее приведут к негативным последствиям.
Другое дело, если руководитель не может сказать чем занимаеться человек. Не может отличить когда его подчиненные работают, а когда валяют дурака неделями.
К тому же в тексте статьи, как вы можете заметить, есть фраза: «И в том и в другом случае, выгоды от использования ПО очевидны и это признают сами сотрудники. „
Наш диалог пошел совсем не о том.
Скрыть потерю производительности в 2 раза можно вполне. Всегда можно придумать как отмазаться. Есть и классическое «мой код компилируется» :)
Проблема не в пользе. Проблема в удобстве. Готовы ли ваши сотрудники ради мифической пользы делать 10 лишних телодвижения? Ведь слова «я осознаю пользу» и реальное осознание — разные вещи.
У нас в фирме был хороший пример: мы пытались заказчика заставить постить баги напрямую в баг-трекер. Неделю он это делал, а потом сказал: «долго, непонятно, неудобно» и стал снова отсылать все письмами.
Ваши сотрудники — это те же самые заказчики, только с очень большой лояльностью.
Крайне сложно мотивировать тех, кто пришел на работу не потому что интересно, а потому что зарплата_хорошая/больше_некуда_было/ну_надо_где_работать. Сами понимаете, есть ряд профессий и работ (например, на государство, где качество работы важно редко), где мотивация будет невысокой. Возможно, стоит попробовать изменить корень проблемы:
1. Рабочий процесс (чтобы в нем было хоть немого больше творческого начала)
2. Отсутствие духовной мотивации (на одном итальянском заводе по производству мопедов не могли добиться повышения качества никакими тренингами. Пока один менеджер не развесил по всему заводу листы с надписью «На этом мопеде через неделю будет ездить чей-то сын»).
3. Делигировать ответственность на работников (если сделать грамотно, то работник почувствует себя выше — он будет не шестеренкой, а кем-то, у кого есть зона ответственности).
Если меня что-то не устраивало для меня сменить место работы никогда не вызывало трудности. Могу сказать открыто, что я не боюсь таких перемен. Но когда я приходил в новую команду то приходилось принимать какие-то правила от code convensions до инструментов и методов их использования. Где-то это ежедневные отчеты в мантис и еженедельные на мыло дирректору, где-то это подробный отчет по каждой задаче. Далеко не всегда эти правила лично мне по душе, но принимаясь за работу нужно с ними соглашаться.
Вот именно умение работать в команде а не противостоять ей я считаю показателем профессиональности.
Умение работать в команде, имхо, заключается прежде всего в способности объяснить своего коллеге и тем более начальнику в чем он не прав и почему. Этим вы повышаете эффективность и окружающих, и свою собственную.
Если меня что-то не устраивало для меня сменить место работы никогда не вызывало трудности. Могу сказать открыто, что я не боюсь таких перемен. Но когда я приходил в новую команду то приходилось принимать какие-то правила от code convensions до инструментов и методов их использования. Где-то это ежедневные отчеты в мантис и еженедельные на мыло дирректору, где-то это подробный отчет по каждой задаче. Далеко не всегда эти правила лично мне по душе, но принимаясь за работу нужно с ними соглашаться.
Вот именно умение работать в команде а не противостоять ей я считаю показателем профессиональности.
>
Тут вопрос интересный, у меян сейчас работает 2 человека, я у них не прошу отчетность, я прошу результат! и поверьте я стараюсь создать в офисе атмосферу аля Гугл, и людям и работа нравится, и работается легко. А принуждая что-то делать… например креативщика грузить отчетами, в момент его порыва и творения? Я на километр не подпущу к своему программисту, когда он работает! А его лучший отчет будет результат. А если Шеф бегает с биноклем за сотрудником… хм… он старомоден. Я говорю о том что: Создай человеку условия а не правила, и он будет работать. для меня это работает.
Что же касаеться:
То, например, я в одной фирме поднял вопрос о ведение багтрекинга, и он решился в пользу последнего, но поднял вопрос про отчетность и мне сказали что инвесторы так попросили делать. Я не проповедую тупо следовать установленным правилам и не задумываться о том как сделать свою работу и работу команды лучше! Напротив! Но есть такие требования, которые нобходимо принимать. И позиция «не хочу — значит не буду» против логики и «приказов сверху» мне не понятна.
А человек никогда не признается, что он дурак и не может разобраться в Вашем ПО, особенно когда вы ему говорите, что оно очень простое. Это написано то ли здесь www.ozon.ru/context/detail/id/2618420/, то ли у Алана Купера.
Это при переходе с одного ПО на другое. При переходе с «таскания бумажных отчетов» на хоть какую систему документооборота подход другой — приходишь к Васе, который раньше обрабатывал документы, которые ему приносил Петя и объясняешь, что _бумажные_ документы от Пети он смело может выкидывать нафиг и ничего по ним не делать. И ничего ему за это не будет. А виноват будет Петя. На первой же планерке за необработанные документы отгребет тот, кто их сделал бумажными и дальше пойдет как по маслу.
автор наводит порядки на дорогах городка. ставит светофоры, делает разметку — все для того, чтобы пешеходам и водителям стало удобнее передвигаться. а пешеходы, негодяи, все так же идут на красный и переходят в неположенных местах, потому что им, видите ли, так ближе к дому.
нужны заборы и штрафы, чтобы система начала работать.
Приходить и сносить мне софт ПМ не должен, тем более при моем отсутствии на рабочем месте.
Настраивать свой рабочий environment разработчик должен сам.
FYI,
Integrated development environment
Не может один разработчик писать в VS2005, а другой в VS2008 (а то и VIM! с gcc). Не может один пользоваться SVN, а другой VSS. Не может один разработчик оптимизировать релиз по размеру, а другой по скорости. Не может один разработчик создавать обычную отладочную информацию, а другой для Edit&Continue. Не может один пользоваться sandcastle, а другой doxygen.
Цвета и шрифты (и то не произвольно) это всё что вы можете настроить. Если вам позволили настраивать больше, значит у вас бардак.
2. Если в команде разработчиков, можно выбирать любимый редактор для написания программ и от этого никак не зависит выходной результат, то почему нет.
3. Представим ситуацию, что вы/ваш ПМ случайно удалил с вашей машины VS/CVS, а администратор в этот момент болен/в отпуске. У вас разработчики в силах установить это ПО самостоятельно? Или все будут ждать возвращения админа?
А вот чего делать нельзя — это говорить «так, нам нужно перейти вот на это — сделайте, когда Вам будет удобно и и будет время». В это случае перехода не произойдет никогда.
По-моему, 99.9% работников затри им хоть весь хард будут жаловаться в ИТ-отдел, что у них комп сломался.
С другой стороны, если ИТ отдел будет отвечать, что ТАК НАДО…
Но тогда могут быть другие проблемы.
З.Ы. Тоже внедрение прошло хорошо. Просто запретили бумажки и все.
В таких случаях нельзя давать людям выбор — они обязательно сделают неправильный :)
Рассмотрим 3ий случай, когда вы являетесь начальством. Я конечно понимаю что каждому программисту удобнее кодить так как он привык, но если организация большая и всякие может быть(заболел, уволили и т.п.) и другому надо делать за него дела, тут конечно надо всё систематизировать, как решить данную проблему? Перевести всех на оплату 50%, а вторые 50% выдавать премиальными, что это дает? Это дает ввести систему штрафов. Если сотрудник не использует определенное ПО при разработке, то получает штраф, дальше он быстро сообразит как надо себя вести.
Так же как и слесарь, который сидит с напильником, потому что новый станок какой-то сложный и непонятный. Вполне себе повод для увольнения.
Реальная ситуация — совсем другое.
До сих пор осталось множество организаций и мелких и покрупнее, где выдают серую зарплату. Официально, на банковскую карту, перечисляется минимальные 7000 (8000 оклад минус 13%), а все остальное — плучается наличкой в бухгалтерии.
В нашей конторе, когда начали сокращения, всем, кто уволился по собственному, честно выплатили 2 полных зарплаты.
Если бы кто-то не захотел уходить сам — уволили бы по сокращению, с выплатой тех самых 7000.
Проведя тут на днях некоторую разведку по рынку труда, я обнаружил, что на аналогичные должности в других компаниях нанимают уже за гораздо меньшие деньги, чем платят мне. Потому я и держусь на этом месте. Потому я и плюю на конвертную систему. Разумеется, помимо зарплаты, есть еще плюсы, которые меня здесь удерживают.
Разрабатывали на дорогущем фреймворке. К нему были купленны все необходимые компоненты, и разработчики вместо того что бы копаться в доках писали свои велосипеды, которые могли вылиться потом в очень крупную сумму компенсаций, пойди что-то не так.
Всего за неделю-полторы удалось повысить адекватность разработчиков (нас тогда было около 10 человек).
PS: Есть замечательный анекдот про лесника который рубит лес тупым топором, а когда ему посоветовали наточить топор он ответил что ему некогда, ему лес валить надо.
Тогда же цель дирректора была немного другой: он индивидуально каждому показал что инструмент который мы использовали не такой плохой, как его воспринили сразу.
Поэтому в том случае фактор велосипедов был просто критический.
Думаю, не очень-то просто будет заставить разработчика компонентов выплатить компенсацию.
Нужно сказать что не покупалось ПО, покупалось решение для ведение интеграционного бизнеса. А это, как вы сами понимаете, совершенно разные понятия. Так что и документы, думаю, совсем не те «лицензионные соглашения» под опенсурсными приложениями основной строчкой которой являеться «используйте на свой страх и риск». Но конкретно, какие были лицензии, какие были _документы_ и соглашения я вам назвать не могу.
Премия не то чтобы большая, но достаточная чтобы ради нее три минуты в день тратили на кликанье богомерзких кнопочек. Опять же, если я не вижу автоотчетов, то сотруднику будет гораздо тяжелее отпроситься уйти на три часа пораньше «пивка попить». А если вижу — то легко и непринужденно.
Пока плет нормальный.
А потом я где-то, кажется, у Джоэла, прочитал, что так действительно делать нельзя — неэффективно, а надо так: оценить, сколько всего времени потрачено на работу за день и разделить его по задачам, которые выполнялись. Попробовал — работает, так намного лучше.
Все правильно, именно это я и делаю. Заставляя сотрудников отвечать на вопрос «а чем конкретно я сейчас занимаюсь» очень положительно влияет на планирование и производительность их труда. Да, им больно и неприятно — но это намного лучше, чем когда человек сидит в одноклассниках не потому что он раздолбай, а потому что с самоорганизацией у него плохо. Или по пятому разу переписывает тривиальный код «потому что он ему не нравится». Или пишет очередной велосипед, потому что «это прикльно и так три строчки сэкономим».
Тут надобно определиться что нам надо — управляемость и контроль или «свободное творчество». Как показывает практика, немногие программисты в рамках свободного творчества могут эффективно работать :(. И не потому что они плохие, а потому что люди так устроены. Как говорит известная поговорка — «Если дать программисту заниматься тем, чем он хочет — то программист будет делать всякие прикольные фигнюшки. После этого его полезность компании станет стремиться к нулю, его уволят и он умрет от голода» :).
Самоорганизация — сила. Тулза, стимулирующая самоорганизацию (пусть и болезненно) — самый дешевый из известных мне на данный момент способов манифестовать эту силу :(
Во-вторых — программисту, как правило, видно много того, что не видно руководству. В данном конкретном вашем подходе отрепортить что-то мелкое вроде «30 минут на рефакторинг foo.bar» зарепортить невозможно, это придётся заранее согласовывать и планировать, что ведёт к огромным накладным расходам на подобные мелкие задачи. Случайно обнаруженную ошибку, так же, проще порой сразу исправить, нежели тратить время на подобную отчётность.
В-третьих, сложно назвать эффективным подход, где исполнитель ограничен в выборе орудия труда, в данном случае — в выборе средства отчётности.
Наконец, оба подхода дают в результате часы работы и их соответствие задачам, так зачем тогда напрягаться больше?
Не придется. Работнику, в зависимости от квалификации ставится общая задача. А он сам, с помощью тулзы ее разбивает на подзадачи. Добавлять себе «рефакторинг foo.bar» нужно для истории изменений, истории для планирования времени на будующее.
В данном случае это лучше рассматривать не как орудие труда, а как методологию, организацию работы — воплощенную в программу.
Это очень сложный вопрос. Оба подхода обладают как плюсами, так и минусами. В своем конкретном случае я выбрал первый. До этого пользовался вторым :). По моим критериям (управляемость, планирование) он показался мне более эффективным. В каких то случаях он, конечно, будет менее эффективен. Я, собственно, про него здесь рассказываю в рамках вопроса топикстартера — как сделать так, чтобы люди пользовались софтом. В моем случае люди пользуются софтом — у них отсекли варианты :).
Когда на моей бывшей работе внедряли документооборот, через небольшое время не пользоваться системой было просто нельзя — ни сотовый поменять, ни бумагу для принтера получить со склада, а уж PMу вообще нечего делать без него — все, буквально все — от появления названия проекта до закрытия счета проекта было через систему.
Так что думаю что ПО о котором речь в статье просто было откатным :)
В данный момент идет «обкатка», «приемка» которая длится уже 2 месяц… И работать в проекте не работают (сотрудники)… И принять не принимают (руководство) — потому что не могут увидеть как система работает (сотрудники). Замкнутый круг блять.
ПО-простому надо перевести коммуникации во внедряемую систему. То есть если Маша передает по цепочке работу Ване, то Ване надо директивно, в приказном порядке, запретить принимать работу иначе чем через систему. Делается это с задницы цепочки — сначала последним проводим обучение и заставляем вносить все в систему — это самое сложное ( нужно обсудить с начальством, обязать, простимулировать итд ), потом подключаем к ним тех кто им передает. При этом уже обученные рады страшно, поскольку с них снимается куча работы и так до самых первых.
Другой, обычно внутренний вариант — берется отдельный сегмент организации — и с понедельника все делается в системе ( конечно обучение и тесты, но помогает мало :) ) При этом часть людей делает работу два раза — по старинке и в системе.Помучавшись и привыкнув «радуем» их отменой «по-старинке», заодно переводим еще один отдел или вообще всех в систему.
В общем обычные офисные игры :)
то есть всякий раз, когда надо было с этим ПО что-то сделать — возникало почти физическое отвращение.
например, Документум (то, что в прошлой конторе писали на документуме).
просто у него хреновое юзабилити — совершенно неочевидные действия для того или иного результата (программисты разработали определенные шаманские действия с мышкой. если их выполнить правильно — будет результат, логики не наблюдается — конечно никто не захочет работать с таким ПО).
1) Сначала оттестировали на узкой группе людей с узкими задачами (бывает такое на большом предприятии), но это был шаг вынужденный — прога самописная, заодно и невидимые баги отловили и юзабилити подправили (явные левые телодвижения).
2) Потом для всех запустили один модуль визирования на ограниченной группе ОРД-документов (приказы etc)
3) Потом в эту группу документов стали добавлять ещё документы, пока все документы не стали проходить через систему
4) Потом последовательно остальные модули (контроль исполнения etc)
И ещё, извините, конечно, не знаю что за прогу вы внедряете, но у меня впечатления после знакомства с большим количеством систем документооборота были не особо приятные. Очень часто это системы громоздкие, загаженные огромным количеством разных форм с подавляющим количеством контролов, с неявной логикой (видной только после вдумчивого изучения документации) изгаженной добавлением разных мелких фич непонятно для кого.
Людям трудно к такому сразу приспособиться и перенести у себя в голове техпроцесс «отнести Маше шоколадку и документ для визы у главного инженера» к процессу «открыть систему — внести документ (на кой-то требуют ещё какие-то поля заполнять, кроме самого текста документа) — нажать кучу кнопок для назначения визирующих лиц» и решить вопрос — нести или нет шоколадку и когда?
Люди используют ПО, чтобы решать свои проблемы. Вам надо всего-лишь показать, что при помощи ПО можно решить проблемы.
Я так пересадил 40 человек с винды с фотошоп на Линукс — сделал видео уроки. :)
По-моему очень мало данных для советов, крайне мало. Особенно вот тут: "Смею заверить, что это не так, и все процессы, интерфейс уже давно вылизаны до блеска, оттестированы, опробованы ответственными лицами и признаны полезными/удобными/понятными" очень сомнительно. Что-то значит не так, что-то не объяснили, что-то не работает, надо смотреть и разбираться. Может у вас надо мышкой много работать, а было не надо, может у вас отчёты непохожие на старые, да миллион может причин быть.
Конечно, люди всегда оказывают сопротивление, всегда. Но опять же всегда у клиента находится толковый человек-два, которые «схватывают», понимают в чём новая система удобнее и вот таких людей надо искать и за них цепляться. Опять же советы и просьбы этих людей надо выполнять. Программистам никогда полностью не понять предметной области клиента и его чаяний, им совсем другое удобнее.
За несоблюдение — шраф
Проблема в том что это никому ненадо — ПО заказали для «освоения бюджета», увы
Хм… А я бы простимулировался, если бы за соблюдение — шарф. А то -30 на дворе, холодно…
На актив можно давить, его можно стимулировать… теребить… (: эээ… извините увлекся…
Т.е. чтобы обучить стадо обезьян, нужно обучить главную обезьяну.
С одной стороны, дело тут может быть в том, что к новой системе надо привыкать и всем лень. Тогда тут могут помочь подробные тренинги и/или волевое решение руководства.
С другой стороны, может оказаться, что не смотря на все удобство, в некоторых случаях гибкости системы не хватает и проще позвонить или разобраться на бумажке. В этом случае сколько не дави, толку не будет.
Судя по этой фразе, ваша система хорошо помогает людям экономить время, т.е. делать больше за меньшее время. Почему бы не задать Балде службу, чтоб стало ему невмочь, а требовать чтобы он ее исполнил точь-в-точь? Другими словами, заставить приказом сверху в короткое время сделать столько работы, что без вашей системы ее в принципе за такое время не сделаешь?
прекрасно):
— низкая производительность труда в период освоения: думаю многие тут, на хабре, проходили через это — новый продукт (или версия старого) обещает значительные плюсы, но освоение может длиться недопустимо долго, при том что текущую работу, дедлайны и т. д., никто не отменял — «надо еще вчера»
— боязнь показаться неквалифицированным (читай тупым :) ): не может быть, как правило, всё понятно в абсолютно новой системе, но задавать вопросы многие люди не любят, предпочитают или «на бумажке» или разбираться самим (что еще больше усиливает первый пункт)
— «коллективная боязнь» потерять должность/работу или получить дополнительную нагрузку (без дополнительной мотивации): сейчас люди «как-то» справляются со своими обязанностями, если новая система увеличит производительность их труда, скажем, вдвое, то текущие ежедневные задачи они выполнят условно до обеда, а после обеда делать им будет нечего. Вероятность, что начальство этого не заметит — или заметив сочтёт это нормальным, — достаточно мала… Или будут сокращения, или увеличится количество/сложность задач.
— банальная привычка или следование принципу «работает — не трогай»
я мог бы рассказать, но… ну да, чуть ниже я уже посоветовал книгу.
как раз там ответы на вопрос «почему люди не исследуют новые возможности».
потому что всегда используют необходимый минимум (есть люди-исключения — и они чаще программисты. но не всегда).
потому что любому программисту кажется, что продукт, который он написал — удобен в использовании и всё очевидно — даже если все комманды свалены в кучу и нужную функциональность приходится выковыривать…
а пользователь не склонен ковыряться в чужих запутанных штуках — он использует то, что минимально необходимо.
Второе — увеличить нагрузку до невозможной при ручной работе.
Челоек странное животное. ПО это ещё объяснимо — боъязнь новизны, низкий уровень развития, лень и т д. А вот как объяснить то что человек будет весь день таскать раствор или песок вёдрами при том что в десяти метрах стоит колёсная тачка. И человек этот работает на себя.
Я думаю мы просто не умеем получать удовольствие от своей работы. Не обучены-с.
он там хорошо рассказывает об использовании возможностей.
очень полезная книга.
Повернуть его в свою пользу.
Ведь нужность понятие субъективное. Нужно кому? Скорее всего руководству, чтобы больше пахали. А рядовому сотруднику нафиг не нужно. Меньше бумажек в день — меньше работы. Больше механической работы — меньше умственной.
и… почитайте «Психбольницу в руках пациентов» Алана Купера — это поможет понять, почему люди плохо пользуются софтом.
это — база.
Сотрудники некоей организации производили файлообмен через расшаренную директорию на сервере. Надо передать документ — скопировал в папку другому, отзвонился и всё.
Админы решили, что это рассадник вирусов и, будучи не в силах справиться с их наплывом другими способами, решили: отныне все будут меняться файлами через внутренний почтовый сервер! Надо ли говорить, что спустя полтора года файлообмен по-прежнему производится через шару?
А почему так произошло?
Чтобы отправить другому файл, следует предпринять ряд нетривиальных для хомо офисус действий: открыть почтовый клиент, открыть сравочник адресов сотрудников, найти сотрудника в справочнике, скопировать адрес, вставить в почтовый клиент, открыть диалог добавления приложения, пробиться через дебри файловой системы чтобы найти где-то в дереве файл, прикрепить его, написать сопроводиловку, отправить.
Но при этом он не знает — осведломлен же адресат тут же о получении файла (т.е. запущен ли у него при этом почтовый клиент и получил ли он уведомление о получении)? Что он делает? Правильно — поднимает трубку и звонит чтобы сообщить о передаче.
Что нужно сделать адресату? Страдать — держать почтовый клиент запущенным. При получении файла сохранять приложение на диск, пробираясь через дебри ФС и уже потом, снова отыскав его, открывать и просматривать.
Нафиг нужно! — скажут люди и будут правы. И продолжат по старинке копировать файл в нужную папку и звонить потому что ярлык на шару у них на рабочем столе, под рукой.
Я понимаю, что в ваших системах все может быть намного более прекрасно чем в моем примере, но может быть какие-то проблемы есть?
юзабилити (вернее, хреновое узабилити) — это основная причина, по которой пользователи отказываются от ПО.
но некоторые компании гораздо внимательнее подходятк этому вопросу.
и, да, количество кликов мышкой (и вообще, количество действий) — это критический фактор. всегда — чем меньше — тем лучше (второй важнейший фактор — это наличие необходимой пользователю информации и отсутствие того, что ему не нужно).
в одном интернет-магазине (большом) внедряли покупку одним кликом.
и программист по привычке после клика «купить» сделал запрос «вы уверены, что хотите купить?».
программисту дали по ушам — ведь было уже два клика.
Проблема-то была в вирусах, и решать нужно было именно её?
Например: лишить всех пользователей администраторских прав, запретить запись в Program Files и системные каталоги, запретить запуск приложений откуда-либо кроме папок Windows и Program Files, поставить всем антивирусы, сделать выход в интернет только через прокси, на котором блокировать нежелательный контент и IE, установить всем Firefox (юристам оставить IE но только для сайта консультанта и других нужных для работы, которые не поддерживают Firefox).
Работаю уже во второй крупной (тысячи сотрудников) компании — никогда не слышали ни о каких вирусах.
потому что с большой вероятностью честный ответ будет таким:
ПО такое мутное… я в нем не разбираюсь — что означает, что пользователю просто неудобна и непонятна работа в данном ПО.
потому что часто человек и сам не может пояснить, что именно мутного в данном ПО.
и дальше уже смотреть.
если человек в каком-то месте подвисает — ищет, куда тыкнуть — значит мутная навигация и, возможно, перегрузка функциями.
если для того, чтобы научится работать надо прочитать килограммы доков — значит точно мутная навигация.
ну и так далее.
Но если есть возможность полноценного юзабилити-тестирования, то по правильному оно явно должно быть проведено на этапе прототипа, а не когда «после внедрения продукт вдруг не идет».
А тут уж, если встали на грабли и ресурсов уже нет — то можно попробовать хотя бы опросом.
Вообще, в целом, в исходной задаче поста — недостаточно данных что бы дать толковые советы в конкретном случае.
Если ответственные лица — это руководство, то это ни о чем не говорит. Часто бывает, что видение руководства сильно отличается от видения рядовых сотрудников.
На словах сотрудники могут говорить, что выгода есть. Но по факту — вряд ли это так. Рядовым сотрудникам от того, что они сэкономят время и не будут бегать с бумажками — никакой выгоды нет. Платить то им будут так же, а напрягаться придется больше. Так что действительно нужно не оставлять альтернатив, как уже предлагали выше.
если им не оставить альтернатив (но будет всё так же неудобно) — они будут работать с большим скрипом. лучше от этого никому не будет. выше пример про передачу файлов почтой — замечательный пример.
ТАК ВЕДЬ РАБОТАЕТ!
И для того чтобы что-то менять когда всё работает необходимо иметь или волю или финансовую заинтерисованность для формирования воли.
Хорошо в Китае — расстреляли пару сотрудников за рисование табличек в word. Остальные уже интегрируют excell объектом.
Вот ещё вспомнил — у меня такое впечатление что я один в мире центрирую текст с помошью форматирования «выравять по центру» а не пробелами.
Просто пишите удобный, интуитивно понятный софт, спрашивайте пользователей как им удобнее и делайте именно так, постоянно отслеживайте в каких модулях происходит торможение. Ведь вы же пишете для людей, а не вопреки им…
После прочтения данного поста живо представил себе убогие софтины какие используются в гос структурах. Их пишут студенты просто чтобы отбить бабла, соответственно пользоваться ими в 99% случаев банально невозможно.
добавлюсь.
«много всевозможной функциональности» — это не то, что нужно.
пользователю нужен обычно весьма конкретный список функциональности. всё что сверх него (чем он не пользуется, но что есть в ПО «чтоб было» — загромождает и снижает удобство использования ПО).
«много всевозможной функциональности» — это не то, что нужно всегда.
эта функциональность должна присутствовать, но желательно чтобы она была незаметной и появляться только когда нужна и востребована именно теми кому она нужна.
Интерфейс в новом офисе стал интуитивнее, но привычка-то осталась…
И ведь работало все и в 2003…
По себе сужу: разные системы issue трекинга у меня не приживаются, т.к. каждая заточена на одну конкретную задачу. Даже комбайны вроде trac и redmine лучше подходят для итераций разработки системного ПО, а не, скажем, развесистого дерева исходников приличного вебсайта (для контраста можно упомянуть вики-системы, которые можно использовать для множества целей, т.к. они универсальны). Вот и получается, что 10 системщиков решат: «trac это здорово», остальные посмотрят и скажут: «да, здорово!», только корпоративной CRM`ки/планировщика из этого не получится — слишком разнородные задачи. А что бы получилось, надо предусматривать возможность подключения к системе по открытым протоколам других пользовательских программ, которые больше подходят «остающимся за бортом». Для примера взгляните, как поступили яндексовцы со своими переговорками: habrahabr.ru/company/yandex/blog/77540/.
Отвечая на вопрос, выведенный в заголовок: с человеческим фактором не нужно бороться. Его надо просто учитывать.
Только даже думать не смейте что софт гавно, это не так, просто есть такое правило…
Сам с этим сталкивался
Итог внедрения — около 10 докладных со стороны внедренцев и примерно такое же количество со стороны сотрудников компании-клиента. Трое уволенных. Жестоко, но либо нас либо их :)
Итог: ПО внедрено, работа около 3-4 лет, сотрудники довольны, к бумажной работе возвращаться не хотят.
Правильно. Только так!
Пример: ПО позволяет (кроме прочего) по нажатию одной кнопки сформировать огромную спецификацию оборудования. Часть сотрудников продолжают делать это вручную (тупо копировать в ворд тысячи строк).
Причина: для того, чтобы всё сработало автоматически, надо всё-таки напрячься — внести оборудование в справочник. Внести тоже автоматически, через экспорт, но дело в том, что сначала надо понять, в какой раздел вносить. То есть, людям надо структурировать оборудование, с которым они работают каждый день. А это требует напряжения. Куда как проще потратить день на копирование строчек — никакого дискомфорта и человека даже нельзя назвать бездельником — он же трудится.
The psychology of change
Я в шоке!
Вы посмотрите, как вопрос ставите: «Как бороться с человеческим фактором при внедрении ПО?»
Создается впечатление, что пишет не человек, а робот по внедрению ПО.
Не нужно бороться. Люди не хотят использовать, то что начальство с вашей подачи им навязывает. Они не хотят прямо заявлять и обосновывать свою позицию, раскрываться, потому что не чувствуют себя в безопасности. Не видят, что копания защищает их и заботиться. Она этого и не делает. Они формально выполняют требования сверху и ждут очередной зарплаты, Они пришли работать за деньги, и не получают возможности для самореализации. Им безразличен результат их коллективного труда. Они несчастны.
Виноват организатор этого процесса и все спящие участники.
Тут ещё приходите вы, со своим ПО. Внедрен… слов нет. Люди едва приспособились к их ежедневному быту за мониторами, а тут снова, зачем? Они не заинтересованы, Вы навязываете им.
И потом вы называете их поведение «человеческим фактором». Такое положение не красит их. Они спят, но они люди. А вы? Их руководству вы втюхали свои продукты, услуги, вот только рабы есть это отказываются. Человеческий фактор — это всё, что имеет смысл. С ним нужно не бороться, его нужно найти и развивать. Вся эта хоботня для людей, или для внедрения ПО? Кто б… цель, а что средства?
Скайнет 2009: «надо что-то делать с человеческим фактором? Потребители совсем не потребляют наш, чудо-товар, они даже купят, а не едят, вот гады.»
Автор, проснись уже.
Всего хорошего!
Ф
Двумя руками за. +1, как говорится.
И по формулировке «бороться с человеческим фактором» — возможно, нужно было написать «Как бороться с нежеланием сотрудников работать во внедренном ПО?», так наверное более четко звучит вопрос.
Идеальный вариант — пришли, установили, обучили, начали работать — возникли вопросы / пожелания — доработали софт — работаем спокойно. Все сыты и целы.
Реальный вариант — пришли, установили, обучили, заглохло…
Мой вопрос в том — что именно нужно делать, чтобы процесс пошел так как нужно. А бороться, действительно бесполезно :)
Это очень полезная книга. Она же есть в печатном виде. Там есть всё о чём вы пишете.
Писал человек с огромным стажем работы. Не поленитесь хотя бы пробежаться по ней глазами.
Если руководитель адекватный, более того, требующий работать так и только так, и не делающий исключений ни для кого, успех будет.
Если же руководитель через месяц-другой забывает/забивает, то сотрудники чуют это особым нюхом сотрудника и тоже втихаря забивают… А если еще появляются исключения в виде любимчиков/любовниц/родственников…
Ну и несколько вещей я для подчерпнул для себя, которые были уже озвучены в комментах выше:
1) Огромным плюсом будет вовлечь сотрудников в процесс разработки, показывать этапы работы, какие-то готовые модули, обсуждать с ними. Причем не только с начальством, а именно с теми кто будет постоянно пользоваться. Человек внесший свой вклад (пусть даже своим мнением и советами) будет уже по другому относиться к данному продукту. Ну это больше психологический момент.
2) Организационный момент. Сделать процесс работы в компании зависимым от ПО. В моем случае, менеджерам выдавались ключи на корпоративные авто (для встреч с клиентами) только по специальной заявки из CRM. А заявка представляла собой просто задачу на встречу в планировщике. Таким образом менеджеры научились пользоваться планировщиком. Далее им стало удобно видеть свои встречи и планировать их вперед на неделю.
3) Еще способ. Call-центр получал бонусы за количество отработанных звонков на основании отчетов, которые формировались в CRM по итогам отчетных дат. Но сразу оговорюсь, что именно модуль call-центра вылизывался вместе с сотрудниками, мы спрашивали, советовались, что удобно, что нет, где много тратиться времени на ввод в систему звонка. Итог: сотрудники при входящем звонке уже не использовали ручки и бумажки ))) а сразу вводили данные в CRM.
4) Хороший модуль отчетности для руководства компании. Но об этом много написано уже.
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!
Что пытались делать:
а) убеждать сотрудников, показывать им выгоды, обучать лично каждого и отвечать на все вопросы
>>> Убеждать бессмысленно, это своего рода насилие, как и уговаривать. У человека есть натуральный механизм (встроенный так сказать) — механизм приспособления. Так вот, убеждать не надо, надо изменить условия в которых он работает, что бы он понял, что ему нужно приспособится под них и Ваше ПО это то что ему в этом поможет. В умных книгах это называется «продать идею». Для этого надо обратиться к истокам решения — зачем нужно новое ПО? Какие цели его установки? Если удобство пользователей — то тут сколько людей столько мнений, а если скорость операций то это уже более конкретно — было 3 часа (бумажку напечатать, положить в ящик, найти, сходить к Вале, покурить по дороге, по трындеть по пути, посидеть в очереди и.т.д.), а можно за 5 минут. Так надо и посчитать сколько нужно людей если все по 5 минут. И решить — я хочу по 5 минут, сделаю Вам такой софт и отдел сокращу, а лишних перепрофилирую или уволю. Поставить задачу начальнику отдела и сотрудникам. Сказать — мы будем более эффективны сможем зарабатывать больше а тратить меньше, всем кто в итоге останется повысим зарплату. Будут помогать, еще как, будет лучше. Но надо быть готовым поделится своими успехами с сотрудниками потому что те кто вам поможет во внедрении — они главнее вас, они дадут возможность заработать больше. А если их кинете, то вообще останетесь у разбитого корыта.
б) делать спец.отчетность для руководства, чтобы было видно, кто работает в системах а кто нет — и можно было принимать решения.
>>> Это то же из серии РУКОводства — это борьба со следствием, а не с проблемой. Руководство не смогло продать идею сотрудникам, так будем лупить тех кто не купился. В таком случае лучше заменить руководство поскольку грош ему цена если не может менять поведение работников, оно тогда не руководство, а бюджетные контролеры и распределители ресурсов.
в) разговаривать с руководством… Хотя что их-то убеждать? Они заказали и оплатили это ПО. Самое главное у них желание, возможности есть, в том числе возможности «кнута и пряника». Собираются планерки, ставятся задачи, сроки… а «воз и ныне там».
>>> А это потому что они думают, что для того что бы быть руководителем достаточно денег много, кабинет, визитки и водилу в лексусе. Если они сами не понимают зачем ПО купили, и как это на бизнес повлияет, то чего их убеждать. А если понимают, но рассказать сотрудникам не могут, то та же история, а если рассказать могут но сотрудники не понимают, то то же не фонтан — что же набрали таких тупеньких… В таком раскладе, лучше деньги забрать за работу да и раскланяться, а название компании в презентации вставить.
Принуждение — вот единственный выход из этой проблемы.
1. Сделать продукт, который будет решать задачи пользователя
2. Продумать интерфейс — четкие и небольшие подсказки — половина успеха использования. Если надо две кнопки для решения задачи — значит надо сделать только две кнопки. Если требуется текстовый редактор — то такой, который печатает текст, а не аля вектор-растро-супер-3д-редактор, в котором кое где можно печатать текст. Если требуется файлообменник — то настроить две папки для передачи не так трудно. Для оповещения о том, что в какой-то папке появился файл, используются программки. Сам такую юзал в офисе, когда занимался версткой (при поступлении файла в папке !Inbox выскакивало окно.
3. Ограничение в рамках операционки, но с возможностью отписать админам о своих мыслях. Простым языком — обратная связь.
4. Продумать альтернативу — иногда вроде бы нелогичные с точки зрения разработчика почему-то чаще используются пользователями.
И еще — необходимо посмотреть как работает работник прежде чем внедрять ПО.
habrahabr.ru/blogs/ui_design_and_usability/77681/
Это все равно что:
— Как бороться с клиентами ресторана если они покупают еду и не доедают и говорят что она гадкая?
— Как бороться с клиентами больницы если они мрут как мухи в процессе лечения?
:)