Меня попросили документировать, что, по моему мнению, должно быть распределением ролей и обязанностей для нашей производственной системы, в которой размещено веб-приложение компании. Это частично для того, чтобы мы начали распределять ответственность немного более формально и чтобы мы могли избежать того, что не ускользнет через пробел «Я думал, что вы сделали это». Так...
Я думал, что спрошу вас у многих, какими, по вашему мнению, они должны быть.
В качестве доказательства моей работы это обзор моих текущих взглядов. Каждая линия - это отдельная роль / ответственность. Хотя у одного человека может быть одна или несколько ролей, если одна роль разделена между несколькими людьми, было бы разумно иметь для нее одного основного контактного лица.
Я предполагаю, что существуют различные сквозные обязанности (например, безопасность), которые, возможно, координируются кем-то ответственным, даже если работа выполняется несколькими людьми.
Любые мысли, дополнения, удаления или корректировки вышеперечисленного. Я открыто признаю, что нахожусь где-то за пределами моей компетенции в этом вопросе.
Размер компании и отрасли во многом влияет на структуру ИТ-отдела. В некоторых случаях многовато. Моя профессиональная деятельность - инфраструктура Интернет-технологий.
Я рекомендую разделить обязанности между основным производством и внутренней поддержкой интрасети. Даже в технологической компании будут только внутренние приложения и запросы на поддержку. Часто служба поддержки умещается во внутренней внутренней сети. В зависимости от размера вашей среды вы потенциально можете оправдать разделение производственных обязанностей между архитектурой и обслуживанием.
Мне нравится подход младшего и старшего уровней, который хорошо задокументирован SAGE должностные инструкции для системных администраторов. Это разумное практическое правило, которому нужно следовать в целом.
В небольшой среде слишком большое разделение обязанностей не будет оправдано и может способствовать разобщенности внутри отдела. Меньшие среды выигрывают от общих знаний и ответственности. По мере роста компании и ИТ-отдела может иметь смысл начать более конкретное разделение обязанностей.
Ключевые области, которые часто выигрывают от разделения ответственности:
Я бы предложил создать электронную таблицу, в которой перечислены ключевые обязанности в вашем отделе. Это могло бы быть более общим и идентифицировать конкретные области, которые имеют больше связанной с ними поддержки, такие как телефонная система или система тикетов. Назначьте персонал как основной, так и дополнительный, чтобы можно было поделиться непосредственными знаниями в дополнение к документации. Это прояснит обязанности, и их можно будет перемещать, чтобы предотвратить скуку, а также дать возможность учиться в группе. Вот некоторые примеры категорий для матрицы ответственности:
Резервные копии
Операционные системы
Этот список можно продолжать и продолжать, он будет зависеть от вашей инфраструктуры и потребностей вашей компании.
Я бы порекомендовал также рассмотреть возможность анализа навыков, попросив ваших сотрудников оценить их уровень навыков по различным технологиям, скомпилированным в электронную таблицу. Рейтинг не является окончательным и не повлияет на оценки производительности. Это может выявить потенциальные пробелы в вашем текущем наборе навыков, на которых можно сосредоточить внимание при обучении и будущем найме.
Вы довольно близки к созданию первого черновика без дополнительных подробностей о вашем приложении. Вот как восполнить оставшиеся пробелы: Составьте диаграмму с каждым компонентом в вашем приложении или который поддерживает / поддерживает / зависит от вашего приложения. Убедитесь, что у вас есть имя или команда, которая отвечает за каждую деталь. Пусть хотя бы кто-то другой, желательно не из вашей команды, сделает то же самое с нуля - убедитесь, что у вас разные точки зрения. Это включает в себя руководство - они, вероятно, будут иметь совершенно другую точку зрения, чем ИТ-специалисты, и это может быть очень верным. Это также может быть какая-то чушь CYA, и это все еще может быть актуально :-)
Вот еще несколько идей, которые могут или не могут быть применимы к вам:
AV / безопасность / исправления / соответствие нормативным требованиям. Некоторые из них могут уже совпадать с вашими пользователями ОС / мониторинга / сети. Безопасность и / или соблюдение нормативных требований может потребоваться для собственного персонала.
Документация - или от каждой команды может потребоваться своя собственная документация.
Кто занимается коммуникацией с клиентами? Есть ли система продажи билетов на случай проблем со стороны клиента? Есть ли назначенная группа, которая обрабатывает объявления о техническом обслуживании или незапланированных простоях? Если клиенты являются внешними, есть ли внутренняя группа по работе с клиентами или продавцы, которые хотели бы получать уведомления об этих вещах?
Кто принимает решения об обновлениях, запросах на улучшения и сообщениях об ошибках? Это может быть «управление продуктом» или «управление портфелем», и, вероятно, оно будет в значительной степени совпадать с деловыми людьми.
Может быть, не в рамках того, что вы хотите, но как насчет самого приложения? Например: 1) Что насчет контента (если есть)? То есть, какие роли могут составлять, утверждать и выпускать контент.
2) Какая роль решает, кто может составлять / утверждать / выпускать контент? Какая роль затем реализует это, т.е. настраивает пользователей с соответствующим доступом к черновику / утверждению / выпуску
3) Также контроль доступа. Какая роль отвечает за утверждение новых пользователей и решение о том, какой доступ они получают, а затем какая роль отвечает за его реализацию после того, как решение было принято? Т.е. фактически предоставление соответствующих разрешений, чтобы предоставить пользователю доступ, который он должен иметь.