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

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

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

Но одна из них повторяется чаще, чем я хотел бы – “размывание” границ (scope) проектов, что приводит обоюдному разочарованию: клиента/бизнес в поставщике IT услуг/внутреннего IT, а так же поставщика IT в клиенте. Чаще всего это происходит, когда бизнес просит IT сделать что-то “по быстренькому и просто”, без чёткого понимания возможных осложнений, которые могут быть вызваны попыткой сделать что-то незначительное с точки зрения людей, не знающих IT среду.

Начинается всё стандартно: бизнес просит IT внедрить какой-то небольшой сервис и при первоначальном анализе эта задача кажется тривиальной. После небольшого согласования и понимания, что и кому это необходимо, IT начинает внедрение. Сначала этот процесс идёт хорошо, потом по мере увеличения количества бизнес-пользователей, бизнес начинает выдвигать дополнительные требования, которые кажутся, на первый взгляд, безобидными, но потом приводят к тому, что весь проект начинает “тормозить”.

Из жизни: мой текущий клиент попросил внедрить веб-приложение. Казалось бы: что может быть проще!? Это даже не “внедрение”, а просто опубликовать ссылку на сторонний вебсайт на главном портале клиента. По умолчанию, веб-приложения используются на десктопах. Затем клиент вдруг вспоминает, что его IT стратегия - это централизованное развёртывание приложений на Citrix XenApp, поэтому “опубликовать” приложение надо через Citrix. Первая же попытка использовать приложение под XenApp моментально «высвечивает» проблемы: веб-приложение требует первоначальной активации для пользователя; “флаг” активации сохраняет в HTML5 “cookies”, которые не являются частью мигрируемого профайла (“roaming profile”) пользователя. Когда пользователь использует приложение на своей машине, “cookies” остаются в кешируемом профайле на десктопе и всё прекрасно работает. В “ферме” XenApp больше сотни серверов. При таком положении вещей пользователю пришлось бы активировать веб-приложение каждый раз, когда он перенаправляется на новый сервер. Мало того, все локально закешированные профили удаляются с XenApp серверов (“best practices”), следовательно, бедные пользователи будут активировать приложение снова и снова каждый раз, когда они захотят использовать его под Citrix.

Для решения этой проблемы пришлось “городить” logon/logoff скрипты, чтобы сохранять HTML5 “cookies” на сетевой «домашний» диск пользователя и копировать их обратно в локальный профайл.

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

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

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

Сегодня я закончил дооооолгий период изучения TOGAF – это набор методик, стандартов, рекомендаций и т.д. для создания IT архитектуры масштаба предприятия. Начал учить я где-то года три назад, еще TOGAF8, но потом поменял работу и когда собрался сдавать экзамен – вышел TOGAF9 :) В общем, только полгода назад я снова вернулся к изучению материала.
TOGAF можно сдавать двумя экзаменами или одним, который включает в себя две части. Я решил сдавать полный экзамен, чтобы не мучиться два раза :) Первая часть – обычный тест: вопрос и на выбор четыре ответа. Второй тест – даётся определённый сценарий и так же четыре ответа, просто более развернутых. Для того, чтобы сдать экзамен, надо набрать в первой части более 60% правильных ответов, а во второй – более 55%. Как понимаете, сдать экзамен – не проблема. Если хоть что-то учить и потом использовать правильный подход при выборе ответов – можно спокойно набрать нужные баллы.
Я уже выработал методику при сдаче экзаменов: из четырех ответов можно спокойно отбросить один, который очевидно неправильный. Потом, подумав немного, можно исключить еще один (если, конечно, знать хоть чуть-чуть материал). С оставшимися двумя ответами можно справится, используя сам вопрос. Не зря же говорят, что хороший вопрос – это уже как минимум 50% ответа. С помощью такой простой методики я набрал в первой части 90%.
Вторая часть экзамена должна была быть более сложной: вместо простого вопроса и однозначных ответов даётся большой текст, описывающий крупную компанию, её задачи, проблемы и т.д. и затем даются ответы, которые более сложные и развернутые. Но на самом деле можно использовать тот же подход, что и раньше. В сценарии практически все важные требования указаны в конце длинного текста. “Воду” в начале можно не читать. Затем исключаем один явно неправильный ответ. В паре случаев это было сразу же видно, какой это ответ – он полностью отличался от трех остальных. Потом можно отказаться еще от одного ответа и “переваривать” два оставшихся. Дальше – смешнее. В паре случаев мне помогло внимательное прочтение условия и проверка, какой ответ полнее отвечает условиям и он будет искомым. Например, мне попался сценарий “… директор департамента IT озабочен уровнем знаний и умений команды архитекторов…” и вопрос: “Что можно сделать по этому поводу?”. Два наиболее вероятных ответа были: “…определить необходимые роли и связанные с ними уровни знаний, опыта и т.д., оценить архитекторов, находящихся на ключевых позициях…” и “…определить необходимые роли и связанные с ними уровни знаний, опыта и т.д., оценить всех архитекторов…”. Естественно, директор волнуется по поводу всей команды (как следует из вопроса), следовательно, искомый ответ – второй. Т.е. на этот вопрос можно было ответить и даже не зная TOGAF :)
Суммируя вышесказанное – экзамена бояться не стоит. Достаточно прочитать материал, понять и запомнить ключевые термины, процессы и смело идти сдавать экзамен. Проблем быть не должно.

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

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

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

1. Электронная почта;
2. Всевозможные совещания по поводу и без повода.

Как справляться с “рабочим спамом” в общих чертах понятно:

1. Я устанавливаю определенные промежутки времени, в течении которых я просматриваю и отвечаю на важные емейлы, остальное я пропускаю до момента, когда у меня есть свободное рабочее время. Я даже на важные емейлы (правильнее, наверное, было сказать – емейлы, относящиеся к непосредственной работе/проектам) не реагирую моментально, так как считаю, что если это было действительно важно, то человек мог бы взять и позвонить, либо подойти ко мне;
2. Емейлы, посланные мне как “CC” оставляю для беглого просмотра в свободное время, когда мне просто скучно. Blackberry помогает в этом случае, когда в метро я не знаю чем занять руки :)
3. Я настроил несколько правил в Outlook, которые выделяют письма от важных отправителей. В данном списке два человека: директор моего департамента и мой менеджер. Им я отвечаю в первую очередь и по возможности сразу, как замечу письма от них, адресованные непосредственно мне.

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

1. Я отказываюсь принимать приглашения на совещания без определённого плана обсуждения. Если я не знаю, о чём конкретно будет вестись разговор и меня никто лично заранее не предупредил, либо не обговорил тему предстоящей встречи, то я без зазрения совести нажимаю кнопку “отказаться” в Outlook-е;
2. Пару раз я приходил на совещания и мне пришлось ждать почти час, пока обсуждались вопросы “погрузки/разгрузки”, я же отчитался за пять минут, но в целом за эту встречу я потерял полтора часа времени. Теперь, если я вижу, что разговор уходит не “в ту степь”, я прямо спрашиваю организатора совещания, требуется ли моё присутствие. Если нет – встаю и ухожу, не жду момента – а вдруг кто-то меня что-то спросит. Я не только экономлю своё время, но еще, как дополнительный плюс, добиваюсь того, что моё время люди начинают ценить.

У меня есть еще пара дополнительных трюков, которые помогают мне справится с работой.
Первый из них – я работаю из-дому, когда мне надо сконцентрироваться на какой-то определённой задаче. В офисе это сделать тяжело, потому что куча народу подходит спросить что-то “буквально на минуточку”, это выливается в как минимум в 15 минут пространного разговора, потом надо потратить еще минут пять, чтобы вернуть концентрацию и, в худшем случае, так впустую тратиться почти целый день.
Ещё я начал отказываться помогать коллегам, когда они просят что-либо меня сделать, так как “мне это проще и у меня получится это быстрее”. Я так один раз сделал и в потом в течении двух дней я “разгребал” все сопутствующие проблемы и вносил изменения. А коллега в это время расслабленно занимался своим делом. Получается, я помог ему, мне пришлось тратить своё дополнительное время и усилия, чтобы справляться с его и моими задачами, а он спокойно отчитался о выполненном проекте. Нееее, я уже “поумнел” :)

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