ИТ-Стайер

Я негативно отношусь к практике, когда считается нормальным постоянно работать сверхурочно. Не может человек постоянно грузить мозг по 8-10 часов в день. Это плохо заканчивается. Лучше отдохнуть и с большой вероятностью ты сделаешь ту же работу в два раза быстрее. И еще руководителям стоит понимать, если человеку для работы нужен интеллект, то не стоит его принуждать. Его мозг в этом случае будет занят не мыслями о том как сделать работу качественно, а о том какой дурак у него начальник и как бы быстро сделать так, чтобы получилась гадость, но при этом были выполнены дурацкие требования и формально ко мне не было претензий.

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

Люди ценят хорошее отношение, то что с ними разговаривают, то что с ними есть неформальные договоренности, то что им позволяют некоторые вольности в виде небольших нарушений того же дрескода, то что им не нужно оформлять больничный и они могут несколько дней поработать на удаленке и так далее.

Желание сделать что-то хорошее, стремление не подвести коллектив, в котором тебе хорошо, и своего хорошего руководителя, которого ценишь ты и который ценит тебя – это мотивирует намного больше, чем жажда наживы, на которой играть намного проще, но которая точно не является позитивным чувством.

Вспоминается один случай, когда в три часа ночи меня разбудил звонок и мне сообщили, что на одном распределительном центре наблюдаются проблемы с работой системы управления складом. Я набрал разработчика и он ответил буквально на первом звонке.

– Привет! Мне тут позвонили…

– Привет! Знаю, уже занимаюсь.

– ???

– Проснулся ночью. Дай думаю загляну, посмотрю как оно там..

Вот что заставило человека среди ночи посмотреть как работает система? Точно не деньги. Никакая формальная система мотивации на это неспособна. Человек ответственно относится к своей работе, ему нравится то, что он делает, ему интересно как оно там работает, он видит, что сделанное им работает и приносит пользу. И он уверен, что это оценят.

Глава 12

Чуть-чуть об информационной безопасности

Интуитивно понятно, что информационная безопасность имеет непосредственное отношение к ИТ. Существует множество тематической литературы, которую можно и стоит поизучать. Здесь я не планирую излагать основополагающий курс или умничать соревнуясь со специалистами в данной области. Моя цель поделиться некоторым практическим опытом, который возможно кому-то может пригодиться.

Для начала поговорим о том, кто должен заниматься вопросами информационной безопасности (ИБ). Я наверное, не буду оригинален, если скажу, что ИБ – это сфера, которая касается каждого сотрудника. недаром в нормальных организациях при приеме на работу каждый подписывает ряд соответствующих документов и в должностных инструкциях, как правило, прописаны некоторые моменты, связанные с коммерческой тайной и режимами доступа к информационным системам и данным. Нельзя выносить, копировать, несанкционированно получать доступ, приносить, устанавливать, скачивать, говорить кому-то свой пароль и т.д. и т.п. Это должен знать каждый.

Направлять эту работу, формировать концепцию, разрабатывать стратегию, политики, положения, регламенты и правила, вырабатывать и реализовывать комплекс мероприятия, а также осуществлять контроль – это отдельный функционал, которым кто-то должен озаботится.

В маленьких компаниях – это выпадает на долю ИТ-шников, поскольку они не могут себе позволить другого по экономическим соображениям. Но там и риски невелики, да и ограничивается все, как правило, настройкой сетевого экрана, установкой антивируса, ну и созданием некоторых ролей регламентирующих доступ к ресурсам.

Но рано или поздно приходит время для создания службы информационной безопасности (СИБ), как отдельного подразделения. И сразу возникает вопрос: а где ее место? Мое мнение однозначное – в службе безопасности, а не в ИТ. Безопасность вопрос комплексный и решать его нужно комплексно и информационная – это только небольшой кусочек, которым заниматься автономно непродуктивно.

При этом нужно понимать ряд моментов:

– ИТ-шники – это серьезная группа риска с точки зрения информационной безопасности и за ними будет особый надзор

– ИТ-шники во многом являются подрядчиками СИБ, реализуя то, что они напридумывают и работая по их правилам

– ИТ-шники являются прокладкой между пользователями и СИБ и принимают на себя весь негатив закручивания гаек

Нужно сразу правильно выстраивать взаимоотношения между ИТ и СИБ. Правильно организованное взаимодействие между этими подразделениями может принести существенную пользу. В моем понимании правильное – это когда СИБ помогает сформировать правила и контролирует их исполнение через аудиты и другие контрольные мероприятия. А вот перетягивание функций администрирования, даже в минимальном объеме – это в конечном итоге рано или поздно приводило к нехорошим последствиям. Был случай когда чуть ли не день разбирались с проблемами, когда безопасность, которая заведовала антивирусом, перекидывалась мячом с админами, занимавшимися сетью.

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

Более критичными являются случаи утраты информации вследствие злого умысла, либо неквалифицированных действий пользователей или ИТ-шников, при выполнении сервисных операций. Вирусы, хакеры, обиженные уволенные администраторы и даже любопытные пользователи, тыкающие куда попало – это те угрозы к которым нужно относится крайне серьезно.

Была одна интересная история. Пошли с безопасниками найти один телефонный разговор на станции записи телефонных переговоров. Нашли, прослушали. А потом инженер покачнулся и задел рукой клавиатуру. Мне потом стало интересно, какой умный человек в цифровой её части разместил клавиши “Del” и “Enter” таким образом, что одним простым слитным движением их можно нажать в нужной последовательности. Понятно, что и разработчики программы показали себя с нелучшей стороны, установив действие по умолчанию для вопроса “Вы уверены, что хотите удалить файл безвозвратно?” на “Да”. Короче, ползущая полоска удаления при округлившихся глазах, и потом много объяснений.

Серьезный подход к организации дистанционного доступа, максимальное ограничение прав доступа в соответствии с ролями, отслеживание и отработка всех рекомендаций по настройкам защиты от проникновений и вирусов – набор инструментов, который вы легко найдете в сети.

В это сложно поверить, но в большинстве компаний я, будучи ИТ-директором вообще не имел доступа в операционные рабочие базы.

Кстати, в моей практике был реальный классический случай, когда мальчик и девочка, занимавшиеся автоматизацией платежей организовали для себя тонюсенький ручеек от большого финансового потока. Закончилось все плачевно, но факт имел место быть.

Очень хорошим вариантом является – это периодическое привлечение внешнего аудита для проверки вашей информационной системы на предмет соответствия современным требованиям безопасности. Если ваше компания может себе это позволить – это точно будет не лишней строчкой в бюджете.

В моей практике случались случаи когда безопасники пытались встроиться и в процесс внесения изменений в ИТ-продукты, но, как правило ни к чему хорошему это не приводило. Полноценную ревизию кода все равно быстро не сделаешь, тестирование им отдавать тоже смысла нет. Поэтому дело обычно заканчивалось максимум формальным контролем исполнения процесса: кто делал, кто собирал, кто тестировал, если результаты тестов оформлены правильно – даем добро на установку. А дальше есть правила безопасности, которые должны соблюдаться неукоснительно:

– ничего не разрабатываем на рабочей базе

– обязательно тестируем, что изменение сильно ничего не поломает

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

– критичные операции лучше делать вдвоем: один смотрит, другой контролирует

Еще один момент связан с тем, что ИТ-шники создают интеллектуальную собственность. Озаботится ее защитой – это прямая обязанность ИТ-управленца. Зарегистрировать права на создаваемые продукты не так уж и дорого и муторно, но страхует от возможных неприятностей. В моей практике был случай, когда правоохранительные органы нашли наш программный продукт в одной из организаций не имеющих к нам никакого отношения. Расследование показало, что туда его продал один из уволившихся сотрудников. Тот случай закончился в какой-то степени позитивом, поскольку мы получили компенсацию, которая составила чуть ли не полугодовой наш бюджет, но могло сложится и по другому: если бы кто-то взял и на себя зарегистрировал права и потом предъявил претензии

Напоследок хочу еще отметить, что ИТ-шники имеют такую роль, как проверка требований безопасников на адекватность, поскольку только они могут квалифицированно сказать, что пароль из 28 знаков с обязательной сменой через 3 суток является слегка завышенным требованием.

Глава 13

Немного о внутрикорпоративных проектах

В любой современной компании практически ни один проект не обходится без серьезной ИТ-составляющей. При этом эта составляющая сама по себе может быть выделена в отдельный проект. Иногда ее объем представляется настолько большим, что происходит подмена и создание программного продукта, начинают путать с реализацией проекта в целом.

Например, проект “Автозаказ”. Мы хотим, чтобы информационная система самостоятельно рассчитывала количество товара к заказу, на основании данных о продажах, остатках и некоторой другой информации. Многие ошибочно думают, что самое сложное здесь алгоритм. Алгоритмы расчета давно не являются секретом, их можно найти массу, а также придумать и реализовать свои, но это будет, наверное, не более 20% от того, что нужно сделать. Нужно учесть еще массу параметров, а для этого требуется наладить их внесение, сбор, проверку корректности, учет всяких хитрых условий и ситуаций. Графики доставки, активный ассортимент, доступное полочное пространство, промоактивность и пр.пр.пр. Короче обвес алгоритма намного сложнее и более трудоемок, чем работы по программированию самого алгоритма. А потом еще есть огромный объем работ, по внесению необходимых параметров и всяким настройкам.

Самое интересное, что ИТ-шников постоянно пытаются сделать ответственными за подобного рода проекты в целом и именно им начинают задавать вопросы “а как там?”. Они уверенно отвечают “у нас все хорошо”, подразумевая, что они выполнили все основные технические задания. А потом приходят недовольные люди из бизнеса и говорят, что “не все хорошо”, а стоило бы еще сделать это и это. При этом зачастую они забывают сказать, что они пока сами не знают как это сделать и поможет ли это реально и вообще они просто не организовали процесс настройки и внесения необходимых данных.

Давайте понимать, что если у вас не ИТ-компания, то у вас попросту практически не может быть чисто ИТ-шных проектов. ИТ-шники практически не бывают заказчиками и лучше их не делать руководителями проектов. Исключения пожалуй составляют только проекты связанные с какой-нибудь оптимизацией, реинжинирингом ПО, обустройству внутренних процессов ИТ, которые по большому счету никому кроме посвященных не видны.

Все основные проекты – это проекты бизнеса и отвечать за них должен бизнес. Никто не снимает с ИТ-шников ответственности за их часть, но в целом их роль вспомогательная.

Любой проект – это триада: содержание, сроки, стоимость.

Когда мы ведем внутреннюю разработку, то вопрос стоимости, к сожалению, зачастую просто опускается. Хотя было бы правильно, как минимум зарплату, занятых в проекте специалистов ИТ – учитывать в бюджете проекта. Иногда, если это делать, то проекты как-то отпадают. Когда озвучиваешь, что делать будем полгода и обойдется это компании примерно в восемь миллионов рублей, то у некоторых наступает момент отрезвления. Кто-то пытается поискать подешевле на рынке, но по моей практике быстро убеждается, что его хотелки по рынку стоят минимум в два, а то и в 3 раза дороже и вообще подобного готового почему-то нет.

Но обычной практикой является то, что ресурс внутренней разработки считается условно бесплатным. Руководство не задает вопросы сколько это будет стоить. Оно задает один вопрос: когда? Этот вопрос для него удобен, потому что его можно легко проконтролировать. Сделал запись и проверяй. А еще лучше: нарисуй мне какую-нибудь диаграмму Ганта и отчитывайся регулярно по ней.

Вопрос “когда?” является крайне противным, потому что его начинают задавать, в то время когда мы еще практически не представляем себе ответа на вопрос “что?”. Мы не имеем четкого технического задания, мы еще не прорабатывали детали и не можем сказать сколько времени это займет точно. И люди, которые привыкли к некой достаточно конкретной системе координат, а ИТ-шники в основном относятся именно к этой категории, впадают в ступор. Они пытаются каким-то образом прийти к какому-то ответу с учетом массы неопределенных условий, предугадывая возможные варианты постановки, проблемные места и пр. Ответ получается примерно следующим: “Если все будет просто, то столько-то дней, а если вылезет вот это, то столько, а если случится это, то еще нужно будет приплюсовать ..”.

Такой ответ не вносит ясности и в большинстве случаев вызывает сугубо раздражение, которое приводит к взаимной неудовлетворенности и нарастанию напряжения.

Можно ли этого избежать? Можно. Стоит довериться своим ощущениям. Когда я проходил свое становление, как ИТ-директор в Магните, именно на такой термин навел меня Галицкий. “Не пытайся высчитать точно. Скажи когда будет готово по твоим ощущениям”. Наша нейронная сеть, называемая мозгом, с набором опыта начинает выдавать поразительно точные ответы. Плюс-минус неделя – это тот интервал, который вполне приемлем для внутрикорпоративной разработки.

Со временем ты начинаешь чувствовать заказчиков и предполагать, что от них можно ожидать в виде постановки и возникновения потом дополнительных хотелок, ты знаешь производительность своих сотрудников, ты вносишь допуски на непредвиденные ситуации в виде отрыва сотрудников на тушение пожаров, отпуска, болезни, и, в конце концов, достаточно корректный прогноз у тебя возникает как бы сам по себе. Раскидать его по конкретным этапам возможно, но большого смысла, как показывает практика, не имеет.