апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2012 / Выпуск №5 (23) / Работа со сложным ИТ-проектом. Как это сделать?

Рубрика: Управление проектами

Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Работа со сложным ИТ-проектом
Как это сделать?

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

Короче, когда привычное рутинное времяпровождение на работе окончательно разрушено, приходится лихорадочно искать ответ на вопрос: «Как мы это будем делать?»

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

Что такое вообще сложный проект? Это проект, который достаточно нетривиально формализовать. Самые простые программы, которые легко формализуются, – это, например, выпечка печения или установка Linux. Здесь все шаги вполне прогнозируемы. Достаточно хорошо научиться делать это один раз, и остальное можно поставить на автопилот. Автоматизированные установщики операционных систем типа Sysimage, FAI как раз основаны на идее формализации. Более сложные в отношении формализации проекты – запуск ракеты в космос или установка мощного почтового сервера. Понятно, что это совершенно разные вещи, но все равно мы четко представляем все необходимые шаги: что ожидается на входе, какие подсистемы надо настроить и что будет на выходе.

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

Составляем план

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

Это не только приведет в порядок все соображения, но и позволит поделиться объемом работы и всеми шагами по исполнению с другими ключевыми сотрудниками. Часто системные администраторы берутся за исполнение проекта с ходу, плохо задумываясь о разных подводных камнях.

Чем больше и сложнее проект, тем больше таких подводных камней может быть на пути, поэтому очень важно вовремя найти и очертить «фарватер». Для этого и существует план.

Позволю себе привести цитату из книги Виктора Суворова «Аквариум», где он достаточно точно описывает значение составления плана и подготовки к проекту:

«– Откровенно говоря, я не знаю, с чего начать, что делать...

– План писать! – вдруг взорвался он. – Напиши план, я тебе его подпишу и вперед...

– А если события будут развиваться не по моему плану?

– Ч-е-г-о? – он смотрит на меня непонимающими глазами, смотрит на часы, на меня, вздыхает и с укоризной говорит: – Забирай свои бумаги. Пошли. (..)

Прежде всего надо написать план. В плане распиши всякие варианты и свои решения в этих ситуациях. Чем больше напишешь, тем лучше. (..) А написав план, приступай к его подготовке. Главное – подготовить себя психологически. (..) Отмети все отрицательные эмоции. Все переживания. Все сомнения. На дело ты должен идти в полной уверенности в победе. Если такой уверенности в тебе нет, то лучше откажись сейчас. Главное – настроить себя на тон агрессивного победителя. (..) Повторяю, что главное – не план, а психологический настрой. Ты будешь победителем только до тех пор, пока сам себя чувствуешь победителем. (..) Помни это. Будь победителем! Чувствуй себя победителем. Всегда».

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

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

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

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

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

Почему? Работники ИТ, особенно отвечающие за стабильность ЦОД, считают устойчивость системы своим главным приоритетом. Если большинство «падений системы» происходит из-за плохо подготовленных «выпусков нового программного продукта»[5], то системные администраторы инстинктивно отвечают «НЕТ» на нововведения, которые представляют потенциальный риск выхода системы в «оффлайн». Это вызывает цепную реакцию отношения к системным администраторам как к постоянно ворчащим консерваторам, которые хотят зарубить на корню любой проект, если в нем содержится хотя бы минимальный риск. А риск будет всегда.

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

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

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

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

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

Составление плана часто сопровождается и составлением расписания – перечень этапов, кто будет отвечать за тот или иной участок работы (см. рис. 1). Часто вместо расписания используется полноценная GATT-таблица из программы для управления проектами MS Project или аналогичными ей.

Рисунок 1. Составление расписания – перечень этапов, кто будет отвечать за тот или иной участок работы

Оцениваем ресурсы

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

Изучая процесс миграции [1] Mozilla Foundation, я наткнулся на упоминание книги «The Checklist Manifesto: how to get things right» [2] , которую написал известный хирург-реаниматолог Атул Гаванде, чтобы как-то систематизировать удачи и неудачи в сложных проектах.

Эту книгу я сразу же купил и прочитал за пару дней. Автор считает, что промахи и провалы в осуществлении проектов случаются из-за незнания предмета или из-за неумения понять предмет, а часто из-за того и другого.

Незнание предмета – это то, что у нас любят называть выражением «учите матчасть». Глубокие и связанные теоретические знания [3] – весь стек операционной системы, сеть, железо и т.д., словом инструментарий, необходимый на рабочем месте. Но это только начало.

Неумение понять – это злой и коварный враг любого ИТ-специалиста. Одно дело, когда человек назубок знает теорию и сможет в два часа ночи ответить на вопрос, на каком порту работает DNS и как работает шифрация по принципу public/private keys. Совсем другое дело – суметь быстро и правильно найти и устранить неисправность, применяя эти знаний.

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

Техническая сторона

Оценка готовности персонала с технической стороны: есть ли у нас персонал, который в состоянии правильно понять задачу, обладает необходимой технической квалификацией и опытом работы? Если его нет, насколько сложно и дорого будет заполучить такой персонал?

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

В качестве примера я уже несколько раз в своих статьях приводил высоконагруженную телефонную станцию Fujitsu ES-9600, которая хотя и была менее известна на американском рынке по сравнению с доминирующими системами 1990-х от Nortel, но стоила на 50% дешевле, так как вся логика делалась на «софте», работающем под UNIX-подобной системой. Но вот в 1999 году фирма Fujitsu почему-то прекратила операции по продаже подобных систем в Америке, и тогда мы поняли, что поддержка такой системы нам обойдется в копеечку.

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

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

Психологическая сторона

Кроме чисто технической стороны, очень важны и личностные качества [4], а также понимание, насколько полезным для проекта может быть специалист, работающий с теми же продуктами, но в совершенно другой обстановке.

Например, скромный администратор базы PostgreSQL, годами работающий в тихом архиве с небольшой базой, вряд ли покажет выдающиеся результаты по миграции базы из MS SQL в PostgreSQL в сверхвысоконагруженной поисковой системе.

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

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

Есть и просто субъективные качества. Один из моих прошлых начальников не дал добро на прием на работу очень образованного, но, мягко говоря, слишком крупногабаритного сисадмина. Заметив мое удивление, начальник дал такой ответ: «Понимаешь, очевидно, что при его комплекции у него достаточно серьезные проблемы со здоровьем. Мы не знаем, сколько он будет болеть, но я гарантирую, что раз-другой в течение месяца он совершенно точно не появится на работе. К тому же он курит. Может быть, я и не прав, но ты можешь поручиться, что он не уйдет на больничный в самый нужный момент? Я не могу вот так поручиться. Более того, скажу тебе, что вообще в один прекрасный день он просто испугается чего-то и никогда не выйдет на работу. На моем веку было и такое».

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

Оцениваем технологии

Оценка технологий – всегда важная часть подготовки к проекту. Многие, особенно начинающие, системные администраторы, успешно работавшие или внедрившие ту или иную технологию (PHP, .NET, Web Sphere, Apache Tomcat, Jetty и др.) или методологию (Waterfall, Agile), считают ее универсальным рецептом для любой ИТ-организации.

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

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

Вспомним, почему на рынке поисковых систем одни компании занимают лидирующее положение (Google, Yahoo), а другие довольствуются вторыми-третьими ролями (InterSearch, Looksmart)? Ответ в правильном, не совсем правильном или в неправильном выборе технологии, так как бизнес-модели у них достаточно похожи.

Возврат в предыдущее состояние

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

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

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

Для работы на файловом уровне часто помогают «символьные ссылки»:

[root@s1 tmp]# mkdir testphys1
[root@s1 tmp]# mkdir testphys2
[root@s1 tmp]# ln -s testphys1 test

просто меняется ссылка с testphys1 на testphys2 – возможно, придется перезапустить какой-то процесс, но это не должно занять больше нескольких минут.

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

С точки зрения базы данных подобные вспомогательные поля или даже таблицы могут создать временное увеличение объема, но это неудобство ничто по сравнению с необходимостью восстанавливать десятки или сотни гигабайт информации из систем резервного копирования, которые к тому же часто приходится делать при выключенном приложении. Руководство за такие простои, понятное дело, по головке не погладит. По окончании проекта вспомогательные поля (или таблицы) из мигрируемой базы просто удаляются.

Составляем план-схемы

Для работы со сложным проектом очень важно составить блок-схемы, диаграммы, которые помогут визуально осознать потоки информации – не зря говорят: «Лучше один раз увидеть, чем сто раз услышать». Например, это может быть новая логическая топология сети или физическая топология, или очень высокоуровневая схема обмена данными.

На рис. 3 приведена формализованная блок-схема архитектуры кэширования, которую фирма хотела бы внедрить, а на рис. 4 – моментальная фотография, на которой руководитель проекта пытался быстро объяснить, как же это все работает.

Рисунок 3. Формализованная блок-схема архитектуры кэширования, которую фирма хотела бы внедрить

Рисунок 4. Доска, на которой руководитель проекта пытался быстро объяснить, как же это все работает

Если она служит временной иллюстрацией – это одно дело, но если кто-то собирается использовать подобный «шедевр», быстро нарисованный на доске от руки, в качестве чертежа для планирования, скажем ЦОД, то мы обязательно столкнемся с какой-то проблемой.

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

Финансовая сторона дела

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

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

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

Таблица 1. Сводная таблица по выбору решений для представления руководству

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

***

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

1. Миграция Mozilla Foundation – http://cdn.oreillystatic.com/en/assets/1/event/61/
   Moving%20Day_%20Migrating%20Your%20Big%20Data%20from%20A%20to%20B%20Presentation.pdf.
2. Atul Gawande. The Checklist Manifesto. – Picador, 2010.
3. Кондаков К. Начни сначала, или Что должен знать системный администратор. //«Системный администратор», №6, 2012 г. – С. 72-75.
4. Кондаков К. Системные администраторы. Профессия или призвание – http://samag.ru/uart/more/18.
5. Кондаков К. Быстро и безболезненно. Как правильно запустить новый продукт. //«Системный администратор», №5, 2012 г. – http://samag.ru/archive/article/2208.

В начало⇑

Комментарии отсутствуют

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