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

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

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

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

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

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

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

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

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

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

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

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

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

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

Даже не знаю, с чего начать: то ли с извинений, почему я так долго не писал в этот блог, то ли сразу “взять быка за рога” и начать писать по теме. Всё-так склоняюсь к последнему варианту.
Каждая компания проходит через циклы обновлений IT сервисов. В более бюрократических компаниях это может подчиниться сложным процессам, но для иллюстрации больше всего подойдет Microsoft Operational Framework:

Процесс упрощен по сравнению с другими методиками, но MS выбрала, по моему, “главное” и отбросила дополнения или сложности, которые, в большинстве случаев, не нужны.
Как видно из диаграммы, внедрение и поддержка каждого IT сервиса проходит через три главные стадии. Есть и четвёртая  - “Manage”, которая как бы “нависает” надо остальными тремя, но её роль в основном “руководящая”.
Так к чему это я: я бы добавил еще третью ось и процесс выглядел бы не как “хождение по кругу”, а как движение в каком-то направлении, как растянутая пружина. И ось определяла бы увеличение полезности IT сервиса или решения. Этой полезностью может бы и снижение операционных расходов, и внедрение дополнительной функциональности, затребованной бизнесом, или даже улучшение такой иллюзорной метрики, как “удовлетворение пользователей оказываемыми IT услугами”.
А теперь я медленно подхожу к основной теме: что же будет заставлять IT службу “натягивать пружину” полезности? :) Самый распространенный и простой вариант – бизнес видит необходимость что-то изменить или внедрить и поручает эту задачу IT департаменту. К сожалению, многие вещи не видны со стороны бизнеса или даже в IT департаменте “сверху”, со стороны менеджмента. Я не говорю о стратегии, но о мелких вещах, “quick wins”, которые не требуют много времени/ресурсов/денег, но способны облегчить жизнь как и IT персоналу, так и бизнес пользователем.
Как правило, стратегические проекты внедряются долго, может происходить долгая “раскачка”, когда проект начнет внедряться и не факт, что он принесёт именно ту пользу, которую обещали. Это общеизвестный факт, что много глобальных проектов заканчивается “пшиком”. С другой стороны, постоянное, непрерывное улучшение чего-либо оказывает на бизнес гораздо лучшее впечатление. Как я уже писал, бизнес-пользователи и их удовлетворённость IT сервисами – это главное, на что работает IT служба. Маленькие успешные проекты, не требующие больших вложений, создают необходимое доверие бизнеса к своему IT департаменту.
Многие компании уже нашли решение данной проблемы: Google, например, позволяет сотрудникам достаточно большое количество тратить на проекты, не связанные с основной работой. С одной стороны, это как бы бесполезная трата времени, но с другой стороны – сотрудник набирается знаний и опыта, расширяет свой кругозор и это вполне может “выстрелить” при работе над основными задачами. Человеческий капитал, может быть, это то самое главное, что должно быть у каждой компании.
Очень трудно дать какие-либо рекомендации, как этот “человеческий капитал” надо использовать. У каждой компании может быть свой план действий и по моему скромному мнению, “отправными точками” могут быть:

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

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

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

Макс Крайнов опубликовал на своём сайте вакансию и потом за эти последовало два его поста: “Пара мыслей о российских резюме” и “По просьбам трудящихся – что я ХОЧУ видеть в вашем резюме”. С моей точки зрения и опыта, для получения работы резюме должно быть составлено именно таким образом, как написал Макс. Тем не менее, было достаточно много комментариев от людей, которые были не согласны с написанным. Возможно реалии “западного” и “восточного” рынка труда разные. Чтобы лишний раз не спорить, я бы очень посоветовал почитать книги книги, написанные бывшим работником отдела кадров (HR): “44 insiders secrets that will get you hired” и “Corporate Confidential: 50 Secrets Your Company Doesn't Want You to Know - And What to Do About Them”, автор – Cynthia Shapiro. Собственно говоря, в персональном блоге я об этом уже писал. Хотел бы упомянуть об этих книгах и в этом блоге, потому что с некоторыми допущениями принципы поиска работы и продвижения по службе, написанные в этих книгах, применимы во всём мире. Более того, я сделал краткие конспекты этих книг и выложил у себя на SkyDrive: “

• Shapiro, Cynthia: "Corporate confidential - 50 secrets your company does not want you to know";
• Shapiro, Cynthia: “44 secrets that will get you hired”.

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

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

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

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

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