Светофоры нашей жизни
Автор
Марина Аншина
Если тронешь один кирпич, все здание ИТ-архитектуры может развалиться.
Каждый человек во что-то верит. У каждого свой бог и дьявол. И каждый имеет свои заповеди, не всегда четко сформулированные, но всегда вполне определенные, которым он и следует. Эти заповеди — светофоры наших жизней. Правда, чаще всего только с одним глазом — запрещающим красным цветом. Ведь и классические заповеди в основном запрещающе одноглазы. Иногда встречаются светофоры с двумя глазами — красным и разрешающим зеленым. А вот с тремя, с предупреждающим желтым глазом, — большая редкость. Хотя, возможно, по мере развития человечества трехглазые светофоры станут более популярны. А там глядишь, возникнут и другие многоглазые модификации.
Вероятно, кто-то все еще думает, будто заповеди сильно осложняют жизнь. Однако это не так. Заповеди существенно упрощают ее, как светофоры упрощают движение транспорта, а в больших городах просто делают его возможным. Как без них?
Объединяясь в группы, люди, осознанно или нет, стараются найти тех, кто разделяет их принципы. Так что заповеди подобных групп, начиная семьей и заканчивая профессиональными сообществами, обычно во многом схожи.
Я хочу рассказать о том, каким заповедям мы следовали в ИТ-подразделении российского производственного распределенного промышленного холдинга среднего размера и как это нам помогало.
«Не навреди»
Работа ИТ-специалистов во многом напоминает работу хирурга. Ведь в наше время жизнь организации очень сильно зависит от ИТ, и нарушения в их деятельности могут стать для нее смертельными. Это уже касается не только банков и телекома, но и промышленных, розничных, логистических организаций, да и большинства других. Важно также отметить очевидную тенденцию роста данной зависимости. Причем этот рост имеет существенное ускорение, и, к сожалению, многие ИТ-специалисты за ним не успевают. Им все еще кажется, что, например, простой сервера на несколько часов не является большой бедой. За сервером они не видят ИТ-сервисы, которые от него зависят, и не понимают, что происходит с процессами организации, использующими такие сервисы. Именно поэтому необходимо организовать грамотное управление ИТ: архитектурой ИТ предприятия, персоналом, занятым ее развитием и обслуживанием. Вот почему данная заповедь столь важна. И не нужно считать, будто она понятна всем ИТ-специалистам. Практически в любом ИТ-коллективе найдутся люди, просто не задумывающиеся об этом.
Для работ, которые могут привести к нарушениям и тем более к прекращению предоставления ИТ-сервисов, должно действовать правило: «Семь раз отмерь, один раз отрежь». Тем более что технические возможности «отмерить» в наше время всегда есть. А при подсчете, сколько это стоит, не забудьте прикинуть, во что обойдется ошибка.
«Помни про пользователя»
Более мягкий, но не менее важный принцип состоит в том, что любое решение надо проверять, чтобы определить, как оно отразится на пользователях. Скажем, смена интерфейса системы, пусть даже на более удобный и красивый, подразумевает привыкание к новым условиям и обучение сотрудников. Не следует считать, будто они неблагодарны или капризны. Надо посмотреть на ситуацию их глазами. Тогда, возможно, удастся понять: то, что казалось техническим специалистам нужным, для пользователей бесполезно, а то и вредно. Причем такое несоответствие происходит на всех уровнях — от внедрения новой системы до замены оборудования. Поэтому, если что-то делаешь, всегда понимай для чего и для кого. Я ни в коем случае не хочу сказать, что любой проект или задача предполагает строгое экономическое обоснование, но ответить на вопрос «зачем?» необходимо. Даже если руководство настолько доверяет ИТ, что этого не требует. Именно поэтому мы стремились любое важное решение провести через комитет по ИТ, куда входили генеральный директор и руководители функциональных направлений. Именно там мы доказывали, что «зачем» перевешивает затраты, как временные, так и финансовые. Мы старались не принимать решения за заказчика, ведь «отрезать может только тот, кто подвесил». То есть решение о том, делать ли проект, что внедрять, должен принимать тот, кто выделяет ресурсы — дает деньги. Не стоит ИТ самостоятельно выбирать, что нужно компании, надо постараться беспристрастно и объективно показать руководству все достоинства и недостатки того или иного варианта.
«Будь максимально открыт для всех, кто может в этом нуждаться»
Эта заповедь логически продолжает предыдущие. Всё, что относится к ИТ,а также компоненты ИТ-архитектуры настолько тесно связаны между собой, что любое действие, направленное на одну компоненту, способно совершенно непредсказуемым образом отразиться на какой-то другой. Даже очень грамотный ИТ-специалист не всегда может просчитать все варианты и предусмотреть все последствия. Однако если тронешь один кирпич, все здание ИТ-архитектуры может развалиться. Вот почему максимальная открытость — необходимое условие нормального функционирования ИТ в организации.
Не таи то, что делаешь, от коллег, пользователей и всех прочих — тогда вероятность аварий и сбоев существенно снизится. Наиболее простой и, увы, распространенный пример того, как этой заповеди не следуют, — изменения в АС в интегрированной среде. В желании выполнить изменения быстрее, что иногда диктуется производственной необходимостью, ИТ-специалисты упускают из виду, что с изменяемой АС связаны другие АС, эксплуатируемые в компании. Не счесть, сколько проблем и какие убытки приносит организациям такое узкомыслие. Конечно, открытость не предполагает нарушения разумных принципов информационной безопасности.
«Держи уши и ум открытыми»
Будь открыт для информации. Беда в том, что многие ИТ-специалисты интроверты и предпочитают работать изолированно. Они не только не рассказывают, что именно делают, но и не интересуются тем, что делают другие. ИТ-руководителю приходится приложить усилий не меньше, а то и больше дирижера оркестра, чтобы достичь слаженной работы коллектива. Очевидно, что добиться получения информации проще, чем того, чтобы все те, кому это важно, усвоили данную информацию и использовали ее по назначению. Я уже писала, что ИТ во многом сродни медицине. Во всяком случае, не менее актуальны для организаций, чем здоровье для человека. В больницах практикуются ежеутренние летучки, на которых обязательно присутствуют все ключевые сотрудники. У нас в холдинге подобные встречи ИТ-специалистов были еженедельными. Однако сейчас по прошествии времени я думаю, что этого было мало. Хотя и еженедельно проводить такие собрания было непросто — уж слишком сопротивлялся народ столь «неэффективной потере времени».
Небольшое отступление: когда кто-то очень спешит (и не только в ИТ) это обычно означает либо непонимание ситуации, либо нежелание что-то делать. То, что надо срочно, чаще всего не нужно вообще — это достаточно распространенный парадокс, имеющий к ИТ самое прямое отношение. Нередко последствия спешки намного серьезнее, чем увеличение сроков выполнения работы. Отсюда еще одна заповедь.
«Не спеши»
Никогда не обращали внимания, насколько надуманны многие сроки? В советское время это были пятилетки. Теперь — окончание какого-то другого календарного периода. Руководители очень часто назначают сроки, исходя из собственных пристрастий или планов, а бедные работники тянут жилы, чтобы в них уложиться. Это, однако, не означает, будто планирование совершенно бессмысленно. Оно необходимо, хотя бы из-за связанности между собой различных действий и работ и их взаимного влияния. Но там, где возможно, планы должны быть гибкими и должна быть предусмотрена процедура их изменения. Если сроки поджимают и, например, не хватает времени на тестирование ПО, надо хотя бы не полениться продумать, чем грозит сырой код. И если это так уж необходимо, идти на риск с открытыми глазами.
«Не насилуй программное приложение и старайся использовать АС в области ее основной функциональности»
Этот принцип нарушается многими и часто. Причем чем дальше, тем чаще. АС становятся все более сложными и техничными. Они стараются расширить свою функциональность. Все современные АС имеют API и, таким образом, их можно использовать как платформу для разработки чего угодно. Можно на ERP написать CRM или BI, можно и наоборот. Поэтому все чаще АС позиционируют как систему управления бизнес-процессами, а какими — да какими угодно. Но все не так просто. Моя любимая аксиома гласит, что «АС настолько гибка, насколько эту гибкость в нее заложили разработчики». И попробуйте найти возражения. И чем гибче АС, тем она сложнее, а следовательно, менее надежна и производительна, тяжелее в поддержке и обслуживании. Так что не стоит использовать АС вне основного функционала, для которого она предназначена, хотя технические возможности для этого обычно есть. Не буду утомлять читателей перечислением различных случаев, когда «изнасилованная» система жестоко мстила обидчикам. Вспомню проект, за который мне до сих пор стыдно, когда внедряя систему ITSM, я, как РП, пошла на поводу у заказчика, обладающего богатым воображением, и «прикрутила» к системе не свойственную ей особенность поведения. Проект, конечно, провалился, что только подтвердило написанное выше. Больше я таких ошибок не повторяла и всегда стояла на защите прав внедряемой АС.
«Двигайся вперед, не стой на месте»
Это общий принцип, но для ИТ он особенно важен. Здесь еще более, чем в других областях, тот, кто стоит на месте, стремительно движется назад. Ведь отрасль развивается очень быстро, быстрее, нежели многие другие. Это касается как отдельного ИТ-специалиста, так и целых подразделений, направлений и ИТ-компаний. Хотя принцип вполне понятен и прост, он далеко еще не всеми принят. Я имею в виду не только постоянное развитие и саморазвитие ИТ-специалиста, что является непременным условием его (ее) успешной карьеры и результативной работы. Эта заповедь должна пониматься намного шире.
Один из последних наблюдаемых мной примеров отступления от него — внедрение системы, по техническим характеристикам относящейся к прошлому веку, в одной из московских компаний. То ли упрямство, то ли печаль по вложенным ресурсам, заставила руководителя предприятия с упорством маньяка продолжать внедрение не нужной и устаревшей системы, тратя время не только ИТ-специалистов, но и всех сотрудников компании. Результаты были, прямо скажем, горестными. Другой распространенный пример, когда отказ от этой заповеди приводит к плохим результатам, — выбор системы, исходя из собственного опыта ИТ-руководителя. Даже в самом лучшем случае такой опыт ограничен и может не включать те полезные новинки, которые недавно появились на рынке. А то, что в этом опыте есть, может оказаться и не подходящим, и устаревшим для организации.
«Дожимай ситуацию, не надейся на авось»
В моей трудовой биографии есть интересный опыт работы в качестве ИТ-специалиста в США на проекте автоматизации крупного международного химического концерна. Было очень полезно участвовать в этом проекте и на практике постигать премудрости американской методики выполнения проектов. Про это можно написать даже не статью, а полновесную книгу. Но именно данную заповедь, которой я постаралась увлечь своих коллег, я вынесла как основную из опыта своей американской жизни. Они не умней и не трудолюбивей нас, но они всегда дожимают ситуацию. И в этом, по-моему, основной секрет их успехов. Российский ИТ-специалист, придумав хорошую идею, разработав полезное ПО, часто быстро охладевает к полученному результату и ошибочно предполагает, что кто-то доведет начатое им до конца. Вот почему идеи не доводятся до результата, а многие наши разработки не могут похвастаться высоким качеством и не присутствуют на мировой арене.
«Не отказывай себе сам»
Это тоже одна из любимых мною заповедей. Очень часто люди, и особенно ИТ-специалисты (очевидно, от большого ума) видят препятствия там, где их может и не быть. А потому даже не берутся за то, чего нужно и хочется достичь. Поскольку мы не можем предвидеть будущее, всегда стоит двигаться именно в том направлении, которое считаешь разумным, не придумывая, почему это не получится. А если то, что ты делаешь, помешает или повредит кому-то, то тебе об этом непременно скажут. Очень часто сталкивалась с тем, как системный администратор, возможно, наученный горьким опытом, даже не предлагает обновить оборудование или закупить ПО, облегчающее его работу и улучшающее ее результаты. А когда спрашиваешь: «Почему?» — говорит: «Все равно не купят». В ответ на это я и привожу свою девятую заповедь. Ведь именно искусственно придуманные препятствия часто тормозят развитие ИТ, да и не только их.
«Если не получается решить проблему, перейди на другой уровень ее рассмотрения»
Кто-то любит разбивать лоб о закрытые двери. В этом случае мне больше по душе поиск окна, дымохода, какой-то лазейки, чтобы проникнуть туда, куда надо. Не бывает нерешаемых проблем, и из любого тупика всегда есть выход. Если на привычном уровне решить проблему не удается, то стоит подняться на другой уровень, и проблема предстанет в новом ракурсе, и не исключено, что появятся совершенно неожиданные решения. Можно даже математически обосновать эту заповедь: если не удается решить задачу (например, линейного программирования) в существующих ограничениях, вероятно, следует изменить ограничения.
Читатель, возможно, посетует: какие заповеди — понятно, а где про то, как помогало. То, чем я и, насколько я знаю, мои коллеги гордимся, — по опросу сотрудников, признание нашего подразделения лучшим по итогам года в в нашем холдинге. А ведь ИТ-подразделения обычно не любят и винят во многих бедах компании. И часто это вполне закономерно.
Конечно, заповедей намного больше. Разумеется, следование перечисленным в статье не сразу и не всегда приведет к улучшению ситуации с ИТ. Но несомненно поможет превратить ИТ из тормоза в двигатель и улучшить взаимоотношения с заказчиками, пользователями, клиентами и другими партнерами организации.
Опубликовано 04.02.2014
