Глупые мысли об IT

Привет, народ!

В данной статье я хотел бы рассказать об ошибках, которые я когда-либо наблюдал при работоте над проектами. В некоторых ошибках была моя прямая вина, за другие я с радостью переложу ответственность на людей, которые были заняты со мной в различных проектах. Некоторые вещи были достаточно тривиальные и при правильном подходе можно было бы легко их избежать, другие проявлялись из-за системных проблем, таких как отсутствие взаимодействия между командами, работающими над разными задачами в проектах.
Немножко отвлекусь: все, что не делается/внедряется в IT, делается для кого-то. Очень тяжело найти проекты, которые начинаются и внедряются только ради самого IT. Кто-то, а это может быть или бизнес, на которого работает IT отдел, или клиент, который обратился в IT фирму разработать программу или решение, всегда получает напрямую или косвенно какие-либо результаты труда (и хочется верить – улучшения) IT отдела или поставщика. Поэтому к рассмотрению ошибок, сделанных при работе над проектам я предпочитаю подходить с этой точки зрения – с точки зрения выгоды, получаемой бизнесом или клиентом.
Если проект разделить на три фазы: начало проекта, внедрение и окончание, то каждая из фаз может иметь свои организационные (связанные с общим ходом проекта) и технические (техническое внедрение решения, выбор технологии и т.п.) проблемы. (Кстати, поймал себя на том, что мне тяжело использовать слово “проблемы”. В английском “problems” употребляется в смысле “проблем, которые очень трудно или невозможно решить”. Эквивалентом слова “проблемы” в английском является “issues” :))
В начале проекта самые большие ошибки, с которыми я сталкивался, были в основном организационные просчеты:

1. Начало работы над проектом без четких указаний от бизнеса: так называемых функциональных и не-функциональных требований (“Functional/Non-Functional Requirements (FRs/NFRs)”). Много распространяться на эту тему не буду, скажу только, что функциональные требования описывают что должно делать внедряемое решение, в то время как не-функциональные требования должны определять “как”, т.е. количественные и качественные характеристики. Если этих требований нет – это означает, что бизнес сам не понимает, что он хочет и можно потратить кучу времени и усилий на проект, который в конечном счете или “похоронят”, или потом  будет мучительно стыдно за результат работы :);
2. Не определены ясно и четко цели, область и бюджет проекта. В начале следует или получить от бизнеса, или самому “подвести за ручку” бизнес к составлению формального документа, который будет описывать: какие проблемы проект должен решить, какая будет выгода для бизнеса, сколько это займет времени и сколько это будет стоить. Это все, что нужно бизнесу знать! Бизнес не интересует какие модные технологии будут использоваться, как это будет сделано и т.д. Все, что интересует бизнес/клиента – “Сколько это будет стоить в деньгах и времени? И что мне с этого будет?”. Если ответы на эти вопросы будут кристально ясны – можно надеяться на поддержку проекта;
3. Не определены ключевые люди в проекте: заказчики (“stakeholders”); люди, в ответственность которых входит принимать решения по текущим вопросам, возникающих в ходе проекта в случае любых неточностей/конфликтов интересов (“accountable”); прямые исполнители (“responsible”), а так же те, кто более-менее заинтересован в успешном внедрении проекта и/или могут предоставить полезную информацию, которая может помочь с внедрением проекта (“informed” и “consulted”). Это могут быть рядовые сотрудники в бизнесе, которые знают в деталях области (использование программ, бизнес-процессы и т.п.), затрагиваемые в проекте.

Во время внедрения проекта самыми распространенными организационными ошибками были:

1. Ошибки в планировании необходимого количества ресуросов: инженеров в разных технических направлениях, менеджеров проектов и т.д.;
2. Недостаток знаний и умений у персонала, вовлеченного в проект. Были ситуации, когда решения “спускались  сверху” к выполнению, в то время как инженеры ни слухом ни духом не слышали о том, что надо делать и не имели опыта работы с требуемыми технологиями;
3. Отсутствие видимости прогресса и отчетности для заказчика. Вроде бы мелочь, но если проект сложный и растянут по времени, у заказчика может сложиться впечатление, что ничего не происходит. Опять же, многие технические специалисты в силу природной скромности :) не сообщают о каких-либо удачных решениях. Как показывает практика, умение играть в “политические игры” и представление в лучшем виде своих заслуг и достижений – лучшее средство для получения прибавки в зарплате и каръерном росте.

Нельзя сказать, что техническая сторона всегда была на высоте. Основными ошибками  были:

1. Использование технических решений, которые не соотвествуют требованиям. Это, скорее, результат подхода к проекту без понимания целей и требований бизнеса. Используется “модное” решение, которое вполне может не подходить по ряду причин в данный момент в данной ситации. Например, использование сервера баз данных Oracle вместо более дешевой и простой альтернативы из-за того, что Oracle “круче”. Без знаний и опыта работы с Oracle это может привести к проблемам вместо “летающей” баз данных;
2. Внедряемые решения конфликтуют с существующими IT сервисами. Вариантов - масса. Даже самый простой пример: использование серверной операционной системы, не поддерживаемой существующей системой создания резервных копий.  Что будет при возникновении непредвиденной ситуации, связанной с полной неработоспособностью сервера и невозможностью восстановить его с “ленты”!?
3. Внедряемые решения не согласуются со стратегией бизнеса. Это, конечно, более “туманное” определение проблемы, если коротко – то бизнес и IT двигаются в противоположных направлениях. Бизнес может постепенно “децентрализироваться”: переводить разные службы из центрального офиса в регионы, а IT служба не замечать этого и развивать IT сервисы для поддержки старой модели бизнеса. Может случиться, что после окончания проекта он будет никому не нужен именно из-за этого.

Ну а после окончания проекта возможна ситуация, когда проект не удовлетворяет бизнес или заказчика из-за:

1. Несоотвествие ожиданий бизнеса и результатов. Является следствием ошибок в начале проекта п.2 (“цели, область и бюджет”) и п.3 при внедрении (“отсутствие отчетности”). Вполне допустимо менять по ходу внедрения цели проекта, но любые изменения должны быть согласованы и подписаны с заказчиком;
2. Проект закончен, но с существенным превышением бюджета. Без соответствующей отчетности будет тяжело указать на причины превышения затрат, пусть даже они были и вызваны объективными причинами (бизнес мог  изменить требования, что привело к переделке, а следовательно, к удорожанию проекта);
3. Проект закончен с большой задержкой. Так же, как и в п.2, важно знать, чем это было вызвано.

В принципе, п.1-3 окончания проекта уже никак не исправишь. “Поздно пить боржоми…” :) Но при правильном подходе, при хорошей отчетности во время проекта, можно избежать больших споров с бизнесом/заказчиком по всем этим пунктам.
Напоследок хочу сказать: ни в коем случае нельзя соглашаться с бизнесом или заказчиком что-либо переделать в проекте без формального рассмотрения этого как изменения требований! Заказчик очень часто не понимает, что с “небольшие” изменения в проекте, особенно как результат “забывчивости” со стороны бизнеса о важной функциональности, могут вылиться в полную переделку решения. А это время, деньги и, что немаловажно, конечный результат и ожидания бизнеса. Если становится понятно, что количество мелких изменений переходит определенный порог или изменения могут привести к задержкам по срокам, цене – драться надо отчаянно и стоять до последнего! :) Пока бизнес/заказчик не подпишет документ об изменении в требованиях.
И совсем коротко, так как я планирую не накоторых вещах рассказать в следующих постах. Ничего нового изобретать не нужно, все уже давно изобретено: существуют много методик для ведения проектов (Prince2 и т.п.), методик разработки решений с технической точки зрения (TOGAF, Microsoft framework) и управления сервисами (ITIL).
Напоследок рекоммендую прочитать пост Алексея Глазкова “Правила работы надо проектом”.
Это все, что я могу сказать по поводу ошибок. Любые дополнения приветствуются :)

Засим раскланиваюсь,
Рустам.

Привет, народ!

В заключение своих мрачных постов об опасностях аутсорсинга :) (часть первая, вторая, третья, четвертая и пятая) я бы хотел кратко остановится на преимуществах аутосорсинга. Много писать не буду, достаточно взять и почитать любой пресс-релиз компании аутсорсера, чтобы “проникнуться” положительными эмоциями :) Я же попытаюсь сделать акцент на очевидных и неочевидных выгодах аутсорсинга для бизнеса.
Итак, основные области, где компания/бизнес может получить какую-то отдачу:

• IT сервисы;
• Наличие подготовленного персонала (“гарантированно” и “по требованию”);
• Расходы на IT сервисы и персонал;
• Стратегия, связанная аутсорсинга.

В IT сервисах главным преимуществом является то, что аутсорсер, при правильном подходе к аутсорсингу со стороны бизнеса, может улучшить существующие сервисы. Как я уже писал, это может произойти при обоюдном желании: бизнеса – предоставить бюджет, а аутсорсера – инвестировать ресурсы и понести какие-то еще незначительные косвенные затраты.
Аутсорсер так же может помочь с внедрением новых сервисов, которые были бы недоступны без помощи аутсорсера. Аутсорсер может предоставить персонал (инженеров, менеджеров проектов и т.п.), обладающих необходимыми знаниями и умениями для внедрения сложного решения, а потом оказывать поддержку этой системы.Бизнес мог бы, конечно, воспользоваться консультатнами для внедрения, но вопрос поддержки все-равно бы потом “всплыл”.
Персонал: огромным “плюсом” любого крупного аутсорсера является наличие пула ресурсов. Это важно как и для краткосрочных, так и для долгосрочных проектов. Как я уже упомянул выше, бизнес может воспользоваться консультантами для внедрения какого-либо решения или системы. Но консультанты бизнесу будут обходиться раза в два дороже, чем дополнительный персонал аутсорсера, временно нанятый на срок выполнения проекта. А потом, как дополнительная “плюшка”, аутсорсер может дешевле взяться поддерживать систему, так как она была внедрена силами самого аутсорсера. Единственным “минусом” может являться то, что бизнесу для затребования необходимых ресурсов надо будет следовать формальным процессам, чтобы затребовать этот самый персонал аутсорсера, но я думаю, что на это уйдет или столько же времени, как на поиск консультантов, или даже меньше.
Расходы на IT сервисы и персонал: в случае с IT сервисами все просто. Основными преимуществами являются: возможность получения оговоренных IT сервисов за заранее оговоренную цену (финансовый отдел бизнеса будет пищать от восторга!) и понижение стоимости IT сервисов за счет разделяемых сервисов/ресурсов. Как это выглядит на практике, к примеру: аутсорсер может иметь систему мониторинга, за которую он выплатил N-ую сумму производителю этой системы и теперь имеет неограниченное количество клиентских лицензий. Или, как крупный клиент, имеет существенную скидку на клиентские лицензии. Используя эту систему мониторинга на своей инфраструктуре для разных своих клиентов, аутсорсер понижает издержки для себя и, если это не жадный аутсорсер, передает экономию в расходах своим клиентам. Т.е. бизнесы платят меньше, чем платили бы они, если бы сами покупали лицензии и внедряли решения на своей платформе.
С персоналом картина получается еще радужнее. Одна из самых больших статей расходов в развитой капиталистической стране является выплаты работникам (зарплата, больничные, отпускные и т.д.). Бизнес может экономить за счет использования аутсорсером более дешевой рабочей силы. Кроме того, в завимости от контракта, бизнес всегда может иметь гарантированное количество персонала аутсорсера, работающего на него. Т.е. отпуска, больничные и недостаток персонала бизнес волновать не будет. Сказано в контракте – два инженера 24х7, пусть аутсорсер  думает, где и как ему найти нужное количество инженеров :)
В случае аутосринга, бизнесу нет необходимости оплачивать обучение и курсы сотрудников. Это, опять же, задача аутсорсера - предоставлять бизнесу ресурсы с готовыми знаниями :)
Так же бизнес может существенно сэкономить за счет того, что сотрудникам аутсорсера не надо предоставлять дополнительные “бенефиты”: доплачивать в пенсионный фонд, оплачивать больничный и отпускные, премии и т.д. В случае кризиса и последующих увольнений бизнес не связан никакими обязательствами перед работниками аутсорсера: никаких выплат по сокращению, пособий и т.д.
Вот, наверное, и все. Данные “измышления” базируются на моем опыте. Кто-то может дополнит, если я много чего пропустил.

Засим раскланиваюсь,
Рустам.

Привет, народ!

Не беспокойтесь, я уже почти закончил свою сагу об аутсорсинге. Осталось совсем чуть чуть! Потерпите :)
Итак: как вы поняли из заголовка поста, я хочу сказать несколько слов о проблемах аутсорсинга. Об этом надо задумываться еще до того, как принято решение аутсорсить IT или нет. Когда решение сделано, очень тяжело, даже психологически, “сдать назад”. Поэтому когда “процесс пошел”, руководящий состав старается не замечать возможные проблемы.
Не претендуя на правоту, я бы сказал, что существует несколько важных моментов, которые могут негативно повлиять на результат перехода на модель аутсорсинга:

1. Различие/отсутствие бизнес-процессов, управление и культура:
   • Разное понимание целей между компанией, аутсорсящей IT и самим аутсорсером – если компания, отдав аутсорсеру IT, “выторговав” себе крайне дешевый контракт поддержки, ожидает, что аутсорсер вдруг ринеться внедрять новые сервисы, производить апгрейд операционных систем настольных компьютеров и серверов, то эта компания очень ошибается :) Аутсорсер будет стараться сэкономить на поддержке как только можно, вполне и за счет качества. Поэтому сразу же на самом первом этапе обе стороны должн договориться, что ожидается получить в результате. Даже если это будет просто констатация намерений, но ясность в целях позволит обозначить “горизонты”, пусть это и повлияет на цену контракта в сторону удорожания. Зато все будут избавлены от появления неприятных сюрпризов в виде взаимных претензий;
   • Неготовность компании следовать формализованным процессам/отсутствие процессов в отношениях с аутсорсером – как я уже писал, аутсорсер не может интегрироваться в бизнес и в организационную структуру компании. Для эффективного взаимодействия с аутсорсером, компания должна “построить” связующие бизнес-процессы. Это приводит к интересному моменту: когда аутсорсится IT, компания может ожидать, что она подчистую избавится от внутреннего IT. Как бы не так! От технических специалистов она, может, и избавится, но взамен над будет создать организационную единицу, которая будет взаимодействовать с аутсорсером: контролировать выполнение, качество и т.д. Может возникнуть парадоксальная ситуация, когда маленький IT отдел будет заменен штатом более высокооплачиваемых сотрудников для работы с аутсорсером, что в конечном счете приведет к более высоким затратам на этих людей в плане зарплаты :);
   • Проблемы взаимодействия/управления аутсорсером:
     • Контроль качества – когда IT предоставляется внутренней службой/департаментом, гораздо легче получить правдивую картину о качестве IT. Если IT за-аутсорсено, очень тяжело понять, насколько предоставляемые IT сервисы соотвествуют требованиям качества;
     • Остутствие опыта управления распределенной средой – ресурсы, распределенные географически и в разных временных зонах. Вроде бы простая вещь, но для некоторых компаний может стать “камнем преткновения”: бизнесу, привыкшему к “карманному” IT, трудно перестроиться на взаимодействие с IT, которое расположено не на “расстоянии вытянутой руки”. Если раньше любые совещания, вопросы решались просто, можно было просто послать приглашение на совещание и собраться в какой-нибудь комнате, то организовать то же самое, но с людьми, которые находятся, скорее всего, на другом континенте и в другом часовом поясе, будет нелегко. Конечно, аутсорсер организовывает поддержку бизнеса, “выравниваясь” по рабочим часам компании, но это не означает, что все работники аутсорсера будут работать так. Скорее всего первая-вторая линия поддержки будут доступны все время, а вот с другими сотрудниками прийдется согласовывать время. Когда мой предыдущий работодатель организовал совместный бизнес с американцами и нам нужно было что-либо согласовать с техническими специалистами в Штатах, мы назначали совещание на 4-6 вечера, а у них это было раннее утро. Мы жертвовали своим свободным временем (я тогда работал до 16:00), а американцы часто выходили на связь прямо из дома – проснулись, почистили зубы и вперед – конференц-связь.
   • Различная культура общения. Сейчас ситуация улучшается за счет большего присутствия работников аутсорсинговых фирм в офисах компаний, пользующихся их услугами, но раньше это создавало много проблем и недопониманий. Например, индусы никогда не говорили “нет”. Можно было составить подробный план со списком задач, которые они должны были бы выполнить. Даже если работники в  Индии понимали, что столько им не сделать, они все-равно говорили “ОК”. Естественно, когда все задачи не выполнялись, бизнес начинал требовать объяснений, а индусские аутсорсеры недоумевали, что это от них хотят, ведь это сразу было понятно, что они этого не сделают!? :) Именно поэтому нормальные аутсорсеры, которые должны взаимодействовать с бизнесом, стараются увеличить свое “присутствие” у клиентов, нанимая сотрудников со знанием культуры в данной стране. Пусть даже и иммигрантов с других стран ;))
2. Уровень услуг:
   • Недостаточно высокое качество предоставляемых IT сервисов:
     • Персонал аутсорсера с низким уровнем знания и опыта. IT индустрия в странах, предоставляющих аутсорсинг, сейчас переживает бум. Как некоторое время назад в развитых странах, в IT сейчас идут кому не лень. Минимальные знания вдруг дают право людям называться инженерами. Имейте в виду, что контролировать кто там сидит на другом конце земного шара и нажимает на кнопки крайне тяжело (см выше);
     • Персонал аутсорсера может быть подвержен процессу текучки. Люди приходят, ходят и, как следствие, постепенно теряются накопленные знания. По большому счету, это проблемы атусорсера, но будет обидно, если проблемы аутсорсера рикошетом ударят по бизнесу;
     • Отсутствие стимулов и причин к повышению качества. Этот пункт немножко спорный, но, тем не менее, есть вполне оправданные подозрения, что это так. Чаще всего атсорсинг рассматривается как возможность сэкономить деньги. Т.е. получить все задешево. Но иногда для того, чтобы получить экономию, надо будет вложить достаточно большие деньги. Аутсорсер понимает, что после окончания контракта есть шанс проститься с клиентом, поэтому не хочет вкладывать свои деньги или ресурсы в глобальные проекты. А бизнесу будет трудно смириться с тем, что вместо экономии в IT они могут получить еще одни расходы. Аутсорсер будет внедрять без поддержки бизнеса только то, что не потребует больших вложений (прямо – деньгами, или косвенно – временем работников) и даст результат сиюминутно. У постоянно же IT персонала может быть дополнительная мотивация, чтобы “инвестировать” хотя бы свои усилия в то, чтобы улучшить IT.
3. Цена:
   • Оплата услуг, невошедших в первоначальный контракт, может сильно отличаться от цены на остальные сервисы. Как правило, компании, за-аутсорсившие IT, после подписания контракта и передачи IT аутсорсеру теряют главные рычаги воздействия на аутсорсера. Как я уже говорил, очень трудно описать всё в контракте и после некоторого времени бизнес может попасть в “мышеловку”, когда внутренний IT выполнял массу задач, не обговоренных в контракте, и потом обнаруживается, что это крайне важно. Аутсорсер в зависимости от жадности и условий контракта может запросить вполне нескромную цену :) Одна из компаний попалась на эту удочку: она сначала “прижала” аутсорсера контрактом, заставила сделать пару проектов задаром. А потом оказалось, что любой “чих” обходится в большие деньги. Все, что не попадало под контракт, оценивалось в десятки тысяч фунтов. Попытки бизнеса сделать что-то по мелочи самими выливалось в отказ аутсорсером поддерживать эти системы. Представьте себе, когда вам надо перенести пару компьютеров с одного офиса в другой. Аутсорсер выставляет такую цену, что бизнес решает силами своих сотрудников перетащить эти компьютеры и подключить кабеля. После этого аутсорсер заявляет, что эти комьпютеры он не будет поддерживать, так как изменения были внесены не квалифицированными сотрудниками :) Бизнес вынужден был заплатить аутсорсеру за “сертификацию” этих компьютеров “квалифицированными сотрудниками”, после чего аутсорсер “добил” бизнес заявлением о тем, что эти компьютеры уже не попадают под действие предыдущего контракта и на них надо заключать новый (более дорогой, естественно!) :)))
4. Стратегия:
   • Аутсорсер может не стремиться внедрять сервисы, которые в долгосрочной перспективе принесут экономию компании (бизнесу). На это могут быть разные причины: нежелание инвестировать свои ресурсы, нехватка ресурсов или просто тупое желание продолжать “рубить капусту”;
   • В зависимости от отношений аутсорсера и бизнеса, может возникнуть такая ситуация, когда стратегические проекты будет почти невозможно не то что провести, а даже начать! Причиной может быть недоверие между бизнесом и аутсорсером, культура бизнеса и т.д. Очень часто бывает, что люди из внутреннего IT уходят в новую структуру, которая занимается координацией проектов между бизнесом и аутсорсером. Как вы думаете, насколько беспристрастно эти люди могут работать с аутсорсером? Скорее всего, эти работники будут явно или неявно стараться насаждать свои идеи, как что-то должно быть сделано. Такова человеческая природа. Трудно перестроиться и признаться, что теперь ты не технический специалист, а просто еще один бизнес-аналитик. К слову: в этом нет ничего плохого и даже открываются неплохие перспективы в плане каръеры. Бизнесу будут важны люди, которые знают две стороны: бизнес и IT. Аутсорсеры будут меняться, а эти люди в бизнесе – нет;
   • Аутсорсер может упустить что-либо из-за непонимания бизнеса компании и возможной выгоды для бизнеса.
5. Персонал и отношение к работе:
   • Сотрудники аутсорера не будут лояльны к бизнесу. Только товарно-денежные отношения. Хотя, наверное, термин “лояльность” не применим к персоналу, предоставляемым аутсорсером. Какой-то определенной благодарности можно добиться :) Например, практикуется приглашение персонала аутсорсера на регулярные “дринки”, оплачиваемые, естественно, бизнесом;
   • Самой главной проблемой является невозможность получать ресурсы (т.е. инженеров) “на лету”. Я говорю о том случае, когда бизнесу надо “кровь из носа” что-то сделать еще вчера, а у аутсорсера может и не быть свободных инженеров. Могут иметься в наличие инженеры, но без знания конкретного бизнеса и IT, что не позволит выполнить необходимые задачи в срок. Бизнесу надо будет перестроиться и учиться планировать потребность в ресурсах. Обычное “окно” для затребования “ресурсов” – две недели. Причина проста: как я уже говорил, аутсорсер стремится снижать свои расходы и одним из методов является “размазывание” персонала по нескольким клиентам. Т.е. вроде бы есть прикрепленный к бизнесу инженер, но для какого-либо проекта он будет доступен только после оговоренной даты.
6. Ну, и самое вкусное: риск/проблема “выхода” из контракта с текущим аутсорсером:
   • После окончания контракта аутсорсер может отказаться/пассивно сопротивляться предоставлять необходимую информацию. Даже просто у аутсорсера может не оказаться необходимых ресурсов для гладкой передачи IT сервисов и инфраструктуры другому аутсорсеру или внутреннему отделу IT. Контракт заканчивается, зачем держать лишних инженеров, кроме самого минимума, необходимого для поддержания работы систем. Момент выхода (окончания контракта) должен быть очень четко оговорен в контракте, чтобы у аутсорсера не было другого пути, кроме как передать необходимые накопленные знания в приемлемом виде;
7. Сам бизнес по окончанию срока контракта с аутсорсером может не представлять, какую информацию затребовать. Что важно, а что нет. Может сложиться такая ситуация, когда документации много, а насколько она актуальна, насколько полно она описывает имеющуюся IT – непонятно. Тут уж самому бизнесу надо будет проявить себя с лучшей стороны. Как я уже писал, компании 3-го типа будет легко связать существующие IT сервисы с информацией и документами, полученными от аутсорера, остальным прийдется тяжелее.

Ну вот о проблемах и все. Спасибо что дочитали :) В следующий раз я попробую сконцентрироваться на положительных сторонах аутсорсинга.

Засим раскланиваюсь,
Рустам.