Функциональная и географическая этапность

Divide et impera! (лат)

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

Проблематика тривиальна. Если вы разрабатываете и внедряете сложную систему, то логично этот процесс построить так, чтобы эффект появился как можно быстрее и насколько возможно больший. Я верю в принцип Парето, поскольку ни раз сталкивался с его подтверждениями на практике. Исходя из него, вполне можно выделить 20% функционала системы, который даст 80% успеха. А раз так, пускай этот первичный набор "quick win-ов" и будет вашим первым функциональным этапом.
На второй функциональный этап можно отнести то, что не вошло в первый этап. Вроде бы тоже очень важные функции, но реализация их дорога и/или долга, т.е. это не будет "quick", или же, эффект от внедрения этих функций не будет столь искрометным по сравнению с другими, т.е. они не представляют собой "win".
Помня о том, что совершенство - недостижимо и можно вечно потчевать свой перфекционизм, мы получаем некоторую операционную историю постоянного совершенствования. Сюда же попадает развитие продукта, адресующее изменения в конъюнктуре рынка, вызовы времени и пр. факторы, требующие от продукта продолжать решать поставленные перед ним задачи с наилучшими показателями effectiveness и efficiency не смотря ни на что. Все это, и многое другое, включая плохо просматривающиеся, плохо понимаемые фичи, суть которых станет очевидней после появления практики использования функционала первых двух этапов, - можно отнести на третий этап, практически бесшовно переходящий в Operations.

Аналогичный подход можно применить и в географическом отношении, если вам надо внедрить проект во многих сотнях предприятий, расположенных во многих десятках регионах страны и Мира. Пусть первым этапом будут Пилоты - предприятия/регионы на которых можно собрать все возможные грабли и шишки с минимальными рисками. Скорее всего, внедрение вашей системы на предприятии будет отличаться в зависимости от особенностей предприятия (его технологической инфраструктуры, зрелости operations и т.п.). Поэтому, обычно выделяют "типовые площадки", отражающие все возможные сценарии внедрения/интеграции. Важно, чтобы в этап Пилотов попали площадки каждого типа.
Если в корпорации много дочерних предприятий, то, скорее всего, есть некий рейтинг, составленный по важным для бизнеса корпорации критериям. Это может быть прибыль, имидж, стратегический приоритет - да что угодно, важно, что сливками этого рейтинга являются Ключевые предприятия. Собрав все шишки на Пилотах и тем самым отработав порядок внедрения, можно рассматривать внедрение на Ключевых предприятиях следующим этапом, поскольку окучив их можно получить наибольший эффект от проекта в масштабах всей корпорации. Важно, однако, понимать, что характер разрабатываемой и внедряемой системы может определять внедрение на каких предприятиях даст больший корпоративный эффект. Поэтому, может сложиться так, что вторым приоритетом после Пилотов пойдут и не ключевые предприятия, но это как раз и есть тот самый контекст корпорации, с которым должна работать проектная команда, добиваясь как можно большего эффекта как можно скорее.
Отработав проблемы на Пилотах и добившись наибольшего корпоративного успеха на ключевых (или максимально релевантных проекту) предприятиях, оставшиеся предприятия - третий географический этап.

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

Что изображено на картинке?
I. Внедрение функционала первого приоритета в пилотных регионах/предприятиях.
II. Тираж функционала первого приоритета на Ключевые регионы/предприятия
III. Внедрение функционала второго приоритета там где, внедрен первичный. В остальных регионах/предприятиях – тираж функционала первого приоритета.
IV. В пилотных регионах/предприятиях – внедрение остального функционала. В остальных регионах – тираж функционала второго приоритета
V. Тираж остального функционала во всех оставшихся регионах

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

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

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

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

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

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

 

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

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

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

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

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

Детализация описания конфигурации

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

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

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

Пришел Подрядчик, и уже в рамках проекта на основании потребности, изложенной в ФТТ, он разрабатывает Техническое задание (ТЗ). В целом, под ТЗ нормально понимать детализированное ФТТ, поэтому особенности следующие:
- более технический документ;
- определяет уже из чего будет делаться целевая Система (исходные материалы);
- скорее всего (так и надо делать - это правильная практика!), было проведено какое-то обследование (~понимание среды/условий, уточнение требований из ФТТ), поэтому помимо требований к результату указываются требования к проектированию, причем уже с учетом выбранных исходных материалов;
- степень детализации - максимально возможная - результат и важные моменты в рамках проектирования должны быть учтены до мельчайших потребностей.
Важно: Поскольку ТЗ полностью определяет что должно получиться в результате, а, при грамотном подходе (со стороны Подрядчика), может определить и ключевые моменты проектирования, чтобы не иметь проблем с возможными изменениями потребностей Заказчика по ходу проекта (ведущим к изменению объема) - проектирование следует начинать только после полного согласования ТЗ.


ТЗ является исходным материалом для процесса проектирования, в рамках которого разрабатывается Технический проект (ТПр). ТПр:
- полностью технический документ;
- определяет КАК мы будем делать нашу Систему из выбранных исходных материалов;
- степень детализации ТПр должна быть достаточной для того, чтобы превратить исходные материалы в Систему, полностью соответствующую ТЗ и ФТТ; Фактически под ТПр можно понимать детальный план такого приведения - действительно сначала дешевле поупражняться "на бумаге", а уже потом, все 7 раз отмерив, пойти работать ручищами "на железе".
Будучи результатом раздумий "на бумаге" ТПр - это то, "что хотели" получить. Еще важно, что ТПр - во всех подробностях описывает процесс перевода исходных материалов в желаемую Систему.

Закончив проектирование и написав максимально подробный ТПр можно переходить к разворачиванию\внедрению\настройке Системы, т.е. превращению исходных материалов в нашу Систему, соответствующую ТЗ и ФТТ уже в полях.

Если вы - мудрый гений или данный проект для вас далеко не первое упражнение то ваша пусконаладка пройдет в полном соответствии с ТПр, но, к сожалению (а может и к счастью, ибо без приключений наша жизнь скучна) по ходу могут возникать особенности, поэтому, вполне возможно, что получится не совсем то, что планировалось. Ну, конечно, не так, ибо по-любому надо соответствовать ФТТ и ТЗ, но что касается требований к реализации проекта, частенько "все не так на этот раз...".

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

Как правило, в эксплуатационной документации полезно иметь следующие документы:
- Технический паспорт (ТПс);
- Инструкция пользователя (ИП);
- Инструкция администратора (ИА) - если администраторов несколько может быть несколько ИА для всех возможных групп сопровождения, можно и совместить все эти инструкции в одном документе - тут как удобнее организовать использование этих документов;
- Регламент обеспечения непрерывности бизнеса (РОНБ или BCP-DRP).

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

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

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

РОНБ должен содержать подробненькое описание процедур восстановления из резервных копий и всяческих других применяемых механизмов обеспечения непрерывности. Из РОНБ должно быть однозначно понятно к каким типам несчастья мы (вся группа эксплуатации) готовы и что в этих случаях мы делаем применительно к нашей системы.
На заметку: при приемка подобного документа полезно проводить упражнение по полной симуляции наиболее страшного несчастья - "... а ну-ка давайте грохнем файлы данных БД из-под СУБД и попросим наших админов восстановиться по вашей эксплуатационной документации в заявленные вами 3 часа..." - всегда лучше поупражняться сейчас, почти еще в проекте, чем потом, когда беда придет "на боевом дежурстве".
Еще: если сервис супер-критечен и его падение смерти подобно, то полезно не только заниматься тренировкой админов, но и пользователей (вообще, конечно, BCP-DRP тема обширная и даже не отдельного поста, а целой книги (!), тем более не рассказать ее в абзаце). Например, если у вас есть трейдеры которые должны постоянно торговать вашими продуктами на всяких биржах через Интернет, можно подумать о том, что на период недоступности нужной им ИТ-инфраструктуры их можно отправить домой с ноутом и быстрым мобильным Интернетом или посадить в автобус с теми же ноутами и хорошим wi-fi-ем в салоне и прочими минимальными ИТ-сервисами, и увезти туда, где пока еще спокойно и откуда можно продолжать крутить колеса корпорации (причем, куда везти также должно быть хорошо продумано заранее, чтобы минимизировать необходимость придумывания решения по ходу).
Да, еще момент, можно, в принципе, размазывать РОНБ по инструкциям администраторов и пользователей, но, я вас уверяю, лучше, чтобы в час Х все было под рукой, в одном месте, причем, наличие единого Плана придумали задолго до этого поста (возьмите любой гайд для подготовки, например, к CISSP).

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

И последнее - простой пример.
ФТТ: Бизнес: "Нужна деревянная кукла!"
ТЗ: мы должны получить Буратино из сосны, он должен передвигаться, издавать звуки, "думать", в меру возможности.
ТПр: идем в лес, находим говорящую сосну, вырубаем из нее полено, несем в столяную мастерскую, обрабатываем топором, рубанком, наждаком.... рисуем лицо и все остальное... одеваем на "голову" носок.... отдаем в школу....
ТПс: Буратино, сделан из говорящей сосны, полные ТТХ и т.п.
ИП: играть на шарманке, подпевать....
ИА: царапины зачищать наждаком, глубокие - рубанком, сколы красить, подрисовывать лицо по мере истирания, кормить луком раз в месяц....
РОНБ: утерянные конечности восстанавливаются так-то с использованием остатков говорящей сосны, в случае тяжелых потерь - есть 17 братьев-близнецов, полностью обученных и упакованных аналогичным образом, приводимых в рабочее состояние так-то...

Проектирование и внедрение

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

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

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



(*) То, что я тут пишу - не просто ловкословие. Мне не раз приходилось доделывать красиво спроектированные проекты, чтобы все-таки получить не бумагу, а решение. При этом проект далеко не всегда коррелировал с тем, что написано в проекте, цитата Эйнштейна работает всегда.

Снова о "на коленке"

Очень важно осознавать, что зачастую ключевой характеристикой проекта (под проектом я здесь буду понимать любую деятельность по превращению чего-нибудь менее пригодного, во что-нибудь более пригодное) является скорость появления результата. Современные условия бизнеса таковы, что результат нужен как можно скорее - действительно, ложка хороша к обеду, - никто не готов ждать вечно, поскольку никакое качество результата не покроет столь продолжительное ожидание, причем, далеко не нулева вероятность, что к моменту окончания ожидания уже нужно будет не то, что изначально планировалось, а может и вовсе не нужно. Поэтому я противник мега-коплексных подходов и как-следствие долгих проработок. Проект изначально надо продумать так, чтобы он как можно быстрее давал как можно больше Value, этакие "Quick wins", расположенные в правильном порядке для достижения максимального совокупного эффекта.
В этой связи я считаю вполне нормальным подход реализации решения по частям: сперава автоматизировать наиболее востребованный функционал (который наиболее трудоемок на сейчас, или который в текущей реализации производит наболее неготиное влияние) - такая "заплатка" уже сразу даст ощутемый результат, далее можно уже это решение "докручивать", дорабатывать, тиражировать, в общем, развивать.
Не надо заставлять бизнес ждать, пока вы придумаете супер-мега-комплексный подход\процесс, а затем спроктируете и внедрите решение, которое его полностью автоматизирует, при этом все сразу будет учтено и заработает как надо. Это - абсолютная утопия, так как:
1. все сразу учесть не получится, поскольку новый этап познания, открывает нам границы нашего незнания, иными словами, чтобы понять как оно там на крыше, нужно до крыши добраться, или, что аппетит приходит во время еды,
2. пока вы будете долго строить свое решение, окружение уже несколько раз поменяется, поэтому проекты продолжительностью более года имеют мало практического смысла (конкретно мое мнение, - 6 месяцев должно быть достаточно, чтобы "корова" начала приносить "молоко" - через 6 месяцев от начала проекта, должен появиться результат),
3. весь пост про то, что надо стремиться как можно быстрее давать результат, при таком мега-комплексном подходе, результат будет нескоро, а учитывая пп 1, 2 он может быть и не тот, что ожидали и не применим к новым условиям :)

Каша из топора

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


Итак, я подрядчик на сложный проект, вы - заказчик, для простоты, - некого программного обеспечения. У меня нет ресурсов генерить хорошие привильные идеи, ну, например, у меня нет квалифицированных разрабочиков и вообще штата, а под каждый проект я иду в государственный институт и набираю студентов первого курса за соответствующую плату. В качестве решения я выдаю то, что мне выгоднее (действительно, - это же бизнес!). Теперь уже это ваша головная боль показать мне почему то, что я сделал, нехорошо. Очевидно, что мне выгоднее делать негибкое решение: его делать банально дешевле, к тому же, легкие изменения, которые в случае настраиваемого решения можно было бы выполнить конфигурацией, для вас обернутся необходимостью разработки, на которой, очевидно, я могу заработать. А куда вам деваться, если я уже выбран? Если вы ничего не понимаете и/или не хотите разбираться/думать, вы согласуете мой вариант "наименьших затрат". Если вы разбираетесь в вопросе (хотя бы на уровне фильтрации бреда), вы будете вынуждены тратить время на проработку со мной предлагаемых мною вариантов: объективно доказывать, что они не соответствуют каким-то там стандартам/практикам (просто сказать, что так "плохо" не получится, так как предложение будет воспринято мною как "дополнительное требование", которое "out of scope"), тратить время на детальное объяснение своих требований, поскольку я, прикрываясь словами "наша работа используется во всем мире (!), и только у вас такие требования", буду поначалу "не понимать" все о чем вы меня просите (особенно здорово, если мы с вами банально говорим на разных языках, это - небольшое, но преимущество, опять же мое). В конечном счете ваша деталлизация спустится до уровня работы моего архитектора, и вы сами за него сделаете его работу. Как видите, в любом случае вы в проигрыше. Что плохого для вас:
- вы тратите свои ресурсы. Поскольку очевидно, что это - моя работа, вы их в таком объеме не планировали;
- как бы ни был я плох как подрядчик, в любом случае я более профессионален в предметной области (ибо я все-таки успешен на рынке, иначе вы бы меня не выбрали), а обмануть любителя профессионалу проще;
- свои непрофессиональные решения я буду потом оправдывать вашими же согласованиями.


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

Вы ссылаетесь на требования международных стандартов (вам повезло и свой "здарвый смысл" вы можете объективно подтвердить), я легко обосную вам то, как дорого мне (собственно, вам) дорабатывать мой продукт до общепризнанных "Security in depth" (ибо в depth залазить не хочется, например, студенты которые раньше у меня работали и которых я увлоил после проекта уже бородатые дядьки и покупать их уже отнюдь не дешево) и т.п. В итоге, вы снова вынуждены разбираться в предлагаемых мною компромиссных вариантах.


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


Как же вам со мной бороться? Лучше вам, конечно, меня не выбирать, но как это можно сделать:
1. Я должен выбираться в объективном тендере, исключающем коррупцию.
2. Я должен иметь подтвержденный опыт, иметь в штате нужных вам специалистов с подтвержденными компетенциями.
3. Мои подходы к разработке должны соответствовать имеющимся практикам и стандартам, впрочем как и продукты, которые я делаю.
4. Я не должен быть уникальным в каком-либо виде, должна быть настоящая конкуренция. Идеально, если вы как-то проверите, что я не "договорился" со своими конкурентами. Следствие: берите лучше коробочные варианты, а не заказывайте мне разработку, либо держите своих разработчиков и обспечивайте среди них отсутствие "ключевых" фигур.
5. Четко разделяйте ответственность меня и свою. Контролируйте это разделение постоянно.
6. Четко формируйте свои требования, чтобы они не допускали хоть сколько-нибудь свободного толкования. Четко определите что входит в объем проекта и убедитесь в том, что я с этим согласен.
7. Имейте четкое представление о том, что хотите получить. Будьте уверены, что вашими требованиями это покрывается. Можете нанять какого-нибудь стороннего эксперта, обязательно квалификацией не ниже меня и имеющего аналогичный опыт, который поможет вам сформирвоать требования, покрывающие ваши желания, а так же быть экспертом с вашей стороны.
8. Позаботьтесь о том, чтобы у вас были рычаги давления на меня.


Как это не прискорбно сознавать, бизнес циничен. Нам всем нужно смотреть в корень.

Гибкость и сложность

Где начало того конца, которым оканчивается начало?
Козьма Прутков. Мысли и афоризмы.

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

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

Прежде всего давайте поймем, почему же мы вожделеем гибкость.
1. На момент выбора решения не известно что конкретно хочется. Действительно, аппетит появляется во время еды. Да, я знаю, что во всех книжках написано, что подход такой неправильный и что надо на момент выбора решения знать все, что хочется, но на практике, к сожалению, это так.
2. В России очень трудно прогнозировать. На практике все меняется самым непредполагаемым образом: вчера мы поклонялись коммунистам и были пионерами, сейчас узнали, что коммунисты были нехорошие люди, так как уничтожили духовность.... Как следствие, приходится закладываться на все "случаи жизни" - вместо восседания на одной бочке с порохом, сидеть на двух, а может, и больше, чтобы, в случае взрыва одной, успеть перескочить на следующую.

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

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

ИТ, ИБ и Бизнес. Кто с кем?

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

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

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

User Roles in SAP R/3

I’ve been reviewing a number of projects with SAP R/3 in a company I work for and found what seems to be a very big mistake in user rights planning and implementation. I raised this many times but still have no response from our ‘SAP gurus’, probably because their main task is to finish project and move on or maybe because they’re not experienced enough. I don’t know and it’s not my headache, but I think that the problem I’m going to explain is obvious.

The thing is that each project produces a number of roles, and authorizations (piece of privileges) are spread over these roles. During a test phase these roles are tested either by user without additional roles or by user with roles from the same project. I haven’t seen anybody testing roles from one project together with roles from different project. Unfortunately, SAP has weird system of authorizations – there are authorizations to access Objects, to perform Actions (transactions, programs) etc. So, to perform an action upon an object through specified transaction you have to have authorization for Action and for Object. To deny this action it’s enough not to have privileges for Action or for Object.

When a user has a number of roles, authorizations in these roles are added together, and in the end it’s possible for user to gain more capabilities than she should have. Maybe it is hard to understand, but it is really possible in SAP if you have, for example, authorization for Object in one role and authorization for Action in another.

We may significantly reduce the probability of such ‘authorization summation’ by adding each authorization into role manually but it’s very time-consuming. It’s much more easer to build role from menu or use other automated role-generation tools. If we were too lazy to create roles manually we could test all combination of roles to fix ‘authorization summation’ issue. But it would be very difficult!

Well, I see the only solution in this case – make one role for one user. I know this is not what SAP recommends (I attended "CA940: SAP R/3 Application Security Concept"), but in complicated environment where there are thousands of users and thousands of roles from different projects, to my mind, it is the only solution. This strategy can withstand the following common issues:

• authorization summation – you need to test only one role for one user;
• some employees do more than specified in their job description, and in this case you just add authorizations into one role for that user. To my mind, it’s more secure than add whole additional role never being tested in combination with others that user already has;
• you get more flexibility: if roles in project were developed in connection with organizational structure they wouldn’t fit when organization's structure changes. In "one role–one user" situation – just add new authorizations for users that changed their positions.

The only bad thing here – it is more difficult to quickly finish new projects…

Project Management Fun

Classical picture, found here:

Грустные мысли: эффект отсутствующей плитки.

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

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

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

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

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

Влияние человеческих предубеждений на принятие решений прекрасно описано в эссе Брюса Шнайера Психология безопасности.