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

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

Даже не знаю, с чего начать: то ли с извинений, почему я так долго не писал в этот блог, то ли сразу “взять быка за рога” и начать писать по теме. Всё-так склоняюсь к последнему варианту.
Каждая компания проходит через циклы обновлений 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”.

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

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

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

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

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