 |
|
|
|
Успех на работе. Как его достичь?
Успех на работе Итак, вы отработали несколько дней на новом месте. После того как более-менее освоились, возникают вопросы о стратегической линии поведения, приоритетах, тонкостях общения с руководством, а самое главное – как быстро понять, что работает правильно, а что не очень, и как решить эти проблемы На что надо обратить особое внимание Недавно в русском переводе вышло два интересных издания, рецензию на которые написал Дмитрий Навар в юбилейном (100-м) номере «Системного администратора». Речь идет о книгах «Системное и сетевое администрирование. Практическое руководство. Второе издание» [1] и «Тайм-менеджмент для системных администраторов» [2] – это очень важное пособие для тех, кто хочет научиться мыслить стратегически и видеть за пределами командной строки. Так же, как и пользующаяся большой популярностью серия книг «Linux Hacks» [3], где есть практически готовые рецепты для работы, они могут пригодиться в любой организации. Например, системный администратор и ИТ-менеджер часто сталкиваются с необходимостью срочной расстановки меняющихся приоритетов для задач, которые часто встают одновременно, и не знаешь, с чего начать. Допустим, вы пришли утром на работу и после краткого просмотра почты и прослушивания «голосовой почты» у вас сложился вот такой список (см. таблицу 1). Таблица 1. Вот примерно так будет выглядеть рабочий день, если браться за дела «в лоб»
Все бы хорошо, но мы не учли интересов пользователя, который вынужден ждать, поскольку ему, например, нужен был другой адрес. Поэтому, есть смысл реорганизовать наш список с учетом пожеланий «конечных» пользователей. Он может выглядеть примерно так (см. таблицу 2). Таблица 2. Реорганизация нашего рабочего дня с учетом пожеланий «конечных» пользователей
Чем отличаются эти две таблицы? Во второй рабочий день начинается практически сразу же с выполнения задач, которые не занимают много времени у системного администратора, но позволяют остальным делать свою работу (например, сменить пароль у забывшего его бухгалтера), расчищают завалы и освобождают место для других задач. И, что немаловажно, помогая сотрудникам, мы заслуживаем их уважение. Теперь рассмотрим расстановку приоритетов для проектов. Теперь рассмотрим расстановку приоритетов для проектов (см. таблицу 3). Таблица 3. Расстановка приоритетов для проектов
По-моему, очевидно, что проекты класса «А» не нуждаются в дополнительном представлении – если существует какой-то несложный проект, выполнение которого даст большой и ощутимый эффект, то почему бы его не запустить в производство?! Исходя из той же логики, будем полагать, что сложные и зачастую запутанные проекты, эффект от которых не очевиден (категория «Г»), лучше оставлять «на потом» или не делать вообще. Но вот как быть с остальными проектами, чему отдать предпочтение – категории «Б» или категории «В»? Как показывает практика, начинающие администраторы или компании с плохо поставленной организацией труда персонала ИТ обычно берутся за более легкие проекты – категории «В», даже если выгода от их внедрения сомнительна. Это неудивительно, ведь создается иллюзия работы, проект достаточно безопасный («легкие» проекты, как правило, не выводят из строя существующую структуру), можно потом будет отчитаться перед руководством о «проделанной работе». Но мы ведь договаривались рассматривать нормальную ИТ-организацию, а не обсуждать видимость работы в «Рогах и копытах». А нормальная ИТ-организация обычно тяготеет к проектам категории «Б», которые разрабатываются для перевода ИТ- услуг на более высокий уровень, но, к сожалению, не всегда простых в решении. Правда, тут надо сделать одно небольшое уточнение. Если к вам приходит начальник и просит что-то сделать (не суперсложный проект), то это надо делать, как правило, прямо сейчас. Особенно, если приходит начальник вашего босса или кто-нибудь еще выше рангом. Тут вроде и так все ясно, но подспудно возникает вопрос: «А почему?» Объяснение вот какое: если у вашего начальника появился какой-то вопрос или немедленная задача для вас, то скорее всего ему нужен какой-то недостающий компонент для более крупной задачи. Если вы будете задерживать эту информацию, то большой проект вашего начальника также будет задерживаться. Надо ли пояснять, что это означает, когда придет время для оценки вашей работы? Что делать с начальником? Практически во всех книгах и пособиях по трудоустройству уделяется большое внимание пониманию того, что от вас хотят на новом рабочем месте, как и кем будет измеряться эффективность вашей работы, и зачем вообще существует эта позиция. Из всего многообразия данных дельных советов я бы вычленил следующие пять, которые понравятся любому начальнику:
Вы руководитель Теперь развернем ситуацию на 180 градусов – вы начальник или руководитель направления (подразделения) в компании. Нужно всегда быть готовым и к такой ситуации. Афоризм «У каждого солдата в рюкзаке лежит маршальский жезл» очень уместен в сфере информационных технологий. Итак, вы ИТ-менеджер. Какой самый трудный разговор может быть у вас? А какая самая большая ошибка? А в какой момент вы можете получить самую большую прибавку к своей заработной плате? Ответ на все три вопроса один – он про прием на работу и увольнение с нее. Отношение к собственному найму, так же как и отношение к нанимаемым членам команды или, как говорили в советское время, «подбор и расстановка кадров», – самый важный и сложный вопрос в ИТ-организации. То, какие сотрудники будут работать в вашей команде, многократно важнее того, насколько быстрые серверы у вас установлены, и какое программное обеспечение используется на фирме. Мне попалась на глаза интересная логическая связь [4]: «Команда разработчиков определяет используемые технологии (Microsoft .Net, Java, C++., PHP, Ruby, etc), а вот то, какие технологии используются, определит стоимость и качество продукта». Причем под качеством понимается не только «плохой-хороший», но и как и на каких платформах он будет работать. Если ИТ-команда небольшая, то с распределением полномочий все более-менее понятно – в работе с большими командами можно использовать следующее разделение ролей. Вариант 1. Бригада в операционной
Вариант 2. ИТ-команда
Несмотря на различие этих вариантов, они, по большому счету, иллюстрируют то, что надо четко разделять роли, и делать так, чтобы не было смешения или перекосов ответственности – для разных технических функций требуются люди с разными способностями. О важности документации Очень важным элементом успеха на новом месте и вообще залогом нормального (а не аврального) функционирования ИТ-организации является полная, своевременная, свободная от ошибок и легко понимаемая новыми членами команды документация. Тема документации как-то проходится скороговоркой и рассматривается скорее как какая-то малоприятная повинность, которая имеет, если не третьестепенное, то второстепенное значение – это уж точно. Очень зря. Адекватная документация – это не только помощь самому себе и коллегам, посмотреть, как и зачем работает данный программный модуль или сервер, но и средство хранения и передачи «ноу-хау» (в допустимых пределах для каждого «уровня документации») отделу тестирования, новым сотрудникам, ИТ-аудиторам (см. часть 6 ниже) и т.п. Часто документация напоминает скорее диссертацию на соискание должности «профессора прикладных компьютерных наук», а не понятное руководство, которое должно помочь новому работнику разобраться, как и зачем работает та или иная система, какие существуют (если существуют) мониторинг и резервное копирование, как починить вышедшую из строя систему и как восстановить ее с нуля. Как невесело пошутил один мой знакомый системный администратор по поводу отсутствия адекватной документации: «Before you can do anything, you have to know everything» («Перед тем как ты что-то сможешь сделать тут, ты должен знать абсолютно все»). Переизданная спустя 20 лет после первого (1975 год) выхода в свет «настольная книга» ИТ-менеджера «Загадочный человекочас» [5] посвящает теме документации целую главу. Там содержится наиболее полный, на мой взгляд, перечень требований к документированию программы или процесса (там могут быть свои маленькие уточнения).
Как не стать заложником технологий и правильно распределить ресурсы Существует известная история, как при входе в одну мастерскую по ремонту висело вот такое объявление: «Мы обязательно починим, вам только нужно выбрать всего два слова из перечисленных ниже трех: БЫСТРО, ДЕШЕВО, КАЧЕСТВЕННО». По большому счету, в этой полушутливой формулировке заключено очень много здравого смысла, который применим и к работе ИТ-подразделения, но часто игнорируется. Обычно суетливые установки дешевых компонентов также не отличаются высокой надежностью и качеством. Если хотят что-то сделать качественно, но дешево? Увы, в этом случае быстро не получится. Простейший пример: фирма наняла недорого (читай «молодого и неопытного»), но аккуратного и въедливого разработчика или, скажем, системного администратора. Чтобы он разобрался в проблеме и сделал все на совесть, нужно время. Ну и последняя комбинация – быстро и качественно, что самое приемлемое для многих фирм. Увы, подобные решения и специалисты не бесплатны, хотя здесь проходит тонкая грань между асами и профессионалами своего дела с одной стороны и хапугами, которые специализируются выжимании максимальной выгоды из своих монопольных знаний, с другой. Здесь проходит достаточно тонкая, на мой взгляд, грань между вложением в дорогого специалиста/технологию и быть заложником этого специалиста/технологии. Нужно несколько раз подумать и все тщательно взвесить, в особенности предлагаемые варианты технической поддержки, перед тем, как внедрять технологии, которые могут быть «сняты с производства», хотя тут бывает очень сложно что-то рассчитать на долговременную перспективу. Я могу только догадываться о проблемах, с которыми сталкиваются организации, которые в массовом порядке внедрили неплохие, но «ушедшие в небытие» технологии типа OS/2, Netscape Server, WordStar, Fujitsu 9600. Умный и талантливый системный администратор может представлять не меньшую «опасность» для руководителя, который не готов организовать работу ИТ-подразделения, чтобы не стать заложником эксклюзивной технологии или чьих-то уникальных знаний и навыков. Вот типичный пример такой ситуации – умный и талантливый программист, понимая, что надо поднимать работу в ИТ-отделе на новый уровень, наглядно демонстрирует очевидные и неоспоримые преимущества написанной им программы перед старой командой. Квалификации старой команды не хватает, чтобы понять, что и как собирается делать нанятый на работу программист (системный администратор), но они находятся под впечатлением его опыта и одобряют его инициативы. Дальше – больше: в организации появляются новые и отлично работающие программные продукты, старенькие серверы Windows NT заменяются на работающие без проблем FreeBSD, и резко возрастает производительность ИТ. Начальство довольно, все идет по нарастающей, пока... пока наш «талант» не получает заманчивое предложение из другой организации и не переходит в нее. Вот тут и выясняется самое интересное – все нововведения не имеют адекватной документации, а используемый FreeBSD работает с такими «выкрутасами», в которых даже срочно нанятый сторонний консультант, специализирующийся на этой операционной системе, не сразу может разобраться. Дополнительно обнаружены «настроенные под себя» межсетевые экраны pfSense, с которыми ни один из оставшихся специалистов не умеет работать. Как и что поддерживать и обновлять, никто из членов ИТ-команды не знает. Знакомо? А ведь так все хорошо начиналось, и ушедший на другое место искренне хотел только улучшить работу ИТ-организации и внедрить новые программы и ИТ-процессы. Кто же виноват в этой ситуации? В данном случае ИТ-директор оказался не на высоте – он должен был понимать и предвидеть последствия внедрения новых систем в организацию, которая не имеет адекватной структуры для их поддержки, а также организовать так работу своего ИТ-отдела, чтобы оставалось время на документацию и обучение и других сотрудников, которые могут быть вовлечены в процесс поддержки новых программ, новых серверов и т.п. Могут быть резонные возражения: «А где же взять на все время?» Нужно признать, что время – это именно тот ресурс, нехватка которого перекрывает сумму всех других проблем, стоящих перед ИТ-директором. Вот первая десятка проблем, возникающих из-за нехватки времени:
И это только быстро составленная десятка проблем, которую можно легко расширить! Поэтому планирование именно этого ресурса – времени, на мой взгляд, является первостепенным приоритетом любого ИТ-руководителя. Более того, оказывается, что и тут не все просто. Планирование времени имеет ряд особенностей, которые не всегда лежат на поверхности. Унаследованный из советских времен эвфемизм «человекочас» совершенно не работает в сфере ИТ. На эту тему часто приводят выражение «для того, чтобы родить ребенка, нужна одна женщина и девять месяцев – девять женщин и один месяц не помогут», что можно перевести в «два программиста за девять месяцев делают совсем иной продукт, чем девять программистов за два месяца». Ну а лучшая, на мой взгляд, цитата на тему планирования временных ресурсов – из романа «В круге первом» Александра Солженицына: помните ночную сцену встречи министра госбезопасности с заключенным Бобыниным? «–Ведь это получается два с половиной-три года! – возмущался министр. – А вам срок был дан – год! И Бобынина взорвало: – Что значит – дан срок? Как вы представляете себе науку: Сивка-Бурка, вещая каурка? Воздвигни мне к утру дворец – и к утру дворец? А если проблема неверно поставлена? А если обнаруживаются новые явления? Дан срок!» Авторы литературы по планированию ИТ-проектов склоняются к тому, что единицу времени, выделенную на проект, следует делить вот таким образом:
Если начать делать перекосы (а часто первая часть урезается: программисты сходу начинают «кодировать», а системные администраторы устанавливать сервер, не совсем понимая, ЧТО конкретно и ЗАЧЕМ там должно быть установлено), то потом выясняется, что полученную «заготовку» приходится переделывать, часто с нуля. Нужно согласиться с тезисом, что очень хорошие ИТ-профессионалы обычно в десять раз продуктивнее тех, чей уровень стыдливо называется «ниже среднего» – таких любят полушутливо называть «эникейщики». Иными словами, если средняя заработная плата «эникейщика» в Калифорнии составляет около 30 тысяч долларов в год, а за 100-120 тысяч долларов годового оклада можно найти более-менее умного специалиста, то при годовом бюджете на персонал в 200 тысяч я лучше возьму всего двух толковых парней, чем буду разбираться с шестью-семью «эникейщиками» (именно из-за этого обстоятельства). Вообще, если позволяют размеры проекта, то лучше обходиться малой командой: два-три, может быть, четыре человека. Но такие команды просто физически не могут тянуть сложные и разветвленные проекты, для управления которыми требуются совсем иные приоритеты. Если проект затягивается, то «вбрасывание» новых сотрудников для работы не приблизит срок окончания, а отдалит его. Почему? ИТ-проекты – это не битва под Москвой, и новым ИТ-сотрудникам надо не просто присоединиться к команде, а понять, что за проект, что от чего зависит, откуда берутся данные и т.п Обучение и объяснение ситуации отнимет время у людей, которые уже работают над проектом, – читай, отодвинут его сроки. В этой ситуации надо просто «закусить удила» и завершить проект уже имеющимися силами. Но и тут возникает крайность: наверняка любому программисту и системному администратору приходилось сталкиваться с ситуацией, когда старший сотрудник ИТ-отдела или технически подкованный начальник предпочитает (чтобы быстрее) все делать самостоятельно, никому не сообщая о своих действиях и не ведя никакой документации. То, что он может не сообщать другим о своих проектах, – это не очень хорошо, но не смертельно – в конце концов подобные вещи регулируются субординацией и штатным расписанием. А вот то, что не оставляется никакой документации, – это по-настоящему плохо, такой начальник не только не заботится о преемственности проекта, но и убивает на корню работу в команда и инициативу подчиненных. Поэтому, когда системные администраторы в отделе, которые обязаны по определению иметь доступ ко всем ИТ-ресурсам, говорят, что «вот, дескать, ИТ-директор на прошлой неделе купил и установил десятку новых серверов, они делают что-то очень важное, но что и как, а также почему,мы не знаем», – это плохой сигнал для руководства фирмы. Несколько таких примеров ,и станет ясно, что нет единой ИТ-команды, а есть директор ИТ (может, один-два «высокопоставленных» ИТ-сотрудника в придачу) и есть остальной ИТ- персонал, задачи и проекты которому выделяются по остаточному принципу. Кто такой архитектор системы, и зачем он нужен? Успех системных администраторов и всей структуры, которая обслуживает ежедневную работу сервисов, во многом зависит от того, насколько элегантна и масштабируема построенная система: был ли (есть ли?) человек или, что реже, группа людей, которые отвечают за единую информационную концепцию, стратегическое видение – архитектуру системы. Часто бывает, что начальная информационная структура была построена кем-то много лет назад, кто давно уже не работает на фирме: какие-то новшества были введены по ходу дела системными администраторами и программистами, кто-то из них тоже уже давно не работает на фирме, кто-то и сейчас не понимает, как что-то работает, но предпочитает «не трогать». Такой «слоеный пирог» из разных системных архитектур встречается сплошь и рядом. Как правило, новому человеку в нем очень сложно разобраться, а еще сложнее провести замену каких-то важных системных элементов (например, поменять несущую базу данных с Oracle на PostgreSQL), которые больше не устраивают по каким-то причинам. Без единой концепции системы («концептуального дизайна») , которая постоянно поддерживается в текущем состоянии, это сделать очень сложно. Часто срочно требуется кто-то, кто подобно легендарному Василию Ивановичу Чапаеву скажет: «Ребята, на все, что вы тут говорили, надо наплевать и забыть. А делать надо вот как. И вот почему». Существуют временем проверенные и отлаженные технологии (best practises), которые диктуют, как надо, а как не надо строить какую-то информационную систему. Сложность в том, что непросто найти опытного архитектора, который сможет переделать уже имеющуюся, но «хромую» систему в реальном времени, не останавливая работающие северы. Концептуальный дизайн – это и есть работа архитектора системы, но часто он работает совместно с ИТ-директором, а то и ИТ-директор выступает в этом качестве. Но если опытный Архитектор, как правило, представляет себе комплекс проблем, которые его система будет решать, и он видит как сторону «пользователя», так и сторону «системы», то ИТ Директор не всегда является проводником внешней, пользовательской, стороны, его видение часто перегружено чисто системной ИТ-стороной дела, и, как следствие, баланс дизайна нарушается в сторону ИТ в ущерб интересам пользователя, а в худшем случае дается решение совсем другой задачи. Поэтому концептуальный дизайн надо отделять от собственно ИТ- проекта: если задача архитектора сказать, что будет делать система, то задача ИТ Директора – показать, как она это будет делать. И когда ИТ-директор работает над концептуальным дизайном, ему важно понимать эту разницу. Концепция новой программы или строящейся системы – это самое главное в проекте, что доносит ИТ-директор до всех членов своей команды. Это своего рода фундамент здания, и от понимания того, как это здание будет выглядеть, почему оно строится, и какие строительные материалы станут использоваться при строительстве, зависит успех или неудача как проекта, так и всей команды. Поэтому понятно, что элегантную и масштабируемую конструкцию гораздо легче строить, тестировать и сопровождать. С другой стороны, если система имеет концептуальную целостность, то кто-то же должен постоянно контролировать эту концепцию, а проще говоря, «мы делаем вот так, и вот почему» – тут ИТ-директор должен проявить не свою власть, а свой авторитет. Хорошую ИТ-конструкцию – программный комплекс или сконфигурированный сервер – отличает то, что они как бы построены из блоков и компонент, каждый из которых имеет понятную и законченную структуру и может быть легко исправлен, перенесен или заменен. *** Резюмируем сказанное – вот компоненты успеха деятельности ИТ-отдела и, как следствие, его сотрудников:
|
КОНСТАНТИН КОНДАКОВ, директор по ИТ в поисковом гиганте Looksmart в Сан-Франциско. Занимается автоматизацией и гетерогенными сетями. Женат, двое детей. Хобби – альтернативное кино и видеосъемка| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
