Обсуждение

отличная статья, вот мы тут в каченстве issue tracker Jira используем, очень продуктивно, с документацией в confluence

Анатолий, очень интересная мне тема для дискуссии - ибо я являюсь представителем компании, которая как раз таки разрабатывает и продает системы класса Enterprise Content Management (ECM) Documentum - если что :) (думаю, Вы с ней встречались в Росатоме) так вот, сейчас ведущие вендоры ECM-платформ все как один стали позиционировать свои продукты и как основу для решений класса case management (некоторые добавляют модное определение "adaptive", другие используют форрестеровский эпитет "dynamic", мы обходимся только двумя ключевыми словами) постараюсь в ближайшие дни написать у себя текст-ответ на Ваш пост приличного размера на эту тему - конечно, с предвзято-вендорским взглядом, но, по возможности, максимально объективно если здесь в комментах завяжется дискуссия, буду за ней тоже следить и по мере сил участвовать

О, в западных блогах это очень распространенная тема разговора: почему системы документооборота и управления контентом не являются adaptive case management системами, и почему им так хочется себя позиционировать. На эту тему очень много споров, но всё по-английски. Я тут пишу не про класс систем, ибо запрограммировать можно любую платформу на что угодно -- суп из программистского топора можно сварить всегда, были бы деньги и время. Я тут пишу про использование айтишной системы -- для содержательного дела, или для итогового оформления дела.

На практике ведь проблемы возникают чаще не из-за софта, а в силу чистой психологии. Персонал начинает сопротивляться изменениям, байкотировать их или писать заявления об уходе. Что вот с этим делать? Особенно с учетом того, что далеко не в каждую компанию стоит очередь из желающих в ней работать и простой ротацией кадров вопрос не решить.

А вот предпочитаю проблемы обсуждать раздельно, а не в куче. Про всякие "сопротивления персонала" -- это вообще другие дисциплины, это про leadership (как уболтать людей путать свои личные цели и цели компании).

ПОС - конструкция ППР - механизм

хмм... а я и issue tracker'ы не считаю за "систему поддержки коллективной работы" .... там максимум административные коллизии "отслеживаются и сопровождаются". Инженерные коллизии - в аттачах к письмам (1%), или на досках маркерами (99%). А потом результат обсуждений и споров - туда %) Т.е. наверно можно их использовать для поддержки, но почему-то не получается. Case management явочным порядком мутирует в письма начальству или инженеру в другом структурном подразделении (приёмка vs проектировщики), но не более того - как в известном анекдоте про прапорщика : "бомба падает в эпицентр" ...

Коллизии, конечно, в аттачах -- и смотреть/исправлять их можно только в разных САПР (например, в IDE для софта, или какими-нибудь diff для систем ведения версий, или какими-нибудь редакторами графики). Я тут про содержательный обмен информации между инженерами: попытки собрать нужную команду экспертов для разбирательства, поиск компетенций, сбор идей для решения, складирование результатов экспериментов и память о неудачах -- и т.д.. То, что по принципу не подлежит менеджерскому или главноинженерному (т.е. для "кто сидеть будет") утверждению. Это может идти либо в issue tracker (например, баг с момента обнаружения), либо аськами-почтой-телефоном-очными совещаниями и прочими невидимыми для основной корпоративной информационной системы каналами. А потом выясняется, что повторить опыт для чего-то похожего нельзя, он пробежал мимо всех корпоративных хранилищ информации и корпоративных способов что-то ускорить и улучшить...

В принципе с этим можно согласиться, хотя эта переписка всё еще "крупнозерниста", но и то хлеб - действительно, уже чаще замечаю, что кейсы в трекерах (а это комментарии + аттачи + связи с другими системами) всё более информативны.