Организация информации для организации разработки программного обеспечения
Со временем наша информационная стратегия стала повсеместной, и мы стремимся выработать более четкую политику и более четкий способ для всех синхронизировать обмен информацией. Стоит отметить, что в организации более 300 человек, и она находится в разных странах мира. Кроме того, у нас есть люди, которые чувствуют себя комфортно в Sharepoint, люди, которые чувствуют себя комфортно в слиянии и т. Д., Так что здесь определенно есть фактор "изменения"
Вот наши текущие проблемы и что мы думаем о них делать. Я хотел бы услышать отзывы, предложения и т. Д.
Содержание у нас сегодня:
- Техническая информация о дизайне / документы по архитектуре
- Протокол встречи, пункты действий и т. Д.
- Планы проектов и дорожные карты
- информация о деятельности организации - информация о командировках, бюджете, численности персонала и т. д.
- Страницы проекта с бизнес-анализом, требованиями и т. Д.
Вот некоторые из наших основных вопросов:
Куда должны идти данные - слияние WIKI с Sharepoint и с сайтом интрасети - мы используем слияние WIKI для № 1, № 2, № 3, № 5, но мы также используем sharepoint для № 1, № 3, № 4, № 5. Мы пытаемся выяснить, следует ли указывать каждый номер в определенном месте, чтобы все было согласованно. Мы используем Sharepoint больше как структуру каталогов документов, и мы используем слияние для большего количества изменяемого контента.
Устаревшие данные - это, возможно, культурная вещь в организации, но в определенные моменты времени данные просто устаревают и больше не актуальны. Что является лучшим способом обеспечить, чтобы старые данные не создавали много шума и чтобы последние данные были актуальными. Должны ли быть люди в организации, ответственные за это, или это должна быть неявная "работа каждого". Это больше проблема, когда люди уходят, присоединяются и т. Д.,
Более активное использование - что является лучшим способом отвлечь людей от электронной почты и попытаться остановиться и подумать: "Может ли это быть полезным для других?. Позвольте мне поместить это в централизованное место, а не в цепочки электронной почты".,
также любые другие истории о хороших способах улучшения связи и управления информацией в организации.
4 ответа
Фундаментальной причиной информационного беспорядка является "отсутствие собственности".
Люди назначены на проекты. Проекты заканчиваются (или отменяются), люди уходят, а документы остаются позади, чтобы собрать пыль и стать информационным хаосом.
Это трудно предотвратить. Вики против sharepoint не решают проблемы, а просто сдвигают технологическую базу, которая используется для накопления помех.
Давайте посмотрим на беспорядок
Техническая информация о дизайне / документация по архитектуре. Старые не имеют значения. Там текущие и неактуальные. Wiki.
Устаревшая информация о дизайне прошлого года - хорошо - устарела.
Протоколы собраний, элементы действий и т. Д. Элементы действий становятся частью чьего-либо отставания в спринте разработки, или, вероятно, они никогда не будут выполнены. Бэклоги - это вики. Все остальное - история, которая может быть интересной, но обычно это не так. Если он не создавал элементы журнала спринта, не обновлял архитектуру и не решал проблему разработки, встреча, вероятно, была пустой тратой времени.
Планы проектов и дорожные карты. Задержка спринта имеет значение - это то, к чему стремится "план и план". Если вам нужно дополнить свои планы дорожными картами, вам, вероятно, следует отказаться от планирования и просто использовать Scrum и просто поддерживать текущее отставание.
Первоначальный план - чье-то предположение о времени начала проекта, и он не очень интересен для текущей команды проекта.
Информация об организации бизнеса - информация о командировках, бюджете, численности персонала и т. Д. Это странная смесь высокоструктурированных вещей (бюджет, организация) и неструктурированных вещей ("путешествия"?)
Сколько истории вам нужно? Никто? Вики в лучшем случае. Финансовая или кадровая система - это то, где она принадлежит. Но в больших организациях системы бухгалтерского учета могут быть сложными и обременительными в использовании, поэтому мы создаем вторичные источники информации, такие как страница SharePoint с устаревшими номерами бюджета, потому что реальные цифры бюджета скрыты в Oracle Financials.
Страницы проекта с бизнес-анализом, требованиями и т. Д. Это ваше отставание. План проекта, ваши требования и ваш анализ должны быть единым документом. В вики
История редко имеет значение. Чья-то концепция во время начала проекта о том, что это за требования, уже не имеет большого значения. То, к чему предъявлялись требования в их окончательной форме, имеет гораздо большее значение, чем любая история. Это материал вики.
Сколько лет "слишком стар"? Я работал с клиентами, у которых есть 30-летнее программное обеспечение. Программное обеспечение - очевидно - актуально, потому что оно в производстве.
Документация, однако, вся мусорная. Программное обеспечение было сохранено. Он полон записей контроля изменений. "Оригинальные" спецификации должны быть тщательно переписаны с каждым сложенным элементом управления изменениями. Поскольку документы управления изменениями могут быть чрезвычайно распространенными, единственный способ увидеть, где были применены изменения, это прочитать источник и - из этого - перепроектировать текущее состояние спецификации.
Если мы можем понять 30-летнее приложение только путем обратного инжиниринга источника, тогда бросьте 30-летнюю стопку бумаги. Это бесполезно.
Как только обслуживание завершено, "оригинальная" спецификация обесценилась.
Как это почистить? Если вы создаете вики-страницу или сайт sharepoint, вы владеете им навсегда. Когда ты уезжаешь, твоя замена владеет им навсегда.
Каждый менеджер на 100% ответственен за каждую информацию, которую создает его персонал. Они должны удалить вещи. Слабое решение - "архивировать" вещи. Это просто вежливый способ сказать "удалить" без "D-слова".
Очистка должна быть постоянной обязанностью каждого менеджера. Если они не могут вспомнить, что это такое или почему они им владеют, они должны быть обязаны (или "поощрены") удалить его. Все недоступное за последние два года должно быть заархивировано без вопросов. Все 10 лет это просто неактуальная история.
Это больно, и это не похоже на создание ценности. Ведь мы работаем в IT. Наша задача - "писать" программное обеспечение, а не удалять его. Никто не сделает это, если не будет вынужден под угрозой увольнения.
Стоимость хранения относительно низкая. Стоимость очистки оказывается выше.
Как остановить цепочку электронной почты?
Отказаться от участия. Создайте кампанию "Разорвать цепь", нацеленную на замену цепочек электронной почты обновлениями вики (или обновлениями sharepoint).
Убедитесь, что ваша вики содержит ссылки и быстрее редактируется, чем электронная почта.
Вы не можете заставить людей отказаться от действительно удобного решения (электронная почта). Вы должны сделать вики более ценной и почти такой же удобной, как электронная почта.
Увеличьте значение в вики. Устаревать цепочки электронной почты. Отказаться отвечать на цепочки писем. Отказаться от принятия "действий" пунктов действия по электронной почте.
Есть ли причина, по которой вики не могут хранить файлы?
Кроме того, возможно, ограничение почтового сервера запретом на вложения во внутренние сообщения электронной почты является слишком суровым, но просить людей поместить в вики все, что нужно отправлять по электронной почте более одного раза, чертовски полезно.
Вы можете использовать Confluence Wiki для хранения документов в качестве вложений, а пути Wiki работают как пути к файлам в Sharepoint.
Re: устаревшие данные: владелец данных (как человек, так и команда) и убедитесь, что результаты для владельцев включают обслуживание ВСЕХ данных.
Что касается "Отключить электронную почту", это трудно сделать, так как вы не можете заставить людей делать это, если не следить за всей электронной почтой... но вы можете попробовать некоторые результаты с метриками относительно контента, добавленного в Вики. Таким образом, люди с большей вероятностью захотят повторно использовать уже проделанную работу с электронной почтой, чтобы вставить ее в Wiki, чтобы соответствовать "квоте", вместо того, чтобы сочинять свежие вещи.
Наша компания и / или команда использовали все эти три подхода с некоторой степенью успеха в прошлом
Эффективное управление информацией - действительно очень сложная проблема. Мы обнаружили, что принцип "чем проще, тем лучше" может творить чудеса, чтобы решить его.
Куда должны поступать данные - мы большие сторонники вики-подхода. Фактически, мы используем Confluence для совместного использования, возможно, любого типа информации, кроме действительно больших двоичных файлов. Для них мы используем Dropbox. Его простота - абсолютно убийственная особенность. (Совет: вы можете интегрировать их с плагином Dropbox in Confluence.)
Поиск устаревших данных - в нашем определении устаревшие данные - это то, что не обновляется и не просматривается в течение определенного периода времени. Плагин Archiving of Confluence может быстро и автоматически найти их, а затем сообщить об этом авторам и администраторам, которые могут их обновить (или удалить, см. Следующий пункт). Есть, конечно, информация, которая никогда не истекает, но плагин может пропустить их после того, как вы отметите соответствующие страницы.
Удаление устаревших данных - мы довольно агрессивны в этом. Если данные больше не являются (очень) важными, очистите их сейчас! Мы можем смело следовать этой практике, потому что мы никогда не удаляем данные. Мы просто перемещаем устаревшие данные в скрытые пространства архивов, используя опять же плагин архивирования. Если мы передумаем позже, очень легко найти его в архиве, просмотреть или даже восстановить.
Более активное использование - наше правило: если информация должна быть постоянной, не отправляйте ее по электронной почте. Поместите его на вики-страницу. Некоторым людям трудно найти лучшее место для информации (какое место - где в иерархии страниц?). К сожалению, плохо организованные пространства с неопределенным охватом - еще один большой фактор эффективности. Крупные компании могут рассмотреть возможность введения вики-садовника, чтобы вылечить это.