Может кто то писал похожие документы? :)
Очень хотелось бы поиметь данный материал, может у самих разработчиков он есть? Хорошо бы чтобы он прилагался к документации, многие руководители оценили бы это :)
Приветствую.
Для себя мы регламенты не писали.
Есть определенный свод правил, например, отвечать на инциденты определенных папок в течение рабочего дня, писать комментарии в просроченные задания и поручения.
Я знаю, что в других компаниях писали внутренние регламенты по работе с программой.
Осталось заставить их поделиться.
Хотелось бы поднять тему.
А то, что "для себя регламенты не писали" коллеги из IBN, не сочтите за "комплимент", не есть хорошо, и во многом определяет не только успешность внедрений продукта, но и объясняет недоработки заложенных в него хороших идей и некоторое разочарование покупателей после углубленного знакомства с купленным продуктом.
Полагаю, что разработчики используют другой софт для организации разработки своих продуктов, поэтому регламент для IBN не писали
По поводу некоторого разочарования могу сказать, что версия 4.5 разочаровывала намного больше. С появлением 4.7 мы перестали сильно ругаться и перешли к конструктивной спокойной критике, которая приносит свои плоды.
Мне кажется, что разработчики несколько оторваны от реального применения своего продукта - отсюда недоработки, надеемся, что постепенно их устранят. Т.ч. обратная связь с пользователями крайне важна и критика тоже.
Для организации разработки своих продуктов в Mediachase мы используем именно IBN. На этапе проектирования и оценки трудозатрат иногда используется MS Project. Оперативное управление и HelpDesk - исключительно через IBN.
Любая планируемая работа вносится в IBN как поручение с указанием планируемых трудозатрат, приоритета и, при необходимости, планируемой даты окончания. Для удобства, название поручения всегда начинается с имени проекта в квадратных скобках. К примеру, "[IBN] Оптимизация библиотеки". Задачи в поледнее время используем очень редко.
Инциденты автоматически назначаются группе ответственных. Но каждый исполнитель из группы должен посмотреть на инцидент и либо взять на себя ответственность за его выполнение, либо отказаться, либо явно переназначить (когда известно, кто должен этим заниматься). Когда берёшь ответственность за инцидент, рекомендуется проставлять планируемые трудозатраты, т.к. по умолчанию стоит 3 часа, что, как правило, слишком много и будет "портить" страницу "Текущая работа".
Лично мне, как разработчику, в 90% случаев хватает всего двух страниц - "Главное - Моя работа" (блок "Открытые инциденты") и "Главное - Моя работа - Текущая работа". Изменение порядка работ в "Текущей работе" ("закрепление", смена приоритета), как правило, делаю сам. Это позволяет менеджеру видеть чем я занимаюсь и планирую заняться в ближайшее время.
Мы писали положение о комитете по развитию бизнеса, в котором были отсылки на ИБН. Так скажем для практического использования IBN в качестве инструмента. Вообще хочется отметить, что очень сложно сотрудников среднего возраста заставить и заинтересовать работать в ИБН. Инструкции здесь мало помогут. Но если так нужно - могу прислать.
Уважаемый Mr.vukin, если нет завесы конфиденциальности - опубликуйте тут, пожалуйста. Обогатите форум
Инструменты, как и инструкции к ним, мало помогут, если это не будет выгодно сотруднику (или НЕ выгодно), иными словами, есть несколько путей организовать работу - кнут, пряник и молитва. IBN не то, ни другое и ни третье, а просто "доска для публикации поручений" и монитор исполнения. Бывает, что и приказы сотрудники не читают, так что теперь?
На начальной стадии можно при начислении зарплаты/премии принимать во внимание утвержденные менеджерами листы учета времени, заслуженные сотрудники и заслуженные бездельники Вас обвинят в формализме конечно, но любой разумно сформулированный приказ формален, а с отчетами о его выполнении, правда, получается сложнее - слишком много приплетается "если бы", "учитывая объективное изменение ситуации" и т.п. Здесь IBN позволяет поистине цифровую формальность - выполнено/невыполнено. Хотя, ворох невыполненных задач может скопиться (на 99% процентах готовности).
В общем, наверное минимум требований к орг.документации такой:
Хотя полезной для построения мотивационных схем аналитики в IBN не хватает, кое что можно сочинить в настраиваемых отчетах и RDL.
P.S. Олегу Рылину респект за пост про личный опыт в IBN. Хотелось бы продолжить/пробложить эту тему - лучше понимая методологические мотивы разработчиков, у нас, юзеров, может быть шире открылись бы глаза, зашоренные всякими MSP|SPS
Если не сложно, пришлите, плз.
Понимаю, что времени прошло много, но если можно вышлите, пожалуйста, регламенты или инструкции о которых вы говорили... Очень поможет в работе
Тема не потеряла актуальности. Сейчас вкуриваю в IBN 4.7 и думаю о всё тех же регламентах. Собрались покупать 120 лицензий, нужно срочно самому как админу осваивать, потом еще пользаков обучать, а потом еще мотивировать/заставить их эффективно работать с ПО. Ведь путь внедрения у всех примерно одинаков, так почему бы и не выложить регламенты в общий доступ???
Не думаю, что IBN оправдано для 120 пользователей, разве что по стоимости...
Интересно, чем у Вас дело кончилось?
Управление проектами Help Desk Service Desk Sharepoint Учет рабочего времени Управление задачами CRM системы и внедрение