Comments 51
Первого человека я взял по рекомендации от старого коллеги без шаблона (проработал неделю). Следующего взял шеф. Остальных трёх (девушек) набирали частично с моим участием, но не спрашивая моих рекомендаций и не интересуясь мнением.
Не совсем понятно, на какой стадии находится бизнес.
— В целом, — говорил Морковин, — происходит это примерно так. Человек берет кредит. На этот кредит он снимает офис, покупает джип «Чероки» и восемь ящиков «Смирновской». Когда «Смирновская» кончается, выясняется, что джип разбит, офис заблеван, а кредит надо отдавать. Тогда берется второй кредит — в три раза больше первого. Из него гасится первый кредит, покупается джип «Гранд Чероки» и шестнадцать ящиков «Абсолюта». Когда «Абсолют»…
— Я понял, — перебил Татарский. — А что в конце?
— Два варианта. Если банк, которому человек должен, бандитский, то его в какой-то момент убивают. Поскольку других банков у нас нет, так обычно и происходит. Если человек, наоборот, сам бандит, то последний кредит перекидывается на Государственный банк, а человек объявляет себя банкротом. К нему в офис приходят судебные исполнители, описывают пустые бутылки и заблеванный факс, а он через некоторое время начинает все сначала. Правда, у Госбанка сейчас появились свои бандиты, так что ситуация чуть сложнее, но в целом картина не изменилась.
Я это к тому, что сейчас штаты сотрудников раздуты + вы все как один пытаетесь впендюрить ITIL, создавая в 90% случаев дополнительный бюрократический слой(создайте заявку и + 10500 шагов, как сделать заявку), а впендюривая 1-ю, 2-ю и 3 линию — вы увеличиваете время решения проблемы + есть еще любители писать талмуды регламентов.
По мне так ты сильно усложняешь.
Теперь есть и 1 и 2 линия. Границ нет :´(
Сам проходил и самостоятельное сопровождение компании на 150-200 рабочих мест, и организацию саппорта в качестве руководителя ИТ-поддержки в компании на 3000+ рабочих мест. Сравнивать есть с чем. Четкой границы нет, нужно смотреть и на характер и сферу бизнеса, стоимость тех или иных простоев для него, и на уровень автоматизации и используемых для этого решений — факторов на самом деле много.
И если Ваш пример реален, то это действительно абсурдное решение, или просто кто-то решил «поиграться» в ITIL. К сожалению, много кто не может рассчитать границы эффективности применения методологий и подходов в саппорте. А потом получаются вот такие ИТ-отделы, где на самом деле и 2 эникейщика-то уже нужны только лишь для того, чтобы в отпуск или болезнь одного из них работа не встала.
Поймите одну простую вещь любой бизнесмен все считает в бабле и у 95% бизнесменов отдел техподдержки будет убыточен всегда
«Без регламентов вообще не представляю как можно работать» — можно и очень даже эффективно:
A) Если адекватные ИТ сотрудники.
B) Есть возможность раздать пи… в случае чего
В целом ситуация еще зависит от бюрократизации компании.
А вообще Велкам ин реал лайф)))
Ну, так отлично. А как "хозяин" узнает, что клиенты довольны? И что он делает, если они не довольны? И какой поток звонков? И сколько "стоит" ваш клиент? Если от ваших действий уйдет клиент на 1млн, как будет решаться вопрос?
Это как раз видение "сотрудника" отдела. В отделе продаж тоже горазды перекидывать когда надо и не надо людей на ТП. Я в тексте про это написал, что было желание перекинуть на ТП бизнес-вопросы. Если первая линия неверно озвучивает(квалификация сотрудников, все верно) условия сделки и клиент уходит, а потом менеджер при звонке клиенту узнает, что первая линия ввела клиента в заблуждение? Это первый момент. Второй, система наглухо висит два дня и менеджеры всех клиентов переводят на ТП. Правильно ли поступают менеджеры? Должна ли поддержка удерживать клиента или должна просто сделать стандартный ответ:"ожидайте", а остальное забота менеджеров? Сколько вы потеряете клиентов при простое? Все эти вопросы должны как-то системно покрываться. Статистически, или отчетами, или еще как-то. В чем разница между поддержкой сбербанка и рокетбанка?
Я ничего не пытаюсь. Это принцип по которому работают крупные организации, и которые знают, что такое SLA для обслуживания ИС. Изначально, руководством были заявлены амбициознае задачи. Расширение клиентской базы, 24/7, метрики. Когда я увидел, что ничего это не надо — я ушел. Плюс, увидел реакцию всех остальных подразделений, когда клиентов еще нет, а за них уже никто не борется. Ну, как-то так. Вы можете оценивать компанию только с той стороны, насколько мягкий у вас стул, а я привык видеть общую картинку.
Регламент был разработан ИТ-службой и согласован совместно с несколькими руководителями подразделений, включая бизнес и CIO. Но не принят, из-за приоритетов, как раз. Зачем брать человека делать правильно, если устраивает то, как оно есть. Разрабатывать регламент того что есть, вместо того, как должно быть правильно? Да еще и с вероятностью того, что это не будет соблюдаться? А смысл?
Компания не крупная, да. Но я уже писал, что я не из тех кто бездумно все формализует. Хотелось сделать очевидные вещи — упорядочить.
Внедрение, модернизация, модификация ИС недопустима без соответствующей документации (тезис требует пояснения?)
Поддержка пользователей значительно упрощается при наличии соответствующих руководств от интеграторов. Если их нет, нужно обязательно писать свои и больше к этому интегратору никогда не обращаться.
Не получилось описать настройку создания нового продукта в системе, т. к. он создавался полупрограммируемым способом и описывать надо было совместно с программистами.Это нонсенс. Так же должен быть на бумаге зафиксирован порядок действия при форс мажоре. Что-то упало — как поднимать бы стали? А время поддержки итератором истекло уже? Админы остаются на ночь и усердно гуглят? Это как правило называется регламент обеспечения непрерывности бизнеса для данной ИС.
Все документы согласовываются: владельцем бизнес-процесса, владельцем ИС, инженерами кто будет ИС сопровождать. (Больше бумаги — чище ж… па, и не в плане что на вас косяк повесить сложнее, а в плане, что админ знает какую базу откатить и не обосраться и положить несколько рядом работающих ИС)…
Пишется руководство пользователя, и все пользователи расписываются за ознакомление — это повышает личную ответственность пользователя самостоятельно открыть руководство и только потом звонить на первую линию с уже более четко сформулированным вопросом.
Далее необходимо смотреть что еще требуется.
С грехом пополам, описаны несколько процессов в виде схем Visio.
И это так же безобразие: наличие незаконченной и не утвержденной документации — может только еще больше запутать ВСЕХ участников бизнес-процессов.
Понятие «схемы Visio» не несет ни какой информационной нагрузки. Есть методологии для схем, например BPMN, есть типы диаграмм. Понять, что и как вы попытались описать из вашей фразы не представляется возможным.
Вторая часть «марлезонского балета» показывает отсутствие Вашей коммуникации с руководством. Бизнесу не важно, что и как внедрено, важен результат, если результат достигается текущими позициями, то зачем тратить силы и менять позиции? Здесь я не претендую на истинность, но если бы Вы могли показать цифры «в плюс» от ваших предложений и изменений, то скорее всего руководство согласилось бы с ними, а то что «саппорт1 помог юзеру673 сделать формочку2 немного быстрее и веселее» руководство как правило не волнует.
получив крепкий мотивированный отдел поддержки с правильными KPIЗачем Вам KPI, если деньги не Вы делили?
Опыт даже негативный это отлично, НО было бы гораздо лучше, если бы Вы сумели решить все эти проблемы, а так получается «незаконченный проект».
Внедрение, модернизация, модификация ИС недопустима без соответствующей документации (тезис требует пояснения?)
Поддержка пользователей значительно упрощается при наличии соответствующих руководств от интеграторов. Если их нет, нужно обязательно писать свои и больше к этому интегратору никогда не обращаться.
Полностью согласен. Опыта написания проектной документации ИС у меня не было, да и лично мне надо было заниматься только пользовательской. Но после того, как мы начали отлавливать баги и заниматься «тестированием», как-то стало некомфортно.
Есть методологии для схем, например BPMN, есть типы диаграмм. Понять, что и как вы попытались описать из вашей фразы не представляется возможным.
Да, прошу прощения. Делали диаграммы последовательностей в UML, все остальные виды я лично хотел тоже видеть, но сам я бы это не описал.
Здесь я не претендую на истинность, но если бы Вы могли показать цифры «в плюс» от ваших предложений и изменений, то скорее всего руководство согласилось бы с ними...
Руководство признавало, что это влияло бы положительно, но никаих больше действий не предпринималось. Не выделялись ресурсы для решения этих задач.
… и лично мне надо было заниматься только пользовательской
Хорошая практика, когда у ИТ-подразделения работающего с конкретной ИС имеется заверенная копия актуального пакета всей документации.
… но сам я бы это не описал
А как бы вы зерна от плевел отличили? Это вопрос риторический, у каждого своя методика. Некоторые вон вообще интуитивно все делают — и ничего, выживают как то.
Не выделялись ресурсы для решения этих задач.
Если не секрет то сколько ресурсов вы запросили? примерно.
Почему я лично видел в этом необходимость — напишу. При запуске нового продукта потребовалось описать разработчику работу модуля. На уровне прохождения заявки по ролям и реакции системы на определенные события. И когда мы начали это обсуждать, тогда и возникли черные дыры.
Очередной человек, который, осознал? что то, что красиво написано в методичке или трлстой умной книжке не работает сходу в реальности, потому что остальные их не читали и предпочитают действовать в рамках своего мировоззрения. И если читать то гораздо полезнее тонкие книжки вроде "записки автоматизатора". Вот спрашивается нафига внедрять KPI в отдел из 4 х человек? Обычный руководитель и так считает что видет кто как работает при таком кол-ве и не хочет забивать себе голову ещё расчетом коэффициентов. В общем с руководством нужно коммуницировать на его языке, а не на языке красивой теории и не стесняется объяснять на пальцах. Потому что он ваших книжек и курсов вероятно не проходил и для него большая часть того что вы презентовали было просто шумом.
Вы знаете, я это все прекрасно понимаю и не собирался бездумно внедрять ITIL. В любой литературе или практических рекомендациях, или в опыте коллег прямо говорится — не надое его внедрять по учебнику. Но хотя бы подписать документ SLA и выставить цепочку эскалаций можно было бы? Ну элементарные же вещи. Тем более тикет-система есть. На собеседовании все это озвучивалось и начальник это не какой-то там бухгалтер, это, на секунду, зам нач.департамента IT. То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)
"То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)" Если нет обратной связи это не коммуникация.Нужно добиваться реакции.То что он зам.нач. директора это ещё не значит, что он хорошо ориентируйся в ИТ и сервисдеске. И могла оказывать влияние проблема самозванца, про который сейчас часто пишут на Хабре. Человек мог просто бояться признаться, что не понимает о чем вы ему вещаете. ИТ такое обширное и аморфное образование, что для людей адекватных с технической точки зрения очень трудно донести базовые и очевидные на первый взгляд организационные вещи. И стоит учитывать что имеют право на жизнь зачастую весьма противоположные по смыслу вещи.Ну и опять же я не увидел в статье — Вы собирали данные о корреляции ваших улучшений с ростом продаж и прибыли? Люди стали меньше жаловаться на интерфейс, но увеличились ли от этого продажи?
Я указывал на необходимость такого анализа в стратегии. Чтобы собрать их, нужно было получить от бизнеса объем фактически закрытых сделок и чистой прибыли. Я озвучивал, что если сделать акцент на некоторые элементы системы, то мы можем ускорить процесс. К слову, это начали таки дорабатывать. Да и сами пользователи давали свой фидбэк. Но реакция на этот фидбэк была как указана выше:)
За "проблему самозванца" спасибо. Не знал этого термина.
Тут такой момент. Руководство ощущало проблемы с опозданием или задержками релиза? Некоторые вещи лучше всего внедрять не просто чтоб было, а когда есть ощущение необходимости. Любое внедрение это накладные расходы.При внедрении KPI как минимум человеко-часов работы отдела кадров, а ещё бурления среди сотрудников, потому что всегда найдутся недовольные сколь логичной на ваш взгляд система расчета бы не являлась. И опять же данных по финансам у вас не было, чтоб обосновать полезность ускорения выхода релиза.
thumbs up
По факту собраны чуть ли не все грабли, на которые можно было наступить. Надеюсь опыт был получен не зря и в следующий раз к вопросу управления автор подойдет более профессионально.
Да, вы правы. Поэтому я и нанимался делать отдел поддержки, но не отдел тестирования:) коллектив должен был расширяться до 7человек поддержки, и чуть больше разрабов. На разрабов тоже надо уметь влиять, потому что у всех разные характеры, и без четкого указания, как будет происходить взаимодействие, никто работать не будет. А слезно просить переделать модуль ИС без ТЗ и взять на себя ответственность — это еще 10 раз подумать надо, чья это задача.
:D как раз я себе хорошо представляю. Зачем вы мне пишете очевидные вещи? Я же написал, что все что вы описали пытались навесить на саппорт. Бизнес набрал 5 человек и явно не хотел, чтобы они только трубки поднимали. Надо загрузить тп полностью:)
Универсальность, она разная бывает. Вы, конечно, можете и в домене покопаться, и циску настроить и телефон поставить, и код потестировать, и телефон прошить. Но как профессионал вы можете делать что-то одно. И дело тут даже не в глубинке.
Со вторым я согласен, а вот с первым можно было бы поспорить. Хороший линейный специалист может просто быть другого склада характера и не подходить для руководящей должности и топ-менеджмента. На этом проекте как раз хорошо было видно, что руководитель вырос из программиста, но в менеджменте слабоват.
Давайте, так как вы, я так понимаю, работаете по той же схеме, приведу вам пример: представьте, что вы должны протестировать доработку, но при этом вам надо сделать 100 итераций. По 20 итераций после каждого найденого бага. ТЗ на доработку нет, чтобы правильно протестировать вам надо сначала вникнуть в принцип работы модуля, т.е. повторить задачу разработчика. Вы тратите пол дня на разбор методики тестирования и еще пол дня на само тестирование. Теперь представьте, что эти 100 итераций можно свернуть в один цикл и разраб может сделать это за час, а вам надо делать такое тестирование по каждой доработке(допустим их 10) к каждому спринту. Готовы ли вы заплатить за час работы программиста, чтобы убрать с себя ~10рабочих дней? Эти 10 рабочих дней вы можете потратить на monkey job, или на саморазвитие-допустим, научится писать тесты. В данном примере несколько нюансов, решив которые вы оптимизируете свою работу и работу отдела. Кто должен принимать решение и какое?
То есть, по вашему разраб(вы посмотрите, что такое тестирование ПО, тестировщики — почти разрабы) не должен тестировать, а саппорт (который только интерфейс может протестировать) почему-то должен? Просто потому, что саппорт дешевле? Но я вам рассчитал экономию, а вы не поняли в чем. Судя по "обилию терминов" я в этой сфере уже 8 лет, представляю жизненный цикл ПО от встречи с заказчиком и проектированию до тестирования и приемки проекта. Откройте любое мало мальское нормальное ТЗ и встретите там термины. Вы еще раз прочтите статью. Вы мне вменяете, что я отказывался работать, а я вам говорю, что та работа, которую "давали" была несестематизированна и непродуктивна. Давайте закончим нашу беседу и каждый останется при своем:)
Тестировать как? Вы в курсе как оно тестируется? То есть, не "метод тыка", а автоматизацию тестирования. "Метод тыка", это не тестирование, это затыкание одной дыры их ста.
Отдел поддержки: ожидание vs реальность