Успех на работе. Как его достичь?::Журнал СА 7-8.2011
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1826
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1887
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1446
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1066
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1636
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Успех на работе. Как его достичь?

Архив номеров / 2011 / Выпуск №7-8 (104-105) / Успех на работе. Как его достичь?

Рубрика: Карьера/Образование /  Вектор роста

Константин Кондаков КОНСТАНТИН КОНДАКОВ, директор по ИТ в поисковом гиганте Looksmart в Сан-Франциско. Занимается автоматизацией и гетерогенными сетями. Женат, двое детей. Хобби – альтернативное кино и видеосъемка

Успех на работе
Как его достичь?

Итак, вы отработали несколько дней на новом месте. После того как более-менее освоились, возникают вопросы о стратегической линии поведения, приоритетах, тонкостях общения с руководством, а самое главное – как быстро понять, что работает правильно, а что не очень, и как решить эти проблемы

На что надо обратить особое внимание

Недавно в русском переводе вышло два интересных издания, рецензию на которые написал Дмитрий Навар в юбилейном (100-м) номере «Системного администратора». Речь идет о книгах «Системное и сетевое администрирование. Практическое руководство. Второе издание» [1] и «Тайм-менеджмент для системных администраторов» [2] – это очень важное пособие для тех, кто хочет научиться мыслить стратегически и видеть за пределами командной строки. Так же, как и пользующаяся большой популярностью серия книг «Linux Hacks» [3], где есть практически готовые рецепты для работы, они могут пригодиться в любой организации.

Например, системный администратор и ИТ-менеджер часто сталкиваются с необходимостью срочной расстановки меняющихся приоритетов для задач, которые часто встают одновременно, и не знаешь, с чего начать.

Допустим, вы пришли утром на работу и после краткого просмотра почты и прослушивания «голосовой почты» у вас сложился вот такой список (см. таблицу 1).

Таблица 1. Вот примерно так будет выглядеть рабочий день, если браться за дела «в лоб»

Задача Описание Сколько может ждать? Время Срок окончания
1 Поменять пароль 1 минута 10 минут 9 часов 10 минут
2 Создать нового пользователя До утра 20 минут 9 часов 30 минут
3 Установить новый сервер До утра 4 часа + обед 14 часов 30 минут
4 Модифицировать Apache 1 час 30 минут 15 часов
5 Заказать программу 1 час 1 час 16 часов
6 Устранить мелкую ошибку 10 минут 25 минут 16 часов 25 минут
7 Поменять адрес 2 минуты 5 минут 16 часов 30 минут

Все бы хорошо, но мы не учли интересов пользователя, который вынужден ждать, поскольку ему, например, нужен был другой адрес. Поэтому, есть смысл реорганизовать наш список с учетом пожеланий «конечных» пользователей. Он может выглядеть примерно так (см. таблицу 2).

Таблица 2. Реорганизация нашего рабочего дня с учетом пожеланий «конечных» пользователей

Задача Описание Сколько может ждать? Время Срок окончания
1 Поменять пароль 1 минута 10 минут 9 часов 10 минут
7 Поменять адрес 2 минуты 5 минут 9 часов15 минут
5 Заказать программу 1 час 1 час 10 часов 15 минут
4 Модифицировать Apache 1 час 30 минут 10 часов 45 минут
2 Создать нового пользователя До утра 20 минут 11 часов 05 минут
3 Установить новый сервер До утра 4 часа + обед 16 часов 5 минут
6 Устранить мелкую ошибку 10 минут 25 минут 16 часов 30 минут

Чем отличаются эти две таблицы? Во второй рабочий день начинается практически сразу же с выполнения задач, которые не занимают много времени у системного администратора, но позволяют остальным делать свою работу (например, сменить пароль у забывшего его бухгалтера), расчищают завалы и освобождают место для других задач. И, что немаловажно, помогая сотрудникам, мы заслуживаем их уважение. Теперь рассмотрим расстановку приоритетов для проектов.

Теперь рассмотрим расстановку приоритетов для проектов (см. таблицу 3).

Таблица 3. Расстановка приоритетов для проектов


Легкий проект Сложный проект
Большой эффект А Б
Маленький эффект В Г

По-моему, очевидно, что проекты класса «А» не нуждаются в дополнительном представлении – если существует какой-то несложный проект, выполнение которого даст большой и ощутимый эффект, то почему бы его не запустить в производство?! Исходя из той же логики, будем полагать, что сложные и зачастую запутанные проекты, эффект от которых не очевиден (категория «Г»), лучше оставлять «на потом» или не делать вообще.

Но вот как быть с остальными проектами, чему отдать предпочтение – категории «Б» или категории «В»?

Как показывает практика, начинающие администраторы или компании с плохо поставленной организацией труда персонала ИТ обычно берутся за более легкие проекты – категории «В», даже если выгода от их внедрения сомнительна. Это неудивительно, ведь создается иллюзия работы, проект достаточно безопасный («легкие» проекты, как правило, не выводят из строя существующую структуру), можно потом будет отчитаться перед руководством о «проделанной работе». Но мы ведь договаривались рассматривать нормальную ИТ-организацию, а не обсуждать видимость работы в «Рогах и копытах».

А нормальная ИТ-организация обычно тяготеет к проектам категории «Б», которые разрабатываются для перевода ИТ- услуг на более высокий уровень, но, к сожалению, не всегда простых в решении.

Правда, тут надо сделать одно небольшое уточнение. Если к вам приходит начальник и просит что-то сделать (не суперсложный проект), то это надо делать, как правило, прямо сейчас. Особенно, если приходит начальник вашего босса или кто-нибудь еще выше рангом. Тут вроде и так все ясно, но подспудно возникает вопрос: «А почему?» Объяснение вот какое: если у вашего начальника появился какой-то вопрос или немедленная задача для вас, то скорее всего ему нужен какой-то недостающий компонент для более крупной задачи. Если вы будете задерживать эту информацию, то большой проект вашего начальника также будет задерживаться. Надо ли пояснять, что это означает, когда придет время для оценки вашей работы?

Что делать с начальником?

Практически во всех книгах и пособиях по трудоустройству уделяется большое внимание пониманию того, что от вас хотят на новом рабочем месте, как и кем будет измеряться эффективность вашей работы, и зачем вообще существует эта позиция.

Из всего многообразия данных дельных советов я бы вычленил следующие пять, которые понравятся любому начальнику:

  • Умение быстро освоиться на новом месте и самостоятельно работать без дерганий начальства: «А как делать это? А что делать с тем?» У начальника хватает своих проблем, ему нужны люди, которые берут на себя определенный фронт работ и сами знают, как взять в оборот проблему. Конечно, есть разумные исключения – финансовые и кадровые полномочия в первую очередь.
  • Умение войти в коллектив и стать своим человеком в команде. Для любого руководителя просто бальзам на душу, когда он видит спонтанно созданные группы, которые дружно берутся за какой-то проект – что называется, «работа спорится». В этом случае он спокойно может заниматься своими делами, а не разруливать межличностные конфликты и соревнование честолюбий.
  • Владение ситуацией. ИТ-директор должен быть уверен, что все занимаются своим делом и что все слаженно работает. ИТ-проекты должны «не забываться», а быть сделаны людьми , которые за них отвечают, без напоминаний.
  • Владение информацией. Все новости об авральных ситуациях, а также о необходимости проведения той или иной работы, должны передаваться от системных администраторов к ИТ-директорам, а от них к вышестоящему начальству. Но никак не наоборот. Если генеральный директор звонит в полночь ИТ-директору и говорит, что «веб-сайт не работает», то ИТ-директору не остается ничего другого, как признать несостоятельность его системных администраторов, которые по какой-то причине «проворонили»ЧП. Самые большие карьерные перспективы ожидают тех, кто правильно предугадывает, что нужно вышестоящему начальству, информирует его обо всех событиях, а главное – не допускает авралов и ЧП, правильно организуя работу.
  • Здравый смысл. В организации работают люди, а не роботы. А психология человека, его стиль общения, способ получения и усвоения информации, настроение, механизмы мотивации выходят далеко за рамки сухого описания занимаемой должности и квалификационного минимума. Как реагировать на обнаруженные «красные флажки» и какие ресурсы задействовать для решения проблемы, должен понять сам сотрудник в зависимости от конкретного места работы и конкретной ситуации.

Вы руководитель

Теперь развернем ситуацию на 180 градусов – вы начальник или руководитель направления (подразделения) в компании. Нужно всегда быть готовым и к такой ситуации. Афоризм «У каждого солдата в рюкзаке лежит маршальский жезл» очень уместен в сфере информационных технологий.

Итак, вы ИТ-менеджер. Какой самый трудный разговор может быть у вас? А какая самая большая ошибка? А в какой момент вы можете получить самую большую прибавку к своей заработной плате? Ответ на все три вопроса один – он про прием на работу и увольнение с нее.

Отношение к собственному найму, так же как и отношение к нанимаемым членам команды или, как говорили в советское время, «подбор и расстановка кадров», – самый важный и сложный вопрос в ИТ-организации.

То, какие сотрудники будут работать в вашей команде, многократно важнее того, насколько быстрые серверы у вас установлены, и какое программное обеспечение используется на фирме. Мне попалась на глаза интересная логическая связь [4]: «Команда разработчиков определяет используемые технологии (Microsoft .Net, Java, C++., PHP, Ruby, etc), а вот то, какие технологии используются, определит стоимость и качество продукта».

Причем под качеством понимается не только «плохой-хороший», но и как и на каких платформах он будет работать. Если ИТ-команда небольшая, то с распределением полномочий все более-менее понятно – в работе с большими командами можно использовать следующее разделение ролей.

Вариант 1. Бригада в операционной

  • Главный хирург – главный специалист, который за все отвечает (рабочие названия – Ведущий инженер, Technical Lead).
  • Второй пилот – может делать все то, что и Главный хирург, но имеет меньше опыта.
  • Администратор – отвечает за деньги, людей, офис.
  • Редактор – отвечает за документацию.
  • Ассистент – отвечает за «инструментарий».
  • Врачи – помощники хирурга – помогают Главному хирургу.
  • Тестеры – отвечают за тестирование.

Вариант 2. ИТ-команда

  • Менеджер или лидер команды – знает, в какой стадии находится проект, почему сейчас и «когда будет готово».
  • Архитектор – отвечает за технологические идеи.
  • Разработчик – боевая единица, полностью ответственная за качественный и временной результат.
  • Администратор – отвечает за связь с внешним миром
  • Тестеры – группа пользователей, которые имеют возможность общаться с разработчиками напрямую.

Несмотря на различие этих вариантов, они, по большому счету, иллюстрируют то, что надо четко разделять роли, и делать так, чтобы не было смешения или перекосов ответственности – для разных технических функций требуются люди с разными способностями.

О важности документации

Очень важным элементом успеха на новом месте и вообще залогом нормального (а не аврального) функционирования ИТ-организации является полная, своевременная, свободная от ошибок и легко понимаемая новыми членами команды документация.

Тема документации как-то проходится скороговоркой и рассматривается скорее как какая-то малоприятная повинность, которая имеет, если не третьестепенное, то второстепенное значение – это уж точно. Очень зря.

Адекватная документация – это не только помощь самому себе и коллегам, посмотреть, как и зачем работает данный программный модуль или сервер, но и средство хранения и передачи «ноу-хау» (в допустимых пределах для каждого «уровня документации») отделу тестирования, новым сотрудникам, ИТ-аудиторам (см. часть 6 ниже) и т.п.

Часто документация напоминает скорее диссертацию на соискание должности «профессора прикладных компьютерных наук», а не понятное руководство, которое должно помочь новому работнику разобраться, как и зачем работает та или иная система, какие существуют (если существуют) мониторинг и резервное копирование, как починить вышедшую из строя систему и как восстановить ее с нуля.

Как невесело пошутил один мой знакомый системный администратор по поводу отсутствия адекватной документации: «Before you can do anything, you have to know everything» («Перед тем как ты что-то сможешь сделать тут, ты должен знать абсолютно все»).

Переизданная спустя 20 лет после первого (1975 год) выхода в свет «настольная книга» ИТ-менеджера «Загадочный человекочас» [5] посвящает теме документации целую главу.

Там содержится наиболее полный, на мой взгляд, перечень требований к документированию программы или процесса (там могут быть свои маленькие уточнения).

  • Цель. Для чего нужна эта программа или компонента системы?
  • Требования к аппаратным средствам и программному обеспечению. На каком классе компьютеров данная программа, сервер, сервис или процедура должны работать? Что и каких версий должно быть установлено до начала работы? Сколько памяти и дискового пространства необходимо? Нужны ли какие-нибудь иные системные средства – например, плата FireWire или системная библиотека?
  • Какие данные и каким способом вводятся и выводятся? Например, программа может получать данные в 4 часа утра через FTP, работающий на специальном порту 34011 (это же не очевидно!), выводить данные в PostgreSQL.
  • Функции и алгоритмы. Если используются какие-нибудь интересные функции и нестандартные алгоритмы – то их надо объяснить.
  • Формат. В каком из форматов вводятся и выводятся данные.
  • Инструкции для пользователя – какие варианты для успешного и аварийного завершения. Чем запутаннее и непонятнее сообщение обработчика ошибок (если он вообще есть!), тем труднее работать с вашей программой или серверной компонентой другим пользователям. Как правило, большинство ошибок можно вывести на уровень операционной системы – нет места на диске, нет файла, нет прав доступа, не тот файл и т.п.
  • Какие опции (дополнительные параметры) доступны, и что они делают?
  • Ресурсы. Сколько и как работает программа или подсистема – сколько и каких ресурсов она требует? Ваши коллеги могут не знать, что ваша программа должна работать как минимум два часа, и могут начать бить тревогу. Или не всегда очевидно, что в процессе работы ваша компонента загрузит сервер на 100% – это надо делать ясным для избежания недоразумений.
  • Точность (опционально). Требуется ли какая-то точность или специфика вывода? Например, динамически генерируемая веб-страница должна содержать ровно 17 изображений или файл должен быть от 200 до 300 Кб – ни больше и ни меньше. Об этом отдел тестрирования может не знать и «пропустить».

Как не стать заложником технологий и правильно распределить ресурсы

Существует известная история, как при входе в одну мастерскую по ремонту висело вот такое объявление: «Мы обязательно починим, вам только нужно выбрать всего два слова из перечисленных ниже трех: БЫСТРО, ДЕШЕВО, КАЧЕСТВЕННО».

По большому счету, в этой полушутливой формулировке заключено очень много здравого смысла, который применим и к работе ИТ-подразделения, но часто игнорируется.

Обычно суетливые установки дешевых компонентов также не отличаются высокой надежностью и качеством. Если хотят что-то сделать качественно, но дешево? Увы, в этом случае быстро не получится. Простейший пример: фирма наняла недорого (читай «молодого и неопытного»), но аккуратного и въедливого разработчика или, скажем, системного администратора. Чтобы он разобрался в проблеме и сделал все на совесть, нужно время.

Ну и последняя комбинация – быстро и качественно, что самое приемлемое для многих фирм. Увы, подобные решения и специалисты не бесплатны, хотя здесь проходит тонкая грань между асами и профессионалами своего дела с одной стороны и хапугами, которые специализируются выжимании максимальной выгоды из своих монопольных знаний, с другой.

Здесь проходит достаточно тонкая, на мой взгляд, грань между вложением в дорогого специалиста/технологию и быть заложником этого специалиста/технологии. Нужно несколько раз подумать и все тщательно взвесить, в особенности предлагаемые варианты технической поддержки, перед тем, как внедрять технологии, которые могут быть «сняты с производства», хотя тут бывает очень сложно что-то рассчитать на долговременную перспективу.

Я могу только догадываться о проблемах, с которыми сталкиваются организации, которые в массовом порядке внедрили неплохие, но «ушедшие в небытие» технологии типа OS/2, Netscape Server, WordStar, Fujitsu 9600.

Умный и талантливый системный администратор может представлять не меньшую «опасность» для руководителя, который не готов организовать работу ИТ-подразделения, чтобы не стать заложником эксклюзивной технологии или чьих-то уникальных знаний и навыков.

Вот типичный пример такой ситуации – умный и талантливый программист, понимая, что надо поднимать работу в ИТ-отделе на новый уровень, наглядно демонстрирует очевидные и неоспоримые преимущества написанной им программы перед старой командой. Квалификации старой команды не хватает, чтобы понять, что и как собирается делать нанятый на работу программист (системный администратор), но они находятся под впечатлением его опыта и одобряют его инициативы. Дальше – больше: в организации появляются новые и отлично работающие программные продукты, старенькие серверы Windows NT заменяются на работающие без проблем FreeBSD, и резко возрастает производительность ИТ.

Начальство довольно, все идет по нарастающей, пока... пока наш «талант» не получает заманчивое предложение из другой организации и не переходит в нее.

Вот тут и выясняется самое интересное – все нововведения не имеют адекватной документации, а используемый FreeBSD работает с такими «выкрутасами», в которых даже срочно нанятый сторонний консультант, специализирующийся на этой операционной системе, не сразу может разобраться. Дополнительно обнаружены «настроенные под себя» межсетевые экраны pfSense, с которыми ни один из оставшихся специалистов не умеет работать.

Как и что поддерживать и обновлять, никто из членов ИТ-команды не знает. Знакомо? А ведь так все хорошо начиналось, и ушедший на другое место искренне хотел только улучшить работу ИТ-организации и внедрить новые программы и ИТ-процессы.

Кто же виноват в этой ситуации? В данном случае ИТ-директор оказался не на высоте – он должен был понимать и предвидеть последствия внедрения новых систем в организацию, которая не имеет адекватной структуры для их поддержки, а также организовать так работу своего ИТ-отдела, чтобы оставалось время на документацию и обучение и других сотрудников, которые могут быть вовлечены в процесс поддержки новых программ, новых серверов и т.п.

Могут быть резонные возражения: «А где же взять на все время?» Нужно признать, что время – это именно тот ресурс, нехватка которого перекрывает сумму всех других проблем, стоящих перед ИТ-директором.

Вот первая десятка проблем, возникающих из-за нехватки времени:

  • Вовремя не закончена разработка – самое типичное.
  • В разработанном продукте или новой конфигурации непропорционально много ошибок.
  • Не делается резервное копирование.
  • Нетерпеливые разработчики и сисадмины лезут напрямую на «боевые» серверы, вместо того чтобы делать изменения в системе контроля версий. Затем возникает либо неустранимая ошибка или рассинхронизация версий.
  • Отсутствует адекватная документация.
  • Нет нормального обучения или хотя бы передачи знаний.
  • Не проводятся деловые «летучки», а далее выясняется, что ИТ-разработка идет по совершенно разным направлениям.
  • Вовремя не проводится профилактика, не устраняются мелкие ошибки, как следствие, полная нехватка места, выход из строя аппаратных средств и т.п.
  • Не ведется правильная работа с клиентами – клиенты теряются.
  • Нет полноценного общения с партнерами – из-за спешной оценки покупаются продукты, которые не предназначены для решения текущих проблем.

И это только быстро составленная десятка проблем, которую можно легко расширить!

Поэтому планирование именно этого ресурса – времени, на мой взгляд, является первостепенным приоритетом любого ИТ-руководителя.

Более того, оказывается, что и тут не все просто. Планирование времени имеет ряд особенностей, которые не всегда лежат на поверхности. Унаследованный из советских времен эвфемизм «человекочас» совершенно не работает в сфере ИТ. На эту тему часто приводят выражение «для того, чтобы родить ребенка, нужна одна женщина и девять месяцев – девять женщин и один месяц не помогут», что можно перевести в «два программиста за девять месяцев делают совсем иной продукт, чем девять программистов за два месяца».

Ну а лучшая, на мой взгляд, цитата на тему планирования временных ресурсов – из романа «В круге первом» Александра Солженицына: помните ночную сцену встречи министра госбезопасности с заключенным Бобыниным?

«–Ведь это получается два с половиной-три года! – возмущался министр.

 – А вам срок был дан – год!

И Бобынина взорвало:

– Что значит – дан срок? Как вы представляете себе науку: Сивка-Бурка, вещая каурка? Воздвигни мне к утру дворец – и к утру дворец? А если проблема неверно поставлена? А если обнаруживаются новые явления? Дан срок!»

Авторы литературы по планированию ИТ-проектов склоняются к тому, что единицу времени, выделенную на проект, следует делить вот таким образом:

  • 1/3 – дизайн системы;
  • 1/6 – написание кода или конфигурация;
  • 1/4 – тестирование компонентов;
  • 1/4 – тестирование всей системы.

Если начать делать перекосы (а часто первая часть урезается: программисты сходу начинают «кодировать», а системные администраторы устанавливать сервер, не совсем понимая, ЧТО конкретно и ЗАЧЕМ там должно быть установлено), то потом выясняется, что полученную «заготовку» приходится переделывать, часто с нуля.

Нужно согласиться с тезисом, что очень хорошие ИТ-профессионалы обычно в десять раз продуктивнее тех, чей уровень стыдливо называется «ниже среднего» – таких любят полушутливо называть «эникейщики».

Иными словами, если средняя заработная плата «эникейщика» в Калифорнии составляет около 30 тысяч долларов в год, а за 100-120 тысяч долларов годового оклада можно найти более-менее умного специалиста, то при годовом бюджете на персонал в 200 тысяч я лучше возьму всего двух толковых парней, чем буду разбираться с шестью-семью «эникейщиками» (именно из-за этого обстоятельства).

Вообще, если позволяют размеры проекта, то лучше обходиться малой командой: два-три, может быть, четыре человека. Но такие команды просто физически не могут тянуть сложные и разветвленные проекты, для управления которыми требуются совсем иные приоритеты. Если проект затягивается, то «вбрасывание» новых сотрудников для работы не приблизит срок окончания, а отдалит его. Почему?

ИТ-проекты – это не битва под Москвой, и новым ИТ-сотрудникам надо не просто присоединиться к команде, а понять, что за проект, что от чего зависит, откуда берутся данные и т.п Обучение и объяснение ситуации отнимет время у людей, которые уже работают над проектом, – читай, отодвинут его сроки.

В этой ситуации надо просто «закусить удила» и завершить проект уже имеющимися силами. Но и тут возникает крайность: наверняка любому программисту и системному администратору приходилось сталкиваться с ситуацией, когда старший сотрудник ИТ-отдела или технически подкованный начальник предпочитает (чтобы быстрее) все делать самостоятельно, никому не сообщая о своих действиях и не ведя никакой документации. То, что он может не сообщать другим о своих проектах, – это не очень хорошо, но не смертельно – в конце концов подобные вещи регулируются субординацией и штатным расписанием. А вот то, что не оставляется никакой документации, – это по-настоящему плохо, такой начальник не только не заботится о преемственности проекта, но и убивает на корню работу в команда и инициативу подчиненных.

Поэтому, когда системные администраторы в отделе, которые обязаны по определению иметь доступ ко всем ИТ-ресурсам, говорят, что «вот, дескать, ИТ-директор на прошлой неделе купил и установил десятку новых серверов, они делают что-то очень важное, но что и как, а также почему,мы не знаем», – это плохой сигнал для руководства фирмы. Несколько таких примеров ,и станет ясно, что нет единой ИТ-команды, а есть директор ИТ (может, один-два «высокопоставленных» ИТ-сотрудника в придачу) и есть остальной ИТ- персонал, задачи и проекты которому выделяются по остаточному принципу.

Кто такой архитектор системы, и зачем он нужен?

Успех системных администраторов и всей структуры, которая обслуживает ежедневную работу сервисов, во многом зависит от того, насколько элегантна и масштабируема построенная система: был ли (есть ли?) человек или, что реже, группа людей, которые отвечают за единую информационную концепцию, стратегическое видение – архитектуру системы.

Часто бывает, что начальная информационная структура была построена кем-то много лет назад, кто давно уже не работает на фирме: какие-то новшества были введены по ходу дела системными администраторами и программистами, кто-то из них тоже уже давно не работает на фирме, кто-то и сейчас не понимает, как что-то работает, но предпочитает «не трогать». Такой «слоеный пирог» из разных системных архитектур встречается сплошь и рядом. Как правило, новому человеку в нем очень сложно разобраться, а еще сложнее провести замену каких-то важных системных элементов (например, поменять несущую базу данных с Oracle на PostgreSQL), которые больше не устраивают по каким-то причинам. Без единой концепции системы («концептуального дизайна») , которая постоянно поддерживается в текущем состоянии, это сделать очень сложно.

Часто срочно требуется кто-то, кто подобно легендарному Василию Ивановичу Чапаеву скажет: «Ребята, на все, что вы тут говорили, надо наплевать и забыть. А делать надо вот как. И вот почему».

Существуют временем проверенные и отлаженные технологии (best practises), которые диктуют, как надо, а как не надо строить какую-то информационную систему. Сложность в том, что непросто найти опытного архитектора, который сможет переделать уже имеющуюся, но «хромую» систему в реальном времени, не останавливая работающие северы.

Концептуальный дизайн – это и есть работа архитектора системы, но часто он работает совместно с ИТ-директором, а то и ИТ-директор выступает в этом качестве.

Но если опытный Архитектор, как правило, представляет себе комплекс проблем, которые его система будет решать, и он видит как сторону «пользователя», так и сторону «системы», то ИТ Директор не всегда является проводником внешней, пользовательской, стороны, его видение часто перегружено чисто системной ИТ-стороной дела, и, как следствие, баланс дизайна нарушается в сторону ИТ в ущерб интересам пользователя, а в худшем случае дается решение совсем другой задачи.

Поэтому концептуальный дизайн надо отделять от собственно ИТ- проекта: если задача архитектора сказать, что будет делать система, то задача ИТ Директора – показать, как она это будет делать. И когда ИТ-директор работает над концептуальным дизайном, ему важно понимать эту разницу.

Концепция новой программы или строящейся системы – это самое главное в проекте, что доносит ИТ-директор до всех членов своей команды. Это своего рода фундамент здания, и от понимания того, как это здание будет выглядеть, почему оно строится, и какие строительные материалы станут использоваться при строительстве, зависит успех или неудача как проекта, так и всей команды. Поэтому понятно, что элегантную и масштабируемую конструкцию гораздо легче строить, тестировать и сопровождать.

С другой стороны, если система имеет концептуальную целостность, то кто-то же должен постоянно контролировать эту концепцию, а проще говоря, «мы делаем вот так, и вот почему» – тут ИТ-директор должен проявить не свою власть, а свой авторитет.

Хорошую ИТ-конструкцию – программный комплекс или сконфигурированный сервер – отличает то, что они как бы построены из блоков и компонент, каждый из которых имеет понятную и законченную структуру и может быть легко исправлен, перенесен или заменен.

***

Резюмируем сказанное – вот компоненты успеха деятельности ИТ-отдела и, как следствие, его сотрудников:

  • Прозрачность деятельности ИТ-подразделения для всех сотрудников – всем более-менее ясны все функциональные элементы и задачи любого проекта.
  • Адекватная, своевременная и понятная документация.
  • Выбор и использование технологий в соответствии с имеющимися и ожидаемыми людскими и финансовыми ресурсами.
  • Управление временным ресурсом.
  • Успешная совместная работа с архитектором системы.
  1. Томас Лимочелли, Кристина Хоган , Страта Чайлап. Системное и сетевое администрирование. Практическое руководство.– 2-е издание. – «Символ-Плюс», 2009 – рецензия в «Системном администраторе», №3, 2011 г.– С. 98.
  2. Томас Лимочелли. Тайм-менеджмент для системных администраторов. – «Символ-Плюс», 2007 – рецензия в «Системном администраторе», №3, 2011 г. – С. 98.
  3. Bill Von Hagen, Brian K. Jones. Linux Server Hacks – volume 2. – O'Reilly, 2006.
  4. Габриелян В. Презентация доклада «Управление разработкой высоконагруженных проектов. Пример @Mail.ru». HighLoad++ 2009.
  5. Frederick P. Brook, Jr. The mystical man-month. – Addison-Wesley, 1995.

Комментарии
 
  30.08.2011 - 01:36 |  vitor

Хорошо проработанная и интересная статья.

  30.08.2011 - 01:38 |  Гость

Хорошо проработанный материал, интересная статья, но гладко было на бумаге, да забыли про овраги.

  10.11.2011 - 12:48 |  Иван

Хорошо,но к России не подходит

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru