Saturday, September 26, 2015

Вовлеченность и ответственность

В очередной раз выслушивал от Заказчиков негодование по поводу пробуксовки проекта и о том, что я недостаточно самоотверженно его толкаю через различные бюрократические процедуры. 
К сожалению, в крупной компании существует масса контролеров и кураторов каждому из которых надо объяснить различные аспекты проекта, причем желательно используя его язык, иначе он не поймет и не согласует, и проект накроется медным тазом. Кто-то воскликнет, что при поддержке "нормального (== с хорошим грейдом) менеджмента" ничего никаким тазом не накроется, однако, на практике технически  не получится каждого клерка пушить "нормальным менеджментом": не получится эскалировать на вице-президента проблемы с каждым закупщиком, контролером-закупщиком, финансистом и пр. контролерами-кураторами у которых есть какие-то инструкции и их задача заключается исключительно в требовании от всех соблюдения этих инструкций и трава тут не расти! Я даже опущу как сложно порой нетехническому экономисту объяснить какие-то технические подробности, которые ему непременно следует узнать, прежде чем что-то согласовать и пропустить в дальнейшие круги общения с другими клерками, курирующих-контролирующих другие формальности. Невольно приходит в голову аморальная мысль, что все эти формальности придуманы только с одной целью, чтобы у кураторов-контролеров было что контролировать.... Но не в этом дело, и бороться с этим надо не указывая клеркам что они неправильно работают, занимаются ерундой и т.п. - это вообще нерабочий вариант, а вовлечением в проект.

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

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

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

 

Friday, September 25, 2015

Вопросы к DLP

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


Может, кому тоже будет полезна.
Исходник от freemind лежит здесь.

Проблема корпоративных облаков

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

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

Отчасти поэтому идея корпоративных облаков плохо приживается на предприятии. Мне самому несколько печально это осознавать, ибо сам являюсь фанатом этой идеи. К сожалению, я не могу предусмотреть весь комплекс "проверок здоровья", которые должен пройти АРМ пользователя, прежде, чем будет безопасно предоставить доступ к тому или иному корпоративному сервису. Особенно сложно, если этот сервис еще отсутствует. Гарантировано, что при попытке реализовать такую инвентаризацию для доступа к какому-либо из своих новых сервисов, я наткнусь на технические ограничения используемой мной системы удаленного доступа (СУД) с NAC-ом внутри или операционной системы на АРМ, и мне надо будет что-то придумывать, или приостанавливать публикацию этого сервиса, пока любимые мною производители СУД и/или клиентской ОС решат мои проблемы.
Другое дело, если я - Гугл, - я использую свои шлюзы СУД, через которые предоставляю доступ к написанным мною сервисам с АРМ внутри которых крутится моя ОС. Я могу проектировать сервисы сразу для работы в "облачном" режиме, а новые "проверки здоровья" в СУД реализовывать самостоятельно, причем в моей клиентской ОС будут заготовлены интерфейсы для удобной и быстрой проверки. 

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