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

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

Время немножко оживить блог :) В основном я активен на персональном блоге, сюда как-то перестал писать. Но сейчас хочу поделиться своим необычным опытом – с другой стороны поиска работы.
Так получилось, что я сейчас помогаю своему менеджеру нанимать новых сотрудников в отдел. Решение о найме, конечно же, принимаю не я, но моя рекомендация учитывается в конечном решении.
Что меня поразило: оказывается, очень тяжело найти людей с нужными знаниями и опытом в пределах разумной заработной платы. Естественно, если искать кандидатов на зарплату в £1,000,000 в год, то найти их будет легко :), но не каждая компания может это себе позволить. Мы тоже пытаемся “нащупать тонкий баланс” между зарплатой, которую мы обещаем и положением на рынке труда. Скажем так – наше предложение в плане денег имеет большой диапазон, но в целом выглядит вполне разумным.
Несмотря на это, КПД процесса крайне низок:

• За два месяца мы провели телефонные интервью со ~150 кандидатами и с теми, кто прошёл его, персонально встречались или общались через Skype for Business. Результат: предложили позицию 5-ти(!) кандидатам, из них 4-ре приняли предложение о работе. Т.е. “выход” ~3%. И это не считая отдела кадров, которые “просеивали” первичные резюме;
• Среднее время, затраченное на телефонное интервью – ~30 минут;
• Среднее время на второе интервью либо при личной встрече, либо через Skype - ~1 час.

Можно легко посчитать трудозатраты на этот процесс, принимая во внимание то, что телефонное интервью проводит один человек, а второе – три (менеджер и два технических специалиста). Только “прямые расходы” на одного человека могут достигать ~£1,000! Это наше суммарно затраченное время, переведённое в фунты.
Что я для себя выяснил, потратив кучу времени на интервью:

• Абсолютно необходимо интервью первого уровня (по телефону), главной целью которого будет выяснить, насколько соискатель “приукрасил” свои знания и умения в резюме и отобрать кандидатов на второй уровень интервью. Если подходить формально и отбирать на основе резюме – куча времени будет тратиться впустую на кандидатов, не соответствующих требуемому уровню (“Все врут”);
• Задача второго интервью – узнать уровень технических знаний кандидата, понять, насколько он может “вписаться” в команду и перспективы роста будущего специалиста. Может случиться, что человек понравился, но на именно “эту” позицию он или она сейчас не “тянет”, но есть потенциал и кандидата можно всё-таки можно взять с “прицелом” на будущее.

Вы не поверите, но около 60%-70% телефонных интервью заканчивались тем, что я не рекомендовал дальше связываться с кандидатом. В основном преувеличивалось участие и роль в проектах. Например, в резюме было указано, что человек мигрировал Exchange в Office365, а на самом он просто “нажимал кнопки” на портале. Некоторые настолько злоупотребляли “фильтром-бьютификатором”, что практически всё в резюме оказывалось неправдой. Один человек прислал такое резюме, что я сказал своему начальнику: “Либо он немеряно крут, либо отчаянный врун”. Последнее оказалось истиной :). Верите ли, но в резюме был указан опыт программирования на C++/C# и когда я его попросил рассказать об этом подробнее, парень мне сказал, что он создал портал на GitHub для разработчиков, а потом сидел рядом! К коду его не пускали! Т.е. он “сидел там, где курили” и далее по смыслу :)
Как я проводил телефонное интервью: сначала просил рассказать о себе, чтобы немного расслабить и разговорить человека. Спрашивал о хобби и других вещах, не связанных с работой. Потом расспрашивал о проектах, в которых кандидат принимал участие. Главные вопросы при этом – “Какая Ваша роль была в этом проекте?”, “Чем конкретно Вы занимались?”, “Какой был результат Вашей работы?”. Как правило, уже на этом этапе можно было почувствовать насколько резюме соответствует или не соответствует реальному положению дел. Дальше я спрашивал технические вопросы, для ответа на которые достаточно концептуальных знаний о технологиях, ничего сложного. Например, какие есть опции миграции Exchange в Office365. Но даже на таком типе вопросов люди “зарывались”. Один сертифицированный специалист в Azure не смог мне назвать, какие есть варианты сетевого подключения серверного центра (ЦОД) к Azure. Как я уже сказал, вопросы были вполне базовые, я не собирался делать людям “больно”, просто надо было отсеять “левых” кандидатов :)
“Больно” мы соискателем делали на втором интервью :) Здесь важно было проверить технические знания, опыт работы и подход к решению различных проблем. Иногда интервью превращались в цирк: некоторым людям удавалось “уболтать” интервьюера во время телефонного интервью и выйти на второй раунд, но при “перекрёстном допросе” двух технических специалистов они начинали эпически “сыпаться”. Пример из жизни: когда человеку объяснили формат интервью, он тут же испуганно заявил, что не рассчитывал на это! В дальнейшей беседе оказалось, что он не был архитектором решений, а просто руководил проектами, поэтому технических знаний он не имеет. Когда же его спросили, почему в резюме у него написано, что он эксперт в “…” технологиях, а так же был вовлечён в “архитектуру, дизайн и внедрение” кандидат ответил, что это перепутали в агентстве и нам выслали неправильное резюме. Мы попросили прислать “правильное” резюме и больше от этого человека мы ничего не слышали :)
Подход к второму интервью зависел от того, искали ли мы инженера или архитектора. Для инженера задавали больше вопросы по технологиям, больше углублялись в тонкости программных продуктов. В случае архитекторов я предпочитал интервью проводить основываясь на каком-то сценарии: проблема, требования бизнеса, функциональные и не-функциональные требования – вперёд! Естественно, не существует одного правильного решения, задачей было понять, насколько кандидат соответствует позиции: как он подходит к решению проблемы, учитывает ли все требования, какие варианты предлагает (если предлагает вообще), как отвечает на вопросы и т.п. Архитекторы в нашей департаменте общаются с клиентами, поэтому умение правильно изложить свою точку зрения очень важно. Технические знания, с моей точки зрения, здесь менее важны по сравнению с подходом к решению проблемы. Я рекомендовал несколько людей основываясь именно на этом, несмотря на то, что технически они были ограничены в знаниях чисто своими позициями на текущей работе. Нельзя требовать от человека глубоких знаний продукта если он занимается поддержкой инфраструктуры (BAU).
Как правило, процент положительных отзывов после второго уровня интервью выше (~40%-50%), но после этого начинается “торговля” с отделом кадров о зарплате и на этом этапе очень много людей решает отказаться от позиции. Некоторые “просят” слишком много и мы сами им отказываем. Печально. Изначально мой менеджер планировал набрать в отдел около 20 человек, сейчас мечтает, чтобы удалось нанять 10 :))

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

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

Не уверен, писал ли я на эту тему или нет, но мне кажется она важной: как документировать проблемы при работе над проектом. Формально - это одна из обязанностей менеджера проектов (МП), технический специалист (ТС) не должен вести подобного типа документацию. Но иногда бывает, что МП по каким-либо причинам этого не делает, поэтому я самостоятельно начинаю документировать различные проблемы для своей же безопасности.
Не секрет, что часто большие проекты не всегда идут гладко: то возникают какие-то проблемы (в худшем случае – проект приходится закрывать), то происходить выход за границы бюджета, либо отставание по срокам. Вот тут-то начальство и другие люди, участвующие в проекте, начнут искать, на кого “повесить всех собак”. Как раз для эти случаев у меня наготове обычно два документа: “Incident log” (“журнал проблем”) и “Lessons learnt” (“выученные уроки”). Сразу же подчеркну: содержание этих документов должно “тонко подстраиваться” под каждую конкретную ситуацию! Т.е. то, что с вас потом будут спрашивать. Вы сможете потом подтвердить документально все факты и так же их “количественные” и “качественные” характеристики.
По моему опыту, в случае проблем/инцидентов всех интересуют следующие вещи:

1. Когда это произошло. Если проблема не решается быстро, надо знать, как долго она тянется. Либо, если решение проблемы не зависит от вас, как долго вы ждёте действий от кого-то другого;
2. Относится это напрямую к области вашей ответственности или нет. Вполне возможно, что кто-то “спихнул” проблему на вас и вы кучу времени потратили на “разруливание ситуации”, на которую вы не должны были тратить время. Но это же забирает время и ресурсы!? Такая классификация позволяет в дальнейшем доказать, что задержки были вызваны не непосредственно вашими действиями, а внешними факторами. Из последнего моего проекта 11 из 23 проблем не относились к тем изменениям, которые я и моя команда сделали. Порядка 55 часов было потрачено, чтобы решить проблему и доказать, что она возникла не из-за нас. Это огромная цифра;
3. Краткое описание ситуации и проблемы – тут важно правильно всё написать, чтобы потом избежать “переопределения” ситуации и разговоров о том, что было “это”, а не “это”;
4. Влияние на проект (“критическое”, “среднее”, “малое”, “незначительное” и т.п) – для установки приоритетов для решения проблем;
5. Влияние на бизнес (“критическое”, “среднее” и т.п.) – иногда вышестоящие менеджеры не в курсе, насколько значительно происшествие. Категоризация позволит избежать “получения по шапке” за малозначимое событие;
6. Статус инцидента – “закрыт” или всё ещё “открыт”;
7. Причина/что вызвало происшествие – краткое описание как можно в более простых терминах причины события. Более детальная и “техническая” информация заносится (так, по крайней мере, я делаю) в другой документ – “Lessons learnt” (“Выученные уроки”). Об этом чуть позже;
8. Сколько времени потребовалось на диагностику причин проблемы, причём это не включает в себя время, потраченное на устранение. Во время последнего проекта это время колебалось между 1 часом и 1 днем. Суммарно потратили 152 часа (на все инциденты), среднее время для нахождения причины – 7 часов. Это время надо учитывать особенно в том случае, если проблема была вызвана не вами. А вот решение проблемы может практически и не занять много времени;
9. Время, потраченное на устранение инцидента и его последствий – максимально точное время потраченных усилий. Опять же, из последнего проекта – 39 часов суммарно, 2.5 часа в среднем на проблему. Разница существенная между диагностиком и устранением. “Дельта” показывает начальству, куда ушло время. Особенно, если оно было зря потрачено на “бодание” между различными командами. В нашем случае так часто и было;
10. Действия, предпринятые для устранения проблемы в короткий срок – что было сделано, чтобы вернуть какой-либо сервис в нормальную работу. Вполне возможен “костыль”, если надо что-то сделать очень быстро. Но это должно быть описано и задокументировано. Инцидент может быть не закрыт, если бизнес не удовлетворён решением проблемы;
11. Действия для недопущения проблемы в будущем. В отличие от предыдущего пункта, после этого инцидент можно формально будет считать закрытым.

Как я уже сказал, содержимое этого документа определялось вопросами от вышестоящего начальства по поводу проблем в процессе внедрения проекта. Вполне возможно, что что-то можно добавить, а что-то можно удалить. “Документ” – понятие вполне “живое” содержимое может меняться со временем.
По п.11: в него можно добавлять ссылки на документ “Lessons learnt”, но об этом чуть позже.

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

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

Недельки две назад “добил” последний экзамен на гордое звание MCSE: Windows Server 2012. Я решил сдать этот экзамен за день отъезда в командировку, поэтому пришлось срочно искать центр тестирования у которого была свободна эта дата. Немного пострадал из-за доверия к MS: когда я выбирал экзамен, мне было сказано, что этот экзамен доступен для сдачи издому! Т.е. запускаешь у себя на компьютере программу, которая мониторит тебя через вебкамеру и микрофон и сдаешь себе экзамен в тепле и уюте домашней обстановки. Поэтому я и не торопился с датой. Но когда уже начал записываться на экзамен, то получил дулю в виде сообщения, что в моей стране опция домашней сдачи недоступна. Из-за этого и была вся чехарда и спешка. Для меня в пределах доступности был только один центр тестирования в Рединге. Меня удивило, что в нём была куча свободных слотов. Но когда добрался к этому центру, я понял, что это не учебный центр, а так, пара классов для сдач экзаменов. Там даже £1 пытались брать за посещение туалета, но я их обманул :)
Сам экзамен, как мне кажется, будет немного легче 70-413. Может быть, из-за того что сетевым вопросам (RRAS, NPS и т.д.) почти не уделялось внимания. Основной упор: кластеры, виртуализация, т.е. высокая доступность серверов и восстановление после сбоев. Формат такой же, как и в 70-413: дается сценарий, потом шесть вопросов. Затем совершенно другой сценарий и вопросы. После может идти пачка вопросов с выбором ответа из списка. Основная сложность экзамена – в количестве информации в сценариях и неоднозначности. Мне кажется, что в некоторых вопросах возможно было выбрать два правильных ответа. Например, было сказано, что у компании есть два главных серверных центра и два резервных. В главных развёрнуты Hyper-V кластера. Надо развернуть серверы для приложения. Где это сделать? Я долго мучился с выбором, просто не видел разницы между главными центрами. Судя по баллам, которые я набрал, отвечал я правильно. Может, мне повезло и я угадал в некоторых местах. Но набрал я 833 балла из 1000 при проходном 700. Сам удивился :)
А теперь я готовлюсь сдать два экзамена на MCSE Desktop. Честно – сам не понимаю, когда это закончится. Я уже даже не надеюсь обновить VCP и CCEA, мне бы успеть обновить сертификацию MS до того, как снова выйдут новые версии :)

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

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

Пройдена ещё одна веха по пути сертификации на почётное звание специалиста по серверной инфраструктуре :) Неделю назад сдал “70-413 - Designing and Implementing a Server Infrastructure”. Подготовка прошла гораздо быстрее, чем к 70-412, так как “матчасть” я уже выучил и надо было только пройтись по материалам учебного курса.
А вот сам экзамен был гораздо сложнее, чем я ожидал. И не столько из-за сложности вопросов, сколько из-за формата.
Основной принцип экзамена – предоставить сценарий с кучей информации, затем идёт порядка 5-6 вопросов. Сначала очень детально пытался разобраться с большим объёмом информации, затем отвечал на вопросы. После этого перешёл… совершенно другой сценарий и вопросы! Т.е. время, которое потратил на изучение информации в первом случае практически ушло впустую. Там было очень много данных, которые никаким образом не относились к задаваемым вопросам. После третьего сценария я уже просто изучал текст на экране, мысленно выделяя какие-нибудь странные моменты, затем переходил к вопросам и выискивал в тексте нужную информацию.
После сценариев настала очередь вопросов в формате: какая-то информация, затем утверждение и надо было ответить на вопросы: “информация правдива, но утверждение ложно”, “информация ложна, утверждение ложно” и т.п. Например (выдумал сам): “Чтобы добиться устойчивости DHCP сервиса, надо установить дополнительные DHCP сервера. Утверждение: установите DHCP сервер в кластер”. И т.д. Всего было около 30 подобных вопросов.
Когда я ответил на вопросы, я уже был готов увидеть результат, но я рано радовался. С точки зрения MS та пачка вопросов была приятным перерывом в экзамене и потом снова пошли сценарии!!! У меня уже мозги плавились и я уже почти отчаялся. К моему облегчению после пары проходов по сценариям я увидел отчёт об экзамене: сдал! Набрал 700 баллов при проходном – 700 :)
Честно говоря, были сомнения о результате. Очень много вопросов было про удалённый доступ, организацию безопасного доступа на основе RRAS/RADIUS/VPN/NPS и т.п., а я в этом в деле “плаваю”. Я в этом разделе ответил хуже всего, набрав где-то 50% правильных ответов. Этот раздел даёт около 20%-25% в итоговую оценку. Т.е. если правильно отвечать на остальные вопросы, то можно “прорваться” :)

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

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

Недавно столкнулся с тем, что вроде бы устоявшиеся термины такие как DR, HA и прочее, могут людьми восприниматься по разному.
Один клиент очень настойчиво просил для нескольких тестовых сред обеспечить такую же степень отказоустойчивости и восстановления после сбоев, как и у рабочей (“production”) среды. На мои робкие замечания о том, что вряд ли для тестовой среды нужны такие же HA (“high availability”)/DR (“disaster recovery”), мне сказали, что так надо :D. Мало того, компоненты инфраструктуры/приложений “production” по умолчанию должны устанавливаться в двух раздельных серверных комнатах в главном центре обработки данных и в резервном, удалённом от основного на N-ое количество километров. Требование клиента коренным образом меняло дизайн сети, инфраструктуры и т.п. Это и время, и стоимость. После нескольких совещаний, на которых клиент настаивал чтобы “тестовая среда была как production” и DR необходимо, мы выяснили, что всего-лишь требовалась возможность восстановления тестовой среды из резервной копии за оговоренное время :)
Что можно посоветовать: документировать все требования клиента, просить подтвердить правильность их понимания и возникающих осложнений в связи с изменившимися требованиями. В конце концов, если требования неправильно сформулированы и клиенты оплачивают работу – почему бы и нет :) Но лучше, конечно, выяснить разногласия в понимании раньше, чему будут потрачены деньги/время.

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

Со времени сдачи 70-411 прошло почти полгода! Не потому что я затягивал со сдачей экзаменов – я просто хотел нормально выучить технологии, с которыми я очень редко работаю: Workplace join, IPAM, Hyper-V cluster и т.п. “Поднял” тестовую среду на своём лептопе i5/4GB RAM/SATA HDD. Было тяжеловато :) Мой друг Андрей Ш., по совместительству тренер MS, посоветовал для этих целей почаще пользоваться MS Virtual Labs. Надо будет попробовать в следующий раз.
Я прочитал книгу по курсу несколько раз, потом сделал конспект, чтобы помнить важные вещи. Но экзамен показался мне проще, чем 411. Вопросы в основном были про High Availability кластера Hyper-V, трастов “лесов”/доменов AD и т.п. Были вопросы, которые в учебных материалах, которые у меня были, никак не освещались. Например, что можно “бекапить” с помощью Azure Backup. Workplace Join, IPAM были представлены какими-то “хитрыми” вопросами, с которыми, наверное, в реальной работе можно было столкнуться, но выучить их – вряд ли. С моей точки зрения, это не совсем правильно. Я бы спрашивал больше “понимание” функционала IPAM и ограничений, чем задавать вопросы с “подковыркой”.
Но, в целом, экзамена бояться не надо :) В отличие от 411, вопросы достаточно адекватные, т.е. содержат в себе достаточно информации для ответа.

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

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

На прошлой неделе сдал 70-411 “Administering Windows Server 2012”. 800 из 1000, но пришлось изрядно попотеть. Он мне показался сложнее 70-410 из-за большого количества вопросов по DirectAccess/NPS/NAP. Я давно уже не делал удалённый доступ на основе решений Windows, так как обычно это входит в зону ответственности команд Security/Network, а они, сами понимаете, Windows не любят :)
Вопросов по NPS/NAP так много, что в какой-то момент мне казалось, что меня “валят” :) И, как я писал для 70-410, много вопросов поставлены таким образом, что надо догадываться, что имелось в виду. Наверное, таким образом хотят исключить ответы методом “исключения”, но, с другой стороны, не всегда можно вспомнить в таких “неявных” вопросах, какую конкретно опцию надо выбрать.

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

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

Пользуясь случаем, хочу в который раз выразить свою благодарность некоторым людям в помощи в моей сертификации :) Я снова начал бесконечный цикл сдачи экзаменов MS :D
Мне приходится сдавать все экзамены по новой, так как моя MSCE 2003 сертификация устарела и “апгрейд” недоступен. С другой стороны – это хорошо, потому что я уже давно не администрировал сервера и мне полезно пройтись по всем разделам администрирования по новой.
TOGAF и Prince2 отняли у меня много времени: не потому что это сложные экзамены, а потому что они беспредельно скучные! Приходилось заставлять себя читать по паре страниц в день, беспрерывно борясь со сном :)
Учёба по техническим материалам проходит гораздо веселее! :D Единственное, что меня “замедляет” – это необходимость запускать несколько виртуальных машин на моём лептопе с i5/4 GB RAM/HDD SATA. Две виртуальные машины, в которых запущены Win2012 Server с AD, DNS, DHCP, WDS и т.д. капитально “просаживают” лептоп, учат терпению и смирению :)
Первый экзамен “70-410 “Installing and Configuring Windows Server 2012” я сдал, по моему, в апреле. Больше всего времени я потратил на то, чтобы выучить Windows Deployment Service – это, наверное, то, что изменилось больше всего после Win2003/RIS, включая новые форматы образов для установки. Остальные вещи как бы “ложились” уже не существующие знания и опыт, поэтому особых трудностей не доставляли.
А вот экзамен по сравнению с 2003 сертификацией изменился и, по моему скромному мнению, не в лучшую сторону. Не сам формат, а стиль построения вопросов. Они задаются таким образом, что непонятно, какой, собственно, ответ правильный. Не помню точно, что было в 70-410, но в 70-411 меня спросили: “Вы создали GPO для установки шотката в старт-меню. После того, как пользователь залогинился в систему, шоткат отсутствует. Какие возможные причины?” И даются четыре варианта ответов. включая: GPO не применилось из-за security filtering, путь к шоткату неправильный (два остальные были явно неправильные). И что мне надо было выбрать!? Оба варианта возможны, но в вопросе ничего не говорится про ошибки и не даются никакие логи для дополнительной диагностики. Допускаю, что любой из этих двух ответов может приниматься как правильный, но выбрать-то надо один и это вводит в ступор.
Сам экзамен я сдал с результатом 825 из 1000. Рекомендую выучить наиболее распространённые команды PowerShell для установки и администрирования серверов, включая AD и другие компоненты (DNS, DHPC и т.п.) Достаточно много вопросов по “командлетам”.

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

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

Много времени назад я сдал TOGAF9 и стал готовится к сдаче Prince2. Prince2 – это методика управления проектами, не обязательно IT, разработанная для государственных организаций в Британии и более-менее узнаваемая в Европе. Насколько я знаю, в США и остальных странах применяется PMP, но мне это неважно :)
Идея сертификации на Prince2 состояла в том, что она бы дополнила TOGAF9 и помогла бы мне в поиске работы архитектора уровня предприятия (enterprise architect). Скажем так: на 100% это мне не помогло, но, тем не менее видно, что комбинация TOGAF+Prince2 привлекает внимание, так как ко мне на LinkedIn часто “стучатся” рекрутеры и предлагают менеджерские позиции, но я пока решил “крутиться” в околотехнической области :)
Сертификация Prince2 состоит из двух этапов: первый экзамен для получения Prince2 - Foundation, второй – уже собственно Practitioner. Practitioner – это необходимый уровень для менеджера проектов, так как Foundation проверяет только знание теории.
Сдать сразу два экзамена в один день не получиться: надо сначала пройти Foundation, поэтом уже можно сдавать Practitioner. Вся “загвоздка” в том, что эти экзамены в 21-м веке сдаются… на бумаге и результат надо ждать полторы-две недели! :))) Хоть уведомление “сдал/не сдал” присылают по электронной почте :)
Prince2 Foundation я сдал без проблем. Как я уже сказал, экзамен тестирует знание основных терминов, процессов и, имея учебные материалы, пройти его не представляется сложным. Насколько я помню, я набрал около 75 баллов при требуемых 55 для сдачи.
А вот Prince2 Practitioner… Я, честно говоря, не знал его формат и просто пошёл на этот экзамен, надеясь на своё самообразование. Но тест построен по типу сценария, когда тебе даётся описание какой-то ситуации (бизнес-проекта в данном случае) и начинают гонять по всем разделам Prince2: risk management, communication management и т.д. Вот тут я начал и “потеть” :). Если пойти на нормальные курсы, то там два дня посвящяется семинару по “обкатке” и разбору подобных ситуаций. Я на курсы не ходил (почему – это отдельный разговор, от меня это не зависило) и мне пришлось очень туго. Плюс на экзамене разрешено пользоваться официальными учебными материалами, но не своими заметками. Как я завидовал людям, которые на экзамене открывали учебники и заглядывали в них! Мне же приходилось морщить свои три извилины, вспоминая, что там в различных процессах и стадиях..!
Признаюсь, когда я ждал результаты теста Practitioner, я морально был готов к тому, что я его не сдал. Поэтому очень был рад, когда мне пришёл емейл, уведомляющий меня о том, что Practitioner я сдал. Надо было набрать 44 или 46, я набрал 51 или около того. Чуть-чуть переполз нижнюю границу! Но ведь сдал – значит, победил, а победителей не судят! :))))
Теперь коротко суть этого длинного поста: Foundation можно выучить и легко сдать самому, Practitioner – лучше пойти на курсы или на двух-дневный семинар, где будут разбирать сценарии управления проектами. Можно сделать как я: рискнуть и попробовать сдать экзамен, но это будет гораздо труднее, чем Foundation. Плюс разрешение использовать учебные материалы при сдаче Practitioner очень помогает.
Само знание Prince2 мне помогает разговаривать с менеджерами проектов на их “языке”; понимать, зачем они иногда требуют какие-то документы или отчёты; и самое главное – я могу видеть недостатки в управлении проектами и “сманеврировать” в такую сторону, чтобы “упасть” полегче. Например, если мы начинаем работать над сложным проектом, но не определены критерии принятия результатов, то я сразу же начинаю бить тревогу и даю об этом знать всем заинтересованным сторонам.

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

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

Снова пришло время что-нибудь написать сюда, оживить дремлющий, так сказать, технический блог :) Не то чтобы не было что писать, но как-то руки не доходили. Я готовился к различным эказменом, постоянно ездил в командировки, персональный блог и плюс спорт :D
Некоторое время назад я пытался “прорваться” в enterprise architects, но, как показал опыт, без формального титула в резюме сделать это практически нереально, поэтому я решил обновить свою техническую сертификацию, а то уже стыдно даже говорить, что я MSCE 2003 ;)
В ближайшее время собираюсь написать о Prince2 и сдаче экзаменов по Windows 2012 инфраструктуре. Прямо сейчас и начну, а то сижу на ж/д станции Wembley Stadium, жду свой поезд через полчаса и времени навалом :)

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

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

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

Но одна из них повторяется чаще, чем я хотел бы – “размывание” границ (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 минут пространного разговора, потом надо потратить еще минут пять, чтобы вернуть концентрацию и, в худшем случае, так впустую тратиться почти целый день.
Ещё я начал отказываться помогать коллегам, когда они просят что-либо меня сделать, так как “мне это проще и у меня получится это быстрее”. Я так один раз сделал и в потом в течении двух дней я “разгребал” все сопутствующие проблемы и вносил изменения. А коллега в это время расслабленно занимался своим делом. Получается, я помог ему, мне пришлось тратить своё дополнительное время и усилия, чтобы справляться с его и моими задачами, а он спокойно отчитался о выполненном проекте. Нееее, я уже “поумнел” :)

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

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

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

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

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

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

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

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

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

Достаточно долго не писал в этот блог, в основном увлекался постами в персональный :) Да и не было ничего особенного, о чем хотелось бы написать. Так… “текучка” и рутина.
Но недавно мне пришлось провести четыре дня в процессе начального перехода от одного аутсорсера к нам. Аутсорсер, которого мы заменяем – очень уважаемая компания, её имя всем известно. Не буду его называть, но оно у всех на слуху. Так к чему это я: по идее, переход от одного поставщика  IT услуг к другому должен быть сравнительно безболезненным. Как в магазине: сегодня молоко вам привозил один поставщик, завтра – другой. Многие видят подобную гибкость как одну из причин, почему  IT сервисы должны быть за-аутсорсены. Но это в теории. На практике же выглядит всё по другому. Есть аутсорсеры, которые не стараются усложнить жизнь своему “коллеге” и переход происходит сравнительно безболезненно. В моем случае это было “слегка” не так: предыдущая IT компания заявила, что методы безопасности, применяемые к серверам клиента, являются интеллектуальной собственностью компании, поэтому нам не разрешается выполнить миграцию физических серверов в виртуальную среду. Никакие доводы о том, что клиент заплатил деньги за услуги и является собственником своих данных, приложений и платформы не возымели никакого действия! Отказ нам помогать со стороны предыдущего аутсорсера мотивирован очень тонко: они не отказываются предоставлять информацию, доступ к инфраструктуре и т.п., но легкой миграции не получится из-за какой-то эфемерной “интеллектуальной собственности”. Вряд ли компания, которую обслуживал этот аутсорсер, могла даже подумать о таком повороте событий.
Как вы думаете, кому не повезло в этом случае? :) Явно не предыдущему поставщику IT услуг – они свою прибыль уже получили. Даже не мы, новый аутсорсер: отказ в p-2-v миграции означает растягивание миграции по времени, более спокойный переход, клиент будет более лоялен к возможным проблемам после миграции и плюс это дополнительные деньги – коммерческое предложение делалось с учетом определенных условий. Если эти условия не соблюдаются – все необходимые действия по миграции оформляются как проект или набор проектов с соответствующими атрибутами в плане бюджета, ресурсов и т.п. Проигравшим может оказаться клиент, кто будет за это всё платить.
Вывод из этой истории очень простой: прежде чем “впускать” аутсорсера, подумайте, как вы будете его “выпускать” и заранее подстрахуйтесь на случай отказа аутсорсера выполнять какие-либо разумные требования.

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

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

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

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

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

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

• Документацию мало кто хочет читать;
• Ее никто не хочет писать;
• В большинстве случаев непонятна полезность уже написанных документов.

Начнем с последнего пункта. Очень часто люди забывают, что документация должна быть применима каким-либо образом в реальной жизни. Если есть много документов, но непонятно, что с ними делать – грош цена всей этой информации. Документация должна быть написана так, чтобы поддерживать ключевые бизнес процессы и удовлетворять потребности в информации людей, участвующих в этих процессах и исполняющих различные роли. 
Простой пример: в моей компании есть четыре основных процесса: “продажа” (“pre-sales”), “инициация проекта”, “выполнение проекта” и “ежедневная поддержка” (“producation/business as usual”). Есть у нас портал, на котором опубликована масса технической информации (есть и неплохие документы). Но: разных людям нужна разная информация на разных этапах. В случае с “продажей” необходимо знать в общих чертах, что мы можем предложить клиенту, какая выгода от этого будет, сколько это будет приблизительно стоить и займет времени. В процессе инициации проекта надо понимать какие есть предварительные требования для внедрения какого-либо решения (инфраструктура, лицензии и т.п.). Во время внедрения – стандартные решения (“best practices”) для технического персонала и стандартный план проекта для менеджера проектов и т.д. Если опубликованные документы не могут моментально “кликнуть” в каком-либо месте, заявляя свою полезность – мало кто будет дотошно разбираться, как можно использовать тот или иной документ. Поэтому вся документация должна быть “привязана” к бизнес процессам, использовать стандартные шаблоны и т.п.
О первом и втором пункте. Все очень просто: люди по своей природе ленивы. Если их не заставлять, то 90% не будут делать “лишних телодвижений”. Для того, чтобы заставить работников писать/читать документацию, оценка эффективности того, как они это делают, должна быть частью ежеквартального/ежегодного пересмотра качества работы (KPIs, “performance review”) этих сотрудников. В таком случае у них будет личная заинтересованность в том, чтобы как можно полнее использовать документацию (т.е. накопленные знания) и самим ее писать (т.е. делиться своими знаниями).

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

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

Может показаться, что я забросил этот блог. Отнюдь :) Просто в данный момент я заканчиваю работу над крупным проектом и все, что я делаю – это  ударными темпами пишу документацию. Писательский зуд удовлетворяется полностью :)
Мой текущий проект является хорошим примером того, что иногда имеет смысл отказаться от тщательного планирования проекта: сформулировать техническое задание, критерии успеха, планировать ресурсы и т.д. Отличительной чертой проекта было то, что бизнес понимал, что “дальше так жить нельзя”. Но, в то же время, никто в бизнесе не обладал полной информацией, как же все-таки они “хотят жить”. Слава Аллаху, эту проблему бизнес так же осознавал. С другой стороны, моя компания, как поставщик IT услуг, обязана была выполнить ряд задач и это было обговорено в контракте. Так к чему это я: нам пришлось отказаться от большинства шагов, присущих хорошему проекту! Все попытки оценить время, требуемое на завершение проекта, ресурсы, создать предварительный детальный технический дизайн упирались в то, что тупо не было возможным получить необходимую информацию от бизнеса. Все, что мы могли сделать вначале – это предоставить приблизительный план действий на две недели вперед. Максимум! Надо отдать должное, бизнес принял данную ситуацию как есть и мы использовали метод “ковбойского наскока”: составили общий дизайн (этакий комьюнике о намерениях), провели небольшой пилотный проект и начали полномасштабное внедрение по типу JFDI (just f…g do it!).
Признаюсь, у меня лично “сердце не лежит” к данному подходу. Но это позволило нам:

• Все-таки начать работу над проектом несмотря ни на что: опасения и недоверие бизнеса (бизнес считал, что мы не справимся с задачей, потому что предыдущий аутсорсер не смог), отсутствие необходимой информации и т.п.;
• Восстановить доверие бизнеса и продемонстрировать, что проект может быть успешно закончен. После того, как мы прошли отметку приблизительно 10% завершенности проекта, бизнес уже не только не вредил, но и начал активно помогать – те люди, которые не имели раньше времени для анализа сложных моментов или обсуждения чего-либо, стали гораздо доступнее для встреч;
• Обычные пользователи, которые участвовали в “пилоте”, почуствовав “вкус новшеств”, помогли нам изменить настроения среди остальных пользователей с пессиместических на более открытые к изменениям;
• Бизнес и мы “наработали” необходимую информацию о структуре бизнеса, требованиях (в плане приложений, доступа к данным и т.п), которая помогла нам во время проекта и поможет нам в дальнейшем.

Самое смешное, что 99% того, чего опасался бизнес до начала работы над проектом, не подтвердилось. Это все было на уровне диалога, который Э.Берн хорошо описал в книге “Игры, в которые играют люди”: вы нас говорите, что вы будете делать, а мы будем придумывать причины, почему это работать не будет. Именно из-за первоначального недоверия и пессимизма мы с большой “пробуксовкой” начали проект.
К сожалению, есть и своя “ложка дёгтя”:

• Некоторые вещи можно было бы сделать лучше, имей мы необходимую информацию пораньше. Тут уж трудно что-то изменить;
• После окончания проекта надо будет провести еще один цикл хотя бы анализа того, что сделали и наметить задачи для улучшения внедренного решения. С этой точки зрения проект был закончен не самым эффективным образом. С одной стороны - это плохо, с другой – хорошо, так как будет новый проект и под него выделят (а могут и не выделить) новый бюджет.

Напоследок еще раз подчеркну: если бы мы всего боялись, то ничего бы и не сделали. В некоторых случаях надо плюнуть на все и просто постараться что-то сделать вместо того, чтобы фантазировать на темы “что мы будем делать, если что-то будет не так или не так”. “Глаза бояться, а руки делают” :)

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