Регламент был разработан ИТ-службой и согласован совместно с несколькими руководителями подразделений, включая бизнес и CIO. Но не принят, из-за приоритетов, как раз. Зачем брать человека делать правильно, если устраивает то, как оно есть. Разрабатывать регламент того что есть, вместо того, как должно быть правильно? Да еще и с вероятностью того, что это не будет соблюдаться? А смысл?
Компания не крупная, да. Но я уже писал, что я не из тех кто бездумно все формализует. Хотелось сделать очевидные вещи — упорядочить.
Тестировать как? Вы в курсе как оно тестируется? То есть, не "метод тыка", а автоматизацию тестирования. "Метод тыка", это не тестирование, это затыкание одной дыры их ста.
:D как раз я себе хорошо представляю. Зачем вы мне пишете очевидные вещи? Я же написал, что все что вы описали пытались навесить на саппорт. Бизнес набрал 5 человек и явно не хотел, чтобы они только трубки поднимали. Надо загрузить тп полностью:)
Я ничего не пытаюсь. Это принцип по которому работают крупные организации, и которые знают, что такое SLA для обслуживания ИС. Изначально, руководством были заявлены амбициознае задачи. Расширение клиентской базы, 24/7, метрики. Когда я увидел, что ничего это не надо — я ушел. Плюс, увидел реакцию всех остальных подразделений, когда клиентов еще нет, а за них уже никто не борется. Ну, как-то так. Вы можете оценивать компанию только с той стороны, насколько мягкий у вас стул, а я привык видеть общую картинку.
Это как раз видение "сотрудника" отдела. В отделе продаж тоже горазды перекидывать когда надо и не надо людей на ТП. Я в тексте про это написал, что было желание перекинуть на ТП бизнес-вопросы. Если первая линия неверно озвучивает(квалификация сотрудников, все верно) условия сделки и клиент уходит, а потом менеджер при звонке клиенту узнает, что первая линия ввела клиента в заблуждение? Это первый момент. Второй, система наглухо висит два дня и менеджеры всех клиентов переводят на ТП. Правильно ли поступают менеджеры? Должна ли поддержка удерживать клиента или должна просто сделать стандартный ответ:"ожидайте", а остальное забота менеджеров? Сколько вы потеряете клиентов при простое? Все эти вопросы должны как-то системно покрываться. Статистически, или отчетами, или еще как-то. В чем разница между поддержкой сбербанка и рокетбанка?
Да, вы правы. Поэтому я и нанимался делать отдел поддержки, но не отдел тестирования:) коллектив должен был расширяться до 7человек поддержки, и чуть больше разрабов. На разрабов тоже надо уметь влиять, потому что у всех разные характеры, и без четкого указания, как будет происходить взаимодействие, никто работать не будет. А слезно просить переделать модуль ИС без ТЗ и взять на себя ответственность — это еще 10 раз подумать надо, чья это задача.
Ну, так отлично. А как "хозяин" узнает, что клиенты довольны? И что он делает, если они не довольны? И какой поток звонков? И сколько "стоит" ваш клиент? Если от ваших действий уйдет клиент на 1млн, как будет решаться вопрос?
Знаете, были сроки. Но мне даже не приходило в голову, что не попадание в срок может не быть проблемой:) Опять же, это показывает какое-то странное отношение к системе работы: зачем ставить цели и сроки, если пофиг и на то и на другое?
Спасибо. В нашей команде были очень толковые программисты и сотрудники поддержки. Компания переманила с рынка хороших спецов высокими зп. А вот использовать их потенциал не получается.
Я думаю, в моей ситуации было актуально соотношение открытых/выполненных заявок gitlab, количество выполненных каждым сотрудником, и количество протестированных доработок. Это минимум. Заявки, приходящие из чата можно было считать легко. Доработки — посложнее. Но все равно, оба этих показателя могли помочь при анализе задержки релиза.
Ресурсы, котораые я запрашивал, были только людские. Смысл был такой: для задачи по описанию процессов мне требуется регламент процессов от бизнеса и допустим, час работы разработчика в день. Да, никто не был против, если я сам это напишу, но вот отвлекать и бизнес и разработчиков никто не хотел.
Почему я лично видел в этом необходимость — напишу. При запуске нового продукта потребовалось описать разработчику работу модуля. На уровне прохождения заявки по ролям и реакции системы на определенные события. И когда мы начали это обсуждать, тогда и возникли черные дыры.
Я указывал на необходимость такого анализа в стратегии. Чтобы собрать их, нужно было получить от бизнеса объем фактически закрытых сделок и чистой прибыли. Я озвучивал, что если сделать акцент на некоторые элементы системы, то мы можем ускорить процесс. К слову, это начали таки дорабатывать. Да и сами пользователи давали свой фидбэк. Но реакция на этот фидбэк была как указана выше:)
За "проблему самозванца" спасибо. Не знал этого термина.
Спасибо большое за ваш комментарий. Мне очень жалко, что мне не удалось закончить начатое, хотя я очень хотел.
Внедрение, модернизация, модификация ИС недопустима без соответствующей документации (тезис требует пояснения?)
Поддержка пользователей значительно упрощается при наличии соответствующих руководств от интеграторов. Если их нет, нужно обязательно писать свои и больше к этому интегратору никогда не обращаться.
Полностью согласен. Опыта написания проектной документации ИС у меня не было, да и лично мне надо было заниматься только пользовательской. Но после того, как мы начали отлавливать баги и заниматься «тестированием», как-то стало некомфортно.
Есть методологии для схем, например BPMN, есть типы диаграмм. Понять, что и как вы попытались описать из вашей фразы не представляется возможным.
Да, прошу прощения. Делали диаграммы последовательностей в UML, все остальные виды я лично хотел тоже видеть, но сам я бы это не описал.
Здесь я не претендую на истинность, но если бы Вы могли показать цифры «в плюс» от ваших предложений и изменений, то скорее всего руководство согласилось бы с ними...
Руководство признавало, что это влияло бы положительно, но никаих больше действий не предпринималось. Не выделялись ресурсы для решения этих задач.
Да, действительно, возможно усложняю. Я бы этого не делал, если бы у меня не было изначально сделать «службу поддержки». Служба поддержки это полноценная единица, которая своей работой помогает компании, а не является аппендиксом для «галочки». Без регламентов вообще не представляю как можно работать. Вот пример: пришел новый сотрудник: установить рабочую станцию, установить телефон, завести несколько учетных записей(разные ответственные). Угадаете, сколько заняло времени? 3 недели. 1,5 недели не было доступа к тикет-системе, 3 недели не было куплено телефона. Его и не купили, нашли где-то на складе в итоге. Аргументация: ну, мы телефоны ставим 10 раз в год, не видим причины тут что-то менять и регламентировать:)
Вы знаете, я это все прекрасно понимаю и не собирался бездумно внедрять ITIL. В любой литературе или практических рекомендациях, или в опыте коллег прямо говорится — не надое его внедрять по учебнику. Но хотя бы подписать документ SLA и выставить цепочку эскалаций можно было бы? Ну элементарные же вещи. Тем более тикет-система есть. На собеседовании все это озвучивалось и начальник это не какой-то там бухгалтер, это, на секунду, зам нач.департамента IT. То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)
Александр, если хочется разобраться, то можем пообщаться и по материалам и по стратегиям. Если интересно, можно пройти курс консультанта-методиста по финансовой грамотности. Потому что у нас даже есть федеральная программа по развитию фин.грамотности населения на которую выделяются деньги. Но только выглядит это все так же, как и все государственное. Туманно. Как раз сегодня была конференция для региональных представителей этой программы. Много красивых отчетов по реализации программы, много статистики. А результаты на местах вы видите вокруг. 1 из 10 может и ведет бюджет, 1 из 20 знает куда жаловаться при экономической афёре, 1 из 100 представляет что-то про инвестирование. 1 из 1000 инвестирует. Вот один из сайтов с материалами. Слева фильтры
Добрый день. Сейчас все банки пишут свои системы учета финансов со структурированием по статьям. Я пользуюсь google docs шаблонами, чтобы вести ежемесячный бюджет по нескольким картам(просто выписываю результирующие числа из каждого сервиса по статьям), а потом заношу их в годовой шаблон. Доверять сторонним сервисам работать со своими картами автоматом не хочу. Вносить каждый чек в программу учета пробовал, но это удобно для самоконтроля и когда только начинаешь этим заниматься.
Выглядит это вот так
Регламент был разработан ИТ-службой и согласован совместно с несколькими руководителями подразделений, включая бизнес и CIO. Но не принят, из-за приоритетов, как раз. Зачем брать человека делать правильно, если устраивает то, как оно есть. Разрабатывать регламент того что есть, вместо того, как должно быть правильно? Да еще и с вероятностью того, что это не будет соблюдаться? А смысл?
Компания не крупная, да. Но я уже писал, что я не из тех кто бездумно все формализует. Хотелось сделать очевидные вещи — упорядочить.
Тестировать как? Вы в курсе как оно тестируется? То есть, не "метод тыка", а автоматизацию тестирования. "Метод тыка", это не тестирование, это затыкание одной дыры их ста.
:D как раз я себе хорошо представляю. Зачем вы мне пишете очевидные вещи? Я же написал, что все что вы описали пытались навесить на саппорт. Бизнес набрал 5 человек и явно не хотел, чтобы они только трубки поднимали. Надо загрузить тп полностью:)
Я ничего не пытаюсь. Это принцип по которому работают крупные организации, и которые знают, что такое SLA для обслуживания ИС. Изначально, руководством были заявлены амбициознае задачи. Расширение клиентской базы, 24/7, метрики. Когда я увидел, что ничего это не надо — я ушел. Плюс, увидел реакцию всех остальных подразделений, когда клиентов еще нет, а за них уже никто не борется. Ну, как-то так. Вы можете оценивать компанию только с той стороны, насколько мягкий у вас стул, а я привык видеть общую картинку.
Это как раз видение "сотрудника" отдела. В отделе продаж тоже горазды перекидывать когда надо и не надо людей на ТП. Я в тексте про это написал, что было желание перекинуть на ТП бизнес-вопросы. Если первая линия неверно озвучивает(квалификация сотрудников, все верно) условия сделки и клиент уходит, а потом менеджер при звонке клиенту узнает, что первая линия ввела клиента в заблуждение? Это первый момент. Второй, система наглухо висит два дня и менеджеры всех клиентов переводят на ТП. Правильно ли поступают менеджеры? Должна ли поддержка удерживать клиента или должна просто сделать стандартный ответ:"ожидайте", а остальное забота менеджеров? Сколько вы потеряете клиентов при простое? Все эти вопросы должны как-то системно покрываться. Статистически, или отчетами, или еще как-то. В чем разница между поддержкой сбербанка и рокетбанка?
Да, вы правы. Поэтому я и нанимался делать отдел поддержки, но не отдел тестирования:) коллектив должен был расширяться до 7человек поддержки, и чуть больше разрабов. На разрабов тоже надо уметь влиять, потому что у всех разные характеры, и без четкого указания, как будет происходить взаимодействие, никто работать не будет. А слезно просить переделать модуль ИС без ТЗ и взять на себя ответственность — это еще 10 раз подумать надо, чья это задача.
Ну, так отлично. А как "хозяин" узнает, что клиенты довольны? И что он делает, если они не довольны? И какой поток звонков? И сколько "стоит" ваш клиент? Если от ваших действий уйдет клиент на 1млн, как будет решаться вопрос?
Знаете, были сроки. Но мне даже не приходило в голову, что не попадание в срок может не быть проблемой:) Опять же, это показывает какое-то странное отношение к системе работы: зачем ставить цели и сроки, если пофиг и на то и на другое?
Спасибо. В нашей команде были очень толковые программисты и сотрудники поддержки. Компания переманила с рынка хороших спецов высокими зп. А вот использовать их потенциал не получается.
Почему я лично видел в этом необходимость — напишу. При запуске нового продукта потребовалось описать разработчику работу модуля. На уровне прохождения заявки по ролям и реакции системы на определенные события. И когда мы начали это обсуждать, тогда и возникли черные дыры.
Я указывал на необходимость такого анализа в стратегии. Чтобы собрать их, нужно было получить от бизнеса объем фактически закрытых сделок и чистой прибыли. Я озвучивал, что если сделать акцент на некоторые элементы системы, то мы можем ускорить процесс. К слову, это начали таки дорабатывать. Да и сами пользователи давали свой фидбэк. Но реакция на этот фидбэк была как указана выше:)
За "проблему самозванца" спасибо. Не знал этого термина.
Полностью согласен. Опыта написания проектной документации ИС у меня не было, да и лично мне надо было заниматься только пользовательской. Но после того, как мы начали отлавливать баги и заниматься «тестированием», как-то стало некомфортно.
Да, прошу прощения. Делали диаграммы последовательностей в UML, все остальные виды я лично хотел тоже видеть, но сам я бы это не описал.
Руководство признавало, что это влияло бы положительно, но никаих больше действий не предпринималось. Не выделялись ресурсы для решения этих задач.
Вы знаете, я это все прекрасно понимаю и не собирался бездумно внедрять ITIL. В любой литературе или практических рекомендациях, или в опыте коллег прямо говорится — не надое его внедрять по учебнику. Но хотя бы подписать документ SLA и выставить цепочку эскалаций можно было бы? Ну элементарные же вещи. Тем более тикет-система есть. На собеседовании все это озвучивалось и начальник это не какой-то там бухгалтер, это, на секунду, зам нач.департамента IT. То есть мы как бы коммуницировали на одном языке. Только я говорил, а он молчал:)
Если брать из вышеназванных, то я думаю, что во второй:D Бизнес был выкуплен большим акционером и пытается встать на ноги за счет внедрения ИС.
Вот один из сайтов с материалами. Слева фильтры
Выглядит это вот так