Відео: Маша и Медведь (Masha and The Bear) - Подкидыш (23 Серия) (Вересень 2024)
Я ніколи не зустрічав спільного мережевого приводу в бізнесі, який не був хоч трохи неохайним. Спільні сервери, як правило, розроблені для забезпечення можливості співпраці, а також зробити файли та інформацію вільно доступними для наших колег. Вони також допомагають підприємствам легко та ефективно збирати та створювати резервні копії даних - теоретично, тобто.
Насправді вони перетворюються на місце, де зберігаються фотографії святкової вечірки компанії з шести років тому. У цьому останньому реченні я навмисно використовував пасивний голос, оскільки, здається, ніхто ніколи не несе відповідальності за те, щоб щось поставити на спільний диск, який не повинен бути там. Речі просто з’являються. Ніхто не знає, як і чому вони туди потрапили. А отже, ніхто не знімає їх із страху наступити на чужі пальці чи видалити щось, що комусь потрібно.
Спільні простори повинні бути розроблені таким чином, щоб вони відповідали робочому процесу відділу чи компанії або організації. Речі, що мають паралельний характер, як, наприклад, дві команди, які звітуються на одному рівні управління, повинні мати паралельну структуру папок. Коли нова особа приєднується до відділу, вона або він повинні мати можливість швидко визначити, де важливі файли живуть у спільній мережі, оскільки їх розташування (назва папки та те, як вона вкладена в інші папки) повинна відображати, як розробляється бізнес. Справжній червоний прапор - це те, коли хтось, хто довго працював, не може знайти речі, бо не знає, де це, або ще гірше, навіть не знає, де він повинен бути.
Ось усе, що ми зробили, крок за кроком, щоб очистити наші неохайні сервери. Наприкінці ви знайдете підсумок результатів, а також примітки про те, що пішло правильно, а що пішло не так.
Проект очищення сервера
Крок 1. Спілкуйтеся. По-перше, ми поговорили про проблему створення неохайного сервера, включаючи, чому це проблема (неефективність, невідповідності, напруженість нашого мережевого простору), можливі рішення та процедури впровадження цих рішень.
Потім ми ще поговорили. Потім ми поговорили про те, з ким нам ще потрібно поговорити. Я не можу достатньо загнати додому важливість спілкування для успіху цього проекту. Ми багато спілкувалися, як особисто, так і електронною поштою.
Під час цих розмов ми зрозуміли, як важливо було б спілкуватися і з ІТ-персоналом. Тож ми зациклювали їх на своєму плані та запропонованій шкалі часу. ІТ-команда дала нам одну важливу пораду, яка, врешті-решт, стала нашою справжньою стартовою точкою для проекту. Вони сказали: не намагайтеся прибирати те, що у вас є; скоріше, почніть з порожнього полотна та створіть потрібну вам структуру папок і скопіюйте лише файли, які ви хочете зберегти. Все інше, за їхніми словами, архівують.
Крок 2: Перегляньте наявні дані. По-друге, всі зацікавлені сторони - переважно керівники команд - сіли за стіл з ноутбуком та проектором. Ми підключилися до спірного серверного простору та разом переглянули деякі існуючі файли, просто щоб переконатися, що ніхто не оминув увагою якусь партію файлів, яку ми повинні зберегти.
Ми також думали про наявні дані з точки зору того, як це було чи не відображало наші поточні робочі процеси. Спільні простори зазвичай використовуються для спільної роботи. Структура та назви папок повинні точно відображати той робочий процес, щоб він був корисним.
Багато з того, що ми знайшли на серверах, жахливо застаріло. Були названі папки для працівників, які не були з компанією роками. Ми знайшли файли, що відносяться до 2003 року. Були залишки проектів, які ніколи не збивалися з місця. Ніхто не потребував цього матеріалу.
Крок 3: Накресліть нову структуру. Поки ми все ще сиділи за цим столом, ми замальовували структуру папок, яку ми вважали, що має бути на місці. Усі менеджери мали придбання щодо дизайну, який повинен був відображати структуру нашої команди та робочий процес. Ось що ми розробили, хоча я зробив імена загальними, щоб вони мали сенс для когось, хто не знайомий із внутрішнім функціонуванням нашого офісу:
На найвищому рівні у нас є папки для кожної команди та спеціальний проект чи завдання, а також одна для «Ресурсів», які застосовуються для всіх команд.
Кожна команда має підмножину папок: кілька, де відображається робочий процес, по одному для кожного члена команди та додаткові папки, оскільки вони мають сенс для потреб цієї команди. Наприклад, підпапки моєї команди виглядають так:
Ми використовували підкреслення та цифри, щоб зробити наші папки робочого процесу сидіти у верхній частині структури та виглядати в тому ж порядку, в якому відбувається робота. У папці під назвою "1_EDITING" перебувають файли, готові до редагування, і залишаються, поки редагування не буде закінчено. Потім вони переходять до "2_RTP", що означає "готовий до створення" - іншими словами, редагування завершено, і ці файли готові до наступного етапу. Після створення файлу його слід перемістити в "3_PRODUCED", який по суті стає нашим живим архівом. Теоретично все, що в цій папці, може бути заархівоване, тому у нас завжди буде кеш файлів, які ми знаємо, що можемо видалити, якщо нам коли-небудь знадобиться отримати трохи місця.
Крок 4: Створіть правила. Як я вже почав пояснювати в попередньому розділі, кожна папка має деякі пов'язані з нею правила щодо того, що можна, а що не можна входити в них, або як їх слід використовувати. Наприклад, якщо хтось хоче поділитися фотографіями, він повинен розмістити його у власній папці імен. Таким чином, зрозуміло, хто відповідає за дані.
Ми також обговорювали, чи були у нас файли, які повинні бути доступними для декількох команд (ми це зробили, і ми створили для них папку "Ресурси"), і чи повинна бути заблокована будь-яка інформація (так: все, що знаходиться в папці Команди управління).
Крок 5: Забезпечте послідовність. Оскільки ми розробляли наші папки та правила їх використання, ми також шукаємо області, де ми могли б і повинні бути послідовними. Якщо структури папок та робочі процеси можуть (і повинні бути) послідовними, це робиться під час переходів персоналу, наприклад, коли хтось залишає компанію, йде у відпустку по вагітності та пологах або несподівано хворіє. Послідовність спільного серверного простору допомагає всім організаціям з’ясувати стан поточних проектів, а також те, що важливо, яка робота вже завершена тощо.
Подальший проект (який ми зараз реалізовуємо) полягає у створенні кращої узгодженості з нашими конвенціями щодо іменування файлів. Ми вирішили відмовитися від впровадження цієї зміни іменування файлів до тих пір, поки всі не звикли використовувати нові спільні папки, щоб одразу не перевантажувати нікого занадто багато новою інформацією.
Крок 6: Останнє звільнення з усіма зацікавленими сторонами. Перш ніж щось реалізувати, ми провели остаточну перевірку щодо плану з кожним зацікавленим стороною, включаючи декількох людей, яких ми спочатку не думали включати, але чиї імена з'явилися в нашому огляді існуючих даних. "Хіба це не сфера експертизи Аріель? Ми краще запитаємо її, що, на її думку, потрібно зробити в цьому розділі".
Крок 7: Доопрацюйте та повідомте часову шкалу. Останніми кроками було доопрацювання часової шкали, а потім розпочати проект. Це були заключні фрагменти головоломки:
- Вирішіть, коли і як поширювати інформацію: надсилайте електронну пошту всім співробітникам у середині тижня про нову структуру сервера, правила та всю пов'язану інформацію, включаючи дати (див. Наступний пункт).
- Встановіть дати: коли люди повинні копіювати файли, які вони хочуть зберегти (кінець тижня); коли вони повинні почати використовувати нову структуру (в нашому випадку негайно, після отримання електронного листа); коли старий сервер буде відключений (ми їм сказали в кінці тижня, але насправді ми продовжили цей термін ще кількома додатковими днями).
- Сплануйте кілька електронних листів із нагадуванням, перш ніж фактично відключити доступ до старого сервера.
- Нехай ІТ виконує фактичне скорочення.
Результати очищення сервера
Цей електронний лист із серединою тижня, що містить всю інформацію про проект очищення сервера, вийшов о 11:27 однієї середи. У кількох людей виникали пекучі запитання, але нитка відповідей на всі вгамувалася до 11:57 ранку. Це означає, що на всі основні запитання було відповідено протягом 30 хвилин.
У моїй команді додаткові роз'яснення продовжувались щодо нашого робочого процесу, але останнє, що я маю, датоване 13:05 того ж дня. Без сумніву, кілька людей задавали додаткові запитання, не відповідаючи на всі, але на більшість запитань відповіли протягом двох годин.
Протягом наступних кількох днів ми закінчували часовий графік без перешкод. ІТ-команда склала короткий звіт, в якому показала, що ми зменшили загальну кількість даних на 76 відсотків. Цифри говорять самі за себе.
Раніше
- Загальний обсяг: 250 Гб
- Кількість файлів: 447, 249
- Кількість папок: 36, 773
Після
- Загальна площа: 59, 2 Гб
- Кількість файлів: 58 624
- Кількість папок: 2962
Проект "Посмертне життя" та "Зворотній зв'язок"
Через кілька тижнів після закінчення міграції та реструктуризації сервера я поцікавився у керівника проекту, менеджерів та ІТ-мережевих адміністраторів, чи мають вони відгуки чи посмертні нотатки. Ніхто цього не робив. Все пройшло надзвичайно гладко. Ось що сказав провідний ІТ-хлопець:
"За десять років, які я тут побував, це вперше команда відомств здійснила такий проект із власного інтересу і так добре його реалізувала. Це допомагає і [іншому адміністратору ІТ-мережі], і я краще підтримую мережу, і я впевнений, що це допомагає вашій команді в процесі роботи та організації. Ми буквально попросили кілька поколінь керівництва доручити те, що ваша команда досягла на низовому рівні, і це дуже цінується ".
З моєї точки зору, я хочу, щоб ми зробили трохи інакше. Я б хотів, щоб ми спочатку особисто розповідали працівникам про проект на швидкій імпровізованій зустрічі, а не електронною поштою. Електронна пошта чудово, і нікому не подобаються зустрічі, але я відчував, що люди почували б себе більше включеними в процес, якби про них розповіли під час відкритої дискусії, а не через "ВАЖЛИВО!" електронною поштою.
Зараз у нас є кращий, послідовніший, ефективніший і простіший спільний сервер. Правила його використання чіткі, з урахуванням відповідальності. Керівники команд відповідають за папки команд, а люди відповідають за те, що є в папках їх імен.
Якщо ви думаєте ініціювати власний проект з очищення сервера у вашій організації, я сподіваюся, що ви можете отримати поради з цієї статті про важливість отримання консультацій у вашому ІТ-відділі та ретельного спілкування на кожному етапі є вирішальним для успіху.
