Я представитель системного администратора (по сути, разработчик, отвечающий за объединение этих двух областей), и одна из моих задач - представить предложения по улучшению на высших уровнях управления. Я подумывал о планировании задач моих коллег из области системных администраторов на еженедельной основе ... но я не знаю, есть ли лучший подход.
Я имею в виду ... Я хотел бы сделать область системного администратора более "гибкой", если вы понимаете, о чем я. Мой босс просит также разработать какое-то планирование проекта в этой области ...
Что ты предлагаешь?
Не могли бы вы подробнее рассказать о тех областях, которые вы собираетесь улучшить? Не вся работа SysAdmin «дружественна к проекту» - большая часть ее работы (повторяющиеся задачи, контрольные списки, профилактическое обслуживание), большая часть больше похожа на отладку (обработка обращений в службу поддержки), а часть - на проектирование, создание и развертывание новой инфраструктуры. Не все из них будут хорошо вписываться в гибкие методологии, но некоторые, безусловно, будут.
Лучший совет, который я могу дать вам для начала, - это понять природу их общей рабочей нагрузки и попытаться выяснить, сколько их времени связано с различными аспектами работы. Если вы заинтересованы в улучшении возможностей и времени для создания новой \ улучшенной инфраструктуры, обязательно примите участие в одном из этих проектов. Познакомьтесь с командой и объясните, почему существует необходимость в этом соединении (и я думаю, что это отличная идея). Если бы я был на вашем месте, я бы начал это с того, чтобы сделать его улицей с двусторонним движением - например, мы хотим улучшить X, Y и Z, так что вы хотите, чтобы мы были (либо сторона разработчиков, либо менеджмент, либо оба, в зависимости от того, что вам нравится носят) делать взамен.
Одна вещь, на которую следует обратить внимание, - это выявить действительно важные вещи. Например, если я работаю над развертыванием какой-либо новой инфраструктуры и получаю предупреждение о том, что есть проблема с производительностью в SAN или что-то идет не так с брандмауэрами, я собираюсь остановить работу над проектом и сосредоточиться на производственной проблеме, пока она не появится. решено, или кто-то другой вступает во владение. Если это означает, что крайний срок проекта снят, то пусть будет так. Теперь я думаю, что это очевидно, но я был в ситуации, когда в прошлом менеджер по развертыванию тащил меня по углам из-за несоблюдения сроков, потому что я был занят восстановлением и запуском производственного объекта стоимостью 2 миллиарда долларов после катастрофы, поэтому я ' Я знаю, что я считаю неудачными попытками повысить эффективность проекта.
По моему опыту, по мере того, как организации становятся больше, между группами разработчиков и администраторов возникает довольно значительная (и нездоровая) дистанция, что очень жаль, и усилия по устранению или предотвращению этого заслуживают одобрения.
Многие люди пытаются применить принципы гибкой разработки программного обеспечения к системному администрированию. и там написано больше, чем я могу вам здесь рассказать. Я упомяну некоторые ресурсы позже, но сначала несколько советов:
вот упомянутые ресурсы:
Еженедельные встречи в целом звучат нормально. Но если вы хотите преодолеть разрыв, ты должен пойти спросить их или, может быть, их лидерство, если оно есть. Я думаю, вам следует сначала попытаться узнать, что они собой представляют, каковы их общие задачи и т. Д. Тогда у вас могут быть лучшие идеи о том, какой может быть рабочая структура. Если вы придете к плану и не поговорите с ними, они могут защищаться и почувствовать, что вы настроены немного враждебно.
Это важно для будущих отношений, потому что лучшая среда, вероятно, получится из того, что и разработчики, и администраторы смогут уступить потребностям друг друга и потратить время на то, чтобы понять точку зрения друг друга. Если вам не кажется, что ваша главная задача - сначала понять их точку зрения, они, вероятно, не будут открыты для вашей.
Кроме того, вы можете быть осторожны с их "гибкостью", они могут смотреть на вас как на какое-то рвение ;-)
Вам определенно нужно встретиться со своими коллегами-системными администраторами и узнать о том, что они делают, прежде чем вы начнете рекомендовать какие-либо изменения. Даже если у вас есть предыдущий опыт работы с ИТ, у каждой компании есть свои особенности, и нет ничего более раздражающего для человека, чем тот, кто пытается сказать ему, что делать, но не понимает, что он на самом деле делает.
Первое, что я хотел бы выяснить, - это то, как они отслеживают, что нужно сделать. Должны быть некоторые повторяющиеся задачи, которые выполняются по расписанию, и несколько разовых задач, которые включают запросы на поддержку от пользователей и проектов, над которыми работает ИТ. Если есть несколько списков в нескольких местах, вы можете начать с попытки объединить все, желательно в электронной форме, доступной для нескольких людей (тех, кому нужен доступ). Задачи, не являющиеся частью конкретного проекта, следует объединять в общие проекты. Например, проект «Задачи обслуживания ИТ» может включать в себя все задачи планового обслуживания, которые выполняются ежедневно / еженедельно / ежемесячно. Было бы разумно распределить по категориям более определенно, если несколько задач связаны между собой. Например, если есть семь задач, связанных с резервным копированием данных, вы можете захотеть поместить их в отдельный проект, а не в общий проект задач ИТ-обслуживания.
Второе, что нужно выяснить, это то, как они определяют приоритет. Это больше похоже на очередь (FIFO) или стек (LIFO)? Запланированные задачи важнее разовых запросов? Что остается в тени или откладывается на черный день? Вы должны надеяться, что обнаружите, что катастрофические проблемы поднимаются в верхнюю часть списка, потому что системы, используемые для производства, должны работать, иначе ничего не будет сделано, точно так же, как программист отдает приоритет исправлению ошибок над добавлением новых функций. Поскольку вы упомянули слово «гибкий», я бы хотел узнать, учитывается ли время, необходимое для выполнения запроса, при расстановке приоритетов. Я считаю, что выполнение быстрых задач (10-15 минут или меньше) сразу помогает снизить громкость и довести пользователей. Приоритетность более длительных задач должна быть максимально возможной / необходимой; это зависит от того, сколько задач и сколько ресурсов доступно для работы над задачами. Каждая задача должна быть назначена одному ресурсу, и каждый ресурс должен иметь возможность фильтровать список задач, чтобы отображать только свои собственные. Типы менеджеров должны иметь возможность видеть задачи всех, кто находится ниже них, с возможностью сортировки по людям или по проектам.