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

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

Недавно разговаривал со своими бывшими коллегами, которые в данный момент работают на аутсорсера (но не того, на которого работаю я). Они высказали интересное мнение, почему некоторые компании вполне довольны аутсорсингом, даже не смотря на упавшее качество 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% того, чего опасался бизнес до начала работы над проектом, не подтвердилось. Это все было на уровне диалога, который Э.Берн хорошо описал в книге “Игры, в которые играют люди”: вы нас говорите, что вы будете делать, а мы будем придумывать причины, почему это работать не будет. Именно из-за первоначального недоверия и пессимизма мы с большой “пробуксовкой” начали проект.
К сожалению, есть и своя “ложка дёгтя”:

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

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

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