ИТ-Стайер [Сергей Владимирович Романюк] (fb2) читать онлайн


 [Настройки текста]  [Cбросить фильтры]
  [Оглавление]

Предисловие


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

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

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

Перед тем, как сесть и начать писать, я долго размышлял: а нужно ли оно в первую очередь мне? В любом случае это достаточно объемный труд, которому, если им заниматься серьезно, нужно посвящать достаточно много времени. Мои амбиции не позволяют мне лепить “а бы что” и я прекрасно понимаю, что работа над книгой может очень сильно затянуться. Зная себя, я осознаю тот челлендж, который принимаю. Не бросить и завершить – это отдельная задача в рамках достижения определенной цели, которую я определил.

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

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

Фактически книга содержит мои размышления для меня самого. Это мой первый большой труд. По мелочи я пишу достаточно давно и реакция на мои творения дает мне надежду, что возможно прочесть мои мысли будет кому-то просто интересно, а кому-то даже и полезно.

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

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

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

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

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

Связаться со мной всегда можно по электронной почте avanmost@mail.ru

Глава 1 Я ИТ-стайер


Начну с небольшого рассказа о себе.

Меня зовут Романюк Сергей. Мое резюме легко ищется на хедхантере. Оно лежит в открытом доступе и каждый может его прочитать.

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

Наверное сейчас это уже не является каким-то эксклюзивом, но Директор по ИТ ЗАО “Тандер” 2004-2006г.г. – такого нет ни у кого. Да, я первый ИТ директор торговой сети “Магнит”.

Не думаю, что сейчас в России есть хотя бы один человек, который не слышал чего-нибудь о “Магните” и Сергее Николаевиче Галицком. А в 2004 году скорее было наоборот – мало кто слышал. А если и видел рядом с домом неказистый магазинчик, то не мог себе представить, что таких магазинчиков уже больше 600 и за ними уже тогда раскручивался огромный бизнес-маховик, который станет реальным феноменом в розничной торговле.

Эта книга не будет из себя представлять опус “я и Магнит”, но в ней будет достаточно ярких описаний того периода моей деятельности.

Именно Магнит сформировал меня как ИТ-директора. Там я получил кучу “татуировок менеджера и ит-шника”.

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

Что я под этим подразумеваю? ИТ-индустрия очень неоднородная. Она бывает промышленная, бытовая, а бывает внутрикорпоративная, т.е. та, которая растет внутри бизнеса.

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

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

Все это порождает один глобальный проект, которые можно обозвать “совершенствование информационной системы”. Это реально забег на длинную дистанцию. И ты вынужден бежать 10 км, 20 км, марафон – а финиша все нет, потому что изменения могут закочиться только вместе с концом бизнеса.

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

По серьезному я начал “бегать” в Магните. Потом был “Украинский Ритейл”. Потом был этап “Х5”. Крайняя дистанция – это “Самбери”.

На этих дистанциях были и медали и травмы и даже дисквалификация. И вот сейчас я серьезно задумался: “Не пора ли заканчивать бегать самому и переходить на тренерскую работу?”

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

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

Глава 2 Что такое ИТ?


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

Фактически за буквами ИТ – скрывается целая сфера в любой современной компании. Эта сфера окутана информационным туманом и чего в ней происходит в реальности мало кто себе представляет.

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

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

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

В том же Магните, еще в эру ICQ был такой случай. Аська была закрыта у всех, кроме ИТ-шников. Мы реально активно использовали ее в работе. Остальные пользовались внутренним чатом Trillian. Но как-то, уважаемый Сергей Николаевич Галицкий, во время одного из посещений, у кого-то в логистике на экране увидел открытое окошко мессенджера. Да и ладно бы. Но, вроде как, текст содержал некоторую не совсем корректную оценку одного из его личных распоряжений.

Прилетела команда админам немедленно перекрыть все у всех, включая аську для всех ИТ-шников. Команды СН выполнялись всегда. И данная команда не была исключением.

Работа департамента информационных технологий на двое суток была парализована. Не потому, что аська так важна была в работе, а потому что сработал принцип “пчелам запретили носить мед”. Двое суток каждый искал возможность восстановить работу мессенджера. Строились тоннели, писались хитрые программулины и прочее, прочее. Я в то время уже не работал в компании и наблюдал действие он-лайн со стороны. Короче, через двое суток все ромашки сотрудников ИТ Департамента Тандера, которые у меня были в списке контактов, горели зеленым.

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

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

Мир ИТ уже потерял многие элементы своей неформальной культуры, такие как игровой сервер Quake 2 в локальной сети или хранилище видеофильмов, книг или чего-нибудь еще интересного. В свое время приводилась статистика, что наличие порносайта во внутренней сети предприятия позволяет экономить на интернет-трафике от 30 до 80%.

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

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

– системы автоматизации операционной деятельности

– системы финансового и учетного контуров

– статистические системы

– системы внутренних коммуникаций

– системы внешних коммуникаций

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

Приведенное деление просто позволяет в какой-то мере определиться с подходами к реализации, требованиями к производительности, объему хранимых данных и некоторыми другими аспектами их функционирования.

Например, к системам автоматизации операционной деятельности я отношу:

– систему управления складом – WMS (warehouse management system)

– система управления транспортом TMS

– систему формирования заказа

– систему операционного учета товаров (где регистрируются операции прихода, расхода)

– систему управления полочным пространством

– систему управления ценообразованием

– систему управления ассортиментом

– и прочие системы, которые непосредственно автоматизируют труд сотрудников.

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

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

Бизнес-процессы, зашитые в системы подобного рода, не могут быть универсальными. В конце концов с развитием бизнеса эти системы становятся уникальными для каждой компании. Кастомизация (доработка под требования конкретной компании) – это то, от чего уйти практически не получается. С возрастом любой бизнес приобретает уникальность и это не может не отразиться.

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

Финансовый и учетный контур – это:

– бухгалтерия (без нее никуда, именно с нее обычно и начинают)

– бюджетирование

– казначейство

– кадровый учет

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

Данные системы достаточно консервативны и в качестве продуктов для их реализации целесообразно использовать типовые решения.

Перед тем как делать любую доработку в таких системах стоит очень сильно подумать. Уход от типового решения может быть чреват тем, что при каком-нибудь резком движении государства (а оно у нас любит сюрпризы), очередное, крайне необходимое обновление от производителя программного обеспечения то что называется “не встанет” и вы поимеете серьезные проблемы.

Статистические системы служат, как правило целям анализа. BI (business intelligence), Big Data, OLAP-кубы – это все сюда. У меня нет цели познакомить вас с данными технологиями и расписать их. Кому надо тот легко найдет подробности в сети. Стоит просто понимать следующее, что есть определенный класс систем, базирующихся на различных технологиях, который умеет в себе накапливать огромные объемы данных, препарировать их и быстро предоставлять пользователю.

Такие системы позволяют не сидеть по полчаса, глядя на “колесико смерти” или надпись “загрузка…”, ожидая пока сформируется мегаотчет из серии “хочу увидеть все сразу”.

Стоит помнить, что “правильный отчет” с “правильным набором параметров” способен убить любую систему, какими бы ресурсами она не обладала.

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

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

Кстати, электронная почта является примером когда одно решение входит как в систему внутренних, так и внешних коммуникаций.

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

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

Глава 3 Кто такие ИТ-шники?


Внутри сферы информационных технологий крутится много самых разных людей. У них разная специализация, и зачастую, единственный набор умений и навыков, который их объединяет – это бесстрашное нажимание на клавиши клавиатуры. Это примерно схоже с тем, что врачей объединяют белые халаты.

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

Попробую дать определенную классификацию ИТ-шных персонажей.

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

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

“Эникейщик” по легенде пошло с тех времен, когда компьютеры были большими и слово Windows обозначало просто окна. Тогда периодически на экране появлялась надпись “Press any key…”. Перед ней еще было сообщение о какой-нибудь ошибке, но это было не сильно важно. Для продолжения работы нужно было нажать любую клавишу.

Секретарши и бухгалтера при появлении такой надписи пугались и звали компьютерщика, который приходил и выполнял работу по починке техники нажимая “any key” – любую клавишу. Отсюда и пошло жаргонное название эникейщик.

Кстати, однажды самый ленивый оптимизировал процесс. На клавишу пробела он скотчем прилепил бумажку с надписью “any key” и все блондинистые пользователи начали быстро находить чего нужно нажать, чтобы компьютер продолжил работать.

История не сохранила фамилии этого героя, но он точно совершил прорыв. Тема разлетелась со скоростью молнии, и я лично видел не одну такую клавиатуру.

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

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

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

Следующими за эникейщиками идут администраторы. Они бывают разные: сетевые, администраторы серверов, баз данных, каких-то прикладных систем. Их практически не видно. Они сидят в своих каморках и общение с ними происходит в основном дистанционно: по телефону или по электронной почте. А особенно они любят всякие сервис-дески где им ставят задачи, которые не теряются, а потом их там еще и оценивают.

Вообще админы обычно спокойные люди вплоть до аутичности. Они работают не как все нормальные люди, потому что часто им приходится делать свою работу в то время, когда другие уже отдыхают. Зачастую они вообще являются ночными существами.

Например, был у нас один товарищ по прозвищу Борода, который раз в пару месяцев просто ночевал в офисе проводя операцию обрезания базы данных.

Если у админов проблема, то это проблема у всего офиса. Все сидят и курят потому что не работает ничего. Они никогда не говорят “не работает”. “Легло”, “слетело”, “встало”, “отвалилось”, “поломалось” – это набор определений событий, которые случаются как бы сами по себе.

Админы люди тонкой душевной организации, требующие особого подхода. За 25 лет у меня был всего один случай, когда я расстался с человеком по причине того, что он не смог пережить ограничения свободы. Это был админ с которым я несколько месяцев не мог утрясти легальный график его пребывания на рабочем месте. У нас руководство банка развлекалось контролем рабочего времени через новую систему управления доступом, что для того времени было еще диковинкой, и я практически каждый день был вынужден писать объяснительные почему мой сотрудник не приходит вовремя. Никакие уговоры не действовали, предложения легально сдвинуть график тоже. Достал я его тем, что подверг обструкции при коллективе. После этого он продержался месяц, но не выдержал и уволился.

Особой кастой в ИТ являются программисты. Их работа сродни магии. Никто толком не знает чего они делают и как. Мечта любого программиста – хорошее техническое задание (ТЗ).

Если погуглить, то можно найти несколько квалификационных определений для программистов. Кто-то делит по каким-то категориям с номерами, кто-то категории заменяет умными иностранными словами: юниор – типа стажер, или сеньор – крутой перец, который может рулить юниорами.

У меня есть своя профессиональная шкала для программистов: кодер, программер и разраб.

Кодер – это тот, кто не может и главное не хочет включать мозг. Делает все согласно букве технического задания, досконально транслируя в код все глупости, которые в нем заложены. Когда ему потом говоришь: “Ну посмотри – это же понятно, что так работать не будет. Это просто неправильно” – он просто достает ТЗ и говорит: “Но тут так написано”. Основной вопрос с которым работает кодер – это “что?”.

Программер – это надежный боец. Человек творческий и с опытом. Он хорошо знает свое дело. Способен работать со слов и по приблизительному заданию. Ему не нужно разжевывать все до мелочей. Ответ на вопрос “как?” – это его работа. Он не будет делать то, что работать не будет. Главное иногда вовремя остановить полет фантазии. Иначе получаемые решения могут быть поистине шедевральны, а продукт будет перенасыщен всякими фичами (дополнительными возможностями), которые никому не нужны.

Когда-то был случай с товарищем, который при разработке системы управления складом WMS решал задачу, скажем так, аварийного прерывания задания по инициативе комплектовщика заказа. Подразумевалось, что сотрудник должен был сообщить системе причину. В конце у нас осталось всего две “нет места на паллете” и “нет товара в нужном количестве”. А вот изначально правильный программер ввел их штук семь, из которых больше всего поразил вариант “не могу продолжить по медицинским показаниям” (ну а вдруг у него живот заболел).

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

Высшей квалификационной ступенькой для программиста в моей классификации является “разраб”. Это уникальные люди, которые в той области, которую они автоматизировали знают все лучше всех. Они работают с вопросом “зачем?”. Ни один “представитель бизнеса” с ними сравниться не может. И не мудрено. Когда ты переводишь бизнес в цифру, и делаешь это вдумчиво, ты проникаешь в тайны мастерства недоступные никому. Разраб знает “как работает склад” лучше любого руководителя склада. Ему вообще можно не ставить задачи. Ему достаточно подкинуть идею, а зачастую он сам приходит с идеей, и уже реализованной. Их не нужно мотивировать (про мотивацию мы еще поговорим), они знают и любят свое дело. Это золотой фонд любой компании. Если у вас есть разрабы – вам просто повезло.

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

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

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

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

В ИТ место найти можно всем.

Глава 4 Как становятся ИТ-шниками?


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

Реальный случай, когда человек с 9 классами за плечами претендовал на то, чтобы вести за собой все направление бизнес-аналитики. Прикол в том, что на “местном фоне” он еще и смотрелся не совсем плохо. Правда, когда начали общаться плотнее, как раз и начало вылезать, я бы сказал, отсутствие академизма, лоскутность и поверхностность. Все-таки образование вещь нужная и за плечами его не носить. Сложные вещи парню приходилось объяснять долго, а его излишняя самоуверенность и не подкрепленная знаниями амбициозность скоро привели к тому, что наши дороги разошлись. Потом до меня доходили слухи, что в другой компании он продолжил работать в том же направлении и даже чего-то достиг, но там был несколько другой уровень бизнеса и соответственно совсем другие требования.

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

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

К сожалению то, как в наших ВУЗах учат ИТ-шников, мягко говоря, оставляет желать лучшего. Должен сказать, что мне встречалось достаточно много недоучек с очень хорошим профессиональным уровнем. Ребята получали базу, потом видели, что именно с прикладным обучением не очень и сваливали работать в реальный сектор.

Вообще, в моей практике “золотой фонд” – это аспиранты, которые бросили по ряду причин аспирантуру и пошли работать.

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

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

С другой стороны откуда к нам только люди не приходили: из МЧС, из МВД, после армии. В практике был парень кочегар. Показательный случай, когда на одном из складов заметили определенную подозрительную активность в сети. Покопавшись вышли на оператора. Забрали к себе. Впоследствии он стал одним из наиболее ценных сотрудников.

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

Глава 5 Как сделать карьеру в ИТ?


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

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

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

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

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

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

И главное не бояться. Не бояться брать на себя ответственность. Пробовать, делать, ошибаться, переделывать, снова ошибаться и так пока не получится. Я не имею ввиду “кидаться с голой шашкой на танк”. Нужно осознавать ответственность, понимать цену своей возможной ошибки и быть уверенным в своих способностях ее исправить. Это очень важные качества.

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

Мы еще поговорим о внутрикорпоративной разработке программных продуктов. Она имеет достаточно серьезные особенности. Здесь я хочу сказать о том, что делая свое дело, даже сугубо для себя, нужно смотреть на лучший опыт. Нельзя, без особой необходимости, в угоду срокам, халтурить. Это показатель профессионализма. В моей практике случалось, что мы по 4 раза переделывали пользовательские интерфейсы, хотя самый первый вариант вполне соответствовал техническому заданию и формально к нам претензий быть не могло.

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

У программистов не так. Более или менее нормальный программист – это 3-5 лет. В главе “Кто такие ИТ-шники?” я говорил о своей шкале “кодер”-”программер”-”разраб”. Разраб вообще не имеет потолка.

У системных аналитиков, руководителей проектов – своя стезя. Там тоже потолок достаточно условный, а время созревания не быстрое.

ИТ – это игра в долгую. Тут нужен опыт.

Достаточно важным является нахождение баланса между попрыгунчеством и болотным прозябанием. Это тоже относится скорее к общим рекомендациям. Скоростное метание между компаниями и проектами – это дурной тон. Я всегда с подозрением относился к людям, у которых много мест работы и срок работы на каждом до 1 года. Это нормально в самом начале, когда человек нащупывает сферу своих интересов, понимает, что его привлекает. Но если это продолжается и после 30, то это вызывает серьезный вопрос. Вход в серьезный проект, какой бы ты не был специалист, адаптация к новому месту – это месяцы. Все таки ИТ – это достаточно сложный технологический сектор. Уникумов, которые бы пришли и начали работать по полной через пару недель я практически не встречал.

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

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

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

Мне приходилось сталкиваться с людьми, которые очень быстро могли обустроить любое гнездо. У них в их зоне ответственности всегда все было хорошо. Не отлично, но хорошо. Они не были перфекционистами, но получив участок деятельности они быстро доводили его до определенной степени комфортности и дальше запускали процесс заболачивания. Я считал своим долгом обеспечить их миграцию с насиженного места, поскольку только таким образом можно было их развивать. Кто-то обижался, кто-то принимал такой расклад, но я считаю, что такой подход был полезен и для них, ибо они прокачивались, и для компании, которая получала больше "обустроенных" мест.

Если подытожить, то для того, чтобы сделать карьеру в ИТ (как впрочем, наверное, и в любой другой сфере) нужно: держать нос по ветру, следить за изменениями, постоянно задавать себе вопрос: а не пора ли мне чего-то поменять и не стоит ли мне чему-то поучиться? Ну и главное: работать, работать и еще раз работать… Изучай свою матчасть, не бойся брать на себя ответственность и готовься к подвигу.

Уж ИТ – это точно та сфера, где подвигу всегда найдется место. Косяки и аварии в ИТ – это вещь постоянная. Проявить себя в борьбе с ними – это достойно. Единственное, что если косяк или авария будут идентифицированы, как ваши – это может поставить реальный крест на карьере.

Глава 6 Путь ИТ-менеджера


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

Сейчас мы поговорим об ИТ-структуре и управлении ей в целом.

Каких-то особых стандартов я не встречал, но со временем я выработал для себя некоторые подходы, которые сейчас и постараюсь изложить.

Понятно, что все начинается с количества ИТ-шников в Компании. Если группируем 3-4 человека – это группа, если 10 – отдел, до 40 – управление, больше – Департамент. Это достаточно условно, но в целом такой подход вполне себе понятен.

Есть еще вариант. Когда структура строится в расчете на то, что сотрудники будут в двойном подчинении, то для себя я такому подразделению даю название Службы. Например Служба системного администрирования или Служба технической поддержки. Есть куча системных администраторов, которые сидят по своим объектам, административно могут подчиняться их руководителям, но при этом их функциональным руководителем будем сотрудник, возглавляющий соответствующую Службу.

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

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

Но, рано или поздно, если компания развивается, то компьютерщика становится два. А там где есть двое, возникают отношения подчиненности. Кто-то становится старшим. Так появляется зародыш ИТ-менеджера.

Старший наделен властью. Он принимает решение и несет ответственность. Он становится фильтром между руководством и своим подчиненным.

Но он только старший. Он сам выполняет часть функциональных работ. Фактически у него есть только помощник, который разгрузил “изначального компьютерщика”.

Дальше появляется еще один помощник, еще один и еще…

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

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

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

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

Я практически не встречал случаев, когда допустим ИТ-отдел реорганизуется в ИТ-департамент и Руководитель отдела становится Директором Департамента.

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

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

В качестве примера можно привести реорганизацию, которую мы провели в Магните в 2004 году. Отдел автоматизации был преобразован в Департамент. При этом бывший руководитель отдела был назначен Руководителем Управления развития информационных систем (что по уровню выше руководителя отдела) – заместителем Директора Департамента.

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

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

Иногда полезно оценить себя: насколько я хорош как руководитель? Получить ответ на такой вопрос задача достаточно нетривиальная. Можно провести опрос, можно посмотреть на KPI своего подразделения. можно пройти какой-нибудь профессиональный тест. Но я, со временем, для себя вывел несколько другой критерий. Все очень просто. За чем вам ходят сотрудники? Я считаю, что к хорошему руководителю сотрудники ходят за его мнением. Именно его мнение, основанное на его опыте, знаниях и интуиции является наиболее ценным. Совет – он намного лучше чем приказ. Если к вам ходят за советом, а не за нагоняями и распоряжениями – скорее всего вы хороший руководитель.

Должен ли руководитель быть лучшим в своей специальности? Должен ли он сам выполнять какую-то работу? А должен ли командир мотострелкового полка лучше всех бегать кросс, стрелять и водить БМП?

Если командиру полка приходится стрелять самому – значит он плохой командир. Значит он где-то ошибся, он не справился с управлением.

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

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

Менеджмент – это отдельная наука. Бывают ли универсальные менеджеры? Это очень сложный вопрос. Есть общие принципы управления. Используя их, наверное действительно можно управлять чем угодно. Единственное, встанет вопрос с качеством управления.

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

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

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

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

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

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

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

Меня всегда умиляет, когда люди осуществляющие подбор на позицию ИТ-директора задают вопросы: а вы умеете программировать на JavaScript? а вы знаете, как администрировать Microsoft Exchange?

Я в таких случаях задаю встречный вопрос: А вы уверены, что вам нужен Директор по ИТ? может вам нужен Руководитель ИТ-отдела? или Руководитель отдела системного администрирования?

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

Можно ли мигрировать между отраслями? Можно. Это тяжело, затратно – но вполне реально. Речь не идет об универсальности ИТ-директоров. Дело в другом. Сама позиция ИТ-директора требует определенного специфического набора компетенций.

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

Итак.

Старший компьютерщик – Руководитель ИТ-отдела – Директор по ИТ – вот он путь ИТ-менеджера.

Но есть ли что-то дальше?

Есть.

В современном мире ИТ уже не является вспомогательным инструментом в бизнесе. Часто ИТ-это и есть сам бизнес.

Директор по развитию бизнеса, Директор по инновациям, Директор по управлению изменениями – это те позиции, в направлении которых идет путь. ИТ-менеджеры – это разрабы для бизнеса – люди, которые ответят на вопрос “зачем?”.

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

Глава 7 Как организовать ИТ-структуру компании


Как структурировать ИТ в компании? Какие должны быть ИТ-подразделения? Кому они должны подчиняться?

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

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

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

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

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

Хорошая структура проста и понятна. Глядя на нее легко увидеть кто за что отвечает. Важным является наименование подразделений и должностей. Они должны отражать основную суть деятельности.

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

Следует помнить об управляемости, которую необходимо обеспечить и поддержать. Нормальным является, когда управление осуществляется не более, чем 10 объектами. Оптимально от 6 до 8. Меньше 4 – это уже расточительство и нужно думать, чем бы еще таким нагрузить такого менеджера.

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

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

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

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

Я не призываю к перегибам, когда нужно идти на поводу у каждого. Но, если человек хочет называться системным архитектором, а не суперадминистратором баз данных почему его не удовлетворить? Нам не тяжело, а ему приятно.

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

В основу структуры подразделений целесообразно положить разделение ответственности. Это жесткое правило. Не может у какой-то функции, у какого-то процесса быть несколько ответственных.

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

Ответственность – это право принять решение, которое другие должны будут воспринять и исполнить.

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

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

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

Разделять и дополнять – это хорошее решение.

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

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

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

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

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

Есть постановщики задачи, есть разработчики, есть тестировщики, есть внедренцы, есть администраторы, есть те, кто обеспечивает работу инфраструктуры.

Я думаю, что вам не составит труда набросать те рабочие противоречия, которые потенциально могут возникать между этими специалистами. Просто представьте кто-кому может предъявить какие претензии.

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

Это нормальное рабочее противоречие. Оно позволяет развиваться и тем и другим. Главное, чтобы они говорили это друг другу, корректно и аргументированно. И ни в коем случае не бегали жаловаться.

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

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

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

Нужно ли обязательно выделять тестировщиков? Это дорогая функция. Или можно усилить некоторые элементы, которые позволят обеспечить повышение выходного контроля на выходе от программистов, а непосредственное тестирование передать внедренцам?

Можно ли объединить в одном человеке и постановку задач и тестирование и внедрение?.

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

Любое дополнительное подразделение – это деньги. Больше 8-10 непосредственных подчиненных – это потеря управляемости, меньше 4 подчиненных – это расточительство. Людей объединяют общие задачи. Желательно разделять функционал на основе управленческих стилей.

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

– Отдел системного анализа и проектной поддержки (руководители проектов, проектировщики бизнес-процессов, постановщики задач, создатели технических заданий)

– Отдел развития информационных систем (программисты)

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

– Отдел системного администрирования (серверная группа, сетевые администраторы, специалисты по телекоммуникациям, эникейщики)

– Служба технической поддержки (если есть большая сеть региональных объектов)

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

А дальше мы пережили ряд трансформаций.

Вначале произошло размежевание в результате которого появились Департамент инноваций и внутреннего развития и Управление автоматизации в составе Департамента внутренних сервисов.

Первое подразделение включало в себя:

– Отдел диагностики и проектирования бизнес-процессов

– Отдел проектной поддержки

– Отдел развития универсальных программных решений

– Отдел развития платформенных решений (1С)

В составе управления автоматизации были:

– Отдел развития систем автоматизации торговых объектов (непосредственная автоматизация магазинов: кассы, весы и прочее оборудование)

– Отдел инфраструктуры

– Отдел сопровождения и администрирования баз данных

– Служба технической поддержки магазинов

На следующем шаге на уровне холдинга произошла централизация ряда функций (всего что касается телекоммуникаций и обслуживания компьютерной техники общего назначения). В торговой сети отреагировали и появился Департамент управления изменениями технологий и процессов, состоящий из:

– Управления поддержки системных изменений

– Управления развития универсальных программных решений

– Управления развития платформенных решений

– Управления автоматизации торговых объектов

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

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

Не нужно бояться изменений в структуре, но и не стоит ими злоупотреблять.

Стоит остановиться еще на паре моментов.

При внутренней разработке всегда наблюдается недостаток ресурсов программистов. О причинах и вариантах преодоления такого рода голода мы поговорим в отдельной главе. Сейчас же немного о другом.

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

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

Сложно объяснить, что, как правило, программист не работает в отрыве. Есть разные специализации. Над продуктом работает коллектив. Есть специалисты по структурам, есть по базам данных, есть по интерфейсам, есть тестировщики, админы и пр. Конечно бывают случаи, когда можно очертить достаточно конкретный круг специалистов, действующих сугубо в интересах одного подразделения (например, если разрабатывается WMS – система управления складом), и тогда, такой коллектив, можно отдать непосредственно в логистику, но это скорее исключение. Как правило, все подразделения завязаны на одну систему или группу систем и управлять развитием в таком варианте можно только централизованно.

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

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

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

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

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

Не бывает дешевого хорошего аутсорсинга. Но бывает выгодный хороший аутсорсинг. Где и когда он оправдан?

Он точно оправдан, когда специалист с какой-то очень специфической компетенцией нужен на ограниченное время. Как правило, такой специалист является реально дорогим, загрузить его постоянной работой на все 100% мы не можем, а факультативно заниматься еще какой-то менее дорогой работой он не хочет, что и правильно.

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

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

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

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

Глава 8 Что мы строим и как выбрать ИТ-решение?


Для начала несколько слов о Миссии. О Миссии, как о предназначении. Мы поищем ответ на вопрос, что ИТ-шники несут людям.

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

Сейчас, начиная разговор на эту тему я рассказываю всем известную притчу.

Мужик толкает тачку с кирпичами. Ему задают вопрос:

– А что ты делаешь?

И в ответ можно получить разные варианты:

– Кирпич везу…

– Тачку таскаю…

– На стройке работаю…

Но есть ответ, который несет в себе более высокую составляющую:

– Храм строю…

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

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

Стройте свой храм и к вам будут приходить, и будут оставаться с вами даже если где-то обещают лучше кормить.

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

“Вначале было слово”. Слова имеют силу. Часто они программируют наши действия. Слова, зафиксированные в текстах несут в себе магию. Умные люди это поняли давно. Только данный секрет не распространяют. Этой магией активно пользовались в ХХ веке. Плакаты советского времени – это еще доступные образцы. Главное не забывать, что слова не должны диссонировать с реальностью. Иначе можно получить зеркальный эффект.

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

Для Департамента управления изменениями и для Департамента информационных технологий мы сформулировали следующее:


“Мы формируем будущее Компании, обеспечиваем конкурентоспособность, технологическое лидерство и стабильное развитие, минимизируя риски негативного влияния изменений.

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

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


“Мы экономим время людей и освобождаем их от рутины, предоставляя возможность сконцентрироваться на интеллектуальной и продуктивной деятельности.

Благодаря нам, наша Компания выглядит современно и технологично.

Мы облегчаем понимание и помогаем найти лучшие решения.

Автоматизируя бизнес-процессы, мы повышаем их эффективность и снижаем влияние человеческого фактора.”


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

Реально можно провести определенную аналогию между строительством ИТ-системы компании и созданием реального храма. Есть в этом достаточная доля религиозности. Многие моменты находятся за гранью рационального, отдают мистицизмом и их осознание базируется на вере.

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

SAP, 1C, Axapta? Что круче и лучше? Или вообще лучше свое доморощенное, напоминающее какой-то языческий культ?

Как выбрать ИТ-решение?. Вообще, выбор ИТ-платформы для Компании это сродни выбору, который пришлось делать князю Владимиру в IX веке, когда он определялся с тем какой быть Руси: католической, православной, иудейской или оставаться языческой.

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

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

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

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

Отсутствие реальных знаний всегда порождает мифы. А мифы – это из категории веры. То есть мы опять возвращается к чему то религиозному.

Основной миф заключается в том, что где-то есть система автоматизации, которая умеет все сама. Внедрив такую систему, можно получить суперконкурентное преимущество, повысив на порядки производительность труда (чуть ли не вообще отказавшись от людей) и прямо изничтожив влияние человеческого фактора.

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

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

Покупая любую систему автоматизации, если вы до этого не имели с ней дела, вы покупаете “кота в мешке”. Будьте готовы, что ваши ожидания могут очень существенно разойтись с реальностью.

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

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

Для примера. Мой опыт говорит, что те же торговые сети очень легко категоризировать исходя из количества магазинов. До 10 торговых точек – это одна история, от 10 до 30-40 – другая, до 100 – третья, до 400 – четвертая, а после 400, если у вас выстроено все правильно, то уже большого значения не имеет. Если присмотреться, то это все напоминает армейские структуры: отделение, взвод, рота, батальон, ну и дальше уже выходим за уровень тактического звена и там начинают работать другие правила.

Количество объектов в системе определяет определенные требования как к архитектурным подходам, так и к интерфейсам. Попробуйте вывести в экранном интерфейсе 100 столбцов, не говоря уже по 400 и более.

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

Различные решения изначально ориентированы на различный уровень компаний.

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

Когда, с приходом ЕГАИС в РФ (государство обязало регистрировать движение алкоголя), пришло время автоматизироваться мелкой рознице оказалось, что традиционные игроки практически не смогли ничего предложить. И сейчас в этом сегменте играют совсем другие персонажи. Кстати, в основе одного из наиболее популярных сейчас продуктов, лежит разработка небольшой украинской ИТ-компании, в которой я был основным учредителем и идеологом.

Еще стоит поговорить об “излишнем фанатизме”. Автоматизация – это всегда здорово, но стоит хорошо подумать стоит ли ставить систему WMS (управления складом) для фактически кладовки площадью 40 квадратных метров и одним кладовщиком или крутую систему бюджетирования, если у вас всего десяток сотрудников и фактически один центр финансовой ответственности в виде вас самого – любимого.

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

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

Выбирать модное и новое – это большой риск. Если у вас 10000 магазинов, то поставить эксперимент на 10 – это вполне оправдано, но если их у вас всего 10, то выпадение даже одного может стать фатальным для бизнеса. Современная история знает случаи, когда смена версии программного обеспечения учетной системы у одной компании с весьма солидным оборотом парализовала ее деятельность на несколько недель. Хорошо, что за ней стоял другой финансовомощный бизнес, иначе все могло бы закончится плачевно.

Если в вашей сфере деятельности, есть какое-то проверенное отраслевое решение, адаптированное к вашему рынку – это будет лучший выбор.

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

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

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

Основной вопрос это обзавестись тем, кто будет поддерживать идеологию ИТ-системы и развивать ее. Без этого дело можно считать безнадежным.

Люди решают все. У них свои предпочтения, свои планы и приоритеты. Можно найти суперкрутую систему, поставить ее и столкнуться с тем, что ей попросту некому будет заниматься. Работая на Дальнем Востоке я столкнулся с ситуацией, когда в наличии была потенциально очень приличная система для нужд бизнес-анализа, но по факту она не выполняла своих функций. Мы нанимали, учили специалистов, но как только они начинали, что-то из себя представлять и от них должен был вот-вот начать поступать какой-то выхлоп, они мигрировали либо в Санкт-Петербург, либо в Москву. Людей не интересовали деньги – они меняли регион жительства.

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

Сразу остановлюсь на одном моменте. Когда какая-то ИТ-компания говорит, что они сотрудничают с кем-то, то это скорее всего означает лишь то, что в зоопарке данного партнера, есть его одна или несколько зверушек.

Если возвращаться к украинской истории, то нам пришлось переобуваться в воздухе. Большинство сотрудников было приглашено из другой торговой сети и мы приняли решение о внедрении решения, с которым они имели дело на предыдущем месте работы в роли учетной системы, оставив кассовую систему, прошедшую определенную доработку. Все прошло успешно и с некоторыми нюансами, но все заработало. Реально на все ушло порядка 8 недель.

Как определить правильный ли выбор вы сделали?

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

Часто люди недовольны, потому что им не хватает каких-то мелочей, фактически бантиков. А иногда они довольны несмотря на то, что приходишь и видишь, что у них не автоматизированы простейшие вещи и им приходится работать не покладая рук Все зависит от их кругозора, опыта, фантазии и уровня интеллекта.

В моей практике достаточно распространенным случаем является ситуация, когда человек ноет, что “у нас все плохо, у нас система никакая”, а после ухода через пару месяцев при встрече заявляет, что “у нас все было супер, и система была лучшей в мире”.

Глава 9 Как создать и развивать свой продукт?


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

Это совершенно не означает, что все необходимо делать самостоятельно с самого-самого начала. Я говорю про здоровую долю кастомизации или доработки системы под нужды конкретной компании. Нужно понимать, что когда вам говорят, что компания “сидит” на том или ином продукте, например 1С или SAP, то это совсем не означает, что они используют одинаковый типовой функционал.

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

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

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

Особый случай – это когда компания развивает свое совсем уникальное решение на базе полностью внутренней разработки, а не платформы, представленной на рынке каким-либо производителем. Характерным примером могут являться Ашан или Магнит. Такие системы иногда называют “самописными”.

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

Тема “промышленная система” против “собственной разработки” – это поле для еще одной “священной войны”. Оба подхода имеют свои преимущества и свои недостатки.

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

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

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

Итак, развивая ИТ-систему нужно озаботиться, как минимум, двумя вещами:

– наличием адекватного владельцапродукта

– управлением внедрением изменений

Это именно то, что отличает серьезный системный подход от хаотичного шатания и является определяющим порог, за которым остается понятие “самописного”.

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

В последнее время термин “владелец продукта” или “product owner” приобрел определенную популярность. Это связано с тем, что гибкие методологии управления проектами на базе Agile предусматривают такую роль. Владелец продукта определяет и транслирует общее видение развития продукта, агрегирует функциональные требования, планирует порядок их реализации, формируя его ценность.

Очень часто роль владельца продукта при внутрикорпоративной разработке размыта. Разработка часто движется по течению тупо перемалывая поток заявок от подразделений. На мой взгляд, это очень плохая парадигма, приводящая к тому, что появляется “китайский домик”, в котором могут быть достаточно комфортные комнаты, но в целом жизнь не доставляет удовольствия.

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

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

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

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

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

Теперь поговорим об управлении внедрением изменений в ИТ-системы.

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

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

Хотелось бы поделиться некоторыми моментами, с которыми приходилось сталкиваться и которые могут быть полезными.

– Ни одно тестирование не гарантирует, что на “боевых данных” все будет гладко.

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

– Два отлично работающих и оттестированных по отдельности модуля при совместной установке могут поломаться.

– Никогда не нужно проводить обновления в пятницу или перед праздниками.

– Даже изменение цвета или местоположения кнопки – это обновление.

– О любых изменениях нужно оповещать пользователей.

– Большинство пользователей не читают “Что нового?”

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

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

– Обо всех странностях после обновления служба поддержки должна немедленно информировать владельца продукта.

Ну и чтобы текст не был таким сухим приведу два реальных случая, которые имели место во время моей работы в торговой сети Магнит.

Случай первый. Сеть уже насчитывала порядка 1500 магазинов. Каждый магазин имел свою независимую базу данных и система была построена так, что большинство обновлений требовало запуска ряда скриптов, который обеспечивала специальная программа “робот”. Эта программа была сама по себе достаточно уникальна для того времени, поскольку по сети этих “роботов” обеспечивалась передача данных между объектами и они же могли запускать автоматически достаточно большой набор сервисных процедур. Это было прогрессивно: запущенное по сети обновление автоматом устанавливалось практически на все объекты в течении пары дней (связь тогда была еще той), ну а там где возникали ошибки уже подключались люди. Такой подход позволял существенно экономить на обслуживании.

В один теплый пятничный вечер раздается телефонный звонок от руководителя службы технической поддержки и он докладывает, что у него шквал звонков из магазинов по поводу неработающих касс. Потом подсчитали, что за полчаса в поддержку поступило порядка 600 звонков. Кто знает, что для продуктового ритейла в магазинах у дома пятничный вечер – тот поймет.

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

Первое что сделали, это прервали обмен, чтобы те “роботы”, которые не успели получить обновление не повлияли на работу магазинов.

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

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

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

Еще одна история связана с распределительными центрами. Мы как раз только начали заниматься разработкой собственной WMS-системы и много времени проводили на складе в Кропоткине.

Меня зовет руководитель РЦ и в панике говорит, что у них поменялась форма отборочного листа, отборщики отбирают неправильно и товар вместо штук неконтролируемо уходит блочками.

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

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

А за дверью триста мужиков, которые простаивают, а это хуже чем триста спартанцев. У тех хоть все понятно, а у этих горит заработок.

Поиски ничего не дают, все штатно. Ситуация накаляется.

В какой-то мере повезло, потому что в это же время в Кропоткине был руководитель РЦ из Энгельса. Поинтересовавшись в чем проблема и глянув на “новый” отборочный лист он сказал, что уже месяц по такому работает. На вопрос “как так? и как справился с проблемой?” он сказал, что ему админы передали, что вот такую новость прислали из Краснодара и теперь будет так. Он собрал народ, благо у него склад поменьше и народу тоже, проинструктировал по новому и все прошло гладко.

Оказалось, что “новый отборочный лист” был включен в тест, который проходил на РЦ Энгельс и поскольку никаких отзывов не последовало, то сопровождение посчитало, что все прошло отлично и включило его в плановую установку, которую робот и выполнил, когда смог. Когда причину нашли, то проблему устранили в несколько минут.

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

Минут через пятнадцать на вопрос “как обстановка?” руководитель отдела сопровождения отстучался в аську: “Все нормально. Заходил СН. С …. перешел на имена”.

И уж если вспомнился Сергей Николаевич Галицкий, то в контексте разговора о “владельцах продукта”, мне думается, успех Магнита связан именно с тем, что его собственник и руководитель отлично соответствовал этой роли применительно к торговой сети.

Глава 10 Как бороться с хроническим недостатком ресурсов


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

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

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

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

Казалось бы самый простой путь решения такой задачи – это набрать программистов. Если у бизнеса есть потребность и он “готов за это платить”, то почему бы и нет. Ну или не набрать, а привлечь на аутсорсинг. Давайте быстро наберем или привлечем и решим проблему за день-два.

К сожалению, в разработке так не работает. Это сложно воспринимается, поэтому я обычно привожу два примера. Нужно ли два человека, если требуется забить гвоздь? И если бетону для застывания требуется 28 дней, то как повлияет на это наличие 5 или 10 рабочих.

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

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

Задачу взяли в работу вчера и срок в три недели я обозначил руководителю Департамента транспорта в 3 недели. Расчет прост: неделя на разработку, неделя на тестирование и неделя на гарантированную раскатку обновления по всем торговым точкам. В районе обеда раздался шум в коридоре и ко мне в возбужденном состоянии залетел Галицкий вместе с Директором по транспорту.

– Как три недели? Там же нечего делать!

– А вот так. Разработка, тестирование, раскатка..

– Да я на свободном рынке сейчас найду команду, которая это за 3 дня сделает!

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

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

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

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

Так сколько же программистов нужно держать? Это очень сложный вопрос. В моем понимании, ровно столько сколько вы сможете озадачить и еще немножко. А хороший ИТ-директор, поверьте может озадачить очень много.

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

По-моему опыту программисту для адаптации требуется от месяца до полугода.

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

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

Насколько я знаю, Магнит потом расширил практику взаимодействия с университетом. Я тоже потом, работая и в Донецке и Хабаровске, успешно сотрудничал с местными ВУЗами. Мы проводили совместные мероприятия и на мой взгляд это было взаимовыгодно.

Про аутсорсинг мы уже говорили в главе 7. В части наращивания ресурсов программистов, мой опыт говорит, что это далеко не лучший вариант.

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

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

Очень важным является правильно организовать систему поступления и приоритизации и выполнения заявок.

Крайне позитивным в моей практике стало создание входного фильтра на входе в виде подразделения, которое осуществляло предварительную сортировку и адаптацию заявок.

Оградить программистов от “диких пользователей” – это означает, как минимум, вдвое повысить производительность их работы.

Полезно когда кто-то перед тем как задача попадет непосредственно к программисту:

– рассортирует реальные доработки от инцидентов

– определит имеет ли место реальная ошибка в коде или проблема кроется в каких-то настройках или в данных

– проверит заявку на дублирование с уже имеющимся функционалом, уже существующими заявками и на конфликт интересов с другими подразделениями

– проработает задание с пользователем и переведет его на язык более понятный программистам

– согласует приоритеты выполнения

Это все точно может сделать человек с менее дефицитной квалификацией, чем программист-разработчик.

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

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

Если говорить про доработки, то есть тоже одна хитрость, которая поможет сократить их количество. Не секрет, что работа “на корзину” может составлять от 30 до 70% от всего того, что делают программисты. За этим стоят не только потери связанные с оплатой оказавшегося бесполезным труда, но и очень серьезный демотивирующий фактор. Борьба с этим ведется по разному. Кто-то даже вводит штрафы за неиспользуемые отчеты и программные модули, но это ни к чему хорошему не приводит. Потратили бестолково время на программирование и продолжаем тратить время на бестолковое формирование, “чтобы меня не оштрафовали”. Гораздо более действенной является организация возможности попробовать с помощью Экселя. Оказалось, что наличие даже одного кудесника Экселя, который хорошо владеет всеми тонкостями его использования, включая макросы и VBA, позволяет существенно облегчить труд программистов и сделать счастливыми многих пользователей.

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

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

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

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

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

Глава 11 Как управлять коллективом ИТ-шников и мотивировать программистов?


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

Коллектив ИТ-шников имеет свои особенности, связанные с тем, что их труд имеет большую интеллектуальную составляющую. Залезть в мозги человеку не возможно. Дав одну и ту же задачу двум программистам (если это не примитив на пару строчек кода), вы получите скорее всего два различных варианта решения. Провести полную ревизию результата очень сложно. Если проводить аналогию со строительством то можно сказать, что имеет место огромное количество “скрытых работ”.

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

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

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

Правило первое.

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

Правило второе.

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

Правило третье.

Распорядок дня – это святое. Если ты должен быть там-то в такое-то время, то ты должен быть. Не прийти на согласованную встречу – это неправильно. Не ответить на почту в течение суток – это совсем плохо ( у тебя должно быть предусмотрено время в течении дня).

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

Вернемся к квалификации. Каким образом можно повлиять на квалификацию ИТ-шников?

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

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

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

Мало кто задумывается, но производительность труда программиста, впрочем как и любого офисного работника, во многом зависит от такого навыка. как набор текста на клавиатуре. Оказалось, что овладение навыком слепой печати в двух раскладках способна поднять производительность до 30%. В одной компании мы мотивировали освоение данного умения презентуя сотрудникам дорогую эргономичную клавиатуру при предъявлении соответствующего сертификата. Рекомендую к применению: недорого и действенно.

Оснащение. Профессионал должен иметь профессиональные инструменты. Не стоит экономить на дополнительном мониторе. Производительные компьютеры, недерущие глаза экраны, хорошие клавиатуры – это все понятно. Но бывают иногда не совсем очевидные моменты. Например, когда-то перейдя из одного банка в другой, наш коллектив сразу почувствовал разницу… В КРЕСЛАХ. На предыдущем месте работы у нас были кресла, конструкция которых хорошо держала спину и была продумана для того, чтобы в них можно было нормально отработать полный рабочий день, а посидев пару часов на новых человек начинал чувствовать дискомфорт.

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

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

И теперь мы переходим к самому интересному. К мотивации. И самая больная здесь категория именно программисты.

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

Возникает вопрос: так что же делать?

Нужно ли мотивировать? – Конечно нужно! – Как? – Попробуем разобраться.

Пойдем от истоков. Начнем с теории. Поговорим об осликах. Всем хочется чтобы они бежали быстро.

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

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

– А вы уверены, что ослик вообще может бежать быстрее?

– А точно этот ослик так любит морковку, что будет из-за нее надрываться и показывать сверх результат?

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

Короче, нужно помнить несколько вещей. Постоянно хорошо может бежать только сытый и тренированный ослик. Тренированный потребляет много калорий и его нужно хорошо кормить. Но нужно смотреть, чтобы он не зажрался и не заплыл жиром.

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

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

Итого, чтобы ослики (программисты) хорошо бегали у них должно быть просто хорошее настроение, а для этого необходимо:

– следить чтобы они были сытыми в соответствии с текущими затратами калорий (зарплата должна быть в рынке)

– им должно быть интересно бегать и упряжь не должна создавать дискомфорта (грузить нужно интересными задачами, они должны “строить храм”, они должны быть обеспечены инструментами и условиями труда)

– у них должна быть возможность тренироваться и наращивать результаты (создана система развития и обучения)

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

Стоит понимать, что система мотивации и система оплаты труда – это далеко не одно и тоже. Последнюю я обычно выстраиваю так:

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

Понижение, если не случилось совсем кризисного форс-мажора типа мирового катаклизма, я не рассматриваю.

Плановая стоимость сотрудника делится на две части: окладная и премиальная. Премиальная по умолчанию выплачивается всегда. Она может быть задействована, как дисциплинарное воздействие и все об этом знают. Но, должен сказать, что невыплата подобного рода в моей практике случилась всего один раз. Мое мнение, что держать голодного ослика не имеет никакого смысла – он нормально бежать не будет.

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

Безусловно такой подход многие (особенно персональщики) могут раскритиковать, но я имею за плечами именно такую практику, которая, на мой взгляд достаточно хорошо работала.

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

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

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

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

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

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

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

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

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

– ???

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любой продукт можно улучшать до бесконечности. Всегда можно добавить содержание, а это повлечет изменение сроков. Любимая тема заказчика, это маскировать изменение изначально запрошенной функциональности словом “ошибка”. “Нам вот сейчас поправят ошибку” – только умалчивается, что имеет место не ошибка разработки, а ошибка постановки, которую допустил сам заказчик, упустив некоторые, оказавшиеся существенными детали. Если возникающие новые хотелки влияют на сроки, то Заказчик об это должен знать и это должно быть зафиксировано.

Вообще техническое задание вещь необходимая, но только для начала, так сказать “для затравочки”. Я практически не встречал случаев, когда внутрикорпоративная разработка, которая бы “взлетела”, была выполнена точно в соответствии с первичным ТЗ. В процессе работы меняется понимание, приходят новые идеи. Почему-то, казавшаяся вполне продуманной отрисованная экранная форма оказывается совершенно неудобной, когда ты начинаешь реально по ней тыкать мышкой.

Если настроен сделать хорошо, то стоит сразу быть готовым, что придется переделать несколько раз. Иногда даже проще сделать самому без оглядки на пользователя, потом показать и подстроить.

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

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

Ежедневные обсуждения хода работ при обходах – это те же scrum-meeting, еженедельные совещание – это тоже планирование спринтов. Да, мы не развлекались досками и оценкой производительности, но в условиях внутрикорпоративной разработки – это не факт что является необходимым.

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

У Эрика Риса в книге “Бизнес с нуля” я почерпнул очень интересную мысль (эту книгу полезно прочитать всем руководителям, а ИТ-шным тем более). Внутрикорпоративные проекты – это в большинстве своем стартапы. И для управления ими стоит применять соответствующие методики.

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

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

Глава 14 Про бег


– Работать нужно не 12 часов, а головой!

Стив Джобс


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

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

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

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

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

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

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

Тренировки позволят вам быть всегда в хорошей форме. Читайте, изучайте, следите за технологическими новинками, повышайте свой профессиональный уровень. Как только вы перестанете тренироваться – вы начнете отставать. Мир ИТ очень быстро меняется. В реальном беге NIke придумала кроссовки, дающие прирост 5% к результату. Их правда сразу запретили, но в мире технологий таких запретов ожидать не приходится.

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

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

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

И закончить я хотел бы словами преподавателя кафедры физической культуры Киевского высшего военного инженерного училища связи майора Евдокименко, которыми он вразумлял курсантов в далеком 1988 году:

– Хочешь быть красивым – бегай!

– Хочешь быть сильным – бегай!

– Хочешь быть умным – бегай!

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


Оглавление

  • Предисловие
  • Глава 1 Я ИТ-стайер
  • Глава 2 Что такое ИТ?
  • Глава 3 Кто такие ИТ-шники?
  • Глава 4 Как становятся ИТ-шниками?
  • Глава 5 Как сделать карьеру в ИТ?
  • Глава 6 Путь ИТ-менеджера
  • Глава 7 Как организовать ИТ-структуру компании
  • Глава 8 Что мы строим и как выбрать ИТ-решение?
  • Глава 9 Как создать и развивать свой продукт?
  • Глава 10 Как бороться с хроническим недостатком ресурсов
  • Глава 11 Как управлять коллективом ИТ-шников и мотивировать программистов?
  • Глава 12 Чуть-чуть об информационной безопасности
  • Глава 13 Немного о внутрикорпоративных проектах
  • Глава 14 Про бег