Фундаментальной причиной информационного беспорядка является «отсутствие собственности».
Люди назначены на проекты. Проекты заканчиваются (или отменяются), люди уходят, а документы остаются, чтобы собрать «пыль» и стать информационным хаосом.
Это трудно предотвратить. Вики против sharepoint не решают проблемы, они просто сдвигают технологическую базу, которая используется для накопления помех.
Давайте посмотрим на беспорядок
Техническая информация о проекте / документы по архитектуре. Старые не имеют значения. Там текущие и неактуальные. Wiki.
Информация об устаревшем дизайне прошлого года - хорошо - устарела.
Протоколы собраний, элементы действий и т. Д. Элементы действий становятся частью чьего-либо отставания в спринте разработки, или, вероятно, они никогда не будут выполнены. Бэклоги - это вики. Все остальное - история, которая может быть интересной, но обычно это не так. Если оно не создавало элементы журнала спринта, не обновляло архитектуру и не решало проблему разработки, встреча, вероятно, была пустой тратой времени.
Планы проектов и дорожные карты. Задержка спринта имеет значение - это то, к чему стремится «план и план». Если вам нужно дополнить свои планы дорожными картами, вам, вероятно, следует отказаться от планирования и просто использовать Scrum и просто поддерживать текущее отставание.
Первоначальный план является чьим-то предположением во время начала проекта, и не очень интересен для текущей команды проекта.
Организация деятельности: информация о командировках - информация о командировках, бюджете, численности персонала и т. Д. Это странная смесь высокоструктурированных элементов (бюджет, организация) и неструктурированных элементов («путешествия»?)
Сколько истории вам нужно? Никто? Вики в лучшем случае. Финансовая или кадровая система - это то, где она принадлежит. Но в больших организациях системы бухгалтерского учета могут быть сложными и громоздкими в использовании, поэтому мы создаем вторичные источники информации, такие как страница SharePoint с устаревшими номерами бюджета, потому что реальные цифры бюджета скрыты в Oracle Financials.
Страницы проекта с бизнес-анализом, требованиями и т. Д. Это ваше отставание. План проекта, ваши требования и ваш анализ должны быть единым документом. В вики.
История редко имеет значение. Чья-то концепция на момент начала проекта о том, что это за требования, уже не имеет большого значения. То, к чему предъявлялись требования в их окончательной форме, имеет гораздо большее значение, чем любая история. Это материал вики.
Сколько лет «слишком стар»?
Я работал с клиентами, у которых есть 30-летнее программное обеспечение. Программное обеспечение - очевидно, - актуально, потому что оно в производстве.
Документация, однако, является мусорной. Программное обеспечение было сохранено. Он полон записей контроля изменений. «Оригинальные» спецификации должны быть тщательно переписаны с каждым сложенным элементом управления изменениями. Поскольку документы контроля изменений могут быть чрезвычайно распространенными, единственный способ увидеть, где были применены изменения, - это прочитать источник и - из этого - перепроектировать спецификацию текущего состояния.
Если мы можем понять 30-летнее приложение только путем обратного инжиниринга источника, тогда бросьте 30-летнюю стопку бумаги. Это бесполезно.
Как только обслуживание завершено, «оригинальная» спецификация обесценивается.
Как почистить?
Если вы создаете вики-страницу или сайт sharepoint, вы владеете им навсегда.
Когда ты уезжаешь, твоя замена владеет им навсегда.
Каждый менеджер на 100% ответственен за каждую информацию, которую создает его персонал. Они должны удалить вещи. Слабое решение - «архивировать» вещи. Это просто вежливый способ сказать «удалить» без «D-слова».
Очистка должна быть постоянной обязанностью каждого менеджера. Если они не могут вспомнить, что это такое или почему они им владеют, они должны быть обязаны (или «поощрены») удалить его. Все недоступное за последние два года должно быть заархивировано без вопросов. Все 10 лет - это просто неактуальная история.
Это больно, и это не похоже на создание ценности. Ведь мы работаем в IT. Наша задача - «писать» программное обеспечение, а не удалять его. Никто не сделает это, если не будет вынужден под угрозой увольнения.
Стоимость хранения относительно низкая. Стоимость уборки выше.
Как остановить цепочку электронной почты?
Отказаться от участия. Создайте кампанию «Разорвать цепь», нацеленную на замену цепочек электронной почты обновлениями вики (или обновлениями sharepoint).
Убедитесь, что ваша вики содержит ссылки и быстрее редактируется, чем электронная почта.
Вы не можете заставить людей отказаться от действительно, очень удобного решения (электронная почта). Вы должны сделать вики более ценной и почти такой же удобной, как электронная почта.
Увеличьте значение в вики. Устаревать цепочки электронной почты. Откажитесь отвечать на цепочки писем. Отказаться от принятия «действий» пунктов действия по электронной почте.