Добрый день. Хотелось бы поведать небольшую историю, которая произошла со мной не так давно и связана как с карьерными ожиданиями, так и с ошибочным восприятием того, что происходит в реальности. Как работодатель может вводить в заблуждение или неосознанно вредить мотивации команды.
Приехав в провинциальный город из Москвы, я собирался устроиться начальником ИТ-отдела в какую-нибудь фирму. Пройдя в Москве повышение квалификации и все этапы работы от первой линии до третьей, поняв что менеджмент и управление людьми\процессами мне нравится и мне это по плечу, я начал искать вакансию.
Подробности под катом.
Специально не отвлекался на вакансии трансформеры, когда компании нужен “и спец, и жнец, и на дуде игрец”(это когда человек должен и платы паять и 1С-конфигурации писать) я терпеливо ждал хорошего предложения. Через 2 месяца на меня вышел зам.начальника управления, с предложением, на которое трудно было не согласится. Направление только появилось, компания федерального масштаба, создающая отдел поддержки и разработки в регионе, планы были грандиозные и вполне соответствовали моим ожиданиям. Можно было построить команду и процессы с нуля, оптимизировать и встроить их в существующие процессы. Все называли должность с функциями «координатора\начальника Техподдержки». Что ж, я был готов в бой.
Что хотелось: Так как поддерживать предстояло купленную информационную систему, а я раньше больше имел дело с аппаратной инфраструктурой, я решил входить в курс дела постепенно и с той стороны, какая была для меня самой очевидной – я попросил регламенты процессов, автоматизируемых системой, и документацию к ней. И столкнулся с первым сюрпризом – документации у купленной за “деньги” системы не было. Были набросанные компанией-разработчиком на коленке слайды, как определённые роли участвуют в процессе и на этом всё. У компании было ещё 4 месяца поддержки по договору, когда к ним можно было обращаться с вопросами по работе системы. Внутреннего проекта по внедрению системы не было, сроки устанавливались соглашением и excel-документом, в котором были указаны сроки внедрения определённых доработок. Да, после моего найма система дописывалась ещё 5 месяцев.
Что получилось: С грехом пополам, описаны несколько процессов в виде схем Visio. Частично описаны модули системы. Из-за срыва сроков коммуникация с разработчиками купленной системы стала ещё хуже. Насколько я понял, обязательность документации при покупке не оговаривалась.
Вывод: Недокументированная недописанная система плохо подлежит описанию без помощи разработчиков. Старайтесь наладить процесс коммуникации.
Что хотелось: Поддержка на первой линии предполагала набрать определённый пул вопросов от пользователей, предполагалось, что этот пул уже есть у менеджеров, хотя бы частично. Но после переговоров с начальником отдела продаж стало ясно, что пула нет и процесс будет выглядеть следующим образом: пользователь звонит, если это связано с технической частью, то помогаем, если с бизнес-частью, то перезваниваем. Так как бизнес-части ответов не было совсем, то первым пользователям должно было не очень повезти. Опять же, при разговоре я понял, что бизнес не очень то и дорожит новыми пользователями и готов пойти на эти риски.
Чтобы внести ясность, с такими исходниками картина представлялась довольно туманной, но я воспринимал это как вызов.
Что получилось: Создан документ, позволяющий покрывать первоначальный объем бизнес-консультаций. Порядок работы с бизнесом регламентировать не удалось. На новый вопрос «не из списка» бизнес мог забыть ответить. Приходилось повторно запрашивать, держа на контроле. На базе docuwiki создана база знаний с описанием вопросов, архитектуры системы, основных действий второй линии поддержки и администраторов. Не получилось описать настройку создания нового продукта в системе, т. к. он создавался полупрограммируемым способом и описывать надо было совместно с программистами.
Вывод: Создавать базу знаний жертвуя лояльностью клиента неправильный шаг. Если бизнес на это идет, то на поддержку ложится дополнительная нагрузка в виде оправданий недоработок и сдерживания дополнительного негатива клиентов.
Что хотелось: Для подбора сотрудников к себе в команду я подошёл методически: выбрал список компетенций и составил вопросы к телефонному собеседованию по этим компетенциям. Сначала все вопросы имели одинаковый вес и после пары собеседований я понял, что все кандидаты одинаково подходят на вакансию и такими темпами можно долго нанимать людей. Всем компетенциям был дан вес и процесс пошёл веселее.
Таблица компетенций первой линии:
Данный шаблон был отправлен на согласование с руководством, но отклика «применять-не применять» не вернулось.
Первого человека я взял по рекомендации от старого коллеги без шаблона (проработал неделю). Следующего взял шеф. Остальных трёх (девушек) набирали частично с моим участием, но не спрашивая моих рекомендаций и не интересуясь мнением. Допуска к материальной мотивации и бюджетам я не получил.
Что получилось: Набран весёлый, но не полностью соответствующий требованиям отдел, где сотрудники отлично справляются с работой первой линии, но для более глубокого погружения в систему требуются правильно составленный процесс обучения и передачи знаний. При мне люди с ЗП выше средней по рынку на глазах теряли нематериальную мотивацию из-за неверно поставленного процесса работы.
Вывод: готовьте для нового замотивированного сотрудника объем работы. Иначе это плохо влияет на лояльность к работодателю и к системе. Понимайте процесс мотивации персонала — как материальный, так и не материальный.
Что хотелось: После запуска системы мы начали сталкиваться с первыми трудностями: старый интерфейс выглядел ужасно и работал против всех понятий user-friendly. Основной поток звонков пошёл по недовольству именно интерфейсом, а не бизнес-процессом. Пользователи элементарно не могли завести заявку. До вновь набранной команды разработки сразу были доведены основные ошибки, но тут мы столкнулись со второй проблемой: не было коммуникации не только с теми, кто поддерживал систему извне, но и и не было расстановки приоритетов по исправлению системы — все силы были брошены на написание новых функций и продуктов, не получалось выделить человека для латания элементарных ошибок, которые сократили бы количество звонков вдвое.
Что получилось: После очередного указания на проблемы руководству оно все-таки дало разрешение на внесение правок и поток звонков уменьшился втрое.
Вывод: налаживайте процесс приоритизации задач, обсуждая порядок взаимодействия с группой разработки.
Сталкиваясь с каждой из вышеназванных задач я каждый раз приходил к руководству с предложениями оптимизации процессов и попыткой скоординировать своё видение с видением компании, но всегда натыкался или на занятость руководителя(системная проблема) или получал ответ «пока так» и «мы не хотим излишней формализации». Также я знал, что планируется расширение отдела до 5 человек и видел, что надо понять как будет происходить управление процессом поддержки и ресурсами. Я уже начал подозревать, что начальство изменило планы насчёт меня из-за моих постоянных попыток внедрить изменения. Меня уже не называли координатором или начальником, я не участвовал в митингах, связанных с развитием системы.
После этого я решил подготовить стратегию и понять, тем ли я вообще занимаюсь. Потому что начальник не коммуницировал со мной в плане стратегии совсем. Стратегия была направлена сразу на вышестоящее лицо в ИТ в Москву и, для меня картинка моей работы поменялась. Потом стратегия была направлена из Москвы вниз к моему прямому начальству и я попал в конфронтацию с местным начальником.
Вывод: Проанализируйте стратегию подразделения. Определите краткосрочные и долгосрочные планы. Обсудите видение с руководством.
После вышеописанного эпизода со мной практически прекратил общаться прямой начальник. И я начал подумывать об уходе. Изначально я видел интересный проект, который после преодоления определённых трудностей при правильном взаимодействии всех участников процесса можно было успешно завершить, получив крепкий мотивированный отдел поддержки с правильными KPI и с чёткими показателями на выходе, понятными безнесу. Сейчас же, я увидел, что отдел сваливается в рутину еще толком не развившись. В приоритете стали две задачи — ответы на звонки и описание багов(не доработок) системы посредством gitlab, которые исправляли разработчики.
Отдельная история — процесс «тестирования», как его называл руководитель, который тоже предлагалось выполнять нам. Понимания этих процедур ни у кого не было, как и отдельного тестировщика. Функциональное тестирование «черного ящика» без каких-либо показателей эффективности всей командой перед релизом. Никаких других методов не применялось. Набранный персонал не мог эффективно участвовать в тестировании из-за нехватки как бэкграунда в сфере разработки, так и из-за отсутствия процесса обучения. Даты релизов постоянно фейлились или релизы выкатывались без тестирования.
Вывод: отдел не может эффективно заниматься двумя крупными процессами параллельно. Будет два процесса идущих кое-как.
Конфронтация продолжалась. Руководитель умудрился зафейлить все элементы менеджмента, которые я считал важным:
Также были озвучены такие волшебные пункты, как «лояльность к компании в виде прихода на работу раньше и ухода позже»
Окончательно потеряв мотивацию, я пригласил начальника на беседу о моем дальнейшем положении в компании и решении ее покинуть, где мне было сказано, что отдел в текущем своём виде всех устраивает и развития отдельных элементов не планируется. В итоге я покинул компанию, получив практический опыт в попытке реализации своего видения работы отдела поддержки.
Что получилось: опыт, опыт и еще раз опыт.
Вывод: Какие ошибки я для себя зафиксировал:
Также хотелось бы услышать от коллег ваши истории внедрения и нюансы, на которые я, по неопытности, не обратил внимания.
Приехав в провинциальный город из Москвы, я собирался устроиться начальником ИТ-отдела в какую-нибудь фирму. Пройдя в Москве повышение квалификации и все этапы работы от первой линии до третьей, поняв что менеджмент и управление людьми\процессами мне нравится и мне это по плечу, я начал искать вакансию.
Подробности под катом.
Специально не отвлекался на вакансии трансформеры, когда компании нужен “и спец, и жнец, и на дуде игрец”(это когда человек должен и платы паять и 1С-конфигурации писать) я терпеливо ждал хорошего предложения. Через 2 месяца на меня вышел зам.начальника управления, с предложением, на которое трудно было не согласится. Направление только появилось, компания федерального масштаба, создающая отдел поддержки и разработки в регионе, планы были грандиозные и вполне соответствовали моим ожиданиям. Можно было построить команду и процессы с нуля, оптимизировать и встроить их в существующие процессы. Все называли должность с функциями «координатора\начальника Техподдержки». Что ж, я был готов в бой.
Первоначальные цели:
- Поддержка на первой и второй линии.
- Создание базы знаний
- Создание документации пользователей
- Вникнуть в бизнес-процесс для осуществления “бизнес консультаций”
- Подготовить регламент взаимодействий подразделений в рамках методологии ITIL Service Desk(планировал взять оттуда только процесс прохождения заявок и инцидентов + написание SLA, потому как знаю, что в тупую внедрять полностью формализованный процесс никто не даст, да и это не заработает)
- Нанять сотрудников поддержки.
Создание документации
Что хотелось: Так как поддерживать предстояло купленную информационную систему, а я раньше больше имел дело с аппаратной инфраструктурой, я решил входить в курс дела постепенно и с той стороны, какая была для меня самой очевидной – я попросил регламенты процессов, автоматизируемых системой, и документацию к ней. И столкнулся с первым сюрпризом – документации у купленной за “деньги” системы не было. Были набросанные компанией-разработчиком на коленке слайды, как определённые роли участвуют в процессе и на этом всё. У компании было ещё 4 месяца поддержки по договору, когда к ним можно было обращаться с вопросами по работе системы. Внутреннего проекта по внедрению системы не было, сроки устанавливались соглашением и excel-документом, в котором были указаны сроки внедрения определённых доработок. Да, после моего найма система дописывалась ещё 5 месяцев.
Что получилось: С грехом пополам, описаны несколько процессов в виде схем Visio. Частично описаны модули системы. Из-за срыва сроков коммуникация с разработчиками купленной системы стала ещё хуже. Насколько я понял, обязательность документации при покупке не оговаривалась.
Вывод: Недокументированная недописанная система плохо подлежит описанию без помощи разработчиков. Старайтесь наладить процесс коммуникации.
Создание базы знаний
Что хотелось: Поддержка на первой линии предполагала набрать определённый пул вопросов от пользователей, предполагалось, что этот пул уже есть у менеджеров, хотя бы частично. Но после переговоров с начальником отдела продаж стало ясно, что пула нет и процесс будет выглядеть следующим образом: пользователь звонит, если это связано с технической частью, то помогаем, если с бизнес-частью, то перезваниваем. Так как бизнес-части ответов не было совсем, то первым пользователям должно было не очень повезти. Опять же, при разговоре я понял, что бизнес не очень то и дорожит новыми пользователями и готов пойти на эти риски.
Чтобы внести ясность, с такими исходниками картина представлялась довольно туманной, но я воспринимал это как вызов.
Что получилось: Создан документ, позволяющий покрывать первоначальный объем бизнес-консультаций. Порядок работы с бизнесом регламентировать не удалось. На новый вопрос «не из списка» бизнес мог забыть ответить. Приходилось повторно запрашивать, держа на контроле. На базе docuwiki создана база знаний с описанием вопросов, архитектуры системы, основных действий второй линии поддержки и администраторов. Не получилось описать настройку создания нового продукта в системе, т. к. он создавался полупрограммируемым способом и описывать надо было совместно с программистами.
Вывод: Создавать базу знаний жертвуя лояльностью клиента неправильный шаг. Если бизнес на это идет, то на поддержку ложится дополнительная нагрузка в виде оправданий недоработок и сдерживания дополнительного негатива клиентов.
Подбор персонала
Что хотелось: Для подбора сотрудников к себе в команду я подошёл методически: выбрал список компетенций и составил вопросы к телефонному собеседованию по этим компетенциям. Сначала все вопросы имели одинаковый вес и после пары собеседований я понял, что все кандидаты одинаково подходят на вакансию и такими темпами можно долго нанимать людей. Всем компетенциям был дан вес и процесс пошёл веселее.
Таблица компетенций первой линии:
Данный шаблон был отправлен на согласование с руководством, но отклика «применять-не применять» не вернулось.
Первого человека я взял по рекомендации от старого коллеги без шаблона (проработал неделю). Следующего взял шеф. Остальных трёх (девушек) набирали частично с моим участием, но не спрашивая моих рекомендаций и не интересуясь мнением. Допуска к материальной мотивации и бюджетам я не получил.
Что получилось: Набран весёлый, но не полностью соответствующий требованиям отдел, где сотрудники отлично справляются с работой первой линии, но для более глубокого погружения в систему требуются правильно составленный процесс обучения и передачи знаний. При мне люди с ЗП выше средней по рынку на глазах теряли нематериальную мотивацию из-за неверно поставленного процесса работы.
Вывод: готовьте для нового замотивированного сотрудника объем работы. Иначе это плохо влияет на лояльность к работодателю и к системе. Понимайте процесс мотивации персонала — как материальный, так и не материальный.
Процесс работы
Что хотелось: После запуска системы мы начали сталкиваться с первыми трудностями: старый интерфейс выглядел ужасно и работал против всех понятий user-friendly. Основной поток звонков пошёл по недовольству именно интерфейсом, а не бизнес-процессом. Пользователи элементарно не могли завести заявку. До вновь набранной команды разработки сразу были доведены основные ошибки, но тут мы столкнулись со второй проблемой: не было коммуникации не только с теми, кто поддерживал систему извне, но и и не было расстановки приоритетов по исправлению системы — все силы были брошены на написание новых функций и продуктов, не получалось выделить человека для латания элементарных ошибок, которые сократили бы количество звонков вдвое.
Что получилось: После очередного указания на проблемы руководству оно все-таки дало разрешение на внесение правок и поток звонков уменьшился втрое.
Вывод: налаживайте процесс приоритизации задач, обсуждая порядок взаимодействия с группой разработки.
Сталкиваясь с каждой из вышеназванных задач я каждый раз приходил к руководству с предложениями оптимизации процессов и попыткой скоординировать своё видение с видением компании, но всегда натыкался или на занятость руководителя(системная проблема) или получал ответ «пока так» и «мы не хотим излишней формализации». Также я знал, что планируется расширение отдела до 5 человек и видел, что надо понять как будет происходить управление процессом поддержки и ресурсами. Я уже начал подозревать, что начальство изменило планы насчёт меня из-за моих постоянных попыток внедрить изменения. Меня уже не называли координатором или начальником, я не участвовал в митингах, связанных с развитием системы.
После этого я решил подготовить стратегию и понять, тем ли я вообще занимаюсь. Потому что начальник не коммуницировал со мной в плане стратегии совсем. Стратегия была направлена сразу на вышестоящее лицо в ИТ в Москву и, для меня картинка моей работы поменялась. Потом стратегия была направлена из Москвы вниз к моему прямому начальству и я попал в конфронтацию с местным начальником.
Вывод: Проанализируйте стратегию подразделения. Определите краткосрочные и долгосрочные планы. Обсудите видение с руководством.
Вторая часть «марлезонского балета»
После вышеописанного эпизода со мной практически прекратил общаться прямой начальник. И я начал подумывать об уходе. Изначально я видел интересный проект, который после преодоления определённых трудностей при правильном взаимодействии всех участников процесса можно было успешно завершить, получив крепкий мотивированный отдел поддержки с правильными KPI и с чёткими показателями на выходе, понятными безнесу. Сейчас же, я увидел, что отдел сваливается в рутину еще толком не развившись. В приоритете стали две задачи — ответы на звонки и описание багов(не доработок) системы посредством gitlab, которые исправляли разработчики.
Отдельная история — процесс «тестирования», как его называл руководитель, который тоже предлагалось выполнять нам. Понимания этих процедур ни у кого не было, как и отдельного тестировщика. Функциональное тестирование «черного ящика» без каких-либо показателей эффективности всей командой перед релизом. Никаких других методов не применялось. Набранный персонал не мог эффективно участвовать в тестировании из-за нехватки как бэкграунда в сфере разработки, так и из-за отсутствия процесса обучения. Даты релизов постоянно фейлились или релизы выкатывались без тестирования.
Вывод: отдел не может эффективно заниматься двумя крупными процессами параллельно. Будет два процесса идущих кое-как.
Конфронтация продолжалась. Руководитель умудрился зафейлить все элементы менеджмента, которые я считал важным:
- стратегическое видение
- контроль
- управление
- мотивация
Также были озвучены такие волшебные пункты, как «лояльность к компании в виде прихода на работу раньше и ухода позже»
Окончательно потеряв мотивацию, я пригласил начальника на беседу о моем дальнейшем положении в компании и решении ее покинуть, где мне было сказано, что отдел в текущем своём виде всех устраивает и развития отдельных элементов не планируется. В итоге я покинул компанию, получив практический опыт в попытке реализации своего видения работы отдела поддержки.
Что получилось: опыт, опыт и еще раз опыт.
Вывод: Какие ошибки я для себя зафиксировал:
- Чтобы не тратить время — фиксируйте и согласовывайте планы заранее
- Четко определите стратегию. Если возникают недомолвки — решайте вопросы сразу
- Примите решение по комфортному рабочему процессу для себя. Находите компромисс между своей материальной и не материальной мотивацией
- Возможно я слишком много времени потратил на понимание этих вещей. Многое лежало на поверхности
Также хотелось бы услышать от коллег ваши истории внедрения и нюансы, на которые я, по неопытности, не обратил внимания.
altrus
Не совсем понятно, на какой стадии находится бизнес.
— В целом, — говорил Морковин, — происходит это примерно так. Человек берет кредит. На этот кредит он снимает офис, покупает джип «Чероки» и восемь ящиков «Смирновской». Когда «Смирновская» кончается, выясняется, что джип разбит, офис заблеван, а кредит надо отдавать. Тогда берется второй кредит — в три раза больше первого. Из него гасится первый кредит, покупается джип «Гранд Чероки» и шестнадцать ящиков «Абсолюта». Когда «Абсолют»…
— Я понял, — перебил Татарский. — А что в конце?
— Два варианта. Если банк, которому человек должен, бандитский, то его в какой-то момент убивают. Поскольку других банков у нас нет, так обычно и происходит. Если человек, наоборот, сам бандит, то последний кредит перекидывается на Государственный банк, а человек объявляет себя банкротом. К нему в офис приходят судебные исполнители, описывают пустые бутылки и заблеванный факс, а он через некоторое время начинает все сначала. Правда, у Госбанка сейчас появились свои бандиты, так что ситуация чуть сложнее, но в целом картина не изменилась.
Jeisooo Автор
Если брать из вышеназванных, то я думаю, что во второй:D Бизнес был выкуплен большим акционером и пытается встать на ноги за счет внедрения ИС.
anonymous
Помню как в 2004 админил и эникействовал в одну харю, сеть из 200 компов и все работало и руководство устраивало и народ не жаловался. А сейчас наверно человек 10 надо?
Я это к тому, что сейчас штаты сотрудников раздуты + вы все как один пытаетесь впендюрить ITIL, создавая в 90% случаев дополнительный бюрократический слой(создайте заявку и + 10500 шагов, как сделать заявку), а впендюривая 1-ю, 2-ю и 3 линию — вы увеличиваете время решения проблемы + есть еще любители писать талмуды регламентов.
По мне так ты сильно усложняешь.
Mikhael1979
Когда штат компании 200 человек — можно жить без ITIL, линий поддержки и регламентов. Когда штат компании 1000 человек — без ITIL уже никак. Где там между 200 и 1000 человек граница — вопрос индивидуальный. Но граница эта есть, факт. =)
n0wheremany
А если штат программистов 2 шт обслуживает порядка 100 пользователя, эникейщика — 5 чел — обслуживает порядка 150 пользователей.
Теперь есть и 1 и 2 линия. Границ нет :?(
Kotaffei
Границы все же есть, соглашусь с Mikhael1979. Например, границы разумного :)
Сам проходил и самостоятельное сопровождение компании на 150-200 рабочих мест, и организацию саппорта в качестве руководителя ИТ-поддержки в компании на 3000+ рабочих мест. Сравнивать есть с чем. Четкой границы нет, нужно смотреть и на характер и сферу бизнеса, стоимость тех или иных простоев для него, и на уровень автоматизации и используемых для этого решений — факторов на самом деле много.
И если Ваш пример реален, то это действительно абсурдное решение, или просто кто-то решил «поиграться» в ITIL. К сожалению, много кто не может рассчитать границы эффективности применения методологий и подходов в саппорте. А потом получаются вот такие ИТ-отделы, где на самом деле и 2 эникейщика-то уже нужны только лишь для того, чтобы в отпуск или болезнь одного из них работа не встала.
Jeisooo Автор
Да, действительно, возможно усложняю. Я бы этого не делал, если бы у меня не было изначально сделать «службу поддержки». Служба поддержки это полноценная единица, которая своей работой помогает компании, а не является аппендиксом для «галочки». Без регламентов вообще не представляю как можно работать. Вот пример: пришел новый сотрудник: установить рабочую станцию, установить телефон, завести несколько учетных записей(разные ответственные). Угадаете, сколько заняло времени? 3 недели. 1,5 недели не было доступа к тикет-системе, 3 недели не было куплено телефона. Его и не купили, нашли где-то на складе в итоге.
anonymous
«Служба поддержки это полноценная единица» — давайте так, это утверждение верно если владелец бизнеса или исполнительный директор его разделяет. В ином случае — это не взлетает нигде и никогда.
Поймите одну простую вещь любой бизнесмен все считает в бабле и у 95% бизнесменов отдел техподдержки будет убыточен всегда
«Без регламентов вообще не представляю как можно работать» — можно и очень даже эффективно:
A) Если адекватные ИТ сотрудники.
B) Есть возможность раздать пи… в случае чего
В целом ситуация еще зависит от бюрократизации компании.
А вообще Велкам ин реал лайф)))
vadimpl
Работа без регламента — это тоже регламент, но неписанный, чем он и крайне опасен. Отсутствие какого-либо регламента — такого даже на кладбище нет.
gennayo
Автор столкнулся с реальной жизнью… Сочувствую…
GokenTanmay
Если к системе в целом так относились остальные, как вы описываете — то скорее всего она внедрялась «для галочки» потому, что в HQ установлена такая же.
Это нонсенс. Так же должен быть на бумаге зафиксирован порядок действия при форс мажоре. Что-то упало — как поднимать бы стали? А время поддержки итератором истекло уже? Админы остаются на ночь и усердно гуглят? Это как правило называется регламент обеспечения непрерывности бизнеса для данной ИС.Внедрение, модернизация, модификация ИС недопустима без соответствующей документации (тезис требует пояснения?)
Поддержка пользователей значительно упрощается при наличии соответствующих руководств от интеграторов. Если их нет, нужно обязательно писать свои и больше к этому интегратору никогда не обращаться.
Все документы согласовываются: владельцем бизнес-процесса, владельцем ИС, инженерами кто будет ИС сопровождать. (Больше бумаги — чище ж… па, и не в плане что на вас косяк повесить сложнее, а в плане, что админ знает какую базу откатить и не обосраться и положить несколько рядом работающих ИС)…
Пишется руководство пользователя, и все пользователи расписываются за ознакомление — это повышает личную ответственность пользователя самостоятельно открыть руководство и только потом звонить на первую линию с уже более четко сформулированным вопросом.
Далее необходимо смотреть что еще требуется.
И это так же безобразие: наличие незаконченной и не утвержденной документации — может только еще больше запутать ВСЕХ участников бизнес-процессов.
Понятие «схемы Visio» не несет ни какой информационной нагрузки. Есть методологии для схем, например BPMN, есть типы диаграмм. Понять, что и как вы попытались описать из вашей фразы не представляется возможным.
Вторая часть «марлезонского балета» показывает отсутствие Вашей коммуникации с руководством. Бизнесу не важно, что и как внедрено, важен результат, если результат достигается текущими позициями, то зачем тратить силы и менять позиции? Здесь я не претендую на истинность, но если бы Вы могли показать цифры «в плюс» от ваших предложений и изменений, то скорее всего руководство согласилось бы с ними, а то что «саппорт1 помог юзеру673 сделать формочку2 немного быстрее и веселее» руководство как правило не волнует.
Зачем Вам KPI, если деньги не Вы делили?
Опыт даже негативный это отлично, НО было бы гораздо лучше, если бы Вы сумели решить все эти проблемы, а так получается «незаконченный проект».
Jeisooo Автор
Спасибо большое за ваш комментарий. Мне очень жалко, что мне не удалось закончить начатое, хотя я очень хотел.
Полностью согласен. Опыта написания проектной документации ИС у меня не было, да и лично мне надо было заниматься только пользовательской. Но после того, как мы начали отлавливать баги и заниматься «тестированием», как-то стало некомфортно.
Да, прошу прощения. Делали диаграммы последовательностей в UML, все остальные виды я лично хотел тоже видеть, но сам я бы это не описал.
Руководство признавало, что это влияло бы положительно, но никаих больше действий не предпринималось. Не выделялись ресурсы для решения этих задач.
GokenTanmay
Хорошая практика, когда у ИТ-подразделения работающего с конкретной ИС имеется заверенная копия актуального пакета всей документации.
А как бы вы зерна от плевел отличили? Это вопрос риторический, у каждого своя методика. Некоторые вон вообще интуитивно все делают — и ничего, выживают как то.
Если не секрет то сколько ресурсов вы запросили? примерно.
Jeisooo Автор
Ресурсы, котораые я запрашивал, были только людские. Смысл был такой: для задачи по описанию процессов мне требуется регламент процессов от бизнеса и допустим, час работы разработчика в день. Да, никто не был против, если я сам это напишу, но вот отвлекать и бизнес и разработчиков никто не хотел.
Почему я лично видел в этом необходимость — напишу. При запуске нового продукта потребовалось описать разработчику работу модуля. На уровне прохождения заявки по ролям и реакции системы на определенные события. И когда мы начали это обсуждать, тогда и возникли черные дыры.
Saymon
Очередной человек, который, осознал? что то, что красиво написано в методичке или трлстой умной книжке не работает сходу в реальности, потому что остальные их не читали и предпочитают действовать в рамках своего мировоззрения. И если читать то гораздо полезнее тонкие книжки вроде "записки автоматизатора". Вот спрашивается нафига внедрять KPI в отдел из 4 х человек? Обычный руководитель и так считает что видет кто как работает при таком кол-ве и не хочет забивать себе голову ещё расчетом коэффициентов. В общем с руководством нужно коммуницировать на его языке, а не на языке красивой теории и не стесняется объяснять на пальцах. Потому что он ваших книжек и курсов вероятно не проходил и для него большая часть того что вы презентовали было просто шумом.
Jeisooo Автор
Вы знаете, я это все прекрасно понимаю и не собирался бездумно внедрять ITIL. В любой литературе или практических рекомендациях, или в опыте коллег прямо говорится — не надое его внедрять по учебнику. Но хотя бы подписать документ SLA и выставить цепочку эскалаций можно было бы? Ну элементарные же вещи. Тем более тикет-система есть. На собеседовании все это озвучивалось и начальник это не какой-то там бухгалтер, это, на секунду, зам нач.департамента IT. То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)
Saymon
"То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)" Если нет обратной связи это не коммуникация.Нужно добиваться реакции.То что он зам.нач. директора это ещё не значит, что он хорошо ориентируйся в ИТ и сервисдеске. И могла оказывать влияние проблема самозванца, про который сейчас часто пишут на Хабре. Человек мог просто бояться признаться, что не понимает о чем вы ему вещаете. ИТ такое обширное и аморфное образование, что для людей адекватных с технической точки зрения очень трудно донести базовые и очевидные на первый взгляд организационные вещи. И стоит учитывать что имеют право на жизнь зачастую весьма противоположные по смыслу вещи.Ну и опять же я не увидел в статье — Вы собирали данные о корреляции ваших улучшений с ростом продаж и прибыли? Люди стали меньше жаловаться на интерфейс, но увеличились ли от этого продажи?
Jeisooo Автор
Я указывал на необходимость такого анализа в стратегии. Чтобы собрать их, нужно было получить от бизнеса объем фактически закрытых сделок и чистой прибыли. Я озвучивал, что если сделать акцент на некоторые элементы системы, то мы можем ускорить процесс. К слову, это начали таки дорабатывать. Да и сами пользователи давали свой фидбэк. Но реакция на этот фидбэк была как указана выше:)
За "проблему самозванца" спасибо. Не знал этого термина.
it2manager
Отвечаю на вопрос по поводу внедрения KPI в отдел из 4-х человек, можно даже из 2-х :) Основное правило управление — что нельзя измерить, тем нельзя управлять и это факт. Управление на основе внутренних ощущение хорошо при общении с девушкой, на работе должны быть объективные показатели. Тут главное здравый смысл — 100 KPI для отдела в 4 человека действительно глупость, достаточно 5-7, которые оказывают 80% влияние на выполняемую работу. Самый простой пример KPI — Время прихода на работу. Если он еще общедоступен, то это будет мотивировать человека не опаздывать…
Jeisooo Автор
Я думаю, в моей ситуации было актуально соотношение открытых/выполненных заявок gitlab, количество выполненных каждым сотрудником, и количество протестированных доработок. Это минимум. Заявки, приходящие из чата можно было считать легко. Доработки — посложнее. Но все равно, оба этих показателя могли помочь при анализе задержки релиза.
Saymon
Тут такой момент. Руководство ощущало проблемы с опозданием или задержками релиза? Некоторые вещи лучше всего внедрять не просто чтоб было, а когда есть ощущение необходимости. Любое внедрение это накладные расходы.При внедрении KPI как минимум человеко-часов работы отдела кадров, а ещё бурления среди сотрудников, потому что всегда найдутся недовольные сколь логичной на ваш взгляд система расчета бы не являлась. И опять же данных по финансам у вас не было, чтоб обосновать полезность ускорения выхода релиза.
Jeisooo Автор
Знаете, были сроки. Но мне даже не приходило в голову, что не попадание в срок может не быть проблемой:) Опять же, это показывает какое-то странное отношение к системе работы: зачем ставить цели и сроки, если пофиг и на то и на другое?
Haanz
>>Приехав в провинциальный город из Москвы, я собирался устроиться начальником ИТ-отдела в какую-нибудь фирму
thumbs up
По факту собраны чуть ли не все грабли, на которые можно было наступить. Надеюсь опыт был получен не зря и в следующий раз к вопросу управления автор подойдет более профессионально.
Jeisooo Автор
Как оказалось, я то ничем и не управлял в итоге:) Да, опыт хорош. И за это еще заплатили.
vadimpl
Jeisooo, вы молодец, без шуток. Даже не так интересно, какие ошибки вы допустили на этой работе. Лично мне понравилось, что у вас были совершенно конкретные и цели, и методы их достижения, и оценка результата, чего не было и не появилось у вашего руководства. На мой взгляд, у вас была одна серьёзная проблема, которую вы закономерно не смогли решить — хреновая бизнес-модель вашей организации с начальниками соответствующей компетенции.
Ну и самое главное, что вы не остались в этом болоте, а пошли дальше.
Jeisooo Автор
Спасибо. В нашей команде были очень толковые программисты и сотрудники поддержки. Компания переманила с рынка хороших спецов высокими зп. А вот использовать их потенциал не получается.