О пользе интуиции

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

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

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

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

Например, на основе глубокого анализа со всесторонним сравнением выбрали одно программное обеспечение вместо другого. Если внедрение закончилось — уже хорошо. Однако никто не сможет сказать, если бы внедрялось конкурентное решение, итог был бы хуже? Просто он был бы другим. Определить бизнес-успех, приписываемый внедренной системе, нередко очень сложно. Слишком много «шума». Например, отлично потрудились другие подразделения, изменилась экономическая ситуация и т. п. и хороший бизнес-результат — это совокупность реализованных или нет решений и работа окружения.

«Среди богатства выбора другой альтернативы нет»

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

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

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

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

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

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

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

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

Аутсорсинг

Это все высокие материи, но даже в простых технических моментах оптимальность принятого решения не столь очевидна. Вот недавно занимался проектом перевода розничных точек компании с интернет-доступа на каналы передачи данных (MPLS). Стоимость решения сходная. По большому счету разница в том, поднимать ли VPN на своем оборудовании, которое нужно еще приобрести и затем его сопровождать (настраивать, решать вопросы в случае отказа и т.п.), либо отдать все на откуп оператору.

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

Опять же при выборе решения нужно учитывать, кто будет заниматься обслуживаем после твоего ухода, который рано или поздно случится. Пожизненный найм скорее вреден для собственного развития и уж точно для самооценки. Он также не особо полезен для компании — велик риск «зашоривания» людей, принимающих решение (ЛПР), что может приводить к застою. Насколько легко передать сопровождение последователю либо аутсорсеру? В идеале, чтобы новый человек для сопровождения был не «семи пядей во лбу». Например, часть вопросов по решению проблем можно переложить на бизнес-сотрудников на местах.

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

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

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

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

Для меня основной минус штатных специалистов — слишком простой и недорогой доступ к квалифицированной рабочей силе в сравнении с внешними спецами. Когда речь идет о создании и поддержке чего-то уникального — это преимущество, способствующее оперативному решению вопросов. Если же речь идет о поддержании базовых сервисов (бизнес-процессов), то легкий доступ к ресурсам превращается в недостаток, поскольку не стимулирует выстраивание процессов и перестройку работы таким образом, чтобы упростить сопровождение. Грубо говоря, когда есть сравнительно недорогой человек, который может оперативно «залатать» проблемы, то он каждый раз будет это делать. Латая в сотый раз, он далеко не всегда захочет что-то менять, чтобы проблема больше не повторилась.

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

Смена работы

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

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

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

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

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

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

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